swift - Firebase 太慢而无法加载基于图 block 的游戏

Question

我正在使用 swift 和 Firebase 为 iOS 构建一个基于 2d tile 的游戏。因为世界很大，所以我设计了它，以便我只订阅屏幕上的图块。也就是说，我没有为所有 10,000x10,000 个磁贴添加监听器，而是将它们添加到屏幕上的磁贴中。当玩家移动时，我取消注册旧的监听器并注册新的监听器。我在屏幕边缘添加了一些缓冲区，希望所有内容在屏幕上移动时都能充分加载。不幸的是，Firebase 通常有足够大的滞后，以至于这种策略根本不起作用。在次优的互联网连接上，有可能继续走进“未加载的世界”，有时需要几秒钟才能加载丢失的图块。

不过，事情就是这样:同一连接和同一设备上的其他 MMO iOS 游戏运行良好。这不是一个可怕的联系。这让我怀疑我的实现或 Firebase 本身有问题。

从根本上说，每次我迈出一步时，我都在等待大约 20 个图块的“加载一次”事件。一个步骤大约需要 1/4 秒，所以我每秒从 Firebase 请求大约 100 个项目。不过，我想不出更好的方法。 Firebase 文档表明这应该不是问题，因为它都是一个套接字连接。我可以将对象“存储”到 10x10 块中，这意味着我会订阅更少的对象，但这在总数据传输方面也会更加浪费。如果socket连接真的被优化了，总的数据传输应该是唯一的瓶颈，这意味着这种策略是错误的。

编辑

这是一个视频，展示了它是如何工作的。缓冲区大小已减少到 -1 ，以便您可以轻松看到屏幕边缘和瓷砖加载和卸载。视频快结束时，延迟来了，我徘徊在空虚中。我打开另一个游戏，它几乎立即加载。 http://forevermaze.inzania.com/videos/FirebaseLag.mov (n.b.，我在屏幕再次加载之前结束了录制。它永远不会加载失败，所以并不是代码无法工作。这纯粹是滞后。)

这是我用来加载图块的代码。每个图块调用一次。正如我所说，这意味着每一步并行调用这段代码大约 20 次。所有其他应用程序都以良好的速度运行，没有延迟。我在东京使用具有 LTE 连接的 MiFi，所以它是一个可靠的连接。

  /**
   * Given a path to a firebase object, get the snapshot with a timeout.
   */
  static func loadSnapshot(firebasePath: String!) -> Promise<FDataSnapshot?> {
    let (promise, fulfill, _) = Promise<FDataSnapshot?>.pendingPromise()
    let connection = Firebase(url: Config.firebaseUrl + firebasePath)
    connection.observeSingleEventOfType(.Value, withBlock: { snapshot in
      if !promise.resolved {
        fulfill(snapshot)
      }
    })
    after(Config.timeout).then { () -> Void in
      if !promise.resolved {
        DDLogWarn("[TIMEOUT] [FIREBASE-READ] \(firebasePath)")
        fulfill(nil)
        //reject(Errors.network)
      }
    }
    return promise
  }

磁贴位于 [ROOT]/tiles/[X]x[Y] .大多数图块包含的数据很少，但如果该图块上有对象(即其他玩家)，则会存储这些对象。这是 Firebase 的屏幕截图:


编辑2

根据请求，我非常简单地重新创建了这个问题。这是一个 100 行 XCTestCase类(class): http://forevermaze.com/code/LagTests.swift

用法:

将文件放入您的 Swift 项目(它应该是独立的，只需要 Firebase)

更改 firebaseUrl 的值到您的根 URL(即 https://MyProject.firebaseio.com )

运行 testSetupDatabase()函数测试一次以设置数据库的初始状态

运行 testWalking()功能来测试延迟。这是主要的测试。如果任何图块加载时间超过 2 秒，它将失败。

我已经在几个不同的连接上尝试过这个测试。一流的办公室连接没有问题，但即使是高端 LTE 或 MiFi 连接也会失败。 2 seconds已经是一个很长的超时时间，因为这意味着我需要一个 10 tile缓冲区(0.2 秒 * 10 块 = 2 秒)。这是我连接到 LTE 连接时的一些输出，显示加载图块需要近 10 秒 (!!): error: -[ForeverMazeTests.LagTests testWalking] : XCTAssertTrue failed - Tile 2x20 took 9.50058007240295

Answer 1

我运行了一些测试，当我通过 3G 连接进行测试时，加载在 15-20 秒内完成。通过我的常规连接需要 1-2 秒，因此差异可能纯粹基于带宽。

我将您的测试用例重写为 JavaScript 版本，因为我很难弄清楚发生了什么。在这里找到我的:http://jsbin.com/dijiba/edit?js,console

var ref = new Firebase(URL);
var tilesPerStep = 20;
var stepsToTake = 100;

function testWalking() {
  var startTime = Date.now();
  var promises = [];
  for (var x=0; x < stepsToTake; x++) {
    promises.push(testStep(x));
  }
  Promise.all(promises).then(function() {
    console.log('All '+promises.length+' steps done in '+(Date.now()-startTime)+'ms');
  });
}

function testStep(x) {
  var result = new Promise(function(resolve, reject){
    var tiles = ref.child("/tiles_test");
    var loading = 0;
    var startTime = Date.now();
    console.log('Start loading step '+x);

    for (var y=0; y < tilesPerStep; y++) {
      loading ++;
      tiles.child(x+'x'+y).once('value', function(snapshot) {
        var time = Date.now() - startTime;
        loading--;
        if (loading === 0) {
          console.log('Step '+x+' took '+(Date.now()-startTime)+'ms');
          resolve(Date.now() - startTime);
        }
      });
    }
  });
  return result;
}

testWalking();

最大的区别是我不会延迟开始任何加载，并且我不会因为特定的磁贴而失败。我认为最后一点是您的测试失败的原因。

所有来自 Firebase 的加载都是异步发生的，但所有请求都通过相同的连接。当您开始加载时，您正在排队很多请求。这个时间被“尚未完成的先前请求”所扭曲。

这是一个只有 10 个步骤的测试运行示例:

"Start loading step 0"
"Start loading step 1"
"Start loading step 2"
"Start loading step 3"
"Start loading step 4"
"Start loading step 5"
"Start loading step 6"
"Start loading step 7"
"Start loading step 8"
"Start loading step 9"
"Step 0 took 7930ms"
"Step 1 took 7929ms"
"Step 2 took 7948ms"
"Step 3 took 8594ms"
"Step 4 took 8669ms"
"Step 5 took 9141ms"
"Step 6 took 9851ms"
"Step 7 took 10365ms"
"Step 8 took 10425ms"
"Step 9 took 11520ms"
"All 10 steps done in 11579ms"

您可能会注意到，每个步骤所花费的时间加起来并不等于所有步骤所花费的时间。本质上，当管道中仍有请求时，您正在启动每个请求。这是加载这些项目的最有效方式，但这确实意味着您需要以不同方式衡量性能。

基本上所有步骤 开始 几乎同时。然后您等待第一个响应(在上述情况下包括建立从客户端到正确 Firebase 服务器的 WebSocket 连接)，然后响应以合理的时间间隔出现(假设每步有 20 个请求)。

所有这些都非常有趣，但它当然不能解决您的问题。我建议您将数据建模为屏幕大小的存储桶。因此，不要将每个图块分开，而是将每 10x10 个图块存储在“存储桶”中。您将减少每个单独请求的开销，并且每 10 个步骤最多只需要请求一个存储桶。

更新

我很确定我们只是在调试您的基准测试方法的多个工件。如果我将代码更新为:

func testWalking() {
    let expectation = expectationWithDescription("Load tiles")
    let maxTime = self.timeLimit + self.stepTime * Double(stepsToTake)

    let startTime = NSDate().timeIntervalSince1970

    for (var x=0; x<stepsToTake; x++) {
        let delay = Double(x) * stepTime
        let data = ["x":x, "ex": expectation]
        stepsRemaining++
        NSTimer.scheduledTimerWithTimeInterval(0, target: self, selector: Selector("testStep:"), userInfo: data, repeats: false)
    }
    waitForExpectationsWithTimeout(maxTime) { error in
        let time = NSDate().timeIntervalSince1970 - startTime
        print("Completed loading after \(time)")
        if error != nil {
            print("Error: \(error!.localizedDescription)")
        }
    }
}

/**
* Helper function to test a single step (executes `tilesPerStep` number of tile loads)
*/
func testStep(timer : NSTimer) {
    let tiles = Firebase(url: firebaseUrl).childByAppendingPath("/tiles_test")
    let data = timer.userInfo as! Dictionary<String, AnyObject>
    let x = data["x"] as! Int
    let expectation = data["ex"] as! XCTestExpectation
    var loading = 0
    print("Start loading \(x)")

    for (var y=0; y<tilesPerStep; y++) {
        loading++
        tiles.childByAppendingPath("\(x)x\(y)").observeSingleEventOfType(.Value, withBlock: { snapshot in
            loading--
            if loading == 0 {
                print("Done loading \(x)")
                self.stepsRemaining--
                if self.stepsRemaining == 0 {
                    expectation.fulfill()
                }
            }
        })
    }
}

它在高速网络上在不到 2 秒的时间内完成整个加载，在 3G 上需要 15 到 25 秒。

但我建议的建模水平高于每个瓷砖的水平。