Firebase Android：使用许多侦听器缓慢“加入”,似乎与文档相矛盾

概述实施具有多对多关系的 Android Firebase应用：用户< - >窗口小部件(窗口小部件可以共享给多个用户). 注意事项： >列出用户拥有的所有小部件. >用户只能看到与他/她共享的小部件. >能够看到共享给定Widget的所有用户. >单个Widget可由具有相同权限的多个用户拥有/管理(修改Widget并更改为共享对象).与Google云端硬盘与特定用户共享的方式类似. 实现获取(jo 实施具有多对多关系的 Android Firebase应用：用户< - >窗口小部件(窗口小部件可以共享给多个用户).

注意事项：

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

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

// fetch a List of Mary's groupsref.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.

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

>将多个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.

解决方法 “这引发了一个问题,即是否会有很多听众对性能产生负面影响,或者可能会遇到一些限制.”

Firebase实时数据库的答案与新的Cloud Firestore数据库的答案相同.

无论您拥有多少连接或拥有多少监听器,您在客户端处理的数据量都很重要.

所以如果你有100个听众,听100比特的小数据,这已经变得相当便宜但如果每个听众都在收听不断变化的数据流,那对于客户来说非常昂贵很快.

而且由于移动设备非常不同,很难知道有多少是太多.因此,如果您针对的是那些倾向于使用非常高端手机的美国用户,那么如果我们针对手机功耗较低的国家/地区定位,这将是一个不同的限制.

因此,如果您根据活动的生命周期删除它们,您可以拥有任意数量的侦听器,如here所示.

还有另一种方法,使用addListenerForSingleValueEvent.在这种情况下,不需要删除监听器.

总结

以上是内存溢出为你收集整理的Firebase Android：使用许多侦听器缓慢“加入”,似乎与文档相矛盾全部内容，希望文章能够帮你解决Firebase Android：使用许多侦听器缓慢“加入”,似乎与文档相矛盾所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。