Android--进程常驻

最新保活方法：Service之startForegroundService方式，亲测有效；使用方法百度，太多了，例如：https://blog.csdn.net/shift_wwx/article/details/82496447  ，https://www.cnblogs.com/renhui/p/8575299.html

如果不想要显示通知栏，使用stopForeground(true);来实现

网上大致有以下几种方法：

1、将Service设置为前台进程
2、在service的onStartCommand方法里返回 STATR_STICK
3、添加Manifest文件属性值为android:persistent=“true”
4、覆写Service的onDestroy方法
5、添加广播监听android.intent.action.USER_PRESENT事件以及其他一些可以允许的事件
6、服务互相绑定
7、设置闹钟，定时唤醒
8、账户同步，定时唤醒

经测试，都能被轻松干掉，后来在github上找到大神写的，测试成功，分享一下：

 

这是一个轻量级的库，配置几行代码，就可以实现在android上实现进程常驻，也就是在系统强杀下，以及360获取root权限下，clean master获取root权限下都无法杀死进程

支持系统2.3到6.0

支持大部分设备，包括三星，华为，oppo，nexus，魅族等等

可以简单对开机广播进行保护

 

github地址：

https://github.com/Marswin/MarsDaemon

 

需要注意的是要站在自启管理开启自启权限

 

首先下载LibMarsdaemon，作为module（File->New->import module）导入项目，添加依赖(File->Project Structure->library,选择LibMarsdaemon增加)，然后修改代码部分

 

 

自己曾经也在这个问题上伤过脑经，前几日刚好有一个北京的哥们在QQ说在做IM类的项目，问我进程保活如何处理比较恰当，决定去总结一下，网上搜索一下进程常驻的方案好多好多，但是很多的方案都是不靠谱的或者不是最好的，结合很多资料，今天总结一下Android进程保活的一些方案，都附有完整的实现源码，有些可能你已经知道，但是有些你可能是第一次听说，（1像素Activity，前台服务，账号同步，Jobscheduler,相互唤醒，系统服务捆绑，如果你都了解了，请忽略）经过多方面的验证，Android系统中在没有白名单的情况下做一个任何情况下都不被杀死的应用是基本不可能的，但是我们可以做到我们的应用基本不被杀死，如果杀死可以马上满血复活，原谅我讲的特别含蓄，毕竟现在的技术防不胜防啊，不死应用还是可能的。

有几个问题需要思考，系统为什么会杀掉进程，杀的为什么是我的进程，这是按照什么标准来选择的，是一次性干掉多个进程，还是一个接着一个杀，保活套路一堆，如何进行进程保活才是比较恰当……如果这些问题你还还存在，或许这篇文章可以解答。

一、进程初步了解

每一个Android应用启动后至少对应一个进程，有的是多个进程，而且主流应用中多个进程的应用比例较大

1、如何查看进程解基本信息

对于任何一个进程，我们都可以通过adb shell ps|grep 的方式来查看它的基本信息

值	解释
u0_a16	USER 进程当前用户
3881	进程ID
1223	进程的父进程ID
873024	进程的虚拟内存大小
37108	实际驻留”在内存中”的内存大小
com.wangjing.processlive	进程名

2、进程划分

Android中的进程跟封建社会一样，分了三流九等，Android系统把进程的划为了如下几种（重要性从高到低），网上多位大神都详细总结过（备注：严格来说是划分了6种）。

2.1、前台进程(Foreground process)

场景： 
- 某个进程持有一个正在与用户交互的Activity并且该Activity正处于resume的状态。 
- 某个进程持有一个Service，并且该Service与用户正在交互的Activity绑定。 
- 某个进程持有一个Service，并且该Service调用startForeground()方法使之位于前台运行。 
- 某个进程持有一个Service，并且该Service正在执行它的某个生命周期回调方法，比如onCreate()、 onStart()或onDestroy()。 
- 某个进程持有一个BroadcastReceiver，并且该BroadcastReceiver正在执行其onReceive()方法。

用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。

2.2、可见进程(Visible process)

场景： 
- 拥有不在前台、但仍对用户可见的 Activity（已调用 onPause()）。 
- 拥有绑定到可见（或前台）Activity 的 Service

用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，要保持某个或多个前台进程存活

2.3、服务进程(Service process)

场景 
- 某个进程中运行着一个Service且该Service是通过startService()启动的，与用户看见的界面没有直接关联。

在内存不足以维持所有前台进程和可见进程同时运行的情况下，服务进程会被杀死

2.4、后台进程(Background process)

场景： 
- 在用户按了”back”或者”home”后,程序本身看不到了,但是其实还在运行的程序，比如Activity调用了onPause方法

系统可能随时终止它们，回收内存

2.5、空进程(Empty process)

场景： 
- 某个进程不包含任何活跃的组件时该进程就会被置为空进程，完全没用,杀了它只有好处没坏处,第一个干它!

3、内存阈值

上面是进程的分类，进程是怎么被杀的呢？系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app, 这套杀