DroidPlugin代码分析(三) 占坑、动态注册

接上篇，这一篇分析一下“占坑”部分。既然是占坑，先看一下DroidPlugin都占了哪些坑？

扫一眼AndroidManifest.xml可以发现，除了主进程意外，还注册了”:PluginP01” ~ ”:Plugin08”这8个进程，所以一共9个进程。

每个进程里注册了30个activity，1个service，和一个content provider：

  •  .stub.ActivityStub$P00$Standard00
  •  .stub.ActivityStub$P00$SingleInstance00
  •  .stub.ActivityStub$P00$SingleInstance01
  •  .stub.ActivityStub$P00$SingleInstance02
  •  .stub.ActivityStub$P00$SingleInstance03
  •  .stub.ActivityStub$P00$SingleTask00
  •  .stub.ActivityStub$P00$SingleTask01
  •  .stub.ActivityStub$P00$SingleTask02
  •  .stub.ActivityStub$P00$SingleTask03
  •  .stub.ActivityStub$P00$SingleTop00
  •  .stub.ActivityStub$P00$SingleTop01
  •  .stub.ActivityStub$P00$SingleTop02
  •  .stub.ActivityStub$P00$SingleTop03
  •  .stub.ActivityStub$Dialog$P00$Standard00
  •  .stub.ActivityStub$Dialog$P00$SingleInstance00
  •  .stub.ActivityStub$Dialog$P00$SingleInstance01
  •  .stub.ActivityStub$Dialog$P00$SingleInstance02
  •  .stub.ActivityStub$Dialog$P00$SingleInstance03
  •  .stub.ActivityStub$Dialog$P00$SingleTask00
  •  .stub.ActivityStub$Dialog$P00$SingleTask01
  •  .stub.ActivityStub$Dialog$P00$SingleTask02
  •  .stub.ActivityStub$Dialog$P00$SingleTask03
  •  .stub.ActivityStub$Dialog$P00$SingleTop00
  •  .stub.ActivityStub$Dialog$P00$SingleTop01
  •  .stub.ActivityStub$Dialog$P00$SingleTop02
  •  .stub.ActivityStub$Dialog$P00$SingleTop03
  •  .stub.ServiceStub$StubP00$P00
  •  .stub.ContentProviderStub$StubP00

从activity名字就可以看出来，基本上把各种launch mode以及不同theme的activity都注册了一遍。这样当插件app需要启动某一类型的activity时，分配一个空闲的出来用就可以了。

Service只注册了一个，如果一个进程要运行多个service怎么办？后面会看到，会有一个service manager来解决这个问题。

Content provider也只注册了一个，不过一般够用了。

下面挨个分析一下四大组件动态注册的过程。

一、Activity动态注册

写过android app的都知道，所有activity组件都必须在AndroidManifest.xml里声明，否则是找不到的。但是在插件app里会定义哪些activity我们事先是不知道的，又怎么可能定义在AndroidManifest.xml里呢？这里又再次需要发挥“欺下瞒上”的技巧了：系统层看到的只是上面预定义的这些activity，而插件则以为它调用的系统服务是直接返回的，根本意识不到其实是从DroidPlugin那边过了一道。简单回顾一下activity启动的流程：

标红的两部分是被DroidPlugin hook住的两个主要API：

第一个API是最被经常使用的startActivity()，hook的方法上一篇已经介绍过了，主要是通过Java的反射机制替换掉IActivityManager全局对象，具体参见IActivityManager的onInstall()方法。

第二个API是handleLaunchActivity()，这个API隶属于ActivityThread的一个叫做H的内部类，该类继承自Handler，ActivityThread有一个该类型的成员变量mH。scheduleLaunchActivity()里会发送一个LAUNCH_ACTIVITY类型的消息，该消息被mH捕获并调用handleLaunchActivity()。说到这里，大家应该很容易想到如何hook这个API了，直接把这个mH对象通过反射替换掉呗！不错，这就是上一篇最后提到的PluginCallbackHook的工作，看一下PluginCallbackHook的onInstall()方法：

    protected void onInstall(ClassLoader classLoader) throws Throwable {
        Object target = ActivityThreadCompat.currentActivityThread();
        Class ActivityThreadClass = ActivityThreadCompat.activityThreadClass();

        /*替换ActivityThread.mH.mCallback，拦截组件调度消息*/
        Field mHField = FieldUtils.getField(ActivityThreadClass, "mH");
        Handler handler = (Handler) FieldUtils.readField(mHField, target);
        Field mCallbackField = FieldUtils.getField(Handler.class, "mCallback");
        //*这里读取出旧的callback并处理*/
        Object mCallback = FieldUtils.readField(mCallbackField, handler);
        if (!PluginCallback.class.isInstance(mCallback)) {
            PluginCallback value = mCallback != null ? new PluginCallback(mHostContext, handler, (Handler.Callback) mCallback) : new PluginCallback(mHostContext, handler, null);
            value.setEnable(isEnable());
            mCallbacks.add(value);
            FieldUtils.writeField(mCallbackField, handler, value);
            Log.i(TAG, "PluginCallbackHook has installed");
        } else {
            Log.i(TAG, "PluginCallbackHook has installed,skip");
        }
    }

可以看到，不是完全替换掉mH，而是把mH的mCallback成员变量替换成了一个