So to summarize, to save battery all notifications on Android (since two versions ago) have to go through a single notification service (rather than each app having the option of continuously running in the background and maintaining a connection with its own notification service). Recently Google killed their GCM notifications service in favor of Firebase Cloud Messaging, which (unlike GCM) unfortunately doesn't hav…
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.