注意事项：

>列出用户拥有的所有小部件.
>用户只能看到与他/她共享的小部件.
>能够看到共享给定Widget的所有用户.
>单个Widget可由具有相同权限的多个用户拥有/管理(修改Widget并更改为共享对象).与Google云端硬盘与特定用户共享的方式类似.

实现获取(join-style)的方法之一是使用这个建议：https://www.firebase.com/docs/android/guide/structuring-data.html(“加入扁平化数据”)：

// 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 @R_403_103@ to download the data (i.e. the byte count) eclipses any other concerns regarding connection overhead.

但是,可以肯定的是,我做了一个小测试应用程序,比较了两种方法：

>将多个ValueEventListener-s逐个附加到所有小部件(根据上面提到的Firebase的“结构化数据”指南)
>将单个ChildEventListener附加到托管所有窗口小部件的节点(需要在一个节点下充分构建用户窗口小部件)

测试了4种不同的设备和Android版本(4.x – 5.x). Firebase lib：’com.firebase：firebase-client-android：2.3.1′.
在第一种方法中,表现相当令人失望.
我一直看到~15-100个事件/秒.最低的性能,大约15个事件/ s经常出现,所以看起来应该认真对待.
在这种情况下,如果用户有100个小部件,则需要大约6秒来获取有关所有小部件的信息(例如滚动列表).这太慢了.
使用1000个小部件,通过单独的侦听器获取其信息通常需要多达40秒.方式太慢了.

在第二种方法中,我观察到200-3000个事件/秒.因此比第一种方法快15-30倍！
所以看起来像Firebase doc中的保证[…]直到我们进入成千上万的记录,这种方法完全合理[…]考虑到它的工作速度有多慢是不准确的.

鉴于这一切,我有4个相互关联的问题.

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

任何其他提示/考虑因素欢迎.
TIA.