The operation should not be continued when the android background is locked.

Android is a very open platform that allows us to develop applications running in the background and rely on TCP persistent connections to receive message pushing from servers. However, it is widely criticized for its power consumption. If developers, especially those who use IM applications, do not understand the underlying Android mechanism, the applications may become the killer of the standby battery.

Android phones have two processors: application processor (AP) and baseband processor (BP ). AP is an ARM-based Processor used to run Linux and Android systems. BP is used to run real-time operating systems (RTOs) and the communication protocol stack runs on BP's RTOS. For non-call time, the energy consumption of BP is basically about 5mA, while for AP, as long as it is not sleep, the energy consumption is at least 50mA, and the graphics operation will be higher. In addition, the power consumption of LCD is about 100mA, And wifi is about 100mA. Generally, when the mobile phone is in standby mode, the AP, LCD, and WiFi are all in sleep state, and the code of the android application will also stop running.

Android provides the wake
The lock API enables the application to block the AP from hibernation through code (IOS and WP7 do not have such a thing ). Abuse wake without understanding the intent of Android designers
The lock API stops the AP from sleep for a long time for its program to work normally in the background, and the consequences are quite serious.

First, there is no need to worry that the AP sleep will cause messages not to be pushed. The communication protocol stack runs on BP. Once a data packet is received, BP will wake up the AP and wake up enough time for the AP to execute code to complete the processing of the received data packet. When other connectivity events are triggered, the AP is also awakened. The only problem is how the program executes the logic of sending heartbeat packets to the server. You obviously cannot rely on AP for heartbeat timing. Alarm provided by Android
Manager is used to solve this problem. Alarm runs on BP and wakes up the AP to execute the program code when triggered. So what is the use of the wake lock API? For example, the heartbeat packet from the request to the response, for example, the key logic execution process such as password verification during reconnection, requires wake lock to protect. Once a key logic is successfully executed, the wake lock should be released immediately. The heartbeat interval should not be too short. At least 10 minutes later.

The server should not push TCP packets to the client even if nothing happens. When the client is running in the background, it is best to push a package only when the client must immediately display the content in the status bar, and other data must be cached, waiting for the client to actively request when it enters the foreground, or you can add the heartbeat Request Response to the client. The client must wake up the AP to process the push every time it pushes the push. This is easy to say, but as a backend TCP persistent link application, the server may be able to save time in some logic design and cannot suppress the impulse to immediately push to the client.