史上最强Android保活思路：深入剖析腾讯TIM的进程永生技术(17)

1）杀掉Daemon进程，则MSF进程观察到会去拉起Daemon进程； 同时app_d1因为同一个group而被杀，则app_d2进程观察到也拉起Daemon进程，这就是双保险；2）杀掉app_d1进程， 则app_d2进程观察到会拉起MSF进程；3）直接force-stop进程， 则6个进程都会被杀，只是杀的过程并非所有进程同一时刻点被杀，而是有前后顺序，所以造成能自启。6.8 分析思路归纳
我们来回顾一下上面的过程：
1）先有了初步分析过程中对一些常规套路的可能性的排除，并嗅到callingPid=0的异常举动；2）沿着蛛丝马迹，不断反复尝试杀进程，从中寻找更多的规律，不断地向自己提出疑问；3）结合signal，strace, traces，ps，binder，linux，kill等技能 不断地解答自己的疑惑。解系统层的问题，更像是侦探破案的感觉，要有敏锐的嗅觉，抓住蛛丝马迹，加上”大胆猜想，小心验证“ , 终究能找到案件的真相。 此所谓”点动成线，线动成面，面动成体“， 从零星的点滴勾画出全方面立体化的真相。
归纳下，主要提出过这些疑惑：
问题1：安全中心已配置了禁止TIM的自启动， 并且安全中心和Whetstone都有对进程自启动以及级联启动的严格限制， 为何会有漏网之鱼？问题2：startService()的callingPid怎么可能等于0？问题3：进程内的名叫“Thread-89”的线程具有什么特点，如何做到把进程杀掉？问题4：为何需要4个indicator文件？问题5： 这4个进程到达是什么如何相互监听的呢？问题6： app_d到底是如何创建出来？又是如何成为init进程的子进程的？问题7：为何单杀daemon，会牵连app_d进程被杀，这是什么原理？问题8：app_d是由daemon进程间接fork出来的， 会共享binder fd，所以即便daemon进程被杀，死亡回调也不会触发，这又是何触发的呢？问题9：TIM到底对Binder框架做了什么级别的修改？
这4个互保进程，既然callingPid=0，有没有办法知道到底是由谁拉起谁的？7、本文总结
总结一下TIM的保活技术要点，我们可以得出以下经验：
1）通过flock的文件排它锁方式来监听进程存活状态1.1）先采用一对普通的进程Daemon和MSF相互监听文件的方式来获得对方进程是否存活的状态;1.2）同时再采用一对退孤给init进程的app_d进程相互监听文件的方式来获得对方进程是否存活的状态； 而这两个进程都有间接由Daemon和MSF进程所fork而来；双重保险。2）不采用系统框架中startService的Binder框架代码，而是自身在Native层通过自己去查询获取BpActivityManager代理对象， 然后自己实现startService接口，并修改为ONEWAY的binder调用，既增加分析问题的难度，也进一步隐藏自身策略；3）当监听进程死亡，则通过自身实现的StartService的Binder call去拉起对方进程，系统对于这种方式启动进程并没有拦截机制。