前言：
插件化技術(shù)最初源于免安裝運行apk的想法，這個免安裝的apk可以理解為插件谤饭。支持插件化的app可以在運行時加載和運行插件，這樣便可以將app中一些不常用的功能模塊做成插件献丑，一方面減小了安裝包的大小排作，另一方面可以實現(xiàn)app功能的動態(tài)擴(kuò)展泡挺。
一渐裸、插件化介紹
1煌抒、插件化介紹
在 Android 系統(tǒng)中仍劈，應(yīng)用是以 Apk 的形式存在的，應(yīng)用都需要安裝才能使用寡壮。
其實 Android 系統(tǒng)在打開應(yīng)用之后贩疙，也只是開始進(jìn)程，然后使用 ClassLoader 加載 classes.dex 至進(jìn)程中况既，執(zhí)行對應(yīng)的組件而已;
那大家可能會想一個問題这溅，既然 Android 本身也是使用類似反射的形式加載代碼執(zhí)行，憑什么我們不能執(zhí)行一個 Apk 中的代碼呢?
這其實就是插件化的目的棒仍，讓 Apk 中的代碼(主要是指 Android 組件)能夠免安裝運行芍躏，這樣能夠帶來很多收益，最顯而易見的優(yōu)勢其實就是通過網(wǎng)絡(luò)熱更新降狠、熱修復(fù);
2、插件化技術(shù)難點
反射并執(zhí)行插件 Apk 中的代碼(ClassLoader Injection)
讓系統(tǒng)能調(diào)用插件 Apk 中的組件(Runtime Container)
正確識別插件 Apk 中的資源(Resource Injection)
3庇楞、雙親委托機制
ClassLoader調(diào)用loadClass方法加載類榜配，代碼如下：
可以看出ClassLoader加載類時，先查看自身是否已經(jīng)加載過該類吕晌，如果沒有加載過會首先讓父加載器去加載蛋褥，如果父加載器無法加載該類時才會調(diào)用自身的findClass方法加載，該機制很大程度上避免了類的重復(fù)加載;
二睛驳、插件化詳解
1烙心、ClassLoader Injection
簡單來說膜廊，插件化場景下，會存在同一進(jìn)程中多個 ClassLoader 的場景：
宿主 ClassLoader：宿主是安裝應(yīng)用淫茵，運行即自動創(chuàng)建
插件 ClassLoader：使用 new DexClassLoader 創(chuàng)建
我們稱這個過程叫做 ClassLoader 注入;
完成注入后爪瓜，所有來自宿主的類使用宿主的 ClassLoader 進(jìn)行加載，所有來自插件 Apk 的類使用插件 ClassLoader 進(jìn)行加載;
而由于 ClassLoader 的雙親委派機制匙瘪，實際上系統(tǒng)類會不受 ClassLoader 的類隔離機制所影響铆铆，這樣宿主 Apk 就可以在宿主進(jìn)程中使用來自于插件的組件類了;
2、Runtime Container
ClassLoader 注入后丹喻，就可以在宿主進(jìn)程中使用插件 Apk 中的類薄货，但是我們都知道 Android 組件都是由系統(tǒng)調(diào)用啟動的，未安裝的 Apk 中的組件碍论，是未注冊到 AMS 和 PMS 的谅猾，就好比你直接使用 startActivity 啟動一個插件 Apk 中的組件，系統(tǒng)會告訴你無法找到;
我們的解決方案很簡單鳍悠，即運行時容器技術(shù)税娜，簡單來說就是在宿主 Apk 中預(yù)埋一些空的 Android 組件，以 Activity 為例贼涩，我預(yù)置一個 ContainerActivity extends Activity 在宿主中巧涧，并且在 AndroidManifest.xml 中注冊它;
它要做的事情很簡單，就是幫助我們作為插件 Activity 的容器遥倦，它從 Intent 接受幾個參數(shù)谤绳，分別是插件的不同信息，如：
pluginName;
pluginApkPath;
pluginActivityName等袒哥，其實最重要的就是 pluginApkPath 和 pluginActivityName缩筛，當(dāng) ContainerActivity 啟動時，我們就加載插件的 ClassLoader堡称、Resource瞎抛，并反射 pluginActivityName 對應(yīng)的 Activity 類;
當(dāng)完成加載后，ContainerActivity 要做兩件事：
1却紧、轉(zhuǎn)發(fā)所有來自系統(tǒng)的生命周期回調(diào)至插件 Activity
2桐臊、接受 Activity 方法的系統(tǒng)調(diào)用，并轉(zhuǎn)發(fā)回系統(tǒng)
我們可以通過復(fù)寫 ContainerActivity 的生命周期方法來完成第一步晓殊，而第二步我們需要定義一個 PluginActivity断凶，然后在編寫插件 Apk 中的 Activity 組件時，不再讓其集成 android.app.Activity巫俺，而是集成自我們的 PluginActivity认烁，后面再通過字節(jié)碼替換來自動化完成這部操作，后面再說為什么，我們先看偽代碼;
但大概原理就是這么簡單却嗡，啟動插件組件需要依賴容器舶沛，容器負(fù)責(zé)加載插件組件并且完成雙向轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)來自系統(tǒng)的生命周期回調(diào)至插件組件窗价，同時轉(zhuǎn)發(fā)來自插件組件的系統(tǒng)調(diào)用至系統(tǒng);
3如庭、Resource Injection
Android 應(yīng)用的開發(fā)其實崇尚的是邏輯與資源分離的理念，所有資源(layout舌镶、values 等)都會被打包到 Apk 中柱彻，然后生成一個對應(yīng)的 R 類，其中包含對所有資源的引用 id;
資源的注入并不容易餐胀，好在 Android 系統(tǒng)給我們留了一條后路哟楷，最重要的是這兩個接口：
1、PackageManager#getPackageArchiveInfo：根據(jù) Apk 路徑解析一個未安裝的 Apk 的 PackageInfo;
2否灾、PackageManager#getResourcesForApplication：根據(jù) ApplicationInfo 創(chuàng)建一個 Resources 實例;
我們要做的就是在上面 ContainerActivity#onCreate 中加載插件 Apk 的時候卖擅，用這兩個方法創(chuàng)建出來一份插件資源實例。具體來說就是先用 PackageManager#getPackageArchiveInfo 拿到插件 Apk 的 PackageInfo墨技，有了 PacakgeInfo 之后我們就可以自己組裝一份 ApplicationInfo惩阶，然后通過 PackageManager#getResourcesForApplication 來創(chuàng)建資源實例，大概代碼像這樣：
拿到資源實例后扣汪，我們需要將宿主的資源和插件資源 Merge 一下断楷，編寫一個新的 Resources 類，用這樣的方式完成自動代理：
然后我們在 ContainerActivity 完成插件組件加載后崭别，創(chuàng)建一份 Merge 資源冬筒，再復(fù)寫 ContainerActivity#getResources，將獲取到的資源替換掉：
這樣就完成了資源的注入
4茅主、解決資源沖突
合并式的資源處理方式舞痰，會引入資源沖突，原因在于不同插件中的資源id可能相同诀姚，所以解決方法就是使得不同的插件資源擁有不同的資源id;
資源id是由8位16進(jìn)制數(shù)表示响牛，表示為0xPPTTNNNN。PP段用來區(qū)分包空間赫段，默認(rèn)只區(qū)分了應(yīng)用資源和系統(tǒng)資源呀打，TT段為資源類型，NNNN段在同一個APK中從0000遞增;
總結(jié)
市面上的插件化框架實際很多糯笙，如 Tecent 的 Shadow贬丛、Didi 的 VirtualApk、360 的 RePlugin炬丸。他們各有各的長處，不過大體上差不多;
他們大體原理其實都差不多，運行時會有一個宿主 Apk 在進(jìn)程中跑稠炬，宿舍 Apk 是真正被安裝的應(yīng)用焕阿，宿主 Apk 可以加載插件 Apk 中的組件和代碼運行，插件 Apk 可以任意熱更新首启。
