史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术(7)
2023-04-30 来源:飞速影视
以上代码是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调用。
代码如下:
![史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术](http://fs.qqfile.top/re/aHR0cHM6Ly9waWNzMS5iYWlkdS5jb20vZmVlZC8zODAxMjEzZmI4MGU3YmVjZjdjYjlhMDQwY2I0YjQzZTlhNTA2YjY2LnBuZ0BmX2F1dG8_dG9rZW49ZjY5YTcxOTRmYmI3Njk4OTM2YTM3NDg4YjBmYzhlMTAmYW1wO3M9RTg5MkVDMUExRENBNTE0OTBDRjQ4MERBMDAwMEMwQjE1)
虽然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驱动进行数据交互。
本站仅为学习交流之用,所有视频和图片均来自互联网收集而来,版权归原创者所有,本网站只提供web页面服务,并不提供资源存储,也不参与录制、上传
若本站收录的节目无意侵犯了贵司版权,请发邮件(我们会在3个工作日内删除侵权内容,谢谢。)
www.fs94.org-飞速影视 粤ICP备74369512号