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

从实验结果来看，通过修改IPCThreadState.cpp代码， 完成control住了 TIM的所有修改， 这里可以说明：
TIM分别在Java层和Native层，主动向ServiceManager进程查询AMS后，获取BpActivityManager代理对象，然后继续使用框架中的IPCThreadState跟Binder驱动交互，并没有替换掉libbinder.so。
其实，还可以更高级的玩法，连IPCThreadState这些框架通信代码也不使用， 彻底地去自定义Binder交互代码，类似于servicemanager的方式。可以自己封装ioctl()，直接talkWithDriver。TIM保活还有改进空间， 提供保活变种方案，这样的话，上面的调试代码也拦截不了其对flags修改为ONEWAY的过程。 即使如此，一切都在Control之中， 完全可以在Binder Driver中拦截再定位其策略， 玩得再高级也主要活动在用户态， 内核态的策略还是相对安全的， 此所谓“魔高一座，道高一尺”。
另外，通过增加上面的临时代码，再次多次实验对比，可以得出如下关系图：

二度fork是指前面介绍了，fork后再fork，然后托孤，无论如何跟最初的进程都属于同一个group，有着级联被杀关系。