插件加載機(jī)制

上文 Activity生命周期管理 中我們地完成了『啟動沒有在AndroidManifest.xml中顯式聲明的Activity』的任務(wù)；通過Hook AMS和攔截ActivityThread中H類對于組件調(diào)度我們成功地繞過了AndroidMAnifest.xml的限制。

但是我們啟動的『沒有在AndroidManifet.xml中顯式聲明』的Activity和宿主程序存在于同一個Apk中；通常情況下，插件均以獨(dú)立的文件存在甚至通過網(wǎng)絡(luò)獲取，這時候插件中的Activity能否成功啟動呢？

要啟動Activity組件肯定先要創(chuàng)建對應(yīng)的Activity類的對象，從上文 Activity生命周期管理 知道，創(chuàng)建Activity類對象的過程如下：

java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
        cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);

也就是說，系統(tǒng)通過ClassLoader加載了需要的Activity類并通過反射調(diào)用構(gòu)造函數(shù)創(chuàng)建出了Activity對象。如果Activity組件存在于獨(dú)立于宿主程序的文件之中，系統(tǒng)的ClassLoader怎么知道去哪里加載呢？因此，如果不做額外的處理，插件中的Activity對象甚至都沒有辦法創(chuàng)建出來，談何啟動？

因此，要使存在于獨(dú)立文件或者網(wǎng)絡(luò)中的插件被成功啟動，首先就需要解決這個插件類加載的問題。
下文將圍繞此問題展開，完成『啟動沒有在AndroidManifest.xml中顯示聲明，并且存在于外部插件中的Activity』的任務(wù)。

閱讀本文之前，可以先clone一份 understand-plugin-framework，參考此項目的classloader-hook 模塊。另外，插件框架原理解析系列文章見索引。

ClassLoader機(jī)制

或許有的童鞋還不太了解Java的ClassLoader機(jī)制，我這里簡要介紹一下。

Java虛擬機(jī)把描述類的數(shù)據(jù)從Class文件加載到內(nèi)存，并對數(shù)據(jù)進(jìn)行校檢、轉(zhuǎn)換解析和初始化的，最終形成可以被虛擬機(jī)直接使用的Java類型，這就是虛擬機(jī)的類加載機(jī)制。
與那些在編譯時進(jìn)行鏈連接工作的語言不同，在Java語言里面，類型的加載、連接和初始化都是在程序運(yùn)行期間完成的，這種策略雖然會令類加載時稍微增加一些性能開銷，但是會為Java應(yīng)用程序提供高度的靈活性，Java里天生可以同代拓展的語言特性就是依賴運(yùn)行期動態(tài)加載和動態(tài)鏈接這個特點(diǎn)實(shí)現(xiàn)的。例如，如果編寫一個面相接口的應(yīng)用程序，可以等到運(yùn)行時在制定實(shí)際的實(shí)現(xiàn)類；用戶可以通過Java與定義的和自定義的類加載器，讓一個本地的應(yīng)用程序可以在運(yùn)行時從網(wǎng)絡(luò)或其他地方加載一個二進(jìn)制流作為代碼的一部分，這種組裝應(yīng)用程序的方式目前已經(jīng)廣泛應(yīng)用于Java程序之中。從最基礎(chǔ)的Applet，JSP到復(fù)雜的OSGi技術(shù)，都使用了Java語言運(yùn)行期類加載的特性。

Java的類加載是一個相對復(fù)雜的過程；它包括加載、驗證、準(zhǔn)備、解析和初始化五個階段；對于開發(fā)者來說，可控性最強(qiáng)的是加載階段；加載階段主要完成三件事：

1. 根據(jù)一個類的全限定名來獲取定義此類的二進(jìn)制字節(jié)流
2. 將這個字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為JVM方法區(qū)中的運(yùn)行時數(shù)據(jù)結(jié)構(gòu)
3. 在內(nèi)存中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口。

『通過一個類的全限定名獲取描述此類的二進(jìn)制字節(jié)流』這個過程被抽象出來，就是Java的類加載器模塊，也即JDK中ClassLoader API。

Android Framework提供了DexClassLoader這個類，簡化了『通過一個類的全限定名獲取描述次類的二進(jìn)制字節(jié)流』這個過程；我們只需要告訴DexClassLoader一個dex文件或者apk文件的路徑就能完成類的加載。因此本文的內(nèi)容用一句話就可以概括：

將插件的dex或者apk文件告訴『合適的』DexClassLoader，借助它完成插件類的加載

關(guān)于CLassLoader機(jī)制更多的內(nèi)容，請參閱『深入理解Java虛擬機(jī)』這本書。

思路分析

Android系統(tǒng)使用了ClassLoader機(jī)制來進(jìn)行Activity等組件的加載；apk被安裝之后，APK文件的代碼以及資源會被系統(tǒng)存放在固定的目錄（比如/data/app/package_name/base-1.apk )系統(tǒng)在進(jìn)行類加載的時候，會自動去這一個或者幾個特定的路徑來尋找這個類；但是系統(tǒng)并不知道存在于插件中的Activity組件的信息(插件可以是任意位置，甚至是網(wǎng)絡(luò)，系統(tǒng)無法提前預(yù)知)，因此正常情況下系統(tǒng)無法加載我們插件中的類；因此也沒有辦法創(chuàng)建Activity的對象，更不用談啟動組件了。

解決這個問題有兩個思路，要么全盤接管這個類加載的過程；要么告知系統(tǒng)我們使用的插件存在于哪里，讓系統(tǒng)幫忙加載；這兩種方式或多或少都需要干預(yù)這個類加載的過程。老規(guī)矩，知己知彼，百戰(zhàn)不殆。我們首先分析一下，系統(tǒng)是如果完成這個類加載過程的。

我們再次搬出Activity的創(chuàng)建過程的代碼：

java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);

這里可以很明顯地看到，系統(tǒng)通過待啟動的Activity的類名className，然后使用ClassLoader對象cl把這個類加載進(jìn)虛擬機(jī)，最后使用反射創(chuàng)建了這個Activity類的實(shí)例對象。要想干預(yù)這個ClassLoader（告知它我們的路徑或者替換他），我們首先得看看這玩意到底是個什么來頭。（從哪里創(chuàng)建的）

cl這個ClasssLoader對象通過r.packageInfo對象的getClassLoader()方法得到，r.packageInfo是一個LoadedApk類的對象；那么，LoadedApk到底是個什么東西？？

我們查閱LoadedApk類的文檔，只有一句話，不過說的很明白：

Local state maintained about a currently loaded .apk.

LoadedApk對象是APK文件在內(nèi)存中的表示。 Apk文件的相關(guān)信息，諸如Apk文件的代碼和資源，甚至代碼里面的Activity，Service等組件的信息我們都可以通過此對象獲取。

OK, 我們知道這個LoadedApk是何方神圣了；接下來我們要搞清楚的是：這個 r.packageInfo 到底是從哪里獲取的？

我們順著 performLaunchActivity上溯，輾轉(zhuǎn)handleLaunchActivity回到了 H 類的LAUNCH_ACTIVITY消息，找到了r.packageInfo的來源：

final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
        r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null);

getPackageInfoNoCheck方法很簡單，直接調(diào)用了getPackageInfo方法：

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
        CompatibilityInfo compatInfo) {
    return getPackageInfo(ai, compatInfo, null, false, true, false);
}

在這個getPackageInfo方法里面我們發(fā)現(xiàn)了端倪：

private LoadedApk getPackageInfo(ApplicationInfo aInfo, CompatibilityInfo compatInfo,
        ClassLoader baseLoader, boolean securityViolation, boolean includeCode,
        boolean registerPackage) {
        // 獲取userid信息
    final boolean differentUser = (UserHandle.myUserId() != UserHandle.getUserId(aInfo.uid));
    synchronized (mResourcesManager) {
    // 嘗試獲取緩存信息
        WeakReference<LoadedApk> ref;
        if (differentUser) {
            // Caching not supported across users
            ref = null;
        } else if (includeCode) {
            ref = mPackages.get(aInfo.packageName);
        } else {
            ref = mResourcePackages.get(aInfo.packageName);
        }

        LoadedApk packageInfo = ref != null ? ref.get() : null;
        if (packageInfo == null || (packageInfo.mResources != null
                && !packageInfo.mResources.getAssets().isUpToDate())) {
                // 緩存沒有命中，直接new
            packageInfo =
                new LoadedApk(this, aInfo, compatInfo, baseLoader,
                        securityViolation, includeCode &&
                        (aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0, registerPackage);

        // 省略。。更新緩存
        return packageInfo;
    }
}

這個方法很重要，我們必須弄清楚每一步；

首先，它判斷了調(diào)用方和或許App信息的一方是不是同一個userId；如果是同一個user，那么可以共享緩存數(shù)據(jù)（要么緩存的代碼數(shù)據(jù)，要么緩存的資源數(shù)據(jù)）

接下來嘗試獲取緩存數(shù)據(jù)；如果沒有命中緩存數(shù)據(jù)，才通過LoadedApk的構(gòu)造函數(shù)創(chuàng)建了LoadedApk對象；創(chuàng)建成功之后，如果是同一個uid還放入了緩存。

提到緩存數(shù)據(jù)，看過Hook機(jī)制之Binder Hook的童鞋可能就知道了，我們之前成功借助ServiceManager的本地代理使用緩存的機(jī)制Hook了各種Binder；因此這里完全可以如法炮制——我們拿到這一份緩存數(shù)據(jù)，修改里面的ClassLoader；自己控制類加載的過程，這樣加載插件中的Activity類的問題就解決了。這就引出了我們加載插件類的第一種方案：

激進(jìn)方案：Hook掉ClassLoader，自己操刀

從上述分析中我們得知，在獲取LoadedApk的過程中使用了一份緩存數(shù)據(jù)；這個緩存數(shù)據(jù)是一個Map，從包名到LoadedApk的一個映射。正常情況下，我們的插件肯定不會存在于這個對象里面；但是如果我們手動把我們插件的信息添加到里面呢？系統(tǒng)在查找緩存的過程中，會直接命中緩存！進(jìn)而使用我們添加進(jìn)去的LoadedApk的ClassLoader來加載這個特定的Activity類！這樣我們就能接管我們自己插件類的加載過程了！

這個緩存對象mPackages存在于ActivityThread類中；老方法，我們首先獲取這個對象：

// 先獲取到當(dāng)前的ActivityThread對象
Class<?> activityThreadClass = Class.forName("android.app.ActivityThread");
Method currentActivityThreadMethod = activityThreadClass.getDeclaredMethod("currentActivityThread");
currentActivityThreadMethod.setAccessible(true);
Object currentActivityThread = currentActivityThreadMethod.invoke(null);

// 獲取到 mPackages 這個靜態(tài)成員變量, 這里緩存了dex包的信息
Field mPackagesField = activityThreadClass.getDeclaredField("mPackages");
mPackagesField.setAccessible(true);
Map mPackages = (Map) mPackagesField.get(currentActivityThread);

拿到這個Map之后接下來怎么辦呢？我們需要填充這個map，把插件的信息塞進(jìn)這個map里面，以便系統(tǒng)在查找的時候能命中緩存。但是這個填充這個Map我們出了需要包名之外，還需要一個LoadedApk對象；如何創(chuàng)建一個LoadedApk對象呢？

我們當(dāng)然可以直接反射調(diào)用它的構(gòu)造函數(shù)直接創(chuàng)建出需要的對象，但是萬一哪里有疏漏，構(gòu)造參數(shù)填錯了怎么辦？又或者Android的不同版本使用了不同的參數(shù)，導(dǎo)致我們創(chuàng)建出來的對象與系統(tǒng)創(chuàng)建出的對象不一致，無法work怎么辦？

因此我們需要使用與系統(tǒng)完全相同的方式創(chuàng)建LoadedApk對象；從上文分析得知，系統(tǒng)創(chuàng)建LoadedApk對象是通過getPackageInfo來完成的，因此我們可以調(diào)用這個函數(shù)來創(chuàng)建LoadedApk對象；但是這個函數(shù)是private的，我們無法使用。

有的童鞋可能會有疑問了，private不是也能反射到嗎？我們確實(shí)能夠調(diào)用這個函數(shù)，但是private表明這個函數(shù)是內(nèi)部實(shí)現(xiàn)，或許那一天Google高興，把這個函數(shù)改個名字我們就直接GG了；但是public函數(shù)不同，public被導(dǎo)出的函數(shù)你無法保證是否有別人調(diào)用它，因此大部分情況下不會修改；我們最好調(diào)用public函數(shù)來保證盡可能少的遇到兼容性問題。（當(dāng)然，如果實(shí)在木有路可以考慮調(diào)用私有方法，自己處理兼容性問題，這個我們以后也會遇到）

間接調(diào)用getPackageInfo這個私有函數(shù)的public函數(shù)有同名的getPackageInfo系列和getPackageInfoNoCheck；簡單查看源代碼發(fā)現(xiàn)，getPackageInfo除了獲取包的信息，還檢查了包的一些組件；為了繞過這些驗證，我們選擇使用getPackageInfoNoCheck獲取LoadedApk信息。

構(gòu)建插件LoadedApk對象

我們這一步的目的很明確，通過getPackageInfoNoCheck函數(shù)創(chuàng)建出我們需要的LoadedApk對象，以供接下來使用。

這個函數(shù)的簽名如下：

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

因此，為了調(diào)用這個函數(shù)，我們需要構(gòu)造兩個參數(shù)。其一是ApplicationInfo，其二是CompatibilityInfo；第二個參數(shù)顧名思義，代表這個App的兼容性信息，比如targetSDK版本等等，這里我們只需要提取出app的信息，因此直接使用默認(rèn)的兼容性即可；在CompatibilityInfo類里面有一個公有字段DEFAULT_COMPATIBILITY_INFO代表默認(rèn)兼容性信息；因此，我們的首要目標(biāo)是獲取這個ApplicationInfo信息。

構(gòu)建插件ApplicationInfo信息

我們首先看看ApplicationInfo代表什么，這個類的文檔說的很清楚：

Information you can retrieve about a particular application. This corresponds to information collected from the AndroidManifest.xml's <application> tag.

也就是說，這個類就是AndroidManifest.xml里面的<application> 這個標(biāo)簽下面的信息；這個AndroidManifest.xml無疑是一個標(biāo)準(zhǔn)的xml文件，因此我們完全可以自己使用parse來解析這個信息。

那么，系統(tǒng)是如何獲取這個信息的呢？其實(shí)Framework就有一個這樣的parser，也即PackageParser；理論上，我們也可以借用系統(tǒng)的parser來解析AndroidMAnifest.xml從而得到ApplicationInfo的信息。但遺憾的是，這個類的兼容性很差；Google幾乎在每一個Android版本都對這個類動刀子，如果堅持使用系統(tǒng)的解析方式，必須寫一系列兼容行代碼！！DroidPlugin就選擇了這種方式，相關(guān)類如下：

<img src="http://7xp3xc.com1.z0.glb.clouddn.com/201601/1459829051777.png" width="283" alt="DroidPlugin的PackageParser"/>

看到這里我就問你怕不怕！！！這也是我們之前提到的私有或者隱藏的API可以使用，但必須處理好兼容性問題；如果Android 7.0發(fā)布，這里估計得添加一個新的類PackageParseApi24。

我這里使用API 23作為演示，版本不同的可能無法運(yùn)行請自行查閱 DroidPlugin 不同版本如何處理。

OK回到正題，我們決定使用PackageParser類來提取ApplicationInfo信息。下圖是API 23上，PackageParser的部分類結(jié)構(gòu)圖：

<img src="http://7xp3xc.com1.z0.glb.clouddn.com/201601/1459829674687.png" width="481"/>

看起來有我們需要的方法 generateApplication；確實(shí)如此，依靠這個方法我們可以成功地拿到ApplicationInfo。
由于PackageParser是@hide的，因此我們需要通過反射進(jìn)行調(diào)用。我們根據(jù)這個generateApplicationInfo方法的簽名：

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

可以寫出調(diào)用generateApplicationInfo的反射代碼：

Class<?> packageParserClass = Class.forName("android.content.pm.PackageParser");
// 首先拿到我們得終極目標(biāo): 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);

要成功調(diào)用這個方法，還需要三個參數(shù)；因此接下來我們需要一步一步構(gòu)建調(diào)用此函數(shù)的參數(shù)信息。

構(gòu)建PackageParser.Package

generateApplicationInfo方法需要的第一個參數(shù)是PackageParser.Package；從名字上看這個類代表某個apk包的信息，我們看看文檔怎么解釋：

Representation of a full package parsed from APK files on disk. A package consists of a single base APK, and zero or more split APKs.

果然，這個類代表從PackageParser中解析得到的某個apk包的信息，是磁盤上apk文件在內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)表示；因此，要獲取這個類，肯定需要解析整個apk文件。PackageParser中解析apk的核心方法是parsePackage，這個方法返回的就是一個Package類型的實(shí)例，因此我們調(diào)用這個方法即可；使用反射代碼如下：

// 首先, 我們得創(chuàng)建出一個Package對象出來供這個方法調(diào)用
// 而這個需要得對象可以通過 android.content.pm.PackageParser#parsePackage 這個方法返回得 Package對象得字段獲取得到
// 創(chuàng)建出一個PackageParser對象供使用
Object packageParser = packageParserClass.newInstance();
// 調(diào)用 PackageParser.parsePackage 解析apk的信息
Method parsePackageMethod = packageParserClass.getDeclaredMethod("parsePackage", File.class, int.class);

// 實(shí)際上是一個 android.content.pm.PackageParser.Package 對象
Object packageObj = parsePackageMethod.invoke(packageParser, apkFile, 0);

這樣，我們就得到了generateApplicationInfo的第一個參數(shù)；第二個參數(shù)是解析包使用的flag，我們直接選擇解析全部信息，也就是0；

構(gòu)建PackageUserState

第三個參數(shù)是PackageUserState，代表不同用戶中包的信息。由于Android是一個多任務(wù)多用戶系統(tǒng)，因此不同的用戶同一個包可能有不同的狀態(tài)；這里我們只需要獲取包的信息，因此直接使用默認(rèn)的即可；

至此，generateApplicaionInfo的參數(shù)我們已經(jīng)全部構(gòu)造完成，直接調(diào)用此方法即可得到我們需要的applicationInfo對象；在返回之前我們需要做一點(diǎn)小小的修改：使用系統(tǒng)系統(tǒng)的這個方法解析得到的ApplicationInfo對象中并沒有apk文件本身的信息，所以我們把解析的apk文件的路徑設(shè)置一下（ClassLoader依賴dex文件以及apk的路徑）：

// 第三個參數(shù) mDefaultPackageUserState 我們直接使用默認(rèn)構(gòu)造函數(shù)構(gòu)造一個出來即可
Object defaultPackageUserState = packageUserStateClass.newInstance();

// 萬事具備!!!!!!!!!!!!!!
ApplicationInfo applicationInfo = (ApplicationInfo) generateApplicationInfoMethod.invoke(packageParser,
        packageObj, 0, defaultPackageUserState);
String apkPath = apkFile.getPath();
applicationInfo.sourceDir = apkPath;
applicationInfo.publicSourceDir = apkPath;

替換ClassLoader

獲取LoadedApk信息

方才為了獲取ApplicationInfo我們費(fèi)了好大一番精力；回顧一下我們的初衷：

我們最終的目的是調(diào)用getPackageInfoNoCheck得到LoadedApk的信息，并替換其中的mClassLoader然后把把添加到ActivityThread的mPackages緩存中；從而達(dá)到我們使用自己的ClassLoader加載插件中的類的目的。

現(xiàn)在我們已經(jīng)拿到了getPackageInfoNoCheck這個方法中至關(guān)重要的第一個參數(shù)applicationInfo；上文提到第二個參數(shù)CompatibilityInfo代表設(shè)備兼容性信息，直接使用默認(rèn)的值即可；因此，兩個參數(shù)都已經(jīng)構(gòu)造出來，我們可以調(diào)用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);

我們成功地構(gòu)造出了LoadedAPK, 接下來我們需要替換其中的ClassLoader，然后把它添加進(jìn)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，什么都沒有做；當(dāng)然這里可以直接使用DexClassLoader，這里重新創(chuàng)建一個類是為了更有區(qū)分度；以后也可以通過修改這個類實(shí)現(xiàn)對于類加載的控制：

public class CustomClassLoader extends DexClassLoader {

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

到這里，我們已經(jīng)成功地把把插件的信息放入ActivityThread中，這樣我們插件中的類能夠成功地被加載；因此插件中的Activity實(shí)例能被成功第創(chuàng)建；由于整個流程較為復(fù)雜，我們簡單梳理一下：

1. 在ActivityThread接收到IApplication的 scheduleLaunchActivity遠(yuǎn)程調(diào)用之后，將消息轉(zhuǎn)發(fā)給H
2. H類在handleMessage的時候，調(diào)用了getPackageInfoNoCheck方法來獲取待啟動的組件信息。在這個方法中會優(yōu)先查找mPackages中的緩存信息，而我們已經(jīng)手動把插件信息添加進(jìn)去；因此能夠成功命中緩存，獲取到獨(dú)立存在的插件信息。
3. H類然后調(diào)用handleLaunchActivity最終轉(zhuǎn)發(fā)到performLaunchActivity方法；這個方法使用從getPackageInfoNoCheck中拿到LoadedApk中的mClassLoader來加載Activity類，進(jìn)而使用反射創(chuàng)建Activity實(shí)例；接著創(chuàng)建Application，Context等完成Activity組件的啟動。

看起來好像已經(jīng)天衣無縫萬事大吉了；但是運(yùn)行一下會出現(xiàn)一個異常，如下：

04-05 02:49:53.742  11759-11759/com.weishu.upf.hook_classloader E/AndroidRuntime﹕ FATAL EXCEPTION: main
    Process: com.weishu.upf.hook_classloader, PID: 11759
    java.lang.RuntimeException: Unable to start activity ComponentInfo{com.weishu.upf.ams_pms_hook.app/com.weishu.upf.ams_pms_hook.app.MainActivity}: java.lang.RuntimeException: Unable to instantiate application android.app.Application: java.lang.IllegalStateException: Unable to get package info for com.weishu.upf.ams_pms_hook.app; is package not installed?

錯誤提示說是無法實(shí)例化 Application，而Application的創(chuàng)建也是在performLaunchActivity中進(jìn)行的，這里有些蹊蹺，我們仔細(xì)查看一下。

繞過系統(tǒng)檢查

通過ActivityThread的performLaunchActivity方法可以得知，Application通過LoadedApk的makeApplication方法創(chuàng)建，我們查看這個方法，在源碼中發(fā)現(xiàn)了上文異常拋出的位置：

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() 沒什么可疑的，雖然方法很長，但是它木有拋出任何異常（當(dāng)然，它調(diào)用的代碼可能拋出異常，萬一找不到只能進(jìn)一步深搜了；所以我覺得這里應(yīng)該使用受檢異常）。

然后我們看第二句，如果包名不是android開頭，那么調(diào)用了一個叫做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);
}

這里，我們找出了這個異常的來源：原來這里調(diào)用了getPackageInfo方法獲取包的信息；而我們的插件并沒有安裝在系統(tǒng)上，因此系統(tǒng)肯定認(rèn)為插件沒有安裝，這個方法肯定返回null。所以，我們還要欺騙一下PMS，讓系統(tǒng)覺得插件已經(jīng)安裝在系統(tǒng)上了；至于如何欺騙 PMS，Hook機(jī)制之AMS&PMS 有詳細(xì)解釋，這里直接給出代碼，不贅述了：

private static void hookPackageManager() throws Exception {

    // 這一步是因為 initializeJavaContextClassLoader 這個方法內(nèi)部無意中檢查了這個包是否在系統(tǒng)安裝
    // 如果沒有安裝, 直接拋出異常, 這里需要臨時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);

    // 準(zhǔn)備好代理對象, 用來替換原始的對象
    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到這里，我們已經(jīng)能夠成功地加載簡單的獨(dú)立的存在于外部文件系統(tǒng)中的apk了。至此 關(guān)于 DroidPlugin 對于Activity生命周期的管理已經(jīng)完全講解完畢了；這是一種極其復(fù)雜的Activity管理方案，我們僅僅寫一個用來理解的demo就Hook了相當(dāng)多的東西，在Framework層來回牽扯；這其中的來龍去脈要完全把握清楚還請讀者親自翻閱源碼。另外，我在此 對DroidPlugin 作者獻(xiàn)上我的膝蓋～這其中的玄妙讓人嘆為觀止！

上文給出的方案中，我們?nèi)P接管了插件中類的加載過程，這是一種相對暴力的解決方案；能不能更溫柔一點(diǎn)呢？通俗來說，我們可以選擇改革，而不是革命——告訴系統(tǒng)ClassLoader一些必要信息，讓它幫忙完成插件類的加載。

保守方案：委托系統(tǒng)，讓系統(tǒng)幫忙加載

我們再次搬出ActivityThread中加載Activity類的代碼：

java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
        cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);

我們知道 這個r.packageInfo中的r是通過getPackageInfoNoCheck獲取到的；在『激進(jìn)方案』中我們把插件apk手動添加進(jìn)緩存，采用自己加載辦法解決；如果我們不干預(yù)這個過程，導(dǎo)致無法命中mPackages中的緩存，會發(fā)生什么？

查閱 getPackageInfo方法如下：

private LoadedApk getPackageInfo(ApplicationInfo aInfo, CompatibilityInfo compatInfo,
        ClassLoader baseLoader, boolean securityViolation, boolean includeCode,
        boolean registerPackage) {
    final boolean differentUser = (UserHandle.myUserId() != UserHandle.getUserId(aInfo.uid));
    synchronized (mResourcesManager) {
        WeakReference<LoadedApk> ref;
        if (differentUser) {
            // Caching not supported across users
            ref = null;
        } else if (includeCode) {
            ref = mPackages.get(aInfo.packageName);
        } else {
            ref = mResourcePackages.get(aInfo.packageName);
        }

        LoadedApk packageInfo = ref != null ? ref.get() : null;
        if (packageInfo == null || (packageInfo.mResources != null
                && !packageInfo.mResources.getAssets().isUpToDate())) {
            packageInfo =
                new LoadedApk(this, aInfo, compatInfo, baseLoader,
                        securityViolation, includeCode &&
                        (aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0, registerPackage);

            // 略
    }
}

可以看到，沒有命中緩存的情況下，系統(tǒng)直接new了一個LoadedApk；注意這個構(gòu)造函數(shù)的第二個參數(shù)aInfo，這是一個ApplicationInfo類型的對象。在『激進(jìn)方案』中我們?yōu)榱双@取獨(dú)立插件的ApplicationInfo花了不少心思；那么如果不做任何處理這里傳入的這個aInfo參數(shù)是什么？

追本溯源不難發(fā)現(xiàn)，這個aInfo是從我們的替身StubActivity中獲取的！而StubActivity存在于宿主程序中，所以，這個aInfo對象代表的實(shí)際上就是宿主程序的Application信息！

我們知道，接下來會使用new出來的這個LoadedApk的getClassLoader()方法獲取到ClassLoader來對插件的類進(jìn)行加載；而獲取到的這個ClassLoader是宿主程序使用的ClassLoader，因此現(xiàn)在還無法加載插件的類；那么，我們能不能讓宿主的ClasLoader獲得加載插件類的能力呢？；如果我們告訴宿主使用的ClassLoader插件使用的類在哪里，就能幫助他完成加載！

宿主的ClassLoader在哪里，是唯一的嗎？

上面說到，我們可以通過告訴宿主程序的ClassLoader插件使用的類，讓宿主的ClasLoader完成對于插件類的加載；那么問題來了，我們?nèi)绾潍@取到宿主的ClassLoader？宿主程序使用的ClasLoader默認(rèn)情況下是全局唯一的嗎？

答案是肯定的。

因為在FrameWork中宿主程序也是使用LoadedApk表示的，如同Activity啟動是加載Activity類一樣，宿主中的類也都是通過LoadedApk的getClassLoader()方法得到的ClassLoader加載的；由類加載機(jī)制的『雙親委派』特性，只要有一個應(yīng)用程序類由某一個ClassLoader加載，那么它引用到的別的類除非父加載器能加載，否則都是由這同一個加載器加載的（不遵循雙親委派模型的除外）。

表示宿主的LoadedApk在Application類中有一個成員變量mLoadedApk，而這個變量是從ContextImpl中獲取的；ContextImpl重寫了getClassLoader方法，因此我們在Context環(huán)境中直接getClassLoader()獲取到的就是宿主程序唯一的ClassLoader。

LoadedApk的ClassLoader到底是什么？

現(xiàn)在我們確保了『使用宿主ClassLoader幫助加載插件類』可行性；那么我們應(yīng)該如何完成這個過程呢？

知己知彼，百戰(zhàn)不殆。

不論是宿主程序還是插件程序都是通過LoadedApk的getClassLoader()方法返回的ClassLoader進(jìn)行類加載的，返回的這個ClassLoader到底是個什么東西？？這個方法源碼如下：

public ClassLoader getClassLoader() {
    synchronized (this) {
        if (mClassLoader != null) {
            return mClassLoader;
        }

        if (mIncludeCode && !mPackageName.equals("android")) {
            // 略...
            mClassLoader = ApplicationLoaders.getDefault().getClassLoader(zip, lib,
                    mBaseClassLoader);

            StrictMode.setThreadPolicy(oldPolicy);
        } else {
            if (mBaseClassLoader == null) {
                mClassLoader = ClassLoader.getSystemClassLoader();
            } else {
                mClassLoader = mBaseClassLoader;
            }
        }
        return mClassLoader;
    }
}

可以看到，非android開頭的包和android開頭的包分別使用了兩種不同的ClassLoader，我們只關(guān)心第一種；因此繼續(xù)跟蹤ApplicationLoaders類：

public ClassLoader getClassLoader(String zip, String libPath, ClassLoader parent)
{

    ClassLoader baseParent = ClassLoader.getSystemClassLoader().getParent();

    synchronized (mLoaders) {
        if (parent == null) {
            parent = baseParent;
        }

        if (parent == baseParent) {
            ClassLoader loader = mLoaders.get(zip);
            if (loader != null) {
                return loader;
            }

            Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, zip);
            PathClassLoader pathClassloader =
                new PathClassLoader(zip, libPath, parent);
            Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);

            mLoaders.put(zip, pathClassloader);
            return pathClassloader;
        }

        Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, zip);
        PathClassLoader pathClassloader = new PathClassLoader(zip, parent);
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        return pathClassloader;
    }
}

可以看到，應(yīng)用程序使用的ClassLoader都是PathClassLoader類的實(shí)例。那么，這個PathClassLoader是什么呢？從Android SDK給出的源碼只能看出這么多：

public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }

    public PathClassLoader(String dexPath, String libraryPath, ClassLoader parent) {
        super((String)null, (File)null, (String)null, (ClassLoader)null);
        throw new RuntimeException("Stub!");
    }
}

SDK沒有導(dǎo)出這個類的源碼，我們?nèi)?a target="_blank" rel="nofollow">androidxref上面看；發(fā)現(xiàn)其實(shí)這個類真的就這么多內(nèi)容；我們繼續(xù)查看它的父類BaseDexClassLoader；ClassLoader嘛，我們查看findClass或者defineClass方法，BaseDexClassLoader的findClass方法如下：

protected Class<?> findClass(String name) throws ClassNotFoundException {
    List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
    Class c = pathList.findClass(name, suppressedExceptions);
    if (c == null) {
        ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
        for (Throwable t : suppressedExceptions) {
            cnfe.addSuppressed(t);
        }
        throw cnfe;
    }
    return c;
}

可以看到，查找Class的任務(wù)通過pathList完成；這個pathList是一個DexPathList類的對象，它的findClass方法如下：

public Class findClass(String name, List<Throwable> suppressed) {
   for (Element element : dexElements) {
       DexFile dex = element.dexFile;

       if (dex != null) {
           Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
           if (clazz != null) {
               return clazz;
           }
       }
   }
   if (dexElementsSuppressedExceptions != null) {
       suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
   }
   return null;
}

這個DexPathList內(nèi)部有一個叫做dexElements的數(shù)組，然后findClass的時候會遍歷這個數(shù)組來查找Class；如果我們把插件的信息塞進(jìn)這個數(shù)組里面，那么不就能夠完成類的加載過程嗎？！！

給默認(rèn)ClassLoader打補(bǔ)丁

通過上述分析，我們知道，可以把插件的相關(guān)信息放入BaseDexClassLoader的表示dex文件的數(shù)組里面，這樣宿主程序的ClassLoader在進(jìn)行類加載，遍歷這個數(shù)組的時候，會自動遍歷到我們添加進(jìn)去的插件信息，從而完成插件類的加載！

接下來，我們實(shí)現(xiàn)這個過程；我們會用到一些較為復(fù)雜的反射技術(shù)哦～不過代碼非常短：

public static void patchClassLoader(ClassLoader cl, File apkFile, File optDexFile)
        throws IllegalAccessException, NoSuchMethodException, IOException, InvocationTargetException, InstantiationException, NoSuchFieldException {
    // 獲取 BaseDexClassLoader : pathList
    Field pathListField = DexClassLoader.class.getSuperclass().getDeclaredField("pathList");
    pathListField.setAccessible(true);
    Object pathListObj = pathListField.get(cl);

    // 獲取 PathList: Element[] dexElements
    Field dexElementArray = pathListObj.getClass().getDeclaredField("dexElements");
    dexElementArray.setAccessible(true);
    Object[] dexElements = (Object[]) dexElementArray.get(pathListObj);

    // Element 類型
    Class<?> elementClass = dexElements.getClass().getComponentType();

    // 創(chuàng)建一個數(shù)組, 用來替換原始的數(shù)組
    Object[] newElements = (Object[]) Array.newInstance(elementClass, dexElements.length + 1);

    // 構(gòu)造插件Element(File file, boolean isDirectory, File zip, DexFile dexFile) 這個構(gòu)造函數(shù)
    Constructor<?> constructor = elementClass.getConstructor(File.class, boolean.class, File.class, DexFile.class);
    Object o = constructor.newInstance(apkFile, false, apkFile, DexFile.loadDex(apkFile.getCanonicalPath(), optDexFile.getAbsolutePath(), 0));

    Object[] toAddElementArray = new Object[] { o };
    // 把原始的elements復(fù)制進(jìn)去
    System.arraycopy(dexElements, 0, newElements, 0, dexElements.length);
    // 插件的那個element復(fù)制進(jìn)去
    System.arraycopy(toAddElementArray, 0, newElements, dexElements.length, toAddElementArray.length);

    // 替換
    dexElementArray.set(pathListObj, newElements);

}

短短的二十幾行代碼，我們就完成了『委托宿主ClassLoader加載插件類』的任務(wù)；因此第二種方案也宣告完成！我們簡要總結(jié)一下這種方式的原理：

1. 默認(rèn)情況下performLacunchActivity會使用替身StubActivity的ApplicationInfo也就是宿主程序的CLassLoader加載所有的類；我們的思路是告訴宿主ClassLoader我們在哪，讓其幫助完成類加載的過程。
2. 宿主程序的ClassLoader最終繼承自BaseDexClassLoader，BaseDexClassLoader通過DexPathList進(jìn)行類的查找過程；而這個查找通過遍歷一個dexElements的數(shù)組完成；我們通過把插件dex添加進(jìn)這個數(shù)組就讓宿主ClasLoader獲取了加載插件類的能力。

小結(jié)

本文中我們采用兩種方案成功完成了『啟動沒有在AndroidManifest.xml中顯示聲明，并且存在于外部插件中的Activity』的任務(wù)。

『激進(jìn)方案』中我們自定義了插件的ClassLoader，并且繞開了Framework的檢測；利用ActivityThread對于LoadedApk的緩存機(jī)制，我們把攜帶這個自定義的ClassLoader的插件信息添加進(jìn)mPackages中，進(jìn)而完成了類的加載過程。

『保守方案』中我們深入探究了系統(tǒng)使用ClassLoader findClass的過程，發(fā)現(xiàn)應(yīng)用程序使用的非系統(tǒng)類都是通過同一個PathClassLoader加載的；而這個類的最終父類BaseDexClassLoader通過DexPathList完成類的查找過程；我們hack了這個查找過程，從而完成了插件類的加載。

這兩種方案孰優(yōu)孰劣呢？

很顯然，『激進(jìn)方案』比較麻煩，從代碼量和分析過程就可以看出來，這種機(jī)制異常復(fù)雜；而且在解析apk的時候我們使用的PackageParser的兼容性非常差，我們不得不手動處理每一個版本的apk解析api；另外，它Hook的地方也有點(diǎn)多：不僅需要Hook AMS和H，還需要Hook ActivityThread的mPackages和PackageManager！

『保守方案』則簡單得多（雖然原理也不簡單），不僅代碼很少，而且Hook的地方也不多；有一點(diǎn)正本清源的意思，從最最上層Hook住了整個類的加載過程。

但是，我們不能簡單地說『保守方案』比『激進(jìn)方案』好。從根本上說，這兩種方案的差異在哪呢？

『激進(jìn)方案』是多ClassLoader構(gòu)架，每一個插件都有一個自己的ClassLoader，因此類的隔離性非常好——如果不同的插件使用了同一個庫的不同版本，它們相安無事！『保守方案』是單ClassLoader方案，插件和宿主程序的類全部都通過宿主的ClasLoader加載，雖然代碼簡單，但是魯棒性很差；一旦插件之間甚至插件與宿主之間使用的類庫有沖突，那么直接GG。

多ClassLoader還有一個優(yōu)點(diǎn)：可以真正完成代碼的熱加載！如果插件需要升級，直接重新創(chuàng)建一個自定的ClassLoader加載新的插件，然后替換掉原來的版本即可（Java中，不同ClassLoader加載的同一個類被認(rèn)為是不同的類）；單ClassLoader的話實(shí)現(xiàn)非常麻煩，有可能需要重啟進(jìn)程。

在J2EE領(lǐng)域中廣泛使用ClasLoader的地方均采用多ClassLoader架構(gòu)，比如Tomcat服務(wù)器，Java模塊化事實(shí)標(biāo)準(zhǔn)的OSGi技術(shù)；所以，我們有足夠的理由認(rèn)為選擇多ClassLoader架構(gòu)在大多數(shù)情況下是明智之舉。

目前開源的插件方案中，DroidPlugin采用的『激進(jìn)方案』，Small采用的『保守方案』那么，有沒有兩種優(yōu)點(diǎn)兼顧的方案呢？？

答案自然是有的。

DroidPlugin和Small的共同點(diǎn)是兩者都是非侵入式的插件框架；什么是『非侵入式』呢？打個比方，你啟動一個插件Activity，直接使用startActivity即可，就跟開發(fā)普通的apk一樣，開發(fā)插件和普通的程序?qū)τ陂_發(fā)者來說沒有什么區(qū)別。

如果我們一定程度上放棄這種『侵入性』，那么我們就能實(shí)現(xiàn)一個兩者優(yōu)點(diǎn)兼而有之的插件框架！這里我先賣個關(guān)子～

OK，本文的內(nèi)容就到這里了；關(guān)于『插件機(jī)制對于Activity的處理方式』也就此完結(jié)。要說明的是，在本文的『保守方案』其實(shí)只處理了代碼的加載過程，它并不能加載有資源的apk！所以目前我這個實(shí)現(xiàn)基本沒什么暖用；當(dāng)然我這里只是就『代碼加載』進(jìn)行舉例；至于資源，那牽扯到另外一個問題——插件系統(tǒng)的資源管理機(jī)制這個在后續(xù)文章的合適機(jī)會我會單獨(dú)講解。