MultiDex（三）之异步加载优化

一、前言

在上一篇文章《Multidex&＃xff08;二&＃xff09;之Dex预加载优化》中我们提到主进程中直接开启一个子线程执行MultiDex的工作确实可以避免ANR的问题&＃xff0c;然而此时主进程中调用到的类&＃xff0c;可能会因为SecondaryDex的优化尚未完成或者没有被加入到ClassLoader中而导致画面太美不敢看的ClassNotFoundException。如何是好&＃xff1f;明知山有虎&＃xff0c;偏往虎山行&＃xff01;

本文就带你实战MultiDex的异步加载优化。

二、分析

既然我们要做的是异步加载优化&＃xff0c;那毋庸置疑MultiDex.install是要放在子线程了&＃xff0c;这步简单。接下来我们分析下ClassNotFoundException的原因&＃xff0c;在非主Dex没有被优化、加载到ClassLoader之前引用到了其中的Class&＃xff0c;肯定找不到秒秒钟异常给你看。那问题就转换成了下面这两个&＃xff1a;

• 如何保证程序的入口类以及入口类的引用类都在主Dex&＃xff1f;
• 以及在非主Dex类加载的时候如何进行判断干预&＃xff1f;

问题一&＃xff1a;在保证主Dex不被撑爆的前提下&＃xff0c;我们可以定义一个Task对Gradle打包的流程进行自定义&＃xff0c;将程序的入口类以及入口类的引用类都放到主Dex中。
问题二&＃xff1a;在非主Dex类加载的时候进行校验&＃xff0c;当异步优化还没完成的时候返回或者加载一个Loading的界面提示用户等待。如何对一个具体的类进行校验呢&＃xff1f;看起来比较复杂。换个思路&＃xff0c;我们把基类都放到主Dex中&＃xff0c;保证非主Dex加载的时候都是调用四大组件&＃xff0c;然后进行Hook。这样非主Dex被调用的时候都是通过四大组件来调用的&＃xff0c;而基础类都在主Dex已经提前被加载&＃xff0c;可以放心调用。

三、上代码&＃xff0c;Show The Code

Application异步执行Multidex.install&＃xff1b;

public static boolean dexLoadDone;//标示非主Dex有没有被加载成功&＃64;Override
protected void attachBaseContext(Context base) {super.attachBaseContext(base);hookInstrumentation();new Thread(){&＃64;Overridepublic void run() {super.run();//子线程执行&＃xff0c;完成后修改标示MultiDex.install(ChrApplication.this);dexLoadDone &＃61; true;}}.start();
}

干预打包流程&＃xff0c;保证入口类以及入口类的引用类都放在主Dex中。

如何对四大组件进行Hook&＃xff1f;此处分析Activity为例。
startActivty的时候最终都会调用到Instrumentation.execStartActivity方法。
ContextImpl.java

&＃64;Overridepublic void startActivity(Intent intent, Bundle options) {warnIfCallingFromSystemProcess();if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) &＃61;&＃61; 0) {throw new AndroidRuntimeException("Calling startActivity() from outside of an Activity "&＃43; " context requires the FLAG_ACTIVITY_NEW_TASK flag."&＃43; " Is this really what you want?");}mMainThread.getInstrumentation().execStartActivity(getOuterContext(), mMainThread.getApplicationThread(), null,(Activity) null, intent, -1, options);}

Activity.java

public void startActivityForResult(Intent intent, int requestCode, &＃64;Nullable Bundle options) {if (mParent &＃61;&＃61; null) {Instrumentation.ActivityResult ar &＃61;mInstrumentation.execStartActivity(this, mMainThread.getApplicationThread(), mToken, this,intent, requestCode, options);if (ar !&＃61; null) {mMainThread.sendActivityResult(mToken, mEmbeddedID, requestCode, ar.getResultCode(),ar.getResultData());}if (requestCode >&＃61; 0) {// If this start is requesting a result, we can avoid making// the activity visible until the result is received. Setting// this code during onCreate(Bundle savedInstanceState) or onResume() will keep the// activity hidden during this time, to avoid flickering.// This can only be done when a result is requested because// that guarantees we will get information back when the// activity is finished, no matter what happens to it.mStartedActivity &＃61; true;}cancelInputsAndStartExitTransition(options);// TODO Consider clearing/flushing other event sources and events for child windows.} else {if (options !&＃61; null) {mParent.startActivityFromChild(this, intent, requestCode, options);} else {// Note we want to go through this method for compatibility with// existing applications that may have overridden it.mParent.startActivityFromChild(this, intent, requestCode);}}
}

追踪Instrumentation对象的来路&＃xff0c;是在ActivityThread里的performLaunchActivity方法。那我们就对Instrumentation进行Hook。

/** ** 最好在Application中调。*/public void hookInstrumentation() {try {Class activityThreadClass &＃61; Class.forName("android.app.ActivityThread");Method currentActivityThreadMethod &＃61; activityThreadClass.getDeclaredMethod("currentActivityThread");currentActivityThreadMethod.setAccessible(true);//通过currentActivityThread这个静态的方法获取到ActivityThread的实例对象。Object currentActivityThread &＃61; currentActivityThreadMethod.invoke(null);// 拿到原始的 mInstrumentation字段Field mInstrumentationField &＃61; activityThreadClass.getDeclaredField("mInstrumentation");mInstrumentationField.setAccessible(true);Instrumentation mInstrumentation &＃61; (Instrumentation) mInstrumentationField.get(currentActivityThread);// 创建代理对象Instrumentation chrInstrumentation &＃61; new ChrInstrumentation(mInstrumentation);// 替换mInstrumentationField.set(currentActivityThread, chrInstrumentation);} catch (Exception e) {Log.i("lz", "hookInstrumentation Exception");}
}public class ChrInstrumentation extends Instrumentation{
// ActivityThread中原始对象&＃xff0c;反射需要
private Instrumentation mBase;public ChrInstrumentation(Instrumentation base) {mBase &＃61; base;
}&＃64;Override
public Activity newActivity(ClassLoader cl, String className, Intent intent) throws InstantiationException, IllegalAccessException, ClassNotFoundException {if(!ChrApplication.dexLoadDone){//没有完成MultiDex的加载&＃xff0c;就替换显示Activity。className &＃61; LoadDexActivity.class.getName();Log.i("lz","未完成&＃xff0c;重定向");}return super.newActivity(cl, className, intent);
}public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,Intent intent, int requestCode, Bundle options) {try {//newActivity与execStartActivity两个方法只需要覆写一个即可。if (!ChrApplication.dexLoadDone) {intent &＃61; new Intent(MyApp.myApp, ThirdActivity.class);}//这个方法是&＃64;hide的&＃xff0c;反射调用。Method execStartActivity &＃61; Instrumentation.class.getDeclaredMethod("execStartActivity",Context.class, IBinder.class, IBinder.class, Activity.class,Intent.class, int.class, Bundle.class);execStartActivity.setAccessible(true);return (ActivityResult) execStartActivity.invoke(mBase, who,contextThread, token, target, intent, requestCode, options);} catch (Exception e) {Log.i("lz", e.toString());return null;}
}}

此处重写了Instrumentation的两个方法&＃xff0c;newActivity与execStartActivity&＃xff0c;这两个方法都可以实现我们的需求&＃xff0c;具体用哪一个呢&＃xff1f;推荐newActivity&＃xff0c;此处创建Activity对象&＃xff0c;执行顺序靠前。

四、看效果

反编译查看方法数以及keep_in_main_dex.txt里的文件是否在主Dex中。

在子线程中Sleep若干秒&＃xff0c;快速点击非主Dex中的Activity&＃xff0c;制造现场。可以看到打印出来的Log以及&＃xff0c;显示的Activity也是LoadDexActivity&＃xff0c;实现了拦截。

五、问题

1、这个方案的缺点&＃xff1f;
通过以上分析及代码实践&＃xff0c;可以看到&＃xff0c;这个方案虽然实现了Dex在主进程的子线程中的加载&＃xff0c;但是改动量极大&＃xff1b;

• 需要对Gradle打包的过程进行定制&＃xff0c;将入口类以及入口类的引用类都放的keep_in_main_dex.txt&＃xff0c;这个过程需要用脚本实现&＃xff0c;并且经常性的更新、维护&＃xff1b;
• 不同版本Gradle的Api可能会有变化&＃xff0c;因此需要额外处理&＃xff1b;
• 本文分析的是对Activity的Hook&＃xff0c;而原则上四大组件都需要Hook&＃xff0c;时间成本上肯定更长&＃xff1b;
• 还有其他类如记录真实跳转Activity&＃xff0c;在异步处理完毕之后跳往真实Activity的逻辑。

2、推荐方案&＃xff1f;
鉴于问题1中描述的缺点&＃xff0c;所以更推荐上一篇文章《Multidex&＃xff08;二&＃xff09;之Dex预加载优化》的方案&＃xff0c;使用方便简单。


以上就是MultiDex系列文章的全部三篇&＃xff0c;对MultiDex的原理及优化方案进行了分析。

欢迎关注微信公众号&＃xff1a;定期分享Java、Android干货&＃xff01;