thedylanarts Played with the background settings to make it check every 30 seconds. This destroyed my battery, so it is not a good option. Also, it still seemed to be delayed, which is annoying for an instant messenger.
A well implemented push notification service can deliver notifications instantly, and will have no detectable impact on battery life. The problem is that so many people try to make push notifications, but do things very wrong. For instance, polling a server every second is definitely going to kill your battery.
The correct implementation for push notifications is going to use a long-running TCP connection from a service running on the phone, to a server somewhere on the internet. There are protocols that have been developed for this specific purpose, such as Server Sent Events (SSE), which can be handled by a simple PHP script on the server side, and an SSE-capable HTTP library on the client side, such as okhttp3.sse.
Now a "connection", contrary to images that may be conjured up when trying to picture it, isn't like a physical connection (rope or pipe), and it doesn't take any activity to maintain except at long periodic intervals. Its an instruction given to ROUTERS in between the client and the server, so that they know where to send data they receive from one meant for the other. Once the route has been established, the two sides can just go to sleep and wait for incoming data. In the case of SSE, the data all flows from server to client. So when the server sends data to the client, it hands it off to a router in that connection, and that router passes it on to the next one, and eventually some router passes it to the client itself. The client is just sitting there waiting, and the router says "hey, I've got some data for you, here it is!". When that data arrives in the client's network hardware, it sends a wakeup interrupt to the CPU, allowing the driver to receive the data and pass it along to the listening process. In the case of Android, the listening process should create a wakelock, handle the data (notify the user), and terminate the wakelock. At this point, it can go back to sleep and wait for the next message.
Now its important to emphasize here, that the network hardware is responsible for waking the CPU up when the data packet comes in, and that the OS will keep the CPU awake long enough for the listening process to create its own wakelock for handling the data. There is no need to use timers and alarms and crap to wake things up and keep checking anything.