Battery Drain

[nurps]

Kept the webclient active a whole day, at the end of it the device was kept awake over 8h. That makes Threema with 22% the most energy hungry app at the moment on my phone.

Compared to the 0.5% that Threema uses without webclient or Whatsapp uses (WITH active webclient).

[lgrahl]

So, once you reach...

[PeerConnectionHelper] No more local ICE candidates

... the CPU load goes down immediately? That would make some sense (even though CPU load is still too high for my taste).

Also I don't see more STUN packets wireshark during the high cpu phase than after it stops.

Thanks, so it's not the packets that trigger the CPU load. @dbrgn Maybe you can check if there's some remarkable code in the app that could possibly be some kind of busy loop. It could just as well be Google's code but I guess it's better to rule it out.

I also tried using chrome instead of firefox and turning of ipv6 on the phone, both solve the issue.

My experience tells me that this is just a coincidence but it should be easy to check. :)

[yeahnope]

So, once you reach...

[PeerConnectionHelper] No more local ICE candidates

... the CPU load goes down immediately? That would make some sense (even though CPU load is still too high for my taste).

No, the messages appear ~2-5 seconds after entering the password of the session, while the cpu load stays high for further ~25-55 seconds. Unfortunately I did not notice any js console messages or change in packets that happened right when the cpu load went down.

I also tried using chrome instead of firefox and turning of ipv6 on the phone, both solve the issue.

My experience tells me that this is just a coincidence but it should be easy to check. :)

Sorry, for the confusion. I accidentaly wrote the opposite of what I meant to say. I meant to say neither solve the issue (edited the post).

[claudemartin]

There's still a lot of drain. I often just keep the tab open and some hours later the battery is drained. Even when I'm not actually doing anything in.

[lgrahl]

AFAIK this subject hasn't been touched so far, so this is to be expected.

[ovalseven8]

I'm really not sure if Threema should further rely on the massive WebRTC code base for the connection between smartphone and browser. Using a custom protocol that is specialized for Threema's need is worth thinking about, at least. While @lgrahl explained above that adjustments on WebRTC are possible, I wonder if it's worth. Having an own lightweight and efficient protocol ("do one thing and to it well") not only provides more independence from WebRTC/browser support, but also better auditability.

[lgrahl]

@ovalseven8 WebRTC is the only way to do P2P in the browser at the moment. Furthermore, the WebRTC people have an upcoming discussion about what use cases we have for WebRTC next version. And I'll certainly add the use case of long-term connections to the list where there's a stronger focus on low CPU usage, low network activity and low battery usage.

My opinion on this matter hasn't changed, though. The WebRTC implementations of the app (and the browsers) may require debugging and polishing but the underlying protocols aren't inherently bad for this purpose. The main problem is that this is an unusual use case and there are only a handful of people actually working on data channel implementations.

[dbrgn]

@ovalseven8 by the way, @lgrahl is one of them :) https://github.com/rawrtc/rawrtc/

[ovalseven8]

@lgrahl Could not Threema Web use WebWorkers/websockets for the own protocol to do the P2P connection?

And I'll certainly add the use case of long-term connections to the list where there's a stronger focus on low CPU usage, low network activity and low battery usage.

Oh, please. :+1: But until this lands in master it will probably take years, or are there concrete plans? In case there's a GitHub issue, give me the link and I'll give you a thumbs up. :smile:

@ovalseven8 by the way, @lgrahl is one of them :) https://github.com/rawrtc/rawrtc/

Yeah, I know. Perhaps Threema can use rawrtc someday? Or what are the plans now for Threema to tackle this HUGE problem?

Edit: I think WebAssembly could also help here and help with the overall performance issues too ... and because @dbrgn is a Rust dev, I mean, that's super precondition. :smiley_cat:

[lgrahl]

Could not Threema Web use WebWorkers/websockets for the own protocol to do the P2P connection?

WebSockets P2P is not possible. Not even if the app side takes the server role (plaintext WS is not possible since web.threema.ch is TLS-protected and no way to issue a certificate the browser would accept). WebRTC has no support for Web Workers as of today but there is demand for it (see https://github.com/w3c/webrtc-pc/issues/230) and this project would at least slightly benefit from that.

In case there's a GitHub issue, give me the link and I'll give you a thumbs up. :smile:

No GH issue but you can follow the mailing list: https://lists.w3.org/Archives/Public/public-webrtc/

Yeah, I know. Perhaps Threema can use rawrtc someday? Or what are the plans now for Threema to tackle this HUGE problem?

It's unlikely you will get an official answer but let me tell you I have a notepad with lots of ideas in my drawer.

@dbrgn and I regularly chat about WebAssembly and Rust, too. :wink:

[ovalseven8]

@dbrgn and I regularly chat about WebAssembly and Rust, too. :wink:

Are there any plans with WebAssembly? :)

[lgrahl]

Let's finally close this in favour of #498. The design choice has been made. We will drop the permanent background connection requirement and then see how it goes from there.

[ovalseven8]

@dbrgn @lgrahl While this issue is about the battery drain on the phone, which will hopefully improve with #498, I found an interesting article about the efficiency of web pages. Apple has apparently released a new Web Inspector with some cool features. Just thought to let you know. :smile: As I am not owning an Apple device, I've not run those tests but perhaps it's interesting to you. ;-)

https://webkit.org/blog/8970/how-web-content-can-affect-power-usage/