Firebase 对于基于图块的游戏加载速度太慢

Question

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

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

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

编辑

这是一个展示其工作原理的视频。缓冲区大小已减小到-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 的屏幕截图：

edit2

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

用法：

1. 将文件拖放到您的 Swift 项目中（它应该是独立的，只需要 Firebase）
2. 将 firebaseUrl 的值更改为您的根 URL（即 https://MyProject.firebaseio.com）
3. 运行一次testSetupDatabase() 函数测试以设置数据库的初始状态
4. 运行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 秒。

但我建议的建模水平不只是单个图块。