最近开发了个内部即时通信的app，可以说是真的蛋疼了，我几乎把整个保活的文章全部看了一遍，可以说android界真的是特别的鱼龙混杂。很多文章都写得很片面，容易形成很大的误导。我先说一个最近研究得出来的结论，在7.0这个版本，包括三星和国内的这些原生rom，如果不通过用户或厂家设置，至少service是绝对没有任何办法保活的，绝对，除非你还能找到未知的BUG。虽然我也很头疼，但我真的很赞同谷歌这样的做法，不然天天收推送通知真的是恶心得不行，IOS也得手动去关。现在android可以说是将一切统统杀掉，然后把仅有的一丝权限，给予用户去设置，甚至app中连弹出授权的api都不会给你
1、jni保活，在5.0以前，android系统本身是不管理jni层的，所以用linux那套fork机制，可以让进程和app分开，就算关闭app也不会影响到。所以那时很多人说android非常的卡，幸运的是我那段时间用的ios，这些进程连用户都没法关掉，真的特别恶心
2、jobservice，在5.0之后，连native层也会受到系统限制，比如kill、doze之类的，也就是说无论是杀掉还是冻结，都只和你启动的第一个进程有关，后面不再以父子的关系去看待，而是以历史同组的关系去看待。这个历史同组真的是一个很关键的改变，其实不止killgroup的作用性，无论怎样写代码，都脱离不了系统对你app的控制，比如让你何时休眠之类的。说了这么多，那该说下JobService了，JobService的作用是什么呢？关键的作用和正确的用法是在app关闭后，可以在自动创建进程后台干任何事情，包括拉活activity、service或者执行任何的代码。但JobService并不意味着你不受任何限制，比如受到doze、monitor之类的管理。
3、doze，doze是在android6.0的时候出现的，作用在锁屏之后，对app就行一系列的管理，可以说doze是一种底层机制。感觉doze还是很友好的，比如说提供白名单api、延迟执行的操作等等。就是说你每个app都会给你机会去发通知之类的，虽然时间受到限制，但除即时通信外应该也够了，关键是并没有关掉你的进程。并且如果在app中授权ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS，doze就不会再去管你，也就是如果即时通信的话，加doze白名单，再通过JobService拉活，双服务守护，基本上没任何问题。但人为了利益真的是不择手段，只要给我机会就天天发一堆垃圾消息，绝对不让用户清闲，时不时向后台收发点数据什么的，造成doze对android的改观并不明显的感觉。而且任意一个app进白名单，随意weaklock的话，整个系统环境就会被破坏。
4、monitor，monitor可以看成是对doze的一种增强实现，并且是对手机系统管理的一种实现，在绝大部分7.0的rom中都会有这东西，国产那几乎就是100%有了。在7.0的时候，这monitor悄无声息的多了一个白名单，这东西就真的是一个质的改变了，随叫用户总是让Google背锅呢。这monitor也可以看作是一个用root权限的app，在升级到7.0默认好像就开启了，那么它就先把除同等root权限的系统app排除外，对剩余的所有app就行管理（我升级幸免的就Alipay、WeChat、搜狗输入法），把你这些app先全拉到sleeping列表中，之后安装的app默认也在sleeping列表中。那么它有多强呢，对列表中的app，只要app关闭后，就算你通过JobService拉起，你也仅有15分钟的存活时间片，一旦耗光这15分钟的时间片，你就要永远说88了，直到用户下次打开你的app。当然，如果用户手动把app加到白名单，那么就算被关闭也不会被退出任何一个进程。说了这么多，结论就是就算你在doze白名单里面，也没任何作用，除非你能进monitor里面的白名单，否则就直接被拉进小黑屋出不来哦。
5、还有一种方法是拉活activity，不过有一定失败的概率，就是在destroy的时候判断是否关闭并拉活，不能保证100%成功，而且成功会在后台列表中出现。。。以前我看有人在jni层有用类似的办法做守护进程，就是在关闭之前去开新的，和系统抢时间，这个其实有一定合理性在，但属于是概率性事件了。如果使用JobService拉活activity也是和拉活service 同样的命运，毕竟怎么也跑不掉系统调用的killgroup，JobService能拉活完全是可控的故意给你的机会，并不是某些人所说的BUG