The phrase "running continuously" makes it sound like they are doing something... but they aren't: they are blocked reading on a socket. The only time they would run is if they receive information, which is exactly when they would run anyway (as they got a notification). The difference in battery usage would essentially be down to subtle effects caused by the private memory of that process (which might be negligible) not being able to be used as a cache to make some other process more effective. The only reason this would matter is if the processes are forced to wake up occasionally to actively send some kind of keepalive on the socket (which would be an arbitrary requirement caused by the network), which still frankly would not necessarily use much battery if the OS does intelligent gathering of wakeups from multiple processes (like, it would exist and be measurable, but seems strange to me to be something to care about as the phone is probably already waking up every now and then to do other stuff Google wants). I mean, if the notification comes in and the app wouldn't have to wake up to process it normally (which might prevent paging some executable code in from flash) and the notification itself could be delayed into some kind of batch, then maybe? Apple actually does do some of this kind of stuff on iOS: I would bet Google doesn't.
GCM/FCM will delay low priority notifications, in order to batch as many together as possible.
On top of that, the cell networks don't allow keeping a socket open for more than a few minutes without sending keepalive packets. Unlike on desktop, keeping a socket open isn't "free" on mobile.
Waking up the cell radio has a significant penalty on battery life.
So you just batch the keepalives, like the old Nokias were doing. Reaching 1 month long battery lifes with Jabber on.
Absolutely no difference 1 having to send 1 keepalive every 5 minutes than 30.
This is just a subversion of basic networking in order to centralize everything through a single provider and as usual the users are trained to see it as necessary without questioning it.
> On top of that, the cell networks don't allow keeping a socket open for more than a few minutes without sending keepalive packets. Unlike on desktop, keeping a socket open isn't "free" on mobile.
That's right. And it should work as advertised in the documentation.
Anyway, I was responding to the "cell networks don't allow" part of your comment. Cell networks don't have a say in what I do at IP/TCP layer.
They literally said that cell networks don't allow it without the keep alive. You quoted it and said they were wrong because... you can use a keep alive. I'm confused as to what you're correcting.
There are collaborations between mobile network providers and push notification providers to get these sockets special-cased. I.e., they won't need keep-alive at any regular interval. So the radio can actually get layer-1 pings (like, when you're called, or get an SMS) for push notifications.
The main issue with what you're mentioning is usually the fact that only Apple and Google servers tend to be whitelisted on telco routers for long polling connections. Trying to keep long-running HTTP connections for everyone else tends to be extremely hard on battery life since telcos can kill of connections even as often as 2 - 5 minutes. Powering up the main core and radio so often will make your phone hardly last 12 hours.
Are you kidding me, my old Android 6.0 unupdated S7 can easily top days when idle and polling radio only.
The main battery killer is, and always has been, the screen, followed by CPU in high power state.
