源
有几个问题需要思考，系统为什么会杀掉进程，杀的为什么是我的进程，这是按照什么标准来选择的，是一次性干掉多个进程，还是一个接着一个杀，保活套路一堆，如何进行进程保活才是比较恰当……如果这些问题你还还存在，或许这篇文章可以解答。
终于一口气写完了，这是去年在一个月搞的成果，也算是对自己有了一个交代。
其实保活就是两个要点：
1、怎样监听到进程挂掉
2、怎样把进程拉起来
把这两个点都解决，问题就解决了。
大家把我之前的文章都看完，会发现这两个点上都有好多种策略，那么在不同的手机上，两个点的不同策略就有多种组合方式，也也是我适配手机的主要手段。
当时我适配测试的手机有
还要说一句，有的手机会在你系统设置force close的时候，显示已经杀掉了进程，但是其实没有真的杀掉，比如魅族。。。
上一篇我们通过父子进程间建立双管道，来监听进程死掉，经过测试，无耗电问题，无内存消耗问题，可以在设置中force close下成功拉起，也可以在获取到root权限的360/cleanmaster下成功存活。
可是放到5.0+的系统就不能用了，为什么呢？我们来看源码4.4系统和5.0系统在系统force close的时候都做了什么修改。
4.4.3的ActivityManagerService
实现在这里
今天继续昨天，一鼓作气，争取这个礼拜全部写完。
上一篇文章留了一个别人的github链接，他里面的native保活实现方案也是大多数公司采用的方案。
我们先来讲一下他的方案。
他是首先开启一个c进程，将需要保活的service名字传递进去
年前就开篇了android进程常驻，但是一直琐事不断，也一直没有静下心来整理，只是把项目传到的github，有好多朋友会来问我其中实现原理，其实也是一点一点推演过来的。我的想法就是按照我当时的推演过程，按顺序写完这几篇博客，也算是对那一个月努力的一个交代。
上一篇讲了系统管理进程和强杀进程的过程原理，今天就开始想一下，在此基础上，如何实现保活，当然作为一个android开发，最先想到的肯定是在framework层有没有什么机制可以利用实现保活，当时整理了以下几点（是对照自己当时写的ppt整理的，有些细节已经忘记）：
Android 进程常驻，顾名思义，就是要让我们的进程在内存中永远存在，换句话说就是进程保活，臭不要脸的说法就是关不了，杀不死，干不掉。这不是耍流氓，是很多场景如果要想为用户服务，就必须有一个进程常驻，以便在特定的时候做特定的事情。
比如在Android中，许多BroadcastReceiver事件不支持静态注册，也就是说如果我想接受屏幕开关的系统广播，必须要在进程中动态注册，如果没有一个常驻进程，那么锁屏应用就无法正常为用户服务；
另外IM类应用，也需要在后台维护一个长链接，以便于在最及时的时间里将信息传达给用户。
诚然，但凡进程常驻内存，无论怎样优化，都会或多或少的增加一些额外的性能开支，在为用户最负责任的服务，最高品质的体现我们的价值的前提下，我们要尽可能减少内存和电量的消耗，这个后面会说到。这里吐槽一下一些无良开发者，为一些完全不必要的业务常驻一个进程，这样只会加快用户卸载的速度，最让人忍受不了的是，代码低效，保活无力，还特么烧电！最后我想说的是，不以服务用户为目的的内存常驻都是耍流氓！
闲淡少扯。
进入正题。
支持系统2.3到6.0
支持大部分设备，包括三星，华为，oppo，nexus，魅族等等
可以简单对开机广播进行保护
github地址：
https://github.com/Marswin/MarsDaemon
Marsdaemon配置需要三步：
1、明确自己需要常驻的进程service，创建一个和他同进程的receiver，然后在另外一个进程中创建一个service和一个receiver，并写在Manifest中。进程名可以自定义
之前写过一篇android进程保活实践，文章中提到的保活方法其实很早前别人都总结过，而我写那篇文章的本意，其实更多是总结一种进程保活的思路，比如文中提到的进程优先级oom_adj的概念，进程被kill的3种场景，国产手机的现状等。
后来收到不少留言评论，大多数都是讲这个进程保活对很多手机没有作用。我一直没有回复，因为我们项目在使用这个进程保活策略时，同时也加入了进程存活时间的Log记录机制，目的就是想看下有效果没。后台service的启动就开启计时器，以分钟为单位不停写入SharePreference，进程被kill这个值就是存活时间(min)，同时记录机型，Android版本等信息，以Exception的格式封装上传到bugly。由于是纯手动分析数据很麻烦，最后取了1000条数据涵盖了Android5.0-Android8.0，小米，华为，三星，oppo/vivo,金立等各种机型。
之前介绍介绍了 双进程保活，我还大言不惭的 适配 8.0 。但是，从 Android 6.0 之后这个方法及其不好用，说死就死，华为，小米 分分钟 弄死笔者的 App 。 而且 最恶心的事情，居然 ANR 。 笔者对现在那些闭着眼睛 抄博客 的大佬实在不敢恭维了。对了，之前的笔记地址为：自己用到的Android 双服务保活（适配8.0）, Android 6.0 以上不建议使用 ！！！好了，下面说说，服务播放音乐，保活的基本原理吧。
对于进程保活，其实吧，现在对于MIUI、EMUI等等许多高度定制的系统并没有100%的保活方案，该死还是死掉，但是做了一定的操作，还是可以适当的提高存活的。如下就是我用到的保活方案。
目前市面上的应用，貌似除了微信和手Q都会比较担心被用户或者系统（厂商）杀死问题。本文对 Android 进程拉活进行一个总结。
Android 进程拉活包括两个层面：
A. 提供进程优先级，降低进程被杀死的概率
B. 在进程被杀死后，进行拉活
本文下面就从这两个方面做一下总结。
Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要清除旧进程来回收内存。 为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。 必要时，系统会首先消除重要性最低的进程，然后是清除重要性稍低一级的进程，依此类推，以回收系统资源。
进程的重要性，划分5级：
前台进程(Foreground process)
可见进程(Visible process)
服务进程(Service process)
后台进程(Background process)
空进程(Empty process)
进程保活的关键点有两个，一个是进程优先级的理解，优先级越高存活几率越大。二是弄清楚哪些场景会导致进程会kill，然后采取下面的策略对各种场景进行优化：
根据前辈们的经验，如果没有白名单，Android系统要做一个任何情况下都不被杀死的应用几乎是不可能的，但我们可以做一个最大程度不被杀死，如果被杀死可以立即让它在第一时间内复活，那也是ok的。网上的进程常驻也是众说纷纭，这篇文章就总结下Android中进程保活的一些可行性方法，当然这些东西也不是我发明的，我只是在网上查询之后将其写成自己的文章，然后分享出来。
