1、引言

随着Android系统的不断升级，即时通讯网技术群和社区里的IM和推送开发的程序员们，对于进程保活这件事是越来越悲观，必竟系统对各种保活黑科技的限制越来越多了，想超越系统的挚肘，难度越来越大。

但保活这件事就像“激情”之后的余味，总是让人欲罢不能，想放弃又不甘心。那么，除了像上篇《2020年了，Android后台保活还有戏吗？看我如何优雅的实现！》这样的正经白名单方式，不正经的“黑科技”是否还有发挥的余地？

答案是肯定的，“黑科技”仍发挥的余地。不是“黑科技”不行，而是技术没到位。

研究TIM的保活是一次偶然机会，发现在安全中心关闭了它的自启动功能的情况下， 一键清理、强力清理等各大招都无法彻底杀掉TIM，系统的自启动拦截也没能阻止TIM的永生，这引起了我强烈的兴趣，于是便有了本文。

本文将从Andriod系统层面为你深入剖析腾讯TIM这款IM应用的超强保活能力，希望能给你带来更多Android方面的灵感。

* 特别申明：本文的技术研究和分析过程，仅供技术爱好者学习的用途，请勿用作非法用途。

扩展知识：腾讯TIM是什么？（以下文字来自百度百科）

TIM是由腾讯公司于2016年11月发布的多平台IM客户端应用。TIM是在QQ轻聊版的基础上加入了协同办公服务的支持，可QQ号登录，以及好友、消息同步等，适合办公使用。

2、本文作者 

袁辉辉：2019年5月加入字节跳动移动平台部。毕业于西安电子科技大，曾就职于小米、联想、IBM。

之前主要经历从事Android手机系统研发，在上一份小米MIUI系统组工作期间主要负责小米手机Android Framework架构优化、系统稳定、技术预研、平台建设等工作。热衷于研究Android系统内核技术，对Android系统框架有着深刻理解与丰富的实战经验，编写近200篇高质量文章，多次受邀参加业内Android技术大会演讲。

3、保活技术回顾

Android保活技术的进化，可以分为几个阶段。

第一个阶段：也就是各种“黑科技”盛行的时代，比如某Q搞出来的1像素、后台无声音乐（某运动计步APP就干过）等等。

这个阶段的一些典型主要技术手段，可以看以下这几篇文章：

1. 《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》
2. 《Android进程保活详解：一篇文章解决你的所有疑问》
3. 《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》

第二个阶段：到了Android 6.0时代以后，Android保活就开始有点技术难度了，之前的各种无脑保活方法开始慢慢失效。

这个阶段的一些典型技术手段，可以读读以下这几篇文章：

1. 《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》
2. 《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》

第三个阶段：进入Android 8.0时代，Android直接在系统层面进行了各种越来越严格的管控，可以用的保活手段越来越少，保活技术的发展方向已发分化为两个方向——要么用白名单的方式走正经的保活路径、要么越来越“黑”一“黑”到底（比如本文将要介绍的TIM的保活手段）。

这个阶段可以用的保活已经手段不多了，以下几篇盘点了目前的一些技术可行性现状等：

1. 《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》
2. 《全面盘点当前Android后台保活方案的真实运行效果（截止2019年前）》
3. 《2020年了，Android后台保活还有戏吗？看我如何优雅的实现！》

4、什么是保活？

保活就是在用户主动杀进程，或者系统基于当前内存不足状态而触发清理进程后，该进程设法让自己免于被杀的命运或者被杀后能立刻重生的手段。

保活是”应用的蜜罐，系统的肿瘤“，应用高保活率给自己赢得在线时长，甚至做各种应用想做而用户不期望的行为，给系统带来的是不必要的耗电，以及系统额外的性能负担。

保活方案一直就层出不穷，APP开发们不断地绞尽脑汁让自己的应用能存活得时间更长， 主要思路有以下两个。

提升进程优先级，降低被杀概率：

• 1）比如监听SCREEN_ON/OFF广播，启动一像素的透明Activity；
• 2）启动空通知，提升fg-service；
• ... ...

进程被杀后，重新拉起进程：

• 1）监听系统或者第3方广播拉起进程。但目前安全中心/Whetstone已拦截；
• 2）Native fork进程相互监听，监听到父进程被杀，则通过am命令启动进程。force-stop会杀整个进程组，所以这个方法几乎很难生效了。

5、初步分析

5.1 初识TIM

执行命令adb shell ps | grep tencent.tim，可见TIM共有4个进程， 其父进程都是Zygote：

root@gityuan:/ # ps | grep tencent.tim

u0_a146   27965 551   1230992 43964 SyS_epoll_ 00f6df4bf0 S com.tencent.tim:Daemon

u0_a146   27996 551   1252492 54032 SyS_epoll_ 00f6df4bf0 S com.tencent.tim:MSF

u0_a146   28364 551   1348616 89204 SyS_epoll_ 00f6df4bf0 S com.tencent.tim:mail

u0_a146   31587 551   1406128 147976 SyS_epoll_ 00f6df4bf0 S com.tencent.tim

5.2 一键清理看现象，排查初步怀疑

以下是对TIM执行一键清理后的日志：

12-21 21:12:20.265  1053  1075 I am_kill : [0,4892,com.tencent.tim:Daemon,5,stop com.tencent.tim: from pid 4617]

12-21 21:12:20.272  1053  1075 I am_kill : [0,5276,com.tencent.tim:mail,2,stop com.tencent.tim: from pid 4617]

12-21 21:12:20.305  1053  1075 I am_kill : [0,4928,com.tencent.tim,2,stop com.tencent.tim: from pid 4617]

12-21 21:12:20.330  1053  1075 I am_kill : [0,4910,com.tencent.tim:MSF,0,stop com.tencent.tim: from pid 4617]

12-21 21:13:59.920  1053  1466 I am_proc_start: [0,5487,10146,com.tencent.tim:MSF,service,com.tencent.tim/com.tencent.mobileqq.app.DaemonMsfService]

12-21 21:13:59.984  1053  1604 I am_proc_start: [0,5516,10146,com.tencent.tim,content provider,com.tencent.tim/com.tencent.mqq.shared_file_accessor.ContentProviderImpl]

Force-stop是系统提供的杀进程最为彻底的方式，详见文章《Android进程绝杀技–forceStop》。从日志可以发现一键清理后TIM的4个进程全部都已被Force-stop。但进程com.tencent.tim:MSF立刻就被DaemonMsfService服务启动过程而拉起。

问题1：安全中心已配置了禁止TIM的自启动， 并且安全中心和系统都有对进程自启动以及级联启动的严格限制，为何会有漏网之鱼？

怀疑1： 是否安全中心自启动没能有效限制，以及微信/QQ跟TIM有所级联，比如com.tencent.mobileqq.app.DaemonMsfService服务名中以com.tencent.mobileqq(QQ的包名)开头。

经过dumpsys以及反复验证后排除了这种可能性，如下：

12-21 21:12:20.266  1053  1075 I AutoStartManagerService: MIUILOG- Reject RestartService packageName :com.tencent.tim uid : 10146

12-21 21:12:20.291  1053  1075 I AutoStartManagerService: MIUILOG- Reject Re