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

以上代码是framework的框架代码，startService最终都会调用到这里来，所以callingPid必然是不可能出现为0的情况，让我们看不透到底哪个进程把com.tencent.tim: Daemon拉起的。
5.3.2）揭秘：
从前面的分析来看callingPid是不可能为0的， 但从结果来看的确是0， 出现矛盾就一定有反常规存在，难道是存在同步的Binder调用，也存在同时callingPid=0的case？答案是No.
从源码角度来看是没有这种可能性存在，后面再进一步追踪flags值的变化，从如下的flags=17，可以确定的是此处的startService的binder call是ONE_WAY的，这就可以确定的确是发起了异步的Binder调用。
代码如下：

虽然callingPid=0，但从callUid=10146可以确定的一点是com.tencent.tim: Daemon进程是被来自TIM应用自身的某个进程所拉起的。
5.4 小结
通过前面的初步分析，先整理一下思路，有以下初步结论：
1）TIM至少有4个进程，且都是由Zygote进程fork, 保活是通过startService被拉起；2）排除 安全中心的对TIM限制自启动功能失效的情况；3）排除 TIM进程被杀后的Binder死亡回调过程通过Service重新拉起进程；4）排除 alarm机制 拉起进程；5）从callingPid=0，可以得出TIM没有走常规的系统框架中提供的startService()接口来启动服务，而是自定义的方式；6）从callingUid=10146, 可以得出TIM救活自己的方式，是通过TIM自身，而非系统或者第三方应用拉起。到此不难得出一个猜想： 首先TIM应用能做到监听应用进程被杀的情况， 其次是TIM应用自身替换掉或者自定义一套Binder调用，主动跟Binder驱动进行数据交互。