android - Firebase Android : slow "join" using many listeners, 似乎与文档相矛盾

Question

实现一个Android+Firebase应用，多对多关系:User <-> Widget(Widget可以共享给多个用户)。

注意事项:

1. 列出用户拥有的所有小部件。
2. 用户只能看到共享给他/她的小部件。
3. 能够查看共享给定 Widget 的所有用户。
4. 单个 Widget 可以由具有同等权利的多个用户拥有/管理(修改 Widget 并更改它的共享对象)。类似于 Google 云端硬盘向特定用户共享的方式。

实现抓取(连接式)的方法之一是遵循以下建议:https://www.firebase.com/docs/android/guide/structuring-data.html ("Joining Flattened Data "):

// fetch a list of Mary's groups
ref.child("users/mchen/groups").addChildEventListener(new ChildEventListener() {
  @Override
  public void onChildAdded(DataSnapshot snapshot, String previousChildKey) {
    // for each group, fetch the name and print it
    String groupKey = snapshot.getKey();
    ref.child("groups/" + groupKey + "/name").addListenerForSingleValueEvent(new ValueEventListener() {
      @Override
      public void onDataChange(DataSnapshot snapshot) {
        System.out.println("Mary is a member of this group: " + snapshot.getValue());
      }
      @Override
      public void onCancelled(FirebaseError firebaseError) {
        // ignore
      }
    });
  }
});

这提出了一个问题，即拥有大量听众是否会对性能产生负面影响，或者是否会达到一些硬性限制。

但我们在文档中得到了保证:

Is it really okay to look up each record individually? Yes. The Firebase protocol uses web sockets, and the client libraries do a great deal of internal optimization of incoming and outgoing requests. Until we get into tens of thousands of records, this approach is perfectly reasonable. In fact, the time required to download the data (i.e. the byte count) eclipses any other concerns regarding connection overhead.

但是，可以肯定的是，我制作了一个比较 2 种方法的小测试应用程序:

1. 附上很多ValueEventListener -s 一个接一个地添加到所有小部件(根据上面提到的 Firebase 的“结构化数据”指南)
2. 附加一个 ChildEventListener到托管所有小部件的节点(需要在一个节点下充分构建用户的小部件)

在 4 种不同的设备和 Android 版本 (4.x - 5.x) 上进行了测试。 Firebase 库:'com.firebase:firebase-client-android:2.3.1' .
在第一种方法中，性能相当令人失望。我一直看到大约 15-100 个事件/秒。最低的性能，~15 个事件/秒经常出现，所以看起来应该认真对待。在这种情况下，如果用户有 100 个小部件，则需要大约 6 秒的时间来获取有关所有小部件的信息(例如滚动列表)。这太慢了。对于 1000 个 Widget，通常需要多达 40 秒才能由不同的监听器获取它们的信息。太慢了。

在第二种方法中，我观察到 200-3000 个事件/秒。因此比第一种方法快 15-30 倍!
所以看起来像 Firebase 文档中的保证 [...] Until we get into tens of thousands of records, this approach is perfectly reasonable [...]考虑到它的工作速度，它并不是很准确。

鉴于所有这些，我有 4 个相互关联的问题。

1. 任何人都可以根据自己的经验/基准来证实/反驳我的发现吗？也欢迎提供有关其他平台的信息，因为我们计划在多个平台上开发此应用程序。
2. 性能如此显着差异的原因可能是什么？也许是内部数据结构？
3. 有没有办法在保持第一个(多监听器)方法的同时提高性能？
4. 是否应该完全放弃多监听器方法，转而采用 Firebase+Udacity 教程中介绍的非规范化多副本方法(“userLists”节点中的 https://github.com/udacity/ShoppingListPlusPlus - 他们保留每个用户的购物 list 副本信息)？我在另一个问题中询问这种方法的含义 - Firebase: structuring data via per-user copies? Risk of data corruption? .

欢迎任何其他提示/考虑。TIA。

Answer 1

“这提出了一个问题，即拥有大量听众是否会对性能产生负面影响，或者是否会达到一些硬性限制。”

Firebase Realtime database 的答案与新的 Cloud Firestore database 相同。

无论您有多少连接或有多少监听器，重要的是您在客户端处理多少数据。

因此，如果您有 100 个监听器，监听 100 位的小数据，这将变得非常便宜，但如果这些监听器中的每一个都在监听不断变化的数据流，那么对于客户端来说，这将变得非常昂贵处理得很快。

而且由于移动设备非常不同，所以很难知道多少是太多。因此，如果您针对的是倾向于拥有非常高端手机的美国用户，那么如果我们针对的是手机性能低得多的国家/地区，那将是一个不同的限制。

因此，如果您根据 Activity 的生命周期相应地删除它们，那么您可以拥有任意数量的监听器，如前所述 here .

还有另一种方法，使用 addListenerForSingleValueEvent。在这种情况下，无需删除监听器。