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

说明：其中一个app_d进程是由MSF进程，通过两次fork，然后父进程退出，从而成为了孤儿进程，然后托孤给init进程，这是Linux进程机制所保证的。 同理，另一个app_d进程是由Daemon进程所fork。到这里，那么总算是认清的app_d的由来。 app_d是由于cgroup关联所以可以得知Daemon进程的情况。 关于重启的原因是为了重新建立互动的关系。
问题7：为何单杀daemon，会牵连app_d进程被杀，这是什么原理？
解答：从杀进程的日志上来是调用killProcessGroup()杀进程，可事实上adb只调用kill -9 pid的方式，单杀一个进程，怎么就牵连了app_d进程。 这是由于当daemon进程被杀后，死亡回调会回来后，在binderDied()的过程执行了killProcessGroup()。
如果从Linux内核层面，研究过Binder死亡回调机制的童鞋，到这里还就会有想到一个新的疑问如下。
问题8：app_d是由daemon进程间接fork出来的， 会共享binder fd，所以即便daemon进程被杀，死亡回调也不会触发，这又是何触发的呢？
解答：由于app_d进程被fork后，马上执行了exec()系的函数， 而在ProcessState打开Binder驱动的时候， 有一个非常重要的flag, 那就是O_CLOEXEC。
采用O_CLOEXEC方式打开的问题，当新创建的进程调用exec（）函数成功后，文件描述符会自动关闭， 代码如下：

6.7 剖根问底
问题9：TIM到底对Binder框架做了什么级别的修改？这4个互保进程，既然callingPid=0，有没有办法知道到底是由谁拉起谁的？
前面既然说了，TIM强行修改了ONEWAY的方式。可以去掉该flags, 为了调试，这里就针对TIM，并且code=34(即START_SERVICE_TRANSACTION)， 并且修改flag的case下：