Android进程保活的常用方法

进程保活和去保活，一直是一个热门的讨论话题，先看一下保活方法

方法1：APP内部提升优先级

Perceptible(用户可以感受到其运行的(如后台运行的music playback)，
1)在服务的oncreate添加 startForeground(1, new Notification()); （这种需要常驻通知，如mtkloger、music等）
2)还有另外一种方法，就是am.setProcessForeground/setProcessImportant(mForegroundToken, pid, true)直接设置其是前台的)（这个不会有通知，Android S需要SET_PROCESS_LIMIT权限）
Persistent(系统预置应用 + android:persistent=“true”) 常驻进程，优先级比前台还高，一般不建议

方法2：针对adj的调整（系统）

computeOomAdjLSP的最后面修改
adj = ***;//修改adj
adjType = “***”;//修改adjType
// keep it out of the cached vaues.
state.setCurAdj(psr.modifyRawOomAdj(adj));

方法3：不让系统kill掉（系统）

1. lmkd里面加入拦截，不杀死某个应用
2. 系统API forcestop、kill加入拦截
3. Process.kill**等sendSignal中加入拦截、或者更底层的拦截

方法4：依赖关系保活（系统或者app都可以使用, Android上Foreground/Visible等高优先级进程比较多就是由于这个导致）

1. 服务依赖，如（android S上gms meida provider方式，注意调用者是系统进程(也可以是app，不过情况会复杂一点，先说简单的)）
   （如果带有BIND_IMPORTANT，则会变成Persistent Service的级别，如果不带BIND_IMPORTANT，一般处于Visible级别）
   mContext.bindServiceAsUser(new Intent().setComponent(name), mServiceConnection, Context.BIND_AUTO_CREATE | Context.BIND_IMPORTANT, mHandlerThread.getThreadHandler(), UserHandle.of(mUserId))
2. provider依赖，一般情况下，provider依赖都不是unstable非稳定的，也就是依赖结束后会释放关系。不过也有很多例外
   => 如系统只调用acquireProvider，不去releaseProvider,此时稳定引用stable计数不为0 （如果是系统调用，则app是Foreground;如果是别的进程调用，则情况会复杂一点）
   => 如系统查询query了某个app的数据库，故意不调用Cursor的close方法（和上面acquireProvider是一样的表现）
   => 如果uid=1000的内置应用，其provider被引用后，链接不会释放（stable计数是1000） （情况和1类似，优先级跟调用provider的进程有关系）
   //frameworks/base/services/core/java/com/android/server/am/ContentProviderRecord.java
   noReleaseNeeded = (uid == 0 || uid == Process.SYSTEM_UID)
   && (_name == null || !“com.android.settings”.equals(_name.getPackageName()));

方法5：APP互相拉起保活

守护进程，不停监控保活对象是否存在，不存在则互启动