关键词：
参考技术A 对于IM应用和消息推送服务的开发者来说，在Android机型上的后台保活是个相当头疼的问题。老板一句：“为什么微信、QQ能收到消息，而你写的APP却不行？”，直接让人崩溃，话说老板你这APP要是整成微信、APP那么牛，直接进手机厂商白名单，还要程序员在这瞎忙活？
好了，抱怨归抱怨，活还得干，不然靠谁养活广大苦逼的程序员？
正因为Android系统版本的差异，也导致了各种保活黑科技的运行效果大相径庭，所以本文正好借此机会，盘点一下当前主流（截止2019年前）的保活黑科技在市面上各版本Android手机上的运行效果，希望能给大家提供一些客观的参考。
其实Android端APP搞保活的目的倒不是为了干什么见不得人的坏事（但不排除动机不纯的开发者），主要是像IM即时通讯应用和资讯类应用等需要搞后台消息推送、运动类应用需要在后台实时监测用户的运动数据等，因为现在越来越多的手机厂商为了省电策略考虑，基本上如果你的应用没有被加入白名单，一旦处于后台就会被系统限制甚至干掉，但使用APP的用户才不听你这些解释——反正“我”就要你的APP能如期正常运行，开发者也是不得已而为之。
以消息推送为例，当APP处于后台或关闭时，消息推送对于某些应用来说非常有用，比如：
1）IM即时通讯聊天应用：聊天消息通知、音视频聊天呼叫等，典型代表有：微信、QQ、易信、米聊、钉钉、Whatsup、Line；
2）新闻资讯应用：最新资讯通知等，典型代表有：网易新闻客户端、腾讯新闻客户端；
3）SNS社交应用：转发/关注/赞等通知，典型代表有：微博、知乎；
4）邮箱客户端：新邮件通知等，典型代表有：QQ邮箱客户端、Foxmail客户端、网易邮箱大师；
5）金融支付应用：收款通知、转账通知等，典型代表有：支付宝、各大银行的手机银行等；
.... ....
在上述的各种应用中，尤其对于用户接触最多、最平常的IM聊天应用或新闻资讯来说，保活和消息推送简直事关APP的“生死”，消息推送这种能力已经被越来越多的APP作为基础能力之一，因为移动互联网时代下，用户的“全时在线”能力非常诱人和强大，能随时随地即时地将各种重要信息推送给用户，无疑是非常有意义的。
题外话：实际上，对于后台消息推送能力，Android原版系统早就内置了系统级推送服务（跟iOS上的APNs服务是一个东西），它就是GCM服务（现在升级为FCM了），但众所周之的原因，谷哥的服务在国内都是用不了的（你懂的）——无奈啊！
主要黑科技方案有：
1）监听广播：监听全局的静态广播，比如时间更新的广播、开机广播、解锁屏、网络状态、解锁加锁亮屏暗屏（3.1版本），高版本需要应用开机后运行一次才能监听这些系统广播，目前此方案失效。可以更换思路，做APP启动后的保活（监听广播启动保活的前台服务）；
2）定时器、JobScheduler：假如应用被系统杀死，那么定时器则失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0时候有一定影响（可以在电源管理中给APP授权）；
3）双进程（NDK方式Fork子进程）、双Service守护：高版本已失效，5.0起系统回收策略改成进程组。双Service方案也改成了应用被杀，任何后台Service无法正常状态运行；
4）提高Service优先级：只能一定程度上缓解Service被立马回收。 即时通讯聊天软件app开发可以咨询蔚可云。
针对上述方案，具体的实现思路，通常是这样的：
1）进程拉活：AIDL方式单进程、双进程方式保活Service（最极端的例子就是推送厂商的互相唤醒复活：极光、友盟、以及各大厂商的推送，同派系APP广播互相唤醒：比如今日头条系、阿里系）；
2）降低oom_adj的值：常驻通知栏（可通过启动另外一个服务关闭Notification，不对oom_adj值有影响）、使用”1像素“的Activity覆盖在getWindow()的view上（据传某不可言说的IM大厂用过这个方案，虽然他们从未正面承认过）、循环播放无声音频（黑科技，7.0下杀不掉）；
3）监听锁屏广播：使Activity始终保持前台；
4）使用自定义锁屏界面：覆盖了系统锁屏界面；
5）创建子进程：通过android:process属性来为Service创建一个进程；
6）白名单：跳转到系统白名单界面让用户自己添加app进入白名单。
使用AIDL绑定方式新建2个Service优先级（防止服务同时被系统杀死）不一样的守护进程互相拉起对方，并在每一个守护进程的ServiceConnection的绑定回调里判断保活Service是否需要重新拉起和对守护线程进行重新绑定。
后台播放音乐这种保活方法，亲身经历过：
记得当时用的是某运动记步APP，它为了保活就是这么干的。之所以被我发现，是因为在我的Android手机上，每次打开这个APP居然总能莫名其妙听到若有若无的环境噪音样的声音，尤其安静的场所下更明显。我个人估计这个APP里用的保活音频文件，很可能就是程序员在简陋的条件下随手自已录制的，虽然也是不得以为之，但做法确实是有点粗糙。
总结一下，以上方案在当前主流手机上的运行效果
【1】双进程守护方案（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：原生任务栏滑动清理app，Service会被杀掉，然后被拉起，接着一直存活；
2）金立F100(5.1)：一键清理直接杀掉整个app，包括双守护进程。不手动清理情况下，经测试能锁屏存活至少40分钟；
3）华为畅享5x（6.0）：一键清理直接杀掉整个app，包括双守护进程。不手动清理下，锁屏只存活10s。结论：双进程守护方案失效；
4）美图m8s(7.1.1)：一键清理直接杀掉整个app，包括双守护进程。不清理情况下，锁屏会有被杀过程（9分钟左右被杀），之后重新复活，之后不断被干掉然后又重新复活。结论：双守护进程可在后台不断拉起Service；
5）原生7.0：任务栏清除APP后，Service存活。使用此方案后Service照样存活；
6）LG V30+(7.1.2)：不加双进程守护的时候，一键清理无法杀掉服务。加了此方案之后也不能杀掉服务，锁屏存活（测试观察大于50分钟）；
7）小米8(8.1)：一键清理直接干掉app并且包括双守护进程。不清理情况下，不加守护进程方案与加守护进程方案Service会一直存活，12分钟左右closed。结论：此方案没有起作用。
▲ 结论：除了华为此方案无效以及未更改底层的厂商不起作用外（START_STICKY字段就可以保持Service不被杀）。此方案可以与其他方案混合使用。
【2】监听锁屏广播打开1像素Activity（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；
2）华为畅享5x（6.0）：锁屏只存活4s。结论：方案失效；
3）美图m8s(7.1.1)：同原生5.0；
4）原生7.0：同美图m8s；
5）LG V30+(7.1.2)：锁屏后情况跟不加情况一致，服务一致保持运行，结论：此方案不起作用；
6）小米8(8.1)：关屏过2s之后app全部被干掉。结论：此方案没有起作用。
▲ 结论：此方案无效果。
【3】故意在后台播放无声的音乐（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；
2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务，锁屏8分钟后依然存活。结论：此方案适用；
3）美图m8s(7.1.1)：同5.0；
4）原生7.0：任务管理器中关闭APP后服务被干掉，大概过3s会重新复活（同仅START_STICKY字段模式）。结论：看不出此方案有没有其作用；
5）LG V30+(7.1.2)：使用此方案前后效果一致。结论：此方案不起作用；
6）小米8(8.1)：一键清理可以杀掉服务。锁屏后保活超过20分钟。
▲ 结论：成功对华为手机保活。小米8下也成功突破20分钟。
【4】使用JobScheduler唤醒Service（基于onStartCommand() return START_STICKY）：
1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。结论：此方案起作用；
2）华为畅享5x（6.0）：一键清理直接杀掉APP，过12s左右会自动重启服务，JobScheduler起作用；
3）美图m8s(7.1.1)：一键清理直接杀掉APP，无法自动重启；
4）原生7.0：同美图m8s(7.1.1)；
5）小米8(8.1)：同美图m8s(7.1.1)。
▲ 结论：只对5.0，5.1、6.0起作用。
【5】混合使用的效果，并且在通知栏弹出通知：
1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。锁屏超过11分钟存活；
2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务。结论：方案适用；
3）美图m8s(7.1.1)：一键清理APP会被杀掉。正常情况下锁屏后服务依然存活；
4）原生7.0：任务管理器中关闭APP后服务被干掉，过2s会重新复活；
5）小米8(8.1)：一键清理可以杀掉服务，锁屏下后台保活时间超过38分钟；
6）荣耀10（8.0）：一键清理杀掉服务，锁屏下后台保活时间超过23分钟。
浅析im即时通讯开发加白名单
IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论，自从Android8.0后系统大大降低了后台运行应用的保活容忍度，保活从黑科技横行的时代进入了技术蛮荒阶段，真要实现保活，技术难度越来越大。不过话说回来... 查看详情
浅析im即时通讯开发加白名单
IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论，自从Android8.0后系统大大降低了后台运行应用的保活容忍度，保活从黑科技横行的时代进入了技术蛮荒阶段，真要实现保活，技术难度越来越大。... 查看详情
im即时通讯开发之android进程保活详解
关于Android平台的进程保活这一块，想必是所有Android开发者瞩目的内容之一。你到网上搜Android进程保活，可以搜出各种各样神乎其技的做法，绝大多数都是极其不靠谱。怀着学习和膜拜的心情进去Github围观，结果... 查看详情
im即时通讯开发应用保活之进程防杀
在Android4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。虽然APP常驻内存对于用户来说比较”恶心”，但是在诸如IM和... 查看详情
im即时通讯开发：android6.0及以上的保活之被杀复活
随着AlarmManager唤醒、native进程拉起等方式的失效，APP常驻内存的时代将不复存在，尤其是当APP进程被杀死后，基本很难将其复活拉起。从用户的角度来讲，这是一种很好的发展，而这一切应该归功于谷歌和各大厂商不断追求良好... 查看详情
im即时通讯开发之后台应用保活消息推送的噩梦
AndroidP的最后一个开发者预览版（即DP5）已如期发布于2018年7月26日，根据上面这张发布路线图，相信AndroidP的正式版将很快到来。对于Andriod开发者来说，不管AndriodP有多少新功能或者特性（反正“我”用iPho... 查看详情
im即时通讯开发应用保活之进程防杀
在Android4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。虽然APP常驻内存对于用户来说比较”恶心... 查看详情
im即时通讯开发之双进程守护保活实践
在Android4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。虽然APP常驻内存对于用户来说比较”恶心... 查看详情
im即时通讯应用开发中无法解决的“顽疾”
Android进程和Service的保活，是困扰Android开发人员的一大顽疾。因涉及到省电和内存管理策略，各厂商基于自家的理解，在自已ROOM发布于都对标准Android发行版作为或多或少的改动，使得应用层程序在处理进程和Servi... 查看详情
浅析im即时通讯开发中tcp协议层keepalive保活机制
对于IM这种应用而言，应用层的网络保活的最直接办法就是心跳机制，比如主流的IM里有微信、QQ、钉钉、易信等等，可能代码实现细节有所差异，但理论上无一例外都是这样实现。（PS：没错，当初微... 查看详情
基于tcp的移动端im即时通讯开发仍然需要心跳保活
很多人认为，TCP协议自身先天就有KeepAlive机制，为何基于它的通讯链接，仍然需要在应用层实现额外的心跳保活？本文将从移动端IM实践的角度告诉你，即使使用的是TCP协议，应用层的心跳保活仍旧必不可... 查看详情
im即时通讯开发：android6.0及以上的保活之被杀复活
随着AlarmManager唤醒、native进程拉起等方式的失效，APP常驻内存的时代将不复存在，尤其是当APP进程被杀死后，基本很难将其复活拉起。从用户的角度来讲，这是一种很好的发展，而这一切应该归功于谷歌和各... 查看详情
im即时通讯开发之websocket断网重连更快的方法
在一个完善的即时通讯IM应用中，WebSocket是极其关键的一环，它为基于Web的即时通讯应用提供了一种全双工的通信机制。但为了提升IM等实际应用场景下的消息即时性和可靠性，我们需要克服WebSocket及其底层依赖的TCP... 查看详情
im即时通讯开发：高性能http服务端的负载均衡
...压，因此在互联网的大流量项目中，其重要性不言而喻。即时通讯网注：本文中所提及的HTTP负载均衡方案和算法，并不完全适 查看详情
im即时通讯开发：高可用易伸缩高并发的im群聊单聊架构方案设计
要实现一整套能用于大用户量、高并发场景下的IM群聊，技术难度远超IM系统中的其它功能，原因在于：IM群聊消息的实时写扩散特性带来了一系列技术难题。举个例子：如一个2000人群里，一条普通消息的发出问题，将瞬间写扩... 查看详情
浅析怎么开发分布式im即时通讯系统
本文不会给出一套通用的IM方案，也不会评判某种架构的好坏，而是讨论设计IM系统的常见难题跟业界的解决方案。因为也没有所谓的通用IM架构方案，不同的解决方案都各有其优缺点，只有最满足业务的系统才是... 查看详情
im即时通讯开发ios多设备字体适配方案
为何需要字体适配？2014下半年，微信iOS版先后适配了iPad,iPhone6/6plus。但随着这些大屏设备的登场，部分用户觉得微信的字体太小，然而也有很多用户不喜欢太大的字体。为了满足不同用户的需求，我们实现了... 查看详情
分享一种android端im即时通讯智能心跳算法
对于IM或实时消息推送技术来说，客户端的心跳算法几乎是必备品，尤其当前复杂的移动网络环境下，网络心跳保活算法的优劣更是决定了您的APP即时数据收发的实时性和用户体验，非常地关键。 为什么TCP连接需... 查看详情