Android系统的每次版本升级，都会对原有代码进行重构，这就为插件化带来了麻烦。
Android P对插件化的影响，主要体现在两方面，一是它重构了H类中Activity相关的逻辑，另一个是它重构了Instrumentation。
3.1 H类的变身
3.1.1 从Message和Handler说起
对于App开发人员而言，Message和Handler是耳熟能详的两个概念。我们简单回顾一下，一条消息是怎么发送和接收的。
首先，在App启动的时候，会创建ActivityThread，这就是主线程，也叫UI线程。App的入口——main函数，就藏在ActivityThread中，
在main函数中，会创建MainLooper。MainLooper是一个死循环，专门负责接收消息，也就是Message类。
Message类的定义如下，除了耳熟能详的what和obj属性外，还有一个不对App开放的变量target，它是一个Handler：
public final class Message implements Parcelable {
public int what;
public Object obj;
Handler target;
//以下省略很多代码哦
}
在App进程中，Application和四大组件的每个生命周期函数，都要和AMS进程进行跨进程通信。
1）App进程把数据传给AMS进程，是通过ActivityManagerNative完成的。
2）AMS进程把数据传给App进程，App进程这边接收数据的是ApplicationThread。
ApplicationThread在接收到数据后，会调用sendMessage方法。这就把消息Message对象发送给了MainLooper这个死循环。
在MainLooper死循环中，处理这个Message对象。怎么处理呢，取出它的target字段，这是一个Handler类型的对象，调用这个Handler对象的dispatchMessage方法。
是时候看一下Handler类的结构了，我简化了它的代码，为的是易于理解：
public class Handler {
final Callback mCallback;
public interface Callback {
public boolean handleMessage(Message msg);
}
public void handleMessage(Message msg) {
}
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
}
Handler类中有一个mCallback变量，这个变量是插件化技术的核心。书接上文，MainLooper调用了Handler的dispatchMessage方法，这个方法的逻辑是，要么执行mCallback的handleMessage方法，要么执行Handler类自己的handleMessage方法。
Handler类自己的handleMessage方法，是一个空方法，所以我们一般写一个Handler的子类，然后实现这个handleMessage方法。
在Android系统底层，这个Handler类的子类，就是H类，我们在ActivityThread.java中可以找到这个类。H类的handleMessage方法中，定义了所有消息的分发，如下所示：
public final class ActivityThread {
private class H extends Handler {
public static final int LAUNCH_ACTIVITY = 100;
public static final int PAUSE_ACTIVITY = 101;
public static final int PAUSE_ACTIVITY_FINISHING= 102;
public static final int STOP_ACTIVITY_SHOW = 103;
public static final int STOP_ACTIVITY_HIDE = 104;
public static final int SHOW_WINDOW = 105;
public static final int HIDE_WINDOW = 106;
public static final int RESUME_ACTIVITY = 107;
public static final int SEND_RESULT = 108;
public static final int DESTROY_ACTIVITY = 109;
public static final int BIND_APPLICATION = 110;
public static final int EXIT_APPLICATION = 111;
public static final int NEW_INTENT = 112;
public static final int RECEIVER = 113;
//以下省略很多代码
public void handleMessage(Message msg) {
switch (msg.what) {
case LAUNCH_ACTIVITY: {
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
} break;
//以下省略很多代码
}
}
}
}
在H类的handleMessage方法中，会根据msg参数的what值，来判断到底是哪种消息，以及相应的执行什么逻辑，比如说，启动Activity。
在H类中，定义了几十种消息，比如说LAUNCH_ACTIVITY的值是100，PAUSE_ACTIVITY的值是101。从100到109，都是给Activity的生命周期函数准备的。从110开始，才是给Application、Service、ContentProvider、BroadcastReceiver使用的。
至此，我们简单回顾了Android系统内部Message的发送和接收流程。其中比较重要的是：
1）Handler类中有一个mCallback变量。
2）H类中定义了各种消息。
3.1.2 Android P之前的插件化解决方案
在Android P（API level 28）之前，我们做插件化，都是Hook掉H类的mCallback对象，拦截这个对象的handleMessage方法。在此之前，我们把插件中的Activity替换为StubActtivty，那么现在，我们拦截到handleMessage方法，再把StubActivity换回为插件中的Activity，代码如下所示：
class MockClass2 implements Handler.Callback {
Handler mBase;
public MockClass2(Handler base) {
mBase = base;
}
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
// ActivityThread里面 "LAUNCH_ACTIVITY" 这个字段的值是100
// 本来使用反射的方式获取最好, 这里为了简便直接使用硬编码
case 100:
handleLaunchActivity(msg);
break;
}
mBase.handleMessage(msg);
return true;
}
private void handleLaunchActivity(Message msg) {
// 这里简单起见,直接取出TargetActivity;
Object obj = msg.obj;
// 把替身恢复成真身
Intent raw = (Intent) RefInvoke.getFieldObject(obj, "intent");
Intent target = raw.getParcelableExtra(AMSHookHelper.EXTRA_TARGET_INTENT);
raw.setComponent(target.getComponent());
}
}
3.1.3 Android P对Activity消息机制的改造
Android系统升级到P，它重构了H类，把100到109这10个用于Activity的消息，都合并为159这个消息，消息名为EXECUTE_TRANSACTION。
为什么要这么修改呢？相信大家面试Android工程师岗位的时候，都会被问及Activity的生命周期图。这其实是一个由Create、Pause、Resume、Stop、Destory、Restart组成的状态机。按照设计模式中状态模式的定义，可以把每个状态都定义成一个类，于是便有了如下的类图：
就拿LaunchActivity来说吧，在Android P之前，是在H类的handleMessage方法的switch分支语句中，编写启动一个Activity的逻辑：
public void handleMessage(Message msg) {
switch (msg.what) {
case LAUNCH_ACTIVITY: {
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
} break;
//以下省略很多代码
}
}
在Android P中，启动Activity的这部分逻辑，被转移到了LaunchActivityItem类的execute方法中。
public class LaunchActivityItem extends ClientTransactionItem {
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client);
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
}
}
从架构的角度来说，这次重构的效果很好。使用状态模式，使得Android这部分代码，就是OOP的了。我们把写在H类的handleMessage方法中的switch分支语句，拆分到很多类中，这就符合了五大设计原则中的开闭原则，宁肯有100个类，每个类有100行代码，也不要有一个一万行代码的类。好处是，当我想改动Resume这个状态的业务逻辑时，我只要在ResumeActivityItem类中修改并进行测试就可以了，影响的范围很小。
但是这次重构也有缺点，OOP的缺点就是代码会让人看不懂，因为只有在运行时才知道到底实例化的是哪个类，这让原本清晰的Android Activity消息逻辑变得支离破碎。
按照这个趋势，四大组件之一的Service，它在H类中也有很多消息，也是有很多生命周期函数，Android的下个版本，极有可能把Service也重构为状态模式。
3.1.4 Android P针对于H的Hook
Android P把H类中的100-109这10个消息都删除了，取而代之的是159这个消息，名为EXECUTE_TRANSACTION。
这就导致我们之前的插件化解决方案，在Android P上是不生效的，会因为找不到100这个消息，而不能把StubActiivty换回为插件中的Activity。为此，我们需要拦截159这个消息。拦截后，我们又要面对如何判断当前这个消息到底是Launch，还是Pause或者Resume。
关键在于H类的handleMessage方法的Message参数。这个Message的obj字段，在Message是159的时候，返回的是ClientTransacion类型对象，它内部有一个mActivityCallbacks集合：
public class ClientTransaction implements Parcelable, ObjectPoolItem {
private List<ClientTransactionItem> mActivityCallbacks;
}
这个mActivityCallbacks集合中，存放的是ClientTransactionItem的各种子类对象，比如LaunchActivityItem、DestoryActivityListItem。我们可以判断这个集合中的值，发现有某个元素是LaunchActivityItem类型的，那么就相当于捕获到了启动Activity的那个消息。
定位到LaunchActivityItem类的对象，它内部有一个mIntent字段，里面存放的就是要启动的Activity名称，目前值是StubActivity。在这里把它替换为真正要启动的插件Activity，代码如下所示：
class MockClass2 implements Handler.Callback {
Handler mBase;
public MockClass2(Handler base) {
mBase = base;
}
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
// ActivityThread里面 "LAUNCH_ACTIVITY" 这个字段的值是100
// 本来使用反射的方式获取最好, 这里为了简便直接使用硬编码
case 100: //for API 28以下
handleLaunchActivity(msg);
break;
case 159: //for API 28
handleActivity(msg);
break;
}
mBase.handleMessage(msg);
return true;
}
private void handleActivity(Message msg) {
// 这里简单起见,直接取出TargetActivity;
Object obj = msg.obj;
List<Object> mActivityCallbacks = (List<Object>) RefInvoke.getFieldObject(obj, "mActivityCallbacks");
if(mActivityCallbacks.size() > 0) {
String className = "android.app.servertransaction.LaunchActivityItem";
if(mActivityCallbacks.get(0).getClass().getCanonicalName().equals(className)) {
Object object = mActivityCallbacks.get(0);
Intent intent = (Intent) RefInvoke.getFieldObject(object, "mIntent");
Intent target = intent.getParcelableExtra(AMSHookHelper.EXTRA_TARGET_INTENT);
intent.setComponent(target.getComponent());
}
}
}
}
3.2 Instrumentation的变身
在Android P之前，Instrumentation的newActivity方法。逻辑如下：
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return (Activity)cl.loadClass(className).newInstance();
}
到了Android P，则改写了Instrumentation类的部分逻辑。它会在newActivity方法中，检查Instrumentation的mThread变量，如果为空，就会抛出一个异常：
public class Instrumentation {
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
String pkg = intent != null && intent.getComponent() != null
? intent.getComponent().getPackageName() : null;
return getFactory(pkg).instantiateActivity(cl, className, intent);
}
private AppComponentFactory getFactory(String pkg) {
if (pkg == null) {
Log.e(TAG, "No pkg specified, disabling AppComponentFactory");
return AppComponentFactory.DEFAULT;
}
if (mThread == null) {
Log.e(TAG, "Uninitialized ActivityThread, likely app-created Instrumentation,"
+ " disabling AppComponentFactory", new Throwable());
return AppComponentFactory.DEFAULT;
}
LoadedApk apk = mThread.peekPackageInfo(pkg, true);
// This is in the case of starting up "android".
if (apk == null) apk = mThread.getSystemContext().mPackageInfo;
return apk.getAppFactory();
}
}
我们在本书第5章介绍给一种Hook方案，拦截Instrumentation类的execStartActivity方法，如下所示：
public class HookHelper {
public static void attachContext() throws Exception{
// 先获取到当前的ActivityThread对象
Object currentActivityThread = RefInvoke.invokeStaticMethod("android.app.ActivityThread", "currentActivityThread");
// 拿到原始的 mInstrumentation字段
Instrumentation mInstrumentation = (Instrumentation) RefInvoke.getFieldObject(currentActivityThread, "mInstrumentation");
// 创建代理对象
Instrumentation evilInstrumentation = new EvilInstrumentation(mInstrumentation);
// 偷梁换柱
RefInvoke.setFieldObject(currentActivityThread, "mInstrumentation", evilInstrumentation);
}
}
public class EvilInstrumentation extends Instrumentation {
private static final String TAG = "EvilInstrumentation";
// ActivityThread中原始的对象, 保存起来
Instrumentation mBase;
public EvilInstrumentation(Instrumentation base) {
mBase = base;
}
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
Log.d(TAG, "XXX到此一游!");
// 开始调用原始的方法, 调不调用随你,但是不调用的话, 所有的startActivity都失效了.
// 由于这个方法是隐藏的,因此需要使用反射调用;首先找到这个方法
Class[] p1 = {Context.class, IBinder.class,
IBinder.class, Activity.class,
Intent.class, int.class, Bundle.class};
Object[] v1 = {who, contextThread, token, target,
intent, requestCode, options};
return (ActivityResult) RefInvoke.invokeInstanceMethod(
mBase, "execStartActivity", p1, v1);
}
}
这段代码，我们把系统原先的Instrumentation替换成EvilInstrumentation，在Android P以下的系统是可以运行的，但是在Android P上就会抛出Uninitialized ActivityThread, likely app-created Instrumentation的异常，显然这是因为EvilInstrumentation的mThread为空导致的。
想要解决这个问题，就必须重写EvilInstrumentation中的newActivity方法，如下所示：
public class EvilInstrumentation extends Instrumentation {
//省略了部分代码
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return mBase.newActivity(cl, className, intent);
}
}
这样编码，即使是EvilInstrumentation，在执行newActivity方法的时候，也会执行原先Instrumentation的newActivity方法，Instrumentation的mThread字段不是null，所以就不会抛出上述的异常信息了。