The popular ideas are as follows:
1. Let the service not kill the dead. The service's Onstartcommand returns Start_sticky, while OnDestroy inside calls StartService to start itself.
2. Turn service from background to front. Valid before Android 2.0, with Setforeground (true).
3. Let a process not be killed by the system's low memory killer (such as the data caching process, or the status monitoring process, or the remote service process). add android:persistent= "true" into the <application> sections in your androidmanifest.xml. Remember, this can not be abused, the system with this service,app a lot, the whole system is finished. The experiment found that even if this attribute is set, the application cannot be restarted after force kill, it should only be immune to the low memory killer.
4. Improve service priority. In the Androidmanifest.xml file, the Intent-filter can be set to the highest priority by Android:priority = "1000", preventing the service from being reclaimed by the system.
5. Timed wake-up via Alarmmanager. (Valid before Android 4.0, the app that was killed after 4.0 cannot wake the reference http://www.android100.org/html/201305/06/2430.html).
6. When the app is upgraded, restart the service even if the user does not open the app. Because Action_package_restarted,alarmmanager is sent as a system service when the app is upgraded, this event is accepted and then StartService.
7. Let the service boot up. But now a lot of mobile phones will prohibit boot boot.
8. Daemon process. Reference http://www.bubuko.com/infodetail-474019.html
How to make the service as viable as possible with the Android development pit series