问题描述
我们正在开发一个移动应用程序（Android和iOS），我们正在使用Firebase进行聊天和其他实时消息。我们使用的是：pre $ firebase-url / user-id /
contacts / child-element
活动/
加入/子元素
创建/子元素
通知/子元素
为了保持我的应用程序数据更新，我执行一个查询，并将一个子侦听器附加到每个第一级别的子级别（或活动的情况下）的用户id分支（联系人，加入，创建，通知）。功能方面，它完美的工作，可以很容易地保持最新的一切，但今天有一个小时的用户测试和电池耗尽相当沉重（对于一个用户应用程序使用约26％的电池，第二多使用），并始终GC收集器经常运行，我的感觉是，firebase连接可能是最大的用户。它是否正确？可能最好只在用户ID分支上有一个子监听器？
任何帮助，将不胜感激。如果需要的话，我会发布一些Android代码。
$ b PS：这是Android版本的应用程序。
[Firebase工程师]一般来说，Firebase听众本身就非常便宜。你可能会发现瓶颈是通过网络传输的数据量。
在上面描述的情况下，听起来好像你正在附加一个监听器 / a ， a / b 和 a / b / c / a 中的监听器捕获了，所以不会导致重复的数据通过连线。 Firebase客户端很聪明，不会复制这些数据。
至于电池，有许多因素可供参考，改变数据，缓慢变化的数据，更多的写入，更少的写入，更多/更少的UI或CPU等等。这可能是一些组合因素，但额外的调试将帮助你缩小罪魁祸首。
We're developing a mobile app (Android and iOS for now) for which we're using Firebase for chat and other real-time messages.
The structure we're using is:
firebase-url/user-id/
contacts/child-element
activities/
joined/child-element
created/child-element
notifications/child-element
In order to keep my app data updated I execute a query and attach a child listener to each first level child(or second in the case of activities) of the user-id branch (contacts, joined, created, notifications). Functional wise it works perfectly and can easily keep everything up to date, but had a one hour user test today and the battery drain was pretty heavy (for one user the app was using around 26% of the battery, second most used) and always the GC collector runs quite often, my feeling is that the firebase connection might be the biggest user. Is this correct? Might it be better to have a child listener only on the user-id branch?
Any help would be appreciated. I will post some of the Android code if needed.
PS: This was for the Android version of the app.
[Engineer at Firebase] In general, Firebase listeners are very inexpensive in their own right. Where you might start to see bottlenecks are with the amount of data transferred over the wire.
In the case you described above, it sounds like you're attaching a listener to /a, a/b, and a/b/c, which will not cause duplicate data going over the wire, because all nested data is already captured by the listener on /a. The Firebase client is smart about not duplicating this data.
As for the battery, there are a lot of factors to contribute, but try profiling different combinations of behaviors between quickly-changing data, slowly-changing data, more writes, fewer writes, more / less UI or CPU, etc. It's likely some combination of factors, but additional debugging will help you narrow down the culprit.
这篇关于Firebase多个孩子的听众的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！