android 插件加载机制之二

弓背霞明剑照霜，秋风走马出咸阳。这篇文章主要讲述android 插件加载机制之二相关的知识，希望能为你提供帮助。
------本文转载自 Android插件化原理解析——插件加载机制
这一系列的文章实在是写的好!

5 Hook ClassLoader
从上述分析中我们得知，在获取LoadedApk的过程中使用了一份缓存数据；
这个缓存数据是一个Map，从包名到LoadedApk的一个映射。正常情况下，我们的插件肯定不会存在于这个对象里面；
但是如果我们手动把我们插件的信息添加到里面呢？系统在查找缓存的过程中，会直接命中缓存！
进而使用我们添加进去的LoadedApk的ClassLoader来加载这个特定的Activity类！这样我们就能接管我们自己插件类的加载过程了！
这个缓存对象mPackages存在于ActivityThread类中；老方法，我们首先获取这个对象：

// 先获取到当前的ActivityThread对象 Class< ?> activityThreadClass = Class.forName(" android.app.ActivityThread" ); Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod(" currentActivityThread" ); currentActivityThreadMethod.setAccessible(true); Object currentActivityThread = currentActivityThreadMethod.invoke(null); // 获取到 mPackages 这个静态成员变量, 这里缓存了dex包的信息 Field mPackagesField = activityThreadClass.getDeclaredField(" mPackages" ); mPackagesField.setAccessible(true); Map mPackages = (Map) mPackagesField.get(currentActivityThread);

拿到这个Map之后接下来怎么办呢？我们需要填充这个map，把插件的信息塞进这个map里面，
以便系统在查找的时候能命中缓存。但是这个填充这个Map我们出了需要包名之外，
还需要一个LoadedApk对象；如何创建一个LoadedApk对象呢？
我们当然可以直接反射调用它的构造函数直接创建出需要的对象，但是万一哪里有疏漏，构造参数填错了怎么办？
又或者Android的不同版本使用了不同的参数，导致我们创建出来的对象与系统创建出的对象不一致，无法work怎么办？
因此我们需要使用与系统完全相同的方式创建LoadedApk对象；从上文分析得知，
系统创建LoadedApk对象是通过getPackageInfo来完成的，因此我们可以调用这个函数来创建LoadedApk对象；
但是这个函数是private的，我们无法使用。
有的童鞋可能会有疑问了，private不是也能反射到吗？我们确实能够调用这个函数，
但是private表明这个函数是内部实现，或许那一天Google高兴，把这个函数改个名字我们就直接GG了；
但是public函数不同，public被导出的函数你无法保证是否有别人调用它，因此大部分情况下不会修改；
我们最好调用public函数来保证尽可能少的遇到兼容性问题。
（当然，如果实在木有路可以考虑调用私有方法，自己处理兼容性问题，这个我们以后也会遇到）
间接调用getPackageInfo这个私有函数的public函数有同名的getPackageInfo系列和getPackageInfoNoCheck；
简单查看源代码发现，getPackageInfo除了获取包的信息，还检查了包的一些组件；
为了绕过这些验证，我们选择使用getPackageInfoNoCheck获取LoadedApk信息。
5.1 构建插件LoadedApk对象我们这一步的目的很明确，通过getPackageInfoNoCheck函数创建出我们需要的LoadedApk对象，以供接下来使用。
这个函数的签名如下：

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai, CompatibilityInfo compatInfo) {

因此，为了调用这个函数，我们需要构造两个参数。其一是ApplicationInfo，其二是CompatibilityInfo；
第二个参数顾名思义，代表这个App的兼容性信息，比如targetSDK版本等等，这里我们只需要提取出app的信息，
因此直接使用默认的兼容性即可；在CompatibilityInfo类里面有一个公有字段
DEFAULT_COMPATIBILITY_INFO代表默认兼容性信息；因此，我们的首要目标是获取这个ApplicationInfo信息。
5.2 构建插件ApplicationInfo信息我们首先看看ApplicationInfo代表什么，这个类的文档说的很清楚：
Information you can retrieve about aparticular application. This corresponds to information collected from theAndroidManifest.xml’s < application> tag.
也就是说，这个类就是AndroidManifest.xml里面的这个标签下面的信息；
这个AndroidManifest.xml无疑是一个标准的xml文件，因此我们完全可以自己使用parse来解析这个信息。
那么，系统是如何获取这个信息的呢？其实Framework就有一个这样的parser，也即PackageParser；
理论上，我们也可以借用系统的parser来解析AndroidMAnifest.xml从而得到ApplicationInfo的信息。
但遗憾的是，这个类的兼容性很差；Google几乎在每一个Android版本都对这个类动刀子，
如果坚持使用系统的解析方式，必须写一系列兼容行代码！！DroidPlugin就选择了这种方式。
我们决定使用PackageParser类来提取ApplicationInfo信息, 看起来有我们需要的方法 generateApplication；
确实如此，依靠这个方法我们可以成功地拿到ApplicationInfo。
由于PackageParser是@hide的，因此我们需要通过反射进行调用。我们根据这个generateApplicationInfo方法的签名：

public static ApplicationInfo generateApplicationInfo(Package p, int flags, PackageUserState state)

可以写出调用generateApplicationInfo的反射代码：

Class< ?> packageParserClass = Class.forName(" android.content.pm.PackageParser" ); // 首先拿到我们得终极目标: generateApplicationInfo方法 // API 23 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! // public static ApplicationInfo generateApplicationInfo(Package p, int flags, //PackageUserState state) { // 其他Android版本不保证也是如此. Class< ?> packageParser$PackageClass = Class.forName(" android.content.pm.PackageParser$Package" ); Class< ?> packageUserStateClass = Class.forName(" android.content.pm.PackageUserState" ); Method generateApplicationInfoMethod = packageParserClass.getDeclaredMethod(" generateApplicationInfo" , packageParser$PackageClass,int.class, packageUserStateClass);

要成功调用这个方法，还需要三个参数；因此接下来我们需要一步一步构建调用此函数的参数信息。
5.3 构建PackageParser.PackagegenerateApplicationInfo方法需要的第一个参数是PackageParser.Package；
从名字上看这个类代表某个apk包的信息，我们看看文档怎么解释：
【android 插件加载机制之二】Representation of a full package parsed fromAPK files on disk. A package consists of a single base APK, and zero or moresplit APKs.
果然，这个类代表从PackageParser中解析得到的某个apk包的信息，是磁盘上apk文件在内存中的数据结构表示；
因此，要获取这个类，肯定需要解析整个apk文件。PackageParser中解析apk的核心方法是parsePackage，
这个方法返回的就是一个Package类型的实例，因此我们调用这个方法即可；使用反射代码如下：

// 首先, 我们得创建出一个Package对象出来供这个方法调用 // 而这个需要得对象可以通过 android.content.pm.PackageParser#parsePackage 这个方法返回得 Package对象得字段获取得到 // 创建出一个PackageParser对象供使用 Object packageParser = packageParserClass.newInstance(); // 调用 PackageParser.parsePackage 解析apk的信息 Method parsePackageMethod = packageParserClass.getDeclaredMethod(" parsePackage" , File.class, int.class); // 实际上是一个 android.content.pm.PackageParser.Package 对象 Object packageObj = parsePackageMethod.invoke(packageParser, apkFile, 0);

这样，我们就得到了generateApplicationInfo的第一个参数；第二个参数是解析包使用的flag，我们直接选择解析全部信息，也就是0；
5.4 构建PackageUserState第三个参数是PackageUserState，代表不同用户中包的信息。由于Android是一个多任务多用户系统，
因此不同的用户同一个包可能有不同的状态；这里我们只需要获取包的信息，因此直接使用默认的即可；
至此，generateApplicaionInfo的参数我们已经全部构造完成，直接调用此方法即可得到我们需要的applicationInfo对象；
在返回之前我们需要做一点小小的修改：使用系统系统的这个方法解析得到的ApplicationInfo对象
中并没有apk文件本身的信息，所以我们把解析的apk文件的路径设置一下（ClassLoa der依赖dex文件以及apk的路径）：

// 第三个参数 mDefaultPackageUserState 我们直接使用默认构造函数构造一个出来即可 Object defaultPackageUserState = packageUserStateClass.newInstance(); // 万事具备!!!!!!!!!!!!!! ApplicationInfo applicationInfo = (ApplicationInfo) generateApplicationInfoMethod.invoke(packageParser, packageObj, 0, defaultPackageUserState); String apkPath = apkFile.getPath(); applicationInfo.sourceDir = apkPath; applicationInfo.publicSourceDir = apkPath;

5.5 替换ClassLoader 5.5.1 获取LoadedApk信息
方才为了获取ApplicationInfo我们费了好大一番精力；回顾一下我们的初衷：
我们最终的目的是调用getPackageInfoNoCheck得到LoadedApk的信息，
并替换其中的mClassLoader然后把把添加到ActivityThread的mPackages缓存中；
从而达到我们使用自己的ClassLoader加载插件中的类的目的。
现在我们已经拿到了getPackageInfoNoCheck这个方法中至关重要的第一个参数applicationInfo；
上文提到第二个参数CompatibilityInfo代表设备兼容性信息，直接使用默认的值即可；
因此，两个参数都已经构造出来，我们可以调用getPackageInfoNoCheck获取LoadedApk：

// android.content.res.CompatibilityInfo Class< ?> compatibilityInfoClass = Class.forName(" android.content.res.CompatibilityInfo" ); Method getPackageInfoNoCheckMethod = activityThreadClass.getDeclaredMethod(" getPackageInfoNoCheck" , ApplicationInfo.class, compatibilityInfoClass); Field defaultCompatibilityInfoField = compatibilityInfoClass.getDeclaredField(" DEFAULT_COMPATIBILITY_INFO" ); defaultCompatibilityInfoField.setAccessible(true); Object defaultCompatibilityInfo = defaultCompatibilityInfoField.get(null); ApplicationInfo applicationInfo = generateApplicationInfo(apkFile); Object loadedApk = getPackageInfoNoCheckMethod.invoke(currentActivityThread, applicationInfo, defaultCompatibilityInfo);

我们成功地构造出了LoadedAPK, 接下来我们需要替换其中的ClassLoader，然后把它添加进ActivityThread的mPackages中：

String odexPath = Utils.getPluginOptDexDir(applicationInfo.packageName).getPath(); String libDir = Utils.getPluginLibDir(applicationInfo.packageName).getPath(); ClassLoader classLoader = new CustomClassLoader(apkFile.getPath(), odexPath, libDir, ClassLoader.getSystemClassLoader()); Field mClassLoaderField = loadedApk.getClass().getDeclaredField(" mClassLoader" ); mClassLoaderField.setAccessible(true); mClassLoaderField.set(loadedApk, classLoader); // 由于是弱引用, 因此我们必须在某个地方存一份, 不然容易被GC; 那么就前功尽弃了. sLoadedApk.put(applicationInfo.packageName, loadedApk); WeakReference weakReference = new WeakReference(loadedApk); mPackages.put(applicationInfo.packageName, weakReference);

我们的这个CustomClassLoader非常简单，直接继承了DexClassLoader，什么都没有做；
当然这里可以直接使用DexClassLoader，这里重新创建一个类是为了更有区分度；
以后也可以通过修改这个类实现对于类加载的控制：

public class CustomClassLoader extends DexClassLoader {public CustomClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent) { super(dexPath, optimizedDirectory, libraryPath, parent); } }

到这里，我们已经成功地把把插件的信息放入ActivityThread中，这样我们插件中的类能够成功地被加载；
因此插件中的Activity实例能被成功第创建；由于整个流程较为复杂，我们简单梳理一下：
1,在ActivityThread接收到IApplication的scheduleLaunchActivity远程调用之后，将消息转发给H
2,H类在handleMessage的时候，调用了getPackageInfoNoCheck方法来获取待启动的组件信息。
在这个方法中会优先查找mPackages中的缓存信息，而我们已经手动把插件信息添加进去；
因此能够成功命中缓存，获取到独立存在的插件信息。
3,H类然后调用handleLaunchActivity最终转发到performLaunchActivity方法；
这个方法使用从getPackageInfoNoCheck中拿到LoadedApk中的mClassLoader来加载Activity类，
进而使用反射创建Activity实例；接着创建Application，Context等完成Activity组件的启动。
看起来好像已经天衣无缝万事大吉了；但是运行一下会出现一个异常。
错误提示说是无法实例化 Application，而Application的创建也是在performLaunchActivity中进行的，这里有些蹊跷，我们仔细查看一下。
5.5.2 绕过系统检查
通过ActivityThread的performLaunchActivity方法可以得知，Application通过LoadedApk的makeApplication方法创建，
我们查看这个方法，在源码中发现了上文异常抛出的位置：

try { java.lang.ClassLoader cl = getClassLoader(); if (!mPackageName.equals(" android" )) { initializeJavaContextClassLoader(); } ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this); app = mActivityThread.mInstrumentation.newApplication( cl, appClass, appContext); appContext.setOuterContext(app); } catch (Exception e) { if (!mActivityThread.mInstrumentation.onException(app, e)) { throw new RuntimeException( " Unable to instantiate application " + appClass + " : " + e.toString(), e); } }

木有办法，我们只有一行一行地查看到底是哪里抛出这个异常的了；
所幸代码不多。（所以说，缩小异常范围是一件多么重要的事情！！！）
第一句 getClassLoader() 没什么可疑的，虽然方法很长，但是它木有抛出任何异常
（当然，它调用的代码可能抛出异常，万一找不到只能进一步深搜了；所以我觉得这里应该使用受检异常）。
然后我们看第二句，如果包名不是android开头，那么调用了一个叫做initializeJavaContextClassLoader的方法；我们查阅这个方法：

private void initializeJavaContextClassLoader() { IPackageManager pm = ActivityThread.getPackageManager(); android.content.pm.PackageInfo pi; try { pi = pm.getPackageInfo(mPackageName, 0, UserHandle.myUserId()); } catch (RemoteException e) { throw new IllegalStateException(" Unable to get package info for " + mPackageName + " ; is system dying?" , e); } if (pi == null) { throw new IllegalStateException(" Unable to get package info for " + mPackageName + " ; is package not installed?" ); }boolean sharedUserIdSet = (pi.sharedUserId != null); boolean processNameNotDefault = (pi.applicationInfo != null & & !mPackageName.equals(pi.applicationInfo.processName)); boolean sharable = (sharedUserIdSet || processNameNotDefault); ClassLoader contextClassLoader = (sharable) ? new WarningContextClassLoader() : mClassLoader; Thread.currentThread().setContextClassLoader(contextClassLoader); }

这里，我们找出了这个异常的来源：原来这里调用了getPackageInfo方法获取包的信息；
而我们的插件并没有安装在系统上，因此系统肯定认为插件没有安装，这个方法肯定返回null。
所以，我们还要欺骗一下PMS，让系统觉得插件已经安装在系统上了；
至于如何欺骗 PMS，Hook机制之AMS& PMS 有详细解释，这里直接给出代码，不赘述了：

private static void hookPackageManager() throws Exception {// 这一步是因为 initializeJavaContextClassLoader 这个方法内部无意中检查了这个包是否在系统安装 // 如果没有安装, 直接抛出异常, 这里需要临时Hook掉 PMS, 绕过这个检查.Class< ?> activityThreadClass = Class.forName(" android.app.ActivityThread" ); Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod(" currentActivityThread" ); currentActivityThreadMethod.setAccessible(true); Object currentActivityThread = currentActivityThreadMethod.invoke(null); // 获取ActivityThread里面原始的 sPackageManager Field sPackageManagerField = activityThreadClass.getDeclaredField(" sPackageManager" ); sPackageManagerField.setAccessible(true); Object sPackageManager = sPackageManagerField.get(currentActivityThread); // 准备好代理对象, 用来替换原始的对象 Class< ?> iPackageManagerInterface = Class.forName(" android.content.pm.IPackageManager" ); Object proxy = Proxy.newProxyInstance(iPackageManagerInterface.getClassLoader(), new Class< ?> [] { iPackageManagerInterface }, new IPackageManagerHookHandler(sPackageManager)); // 1. 替换掉ActivityThread里面的 sPackageManager 字段 sPackageManagerField.set(currentActivityThread, proxy); }

OK到这里，我们已经能够成功地加载简单的独立的存在于外部文件系统中的apk了。
至此关于DroidPlugin 对于Activity生命周期的管理已经完全讲解完毕了；
这是一种极其复杂的Activity管理方案，我们仅仅写一个用来理解的demo就Hook了相当多的东西，
在Framework层来回牵扯；这其中的来龙去脉要完全把握清楚还请读者亲自翻阅源码。
上文给出的方案中，我们全盘接管了插件中类的加载过程，这是一种相对暴力的解决方案。
6.小结本文中我们采用两种方案成功完成了『启动没有在AndroidManifest.xml中显示声明，并且存在于外部插件中的Activity』的任务。
『激进方案』中我们自定义了插件的ClassLoader，并且绕开了Framework的检测；
利用ActivityThread对于LoadedApk的缓存机制，我们把携带这个自定义的ClassLoader的插件信息添加进mPackages中，进而完成了类的加载过程。
『保守方案』中我们深入探究了系统使用ClassLoaderfindClass的过程，
发现应用程序使用的非系统类都是通过同一个PathClassLoader加载的；
而这个类的最终父类BaseDexClassLoader通过DexPathList完成类的查找过程；我们hack了这个查找过程，从而完成了插件类的加载。
这两种方案孰优孰劣呢？
很显然，『激进方案』比较麻烦，从代码量和分析过程就可以看出来，这种机制异常复杂；
而且在解析apk的时候我们使用的PackageParser的兼容性非常差，我们不得不手动处理每一个版本的apk解析api；
另外，它Hook的地方也有点多：不仅需要Hook AMS和H，还需要Hook ActivityThread的mPackages和PackageManager！
『保守方案』则简单得多（虽然原理也不简单），不仅代码很少，而且Hook的地方也不多；
有一点正本清源的意思，从最最上层Hook住了整个类的加载过程。
但是，我们不能简单地说『保守方案』比『激进方案』好。从根本上说，这两种方案的差异在哪呢？
『激进方案』是多ClassLoader构架，每一个插件都有一个自己的ClassLoader，
因此类的隔离性非常好——如果不同的插件使用了同一个库的不同版本，它们相安无事！
『保守方案』是单ClassLoader方案，插件和宿主程序的类全部都通过宿主的ClasLoader加载，
虽然代码简单，但是鲁棒性很差；一旦插件之间甚至插件与宿主之间使用的类库有冲突，那么直接GG。
多ClassLoader还有一个优点：可以真正完成代码的热加载！如果插件需要升级，
直接重新创建一个自定的ClassLoader加载新的插件，然后替换掉原来的版本即可
（Java中，不同ClassLoader加载的同一个类被认为是不同的类）；
单ClassLoader的话实现非常麻烦，有可能需要重启进程。
在J2EE领域中广泛使用ClasLoader的地方均采用多ClassLoader架构，比如Tomcat服务器，
Java模块化事实标准的OSGi技术；所以，我们有足够的理由认为选择多ClassLoader架构在大多数情况下是明智之举。
目前开源的插件方案中，DroidPlugin采用的『激进方案』，Small采用的『保守方案』那么，有没有两种优点兼顾的方案呢？？
答案自然是有的。
DroidPlugin和Small的共同点是两者都是非侵入式的插件框架；
什么是『非侵入式』呢？打个比方，你启动一个插件Activity，直接使用startActivity即可，
就跟开发普通的apk一样，开发插件和普通的程序对于开发者来说没有什么区别。
如果我们一定程度上放弃这种『侵入性』，那么我们就能实现一个两者优点兼而有之的插件框架！
OK，本文的内容就到这里了；关于『插件机制对于Activity的处理方式』也就此完结。
要说明的是，在本文的『保守方案』其实只处理了代码的加载过程，它并不能加载有资源的apk！
所以目前我这个实现基本没什么暖用；当然我这里只是就『代码加载』进行举例.