进程保活

一 、问：什么是进程保活？

答：进程保活就是进程永远存在内存中，是杀不死的，就算杀死了也会有办法重新启动起来，其实这些并不是流氓手段，很多情况下，如果你想给你的用户提供服务，就必须有一个进程常驻着，便于在特定的时候做一些特定的事情，比如广播接受者，他就不支持静态注册，也就是说如果我们想接受屏幕开关启动的广播，必须要在进程中动态注册，这个时候如果没有一个常驻的进程，锁屏业务就无法正常的为用户展开服务。

二、问：进程是怎么死掉的呢？

答：其实进程被杀死的原因，一方面是人为的，二、可能被第三方应用杀死，如杀敌软件等。

三、问：Android进程的优先级？

答：

  1、前台进程 （Foreground process）：用户当前 *** 作所在的进程，当内存不足以承担前台进程的使用，才有可能回收

  2、可见进程（Visible process）:没有任何前台组件，但是仍然会影响屏幕上所见内容，他是一种极为重要的进程，除非为了维持前台进程，因内存不足，有可能会回收掉可见进程，否则系统是不会回收可见进程。

  3、服务进程（Service process）:他与用户所见的内容是没有直接关联，但是他们通常执行一些用户关心的 *** 作，比如说在后台获取网络数据，后台播放音乐，后台进行一些数据计算等。被杀死的原因：也是为了

  支持前台进程和可见进程，因内存不足情况下才会被回收。

  4、后台进程（BaclGround process）:对用户的体验没有直接的影响，用户可以随时终止他们，这个进程是为了供给上面三个进程来使用的，通常在后台进程运行着很多 *** 作，他们保存在一个列表当中，为了确保用户最近查看Activit的进程最后一个被终止，他是一个LRU算法，

  5、空进程（Empty process） :保存这个进程的唯一目的就是用来做缓存，以缩短下次在运行组件所需的启动时间，为了使系统总体的资源在进程缓存和内存底层之间保持平衡。它是不包括任何组件的进程

四、问：Android进程的回收策略？

答：Android进程的回收策略主要是通过Low memory killer机制来完成的。

  Low memory killer：通过一些比较复杂的评分机制，对进程进行打分，然后讲分数的进程判定为bad进程，杀死并释放内存。Low memory killer是定时进行检查的，它主要是通过进程的OOM_ODJ来判断进程的优先级。当OOM_ODJ的值越小，进程的优先级越高，而OOM_ODJ越不会去回收。反之就会被回收。

  注意：Low memory killer和out memory不一样的地方：out memory机制只有当系统内存不足的时候才会启动检查，而Low memory killer是定时进行检查的，它主要是通过进程的OOM_ODJ来判断进程的优先级。

五、问：进程保活方案？

答：Android进程的回收策略主要是通过Low memory killer机制来完成的。

  1、利用系统广播拉活，在发生系统事件的时候，系统会发出相应的广播，

    详情查看：>

(以极光推送为例)

*** 作：从后台应用列表划除应用

结果：只干掉了UI进程，remote进程没有干掉。

所以推送服务正常运作。

重启手机，推送服务正常运作。

判断是，由于能够捕获到开机监听，其他带有极光SDK的应用做了开机自启动，然后极光SDK再互相启动手机里所有带有极光SDK的服务。

于是自己的应用即使没有做开机自启动推送服务，推送服务也可以正常运作。极光SDK互相拉起。

*** 作：从后台应用列表划除应用

结果：UI进程，remote进程都被干掉了，所有包名下的服务都被干掉，包括前台服务。干干净净。

开机监听无法检测到。

微信那些主流APP已经在小米白名单里，跟系统进程一样开机就存在了。

*** 作：从后台应用列表划除应用

结果：UI进程，remote进程都被干掉了，所有包名下的服务都被干掉，包括前台服务。干干净净。

开机监听无法检测到。

微信那些主流APP已经在小米白名单里，跟系统进程一样开机就存在了。

除非能像微信、QQ等大牌应用获取厂商支持，默认添加进白名单，否则其他应用在用户主动杀死应用后（在后台应用列表中，滑动删除应用），都无法存活，包括推送子进程。

当然，像NEXUS，LG，索尼这类不是本土品牌的手机，则可以存活，原因是本土厂商对手机系统做了严格的限制。你懂的，本土应用太过流氓，后台服务，互相保活，开机唤醒等各种骚 *** 作使得手机性能急剧下降，为了提高用户体验，让手机更具性价比，而为之。

在用户没有主动杀死应用的情况下，提高进程的优先级，让应用不被系统主动回收。进程参数oom_score_adj（oom_adj）标记了进程优先级，数字越小优先级越高，越难被系统回收。

前台进程>可见进程>服务进程>后台进程>空进程

如何提高进程优先级可自行google

使用厂商自家的推送服务。

也就是说，你要支持华为用户，那么就接入华为推送；你要支持小米用户，那么就接入小米推送。

信鸽推送可以减少接入多个厂商的工作量，可以了解其SDK文档。（截止目前，信鸽支持的第三方厂商，有华为、小米、魅族；OPPO刚出了自家的推送服务，信鸽还没有；VIVO压根没有自家的推送服务）

1控制onStartCommand函数的返回值。

我对这个函数的理解是：当服务被异常终止时，是否重启服务

有些文章里面在用这个做保活时，修改的是flag，在我实际测试中是无效。有效的做法是直接返回参数。另外默认的flags值为0，是START_STICKY_COMPATIBILITY。如下：

[java] view plain copy

@Override

public int onStartCommand(Intent intent, int flags, int startId) {

// TODO Auto-generated method stub

return START_STICKY;

//return superonStartCommand(intent, flags, startId);

}

测试结果：

魅族的机子：无效，不管默认还是修改参数，在DDMS里面直接结束进程后都不会重启服务。

其它三台机子（9100没测）：默认参数的情况下就会重启服务，return START_STICKY 会重启，return START_NOT_STICKY 不会重启。

其它：1用360一键清理，或者360超级ROOT的手机优化，会杀死进程，过会儿还是会重启，只是会慢很多，大概是在排队重启服务。

2一次测试完后确保服务重启后，执行了onStartCommand函数。

2在service 的onDestory里面重启服务

这个在所有能触发onDestory的情况下都是有效的。4台测试机都测试过。直接startService 或者发送广播重启都可以 。

但能触发onDestory的情况，我不知道内存回收会不会触发。另外两种情况（2，3）是不触发的。我的测试方法是在“设置”-》应用管理-》正在运行-》停止服务。（这个是正常停止服务，会触发onDestory，所以上面的onStartCommand效果不会触发。）

3提高服务的优先级

这个主要是针对第一种kill服务的情况，内存回收机制。由于这个测试比较难搭建。360清理什么把后台的进程都杀的，体现不出优先级这样的概念。我的建议是能提高就提高。下面例几种。

通知--前台service

创建一个通知使自己成为前台service

测试结果：

360一键清理和手机优化，不会把该service结束掉。

对于后台保护：华为G730不结束service，魅族和华为TL00H都会结束service。

通知栏的保活效果还是可以的，一般的应用要求基本能满足了。

若有root权限：

android:persistent="true",并放入system/app中

测试结果：效果一般，三星9100上用360等清理工具杀不掉进程，在华为G730上没什么效果（这个测试跟onStartCommand有点干扰）

4守护进程

双服务

360会同时杀掉两个服务，分两个apk也一样。

native守护进程

360不会杀掉native的守护进程，但在魅族和华为TL00H中待机一段时间后还是会被杀掉。

结论和待续

1一般的应用添加到后台保护进程后，改个onStartCommand返回值，再加个通知。基本上大部分都能保活了。

2双服务我觉得没有native守护进程来的好，虽然360，微信什么的都有几个进程服务，但如果不添加到后台保活的话，效果一样不能保活，也会进入停止状态。

3但是360手机助手会创建双natice守护进程做相互的看守。存活的效果会高一点点。“没添加到后台保活”一般只会杀一次，（魅族是屏幕关闭后5分钟，华为TL00H是屏幕关闭时）

查看 >

一直以来，使用广播进行Android进程的保活就是一种常规的保活方法，本着用事实说话的原则，我做了一个实验：

我在5台不同品牌的手机上重复了相同的实验，结果一致。由此，似乎可以得出结论——广播保活不靠谱。当然如果这个实验就这么结束了，那也太短了，男人可不能短，接着看。

后来我看到了这篇文章 论Android应用进程长存的可行性 ,作者几乎介绍了所有已知的进程保活方法，让我打开眼界，不过引起我注意的其实是下面这段话：

我突然就想到，应用程序管理器中的“强制停止”功能，会不会默认添加了“STOPPED”状态呢，所以导致广播失效呢？

于是我又进行了一次实验：

以上几步实验可以表明：

至此得出的结论是：

广播保活还是比较靠谱的，毕竟一般用户不会去“强制停止”，虽然我一开始也误以为是结束其下所有进程的意思。。。

其实“强制停止”的英语是“Force Stop”，如果了解STOPPED状态的人，可能会立刻就明白这是做什么用的了。后来我百度“强制停止”的时候，也发现了有人分析过强制停止对广播的影响。不过如果没有接触过STOPPED概念的人，或者没有在开发中遇到相关的坑的人，可能很难想到“强制停止”其实并不只是杀进程，所以也就不会去百度相关的资料了，可见误解甚至是一知半解是多么的可怕。

我们做开发工作的，不但要在遇到问题的时候能够解决问题，还应该在各个方面多积累，在遇到问题的时候才能能立刻找到方向。总之一句话：多读书！！！

以上就是关于进程保活全部的内容，包括:进程保活、android 友盟消息推送 如何保活、android推送保活实验到结论等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！