DroidPlugin代码分析(四) 进程管理

之所以单列一篇写进程管理，是因为看到注释上写“这是一个复杂的进程管理程序”，但是仔细看了一下好像也没那么“复杂”...

这一篇通过分析代码试图搞清楚以下3个问题：

• 插件进程是如何被hook住的？

• 插件进程die是如何被检测到的？

• 插件进程是如何被管理的？

一、插件进程是如何被hook住的？

在写宿主程序的时候，我们知道需要在Application的onCreate()和attachBaseContext()里调用PluginHelper的API来安装hook。但是，插件程序本身是不会调用这些API的，那么被启动的插件程序是如何被hook住的呢？

首先我们要再次回顾一下activity启动的一些细节，图比较大切成了两张，缩进表示该方法是在上一级方法里调用的子方法。先看左半边图：

比较简单，宿主在一个新进程里启动插件的时候，AMS会向插件进程的ActivityThread发起两个调用：bindApplication()和scheduleLaunchAcitivity()。再看右半边图：

这张图主要描述了这两个调用具体干了什么，实际上它们只是向ActivityThread的mH里发送了两个消息，真正干活的是mH（看过第二篇的可能有印象，我们把mH里面的mCallback替换成了我们的PluginCallback）。

看看bindApplication()具体做了哪些事情：

• 调用getPackageInfoNoCheck()创建一个LoadedApk对象，注意，由于AMS并不知道关于插件的事情，所以这里加载的还是宿主apk！所以实际上插件是启动不起来的，具体怎么处理的后面会介绍。创建的LoadedApk会放到一个mPackages的map中。

• 创建Instrumentation，调用LoadedApk.makeApplication()创建Application，注意只是创建，并没有调用Application的onCreate()。创建Application会放到一个mAllApplications的list中。

再看看scheduleLaunchActivity()具体做了哪些事情：

• 通过Instrumentation加载、创建activity对象，这里会用到class loader