Firebase多个儿童听众

我们正在开发一款移动应用（目前为Android和iOS），我们正在使用Firebase进行聊天和其他实时消息。Firebase多个儿童听众

我们正在使用的结构是：

firebase-url/user-id/ 
       contacts/child-element 
       activities/ 
          joined/child-element 
          created/child-element 
       notifications/child-element

为了保持我的应用程序的数据来更新我执行查询并（在活动的情况下，或第二）附加一个孩子监听到每个第一级子用户ID分支（联系人，加入，创建，通知）。功能方面，它可以很好地工作，并且可以很容易地保持一切都是最新的，但是今天有一个小时的用户测试，并且电池消耗非常大（对于一个用户，该应用使用约26％的电池，其次使用的是） GC收集器运行频率很高，我的感觉是，火力点连接可能是最大的用户。它是否正确？只有在用户标识分支上有一个子监听器可能会更好？

任何帮助，将不胜感激。如果需要，我会发布一些Android代码。

PS：这是Android版本的应用程序。

来源

2015-02-04 redspider

我无法回答这个问题，因为我真的不知道肯定。但是从我的研究来看，Firebase听众相对便宜。我会考虑在'user-id'引用上放置一个'ChildEventListener'，并从那里测试你的用法。我想知道你发现了什么，因为我目前正在开发一个主要由firebase驱动的应用程序。 –

[Firebase工程师]一般来说，Firebase听众本身的价格非常低廉。您可能会发现瓶颈是通过电线传输的数据量。

在您上述的情况下，这听起来像您要附加一个监听器/a，a/b和a/b/c，这不会导致重复数据通过线路，因为所有的嵌套的数据已经被捕获的听众/a。 Firebase客户端很聪明，不会复制这些数据。

至于电池，有很多因素可供参考，但可以尝试分析快速变化的数据，缓慢变化的数据，更多的写入，更少的写入，更多/更少的UI或CPU等之间的不同行为组合。这可能是一些因素的组合，但额外的调试将帮助你缩小罪魁祸首。

来源

2015-02-05 20:17:23

听众人数与电池寿命之间是否存在任何直接关系，忽略数据传输量？ –

Firebase多个儿童听众

回答

相关问题