Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RiotX consumes huge amounts of battery #536

Closed
Half-Shot opened this issue Sep 2, 2019 · 35 comments
Closed

RiotX consumes huge amounts of battery #536

Half-Shot opened this issue Sep 2, 2019 · 35 comments
Assignees

Comments

@Half-Shot
Copy link
Member

Half-Shot commented Sep 2, 2019

I can't point my finger at any one reason for this, but anecdotally I've found RiotX to use a large amount of power compared to it's usage time. @anoadragon453 and @babolivier can confirm this as well.

For example, for around a hour of reported screen time, RiotX had taken 25% of the total power draw for that day.

(I am using the gplay build)

@anoadragon453
Copy link
Member

Yep, made my phone only last 1/3rd of a day.

@Cadair
Copy link
Contributor

Cadair commented Sep 2, 2019

I have not noticed this (using the F-Droid build)

@babolivier
Copy link

Can confirm, on my other phone installing and starting using RiotX made my battery life drop from around a day to less than 10h.

@Half-Shot
Copy link
Member Author

I looked again after matrix sync this morning and it's used 6% of my charge so far today. This seems to be related to some background tasks the app is running, because a lot of the charge seems to be drained while the phone is idle.

The google play version isn't trying to sync, is it?

@lpulley
Copy link

lpulley commented Sep 12, 2019

My RiotX installation (from Google Play Store on Galaxy S8 running Android Pie) has been perfectly fine on battery life. 0.7% since about four hours ago, with very light usage.

@bmarty bmarty added this to the Stabilization1 milestone Sep 18, 2019
@bmarty
Copy link
Member

bmarty commented Sep 18, 2019

We just have fixed an issue (in v0.5.0 release): Riot was syncing continuously, even if when in background, when the network was back (ex: when exiting airplane mode).
It should be better now.

@bmarty bmarty self-assigned this Sep 20, 2019
@progserega
Copy link

After update to 0.5.0-dev [10000500] (G-07fca092) RiotX begin "eat" 30% of battery.
This is occur after bad network connectivity. And continuous after network resume to good connectivity.
Screenshot_20190925-082623
Screenshot_20190925-082630

@bmarty bmarty modified the milestones: Stabilization1, Stabilization2 Oct 9, 2019
@shumvgolove
Copy link

shumvgolove commented Nov 15, 2019

Considering the fact that RiotX should replace old Riot™ we need to deal with this problem ASAP.

I am running pure LineageOS without GCM (or recently FCM?) and RiotX consumes at least ~30% of my battrry life (not to mention that this issue directly related to notifications, for example I receiving them with ~8 minutes delay or not receiving at all) that prevents me using RiotX in general. This is disaster for mobile phones. There is similar issues dating from 2016 that people experienced and still not fixed even at the end of 2019:

Taking into account that Matrix is good and actively developing IM alternative to XMPP (which lacks development for clients, not to mention XEP's, that you should check for both server and client), Signal (that requires phone number, centralized and not available in F-Droid (see this good article)) and Wire (which has shaddy Privacy Policy (see this)) we need to implement proper syncing solution which fixes both notification and battery issues.

Like what was mentioned in #3152 I think we should implement SSE (Server Sent Events), considering that PR for SSE is ready for review – matrix-doc#2108 and matrix-doc#2024 for reference.

@fbruetting
Copy link

Is this still true or can this be closed? I never experienced an energy issue in the last three/four months.

@babolivier
Copy link

RiotX still represents around 80% of my phone's battery usage. I'm running the dev build, though, which I know has more checks and works more than the mainline version, but I'd be surprised if that amounted to such a huge increase in battery usage.

@Atrate
Copy link

Atrate commented Feb 22, 2020

Still draining a lot of battery, especially without Google Play Services

@shumvgolove
Copy link

shumvgolove commented Feb 23, 2020

@fbruetting Are you using RiotX with FCM/Google Play Services? Because if yes, then you should consider reading my previous message.

Also, I've found that in order to receive messages from RiotX I need to keep the application open in the background and never close it. Some applications from F-Droid (Linphone, Telegram) use persistent notification hack that will always appear in notifications bar (this will insure that app will always be running in foreground no matter what [1]), so I could close them and receive messages/calls nevertheless. Could be this changed in RiotX to match this behaviour?

IMHO, I still consider SSE best option available (it uses small amount of battery life and handles (pushing/recieving) messages very well). [2]

[1] Telegram push notification issue
[2] Article about Tutanota implementing SSE

@Samonitari
Copy link

Samonitari commented Feb 24, 2020

I can also verify the issue.
I am quite surprised that without GCM (the devil needs/likes to change its name👹) a quality notification system is still missing.

As a note, TutanotA also solved it with SSE. Until then, I have to use the Play version with E2E rooms, because 3000mAh is not enough for busy day otherwise.

Edit: @shumvgolove sorry, didn't realize your link is the same as mine, your link title didn't mention tutanota.

@shumvgolove
Copy link

shumvgolove commented Feb 25, 2020

@Samonitari Fixed the title to clarify things. Also, no problem mate.

@progserega
Copy link

progserega commented Mar 10, 2020

I setup batterystat,wait and get situation with large battery use by RiotX (0.17-gplay):
Screenshot_20200310-145410
Screenshot_20200310-145405
Screenshot_20200310-145354
Screenshot_20200310-145333
Screenshot_20200310-145242 png
Screenshot_20200310-145217 png
Screenshot_20200310-145206

Sorry for big images :-(

@shadow00
Copy link

Any update on this? Currently on F-Droid release 0.19.0 on a non-rooted Android (so I have Google Play Services) and still experiencing massive battery drain (7% - 261 mAh - in just over an hour, until I forcibly stopped the app).

Is going through the Play Store the only option for now?

@promi
Copy link

promi commented Jun 6, 2020

This is a major blocker for me and why I switched back to Riot. RiotX just uses too much battery.

In Riot I have set the sync interval to 600 seconds so it only syncs every 10 minutes, my battery lasts for several days that way. With RiotX I have to recharge every day.

@vibrys
Copy link

vibrys commented Jun 12, 2020

the same for me. syncing every 10, 20 or even 60 minutes would be fine for most cases. Did You consider adding configuration option to customize it?

@maisiliym
Copy link

maisiliym commented Jul 4, 2020

Matrix devs dont even understand their own demographics; they're building an 'open system' except that you need google to use it ... this is fucked!

edit: Conversations has push, so what the fuck guys!?

@Samonitari
Copy link

Matrix devs dont even understand their own demographics; they're building an 'open system' except that you need google to use it ... this is fucked!

edit: Conversations has push, so what the fuck guys!?

Well, I am unhappy as well, but:
YOU don't understand it seems, and you are also unneccesarily offensive.

Techincally you don't HAVE to use google, although if on Android (you can use other platforms...) you choose to do so, it will drain a lot more. And the sad thing is, most app on Android use Google servers and its services. I use MicroG and I know how many of my apps do... If it is an IM app, then it is the ONLY straightforward way, and Google actively makes it less and less feasible for any alternative method (inhibiting running non-system background apps without notification, etc.). So if you want to blame somebody, that is your place.

Conversations keeps its own connection to the server, and F-Droid version of Riot is a bit more clumsy true. But the ideal way is something like openpush, if Conversation's devs would contribute to a generalized solution like that, now that would be fantastic!

@maisiliym

This comment has been minimized.

@progserega
Copy link

progserega commented Jul 8, 2020

At some days ago I get such situation:

  1. RiotX use more battery
  2. I go to setttings->programms->RiotX and press "stop"
  3. I go app list and start RiotX again - drain battery was stopped.
  4. Then I was send "crash report" with logs about this.

You can see at first screenshot as at ~16:00 I stop RiotX service and start it again - and drain battery was stopped:
Screenshot_20200706-165818
Screenshot_20200706-165822

@progserega
Copy link

progserega commented Jul 22, 2020

May be I found when element eat battery:

  1. bad/down network
  2. user send message/image
  3. it can not send by element - freeze in his cache (such as State event to describe bridge constraints for messages matrix-org/matrix-spec#389 )
  4. network up
  5. element try send unsended messages - and it is unsuccesfull - this repeat again and again. Element in battery stat use CPU and battery drain

And I was send logs from phone at this moment.

@chris-dk
Copy link

Element/RiotX and the whole Matrix project is super cool. I really appreciate all the work done for this project. 👍

Unfortunately Element/RiotX is always number one battery consumer of my LineageOS smartphone.

As already mentioned I would also think Server Sent Events (SSE) is the best available solution after using Conversations for quite some time, which uses SSE. Nearly no battery consumption compared to Element and still the notifications are super fast and reliable. Hopefully Synapse will integrate SSE 🤞

@MurzNN
Copy link
Contributor

MurzNN commented Jul 29, 2020

From changelog of v1.0.2:

Sending events is now retried only 3 times, so we avoid blocking the sending queue too long.

So will be good to recheck this issue in this version.

@progserega
Copy link

From changelog of v1.0.2:

Sending events is now retried only 3 times, so we avoid blocking the sending queue too long.

So will be good to recheck this issue in this version.

In new version of element messages offten sended success (at bad network), but I found bug: message freeze at down of messages window and I was can not remove it, or send.
And this time I found, that element begin again drain battery.

@progserega
Copy link

Freeze image on down message window:
Screenshot_20200803-181530~01
All new messages added upper of this freezes image.

@babolivier
Copy link

@progserega This is likely a separate bug (and the battery impact is probably more of a common symptom), can you open a separate issue about it please?

@progserega
Copy link

@progserega This is likely a separate bug (and the battery impact is probably more of a common symptom), can you open a separate issue about it please?

Okey

@progserega
Copy link

progserega commented Aug 5, 2020

today new element (1.0.3 Google servises)
Eat 30% of battery (more then 1 hour - it was use CPU), when phone was in sleep mode (end of graph):
Screenshot_20200805-211311
Screenshot_20200805-211235
Screenshot_20200805-211229

@progserega
Copy link

@progserega This is likely a separate bug (and the battery impact is probably more of a common symptom), can you open a separate issue about it please?

matrix-org/matrix-spec-proposals#1884

@BillCarsonFr
Copy link
Member

BillCarsonFr commented Aug 10, 2020

Hello, just sharing some results of investigations here.
A note, that this is hard to measure because element activity will depend a lot of your account.

I'd prefer to separate this issue in two issues, one for the playstore version and another for the f-droid version.

Regarding fdroid, element will try to sync every 30s, so depending on your account it could sync every 30s even if you have no notifications (and if you have a lof rooms it could sync a lot of data), and do that until you have no more battery

For playstore, if you have no push (notification) the app will never sync. But if you have a setup with lot's of rooms with high priority notifications settings, the app could sync permanently

The fdroid mechanism could be improved by adding more settings, or checking for other API to check for notification and only sync when needed (hopefully the light polling would be less battery heavy). Old riot had a 'battery optimized' mode, that will slow the sync period when battery gets lower or phone stayed still (doze), element android does not have it yet

I have run tests with old riot and element android, for a single sync with one message, the energy/cpu profiles for old riot and element are quite similar; the Memory usage is quite different though, but should not impact battery.

@BillCarsonFr
Copy link
Member

May be I found when element eat battery:

1. bad/down network

2. user send message/image

3. it can not send by element - freeze in his cache (such as matrix-org/matrix-spec#389 )

4. network up

5. element try send unsended messages - and it is unsuccesfull - this repeat again and again. Element in battery stat use CPU and battery drain

And I was send logs from phone at this moment.

Regargin resending, there are two retries mecahnism involved:

  • One in Okhttp stack (aggressivly retries on slow/unreliable connection until success)
  • One in the sdk (Work manager retry), there is a backoff policy to delay more and more in case of failure.

With this PR #1889 the behavior has been modified a bit; now big upload requests will only be one shot (mainly to protect your data plan and not battery)

@BillCarsonFr
Copy link
Member

I will close this issue, as the original issue was due to a bug on early riotX that was syncing continuously in background.
Please fell free to open new issue for fdroid

@BillCarsonFr
Copy link
Member

See #2055 for work on fdroid version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests