6

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.

Ravi Shankar Bharti
  • 8,922
  • 5
  • 28
  • 52
redspider
  • 401
  • 1
  • 6
  • 21
  • I can't answer this, cause I honestly don't know for sure. But from my research, the Firebase listeners are relatively inexpensive. I would consider putting a `ChildEventListener` on the `user-id` reference and test your usage from there. I would like to know what you discover with this, cause I am currently developing an app that is heavily driven by firebase. – Chad Bingham Feb 04 '15 at 20:19

1 Answers1

7

[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.

Rob DiMarco
  • 13,226
  • 1
  • 43
  • 55
  • 4
    is there any direct relationship between the number of listeners and battery life, ignoring the amount of data transfer? – Sushant Garg May 24 '17 at 12:11