My original: http://blog.csdn.net/brycegao321/article/details/52312030
There is a picture of the truth, pro-Test hammer T2, Huawei Mate8 mobile phone kill process can be self-starting, I set the self-start time interval of 500ms (just for testing).
650) this.width=650; "src=" http://img.blog.csdn.net/20160825102131689 "/> 650" this.width=650; "src=" http:// img.blog.csdn.net/20160825204320387 "/>
the first thing to be clear is the concept of keepalive:
1, non-Android core processes (such as Com.android.phone) can be killed;
2, keepalive can not really ensure that the app process is not dead, but can be killed immediately after the start;
The Android system is categorized according to the priority of the process:
1. Foreground processes (Forgroud process): Top activity (executed Onresume), a service that binds to the activity that the user is interacting with, and a startforground function called in the service The broadcastreceiver of the OnReceive function is being executed.
2. Visible process: Activity that is obscured by the dialog, executes the OnPause, has a service bound to the activity, but the activity is obscured, such as pressing the Home key, and performing the OnStop.
3. Service process: There is a running service, but there is no 1/2 feature.
4. The background process (Background processes) does not have a running service, only the invisible activity, that is, activity executes the OnStop function.
5. Empty process, no process with Android 4 large components.
according to the Android design, the app can only improve its own process priority, reduce the probability of being killed.
We are more concerned about how the process is pulled up after being killed, there are several methods:
1, registered static Broadcastreceiver, monitoring system broadcast;
2. Start a service and overwrite the Onstartcommand function of the services and return to Service.start_sticky. The usefulness is to be pulled up by the system at some later time after being recycled by the GC, and the egg is not what we want.
3. Use native process to live, Android5.0 the following good, in the Android5.0 above the waste, so not elaborate.
4. Use the Jobsheduler mechanism to keep alive, when God closed a door (the native process was abandoned), opened a window (Jobsheduler replaced the native process mode).
5. The family of apps, such as all Baidu apps, launches one of the apps, and it pulls up other apps from Baidu. The practice is very rogue, but also the manufacturers and users detest.
public class myjobservice extends jobservice { @Override public void oncreate () { Super.oncreate (); startjobsheduler (); } public void startjobsheduler () { try { int id = 1; JobInfo.Builder Builder = new jobinfo.builder (id, new componentname (GetPackageName (), MyJobService.class.getName () ); Builder.setperiodic (+); //interval 500 milliseconds call onstartjob function, 500 just to verify JobScheduler jobScheduler = (Jobscheduler) This.getsystemservice (context.job_scheduler_ SERVICE); int ret = Jobscheduler.schedule (Builder.build ()); } catch ( EXCEPTION EX) { Ex.printstacktrace (); } } @Override public boolean onstartjob (jobparameters jobparameters) { log.d ("Brycegao", "onStartJob Alive "); return false; } @Override pubLic boolean onstopjob (jobparameters jobparameters) {   LOG.D ("Brycegao", "onstopjob alive"); return false; }}
<service android:name= ". Myjobservice "android:permission=" Android.permission.BIND_JOB_SERVICE "/>
My public number, welcome attention, let us grow together 650) this.width=650; "alt=" laughs "src=" http://static.blog.csdn.net/xheditor/xheditor_emot/default/ Laugh.gif "/>
650) this.width=650; "src=" http://img.blog.csdn.net/20160824153944826 "/>
Android5.0 the correct posture for the app process to survive