// pathclassloader
public class pathclassloader extends basedexclassloader {
public pathclassloader(string dexpath, classloader parent) {
super(dexpath, null, null, parent);
}
public pathclassloader(string dexpath, string librarysearchpath, classloader parent) {
super(dexpath, null, librarysearchpath, parent);
// dexclassloaderpublic
class dexclassloader extends basedexclassloader {
public dexclassloader(string dexpath, string optimizeddirectory,
string librarysearchpath, classloader parent) {
super(dexpath, new file(optimizeddirectory), librarysearchpath, parent);
basedexclassloader
dexpath：要加載的程序文件（一般是dex文件，也可以是j
ar/apk/zip文件）所在目錄。
optimizeddirectory：dex文件的輸出目錄（因為在加載jar/apk/zip等壓縮格式的程序文件時會解壓出其中的dex文件，該目錄就是專門用於存放這些被解壓出來的dex文件的）。
librarypath：加載程序文件時需要用到的庫路徑。
parent：父加載器
阿里系：dexposed、andfix：從底層二進制入手（c語言）。阿里andfix hook 方法在native的具體字段。
art虛擬機上是一個叫artmethod的結構體。通過修改該結構體上有bug的字段來達到修復bug方法的目的，
但這個artmethod是根據安卓原生的結構寫死的，國內很多第三方廠家會改寫artmethod結構，導致替換失效。
騰訊系：tinker：從java加載機制入手。qq的dex插裝就類似上面分析的那種。通過將修復的dex文件插入到app的dexfilelist的前面，達到更新bug的效果，但是不能及時生效，需要重啟。
但虛擬機在安裝期間會為類打上class_ispreverified標誌，是為了提高性能的，我們強制防止類被打上標誌是否會有些影響性能
美團robust：是在編譯器為每個方法插入了一段邏輯代碼，併為每個類創建了一個changequickredirect靜態成員變量，當它不為空會轉入新的代碼邏輯達到修復bug的目的。
優點是兼容性高,但是會增加應用體積
pathclassloader和dexclassloader都繼承自basedexclassloader
1、android使用pathclassloader作為其類加載器，只能去加載已經安裝到android系統中的apk文件；
2、dexclassloader可以從.jar和.apk類型的文件內部加載classes.dex文件就好了。熱修復也用到這個類。
（1）動態改變basedexclassloader對象間接引用的dexelements；
（2）在app打包的時候，阻止相關類去打上class_ispreverified標誌。
（3）我們使用 hook 思想代理 startactivity 這個方法，使用佔坑的方式。
1. startactivity 的時候最終會走到 ams 的 startactivity 方法
2. 系統會檢查一堆的信息驗證這個 activity 是否合法。
3. 然後會回調 activitythread 的 handler 裡的 handlelaunchactivity
4. 在這裡走到了 performlaunchactivity 方法去創建 activity 並回調一系列生命週期的方法
5. 創建 activity 的時候會創建一個 loaderapk對象，然後使用這個對象的 getclassloader 來創建 activity
6. 我們查看 getclassloader() 方法發現返回的是 pathclassloader，然後他繼承自 basedexclassloader
7. 然後我們查看 basedexclassloader 發現他創建時創建了一個 dexpathlist 類型的 pathlist對象，然後在 findclass 時調用了 pathlist.findclass 的方法
8. 然後我們查看 dexpathlist類 中的 findclass 發現他內部維護了一個 element[] dexelements的dex 數組，findclass 時是從數組中遍歷查找的
dexclassloader和pathclassloader，它們都繼承於basedexclassloader。
dexclassloader多傳了一個optimizeddirectory
dexpathlist
多dexclassloader
每個插件單獨一個dexclassloader，相對隔離，replugin採用該方案
單dexclassloader
將插件的dexclassloader中的pathlist合併到主工程的dexclassloader中。方便插件與宿主(插件)之間的調用，small採用該方案
插件調用主工程
主工程的classloader作為插件classloader的父加載器
主工程調用插件
若使用多classloader機制，通過插件的classloader先加載類，再通過反射調用
若使用單classloader機制，直接通過類名去訪問插件中的類，弊端是庫的版本可能不一致，需要規範
資源加載
//創建assetmanager對象
assetmanager assets = new assetmanager();
//將apk路徑添加到assetmanager中
if (assets.addassetpath(resdir) == 0){
return null;
//創建resource對象
r = new resources(assets, metrics, getconfiguration(), compinfo);
插件apk的路徑加入到assetmanager中
通過反射去創建，並且部分rom對創建的resource類進行了修改，所以需要考慮不同rom的兼容性。
資源路徑的處理
context的處理
// 第一步：創建resource
if (constants.combine_resources) {
//插件和主工程資源合併時需要hook住主工程的資源
resources resources = resourcesmanager.createresources(context, apk.getabsolutepath());
resourcesmanager.hookresources(context, resources);
return resources;
} else {
//插件資源獨立，該resource只能訪問插件自己的資源
resources hostresources = context.getresources();
assetmanager assetmanager = createassetmanager(context, apk);
return new resources(assetmanager, hostresources.getdisplaymetrics(), hostresources.getconfiguration());
//第二步：hook主工程的resource
//對於合併式的資源訪問方式，需要替換主工程的resource，下面是具體替換的代碼。
public static void hookresources(context base, resources resources) {
try {
reflectutil.setfield(base.getclass(), base, "mresources", resources);
object loadedapk = reflectutil.getpackageinfo(base);
reflectutil.setfield(loadedapk.getclass(), loadedapk, "mresources", resources);
object activitythread = reflectutil.getactivitythread(base);
object resmanager = reflectutil.getfield(activitythread.getclass(), activitythread, "mresourcesmanager");
if (build.version.sdk_int < 24) {
map<object, weakreference<resources>> map = (map<object, weakreference<resources>>) reflectutil.getfield(resmanager.getclass(), resmanager, "mactiveresources");
object key = map.keyset().iterator().next();
map.put(key, new weakreference<>(resources));
// still hook android n resources, even though it's unnecessary, then nobody will be strange.
map map = (map) reflectutil.getfieldnoexception(resmanager.getclass(), resmanager, "mresourceimpls");
object resourcesimpl = reflectutil.getfieldnoexception(resources.class, resources, "mresourcesimpl");
map.put(key, new weakreference<>(resourcesimpl));
} catch (exception e) {
e.printstacktrace();
替換了主工程context中loadedapk的mresource對象
將新的resource添加到主工程activitythread的mresourcemanager中，並且根據android版本做了不同處理
//第三步：關聯resource和activity
activity activity = mbase.newactivity(plugin.getclassloader(), targetclassname, intent);
activity.setintent(intent);
//設置activity的mresources屬性，activity中訪問資源時都通過mresources
reflectutil.setfield(contextthemewrapper.class, activity, "mresources", plugin.getresources());
資源衝突
資源id是由8位16進制數表示，表示為0xppttnnnn，
由三部分組成：packageid+typeid+entryid
修改aapt源碼，編譯期修改pp段。
修改resources.arsc文件，該文件列出了資源id到具體資源路徑的映射。
[blog.csdn.net/jiangwei091…]( )
// main.cpp
result = handlecommand(&bundle);
case kcommandpackage: return dopackage(bundle);
// command.cpp
int dopackage(bundle* bundle) {
if (bundle->getresourcesourcedirs().size() || bundle->getandroidmanifestfile()) {
err = buildresources(bundle, assets, builder);
if (err != 0) {
goto bail;
resource.cpp
buildresources
resourcetable.cpp
switch(mpackagetype) {
case app:
case appfeature:
packageid = 0x7f;
break;
case system:
packageid = 0x01;
case sharedlibrary:
packageid = 0x00;
首先找到入口類：main.cpp：main函數，解析參數，然後調用handlecommand函數處理參數對應的邏輯，我們看到了有一個函數dopackage。
然後就搜索到了command.cpp：在他內部的dopackage函數中進行編譯工具的一個函數：buildresources函數，在全局搜索，發現了resource.cpp：發現這裡就是處理編譯工作，構建resourcetable的邏輯，在resourcetable.cpp中，也是獲取packageid的地方，下面我們就來看看如何修改呢？
其實最好的方法是，能夠修改aapt源碼，添加一個參數，把我們想要編譯的packageid作為輸入值，傳進來最好了，那就是bundle類型，他是從main.cpp中的main函數傳遞到了最後的buildresources函數中，那麼我們就可以把這個參數用bundle進行攜帶。
[juejin.im/entry/5c008…]( )
[www.jianshu.com/p/8d691b6bf…]( )
————————————————————————————————————————————————
[cloud.tencent.com/developer/a…]( )
在整個過程中，需要修改到r文件、resources.arsc和二進制的xml文件
四大組件支持
proxyactivity代理
代理方式的關鍵總結起來有下面兩點：
proxyactivity中需要重寫getresouces，getassets，getclassloader方法返回插件的相應對象。生命週期函數以及和用戶交互相關函數，如onresume，onstop，onbackpressedon，keyuponwindow，focuschanged等需要轉發給插件。
pluginactivity中所有調用context的相關的方法，如setcontentview，getlayoutinflater，getsystemservice等都需要調用proxyactivity的相應方法。
該方式有幾個明顯缺點：
插件中的activity必須繼承pluginactivity，開發侵入性強。
如果想支持activity的singletask，singleinstance等launchmode時，需要自己管理activity棧，實現起來很繁瑣。
插件中需要小心處理context，容易出錯。
如果想把之前的模塊改造成插件需要很多額外的工作。
預埋stubactivity，hook系統啟動activity的過程
virtualapk通過替換了系統的instrumentation，hook了activity的啟動和創建，省去了手動管理插件activity生命週期的繁瑣，讓插件activity像正常的activity一樣被系統管理，並且插件activity在開發時和常規一樣，即能獨立運行又能作為插件被主工程調用。
其他插件框架在處理activity時思想大都差不多，無非是這兩種方式之一或者兩者的結合。在hook時，不同的框架可能會選擇不同的hook點。如360的replugin框架選擇hook了系統的classloader，即構造activity2的classloader，在判斷出待啟動的activity是插件中的時，會調用插件的classloader構造相應對象。另外replugin為了系統穩定性，選擇了儘量少的hook，因此它並沒有選擇hook系統的startactivity方法來替換intent，而是通過重寫activity的startactivity，因此其插件activity是需要繼承一個類似pluginactivity的基類的。不過replugin提供了一個gradle插件將插件中的activity的基類換成了pluginactivity，用戶在開發插件activity時也是沒有感知的。
[www.jianshu.com/p/ac96420fc…]( )
service插件化總結
初始化時通過activitymanagerproxy hook住了iactivitymanager。
服務啟動時通過activitymanagerproxy攔截，判斷是否為遠程服務，如果為遠程服務，啟動remoteservice，如果為同進程服務則啟動localservice。
如果為localservice，則通過dexclassloader加載目標service，然後反射調用attach方法綁定context，然後執行service的oncreate、onstartcommand方法
如果為remoteservice，則先加載插件的遠程service，後續跟localservice一致。
[www.cnblogs.com/jackie-zhan…]( )
1、模塊間解耦，複用。
（原因：對業務進行模塊化拆分後，為了使各業務模塊間解耦，因此各個都是獨立的模塊，它們之間是沒有依賴關係。
每個模塊負責的功能不同，業務邏輯不同，模塊間業務解耦。模塊功能比較單一，可在多個項目中使用。）
2、可單獨編譯某個模塊，提升開發效率。
（原因：每個模塊實際上也是一個完整的項目，可以進行單獨編譯，調試）
3、可以多團隊並行開發，測試。
原因：每個團隊負責不同的模塊，提升開發，測試效率。
組件化與模塊化
組件化是指以重用化為目的，將一個系統拆分為一個個單獨的組件
避免重複造輪子，節省開發維護成本；
降低項目複雜性，提升開發效率；
多個團隊公用同一個組件，在一定層度上確保了技術方案的統一性。
模塊化業務分層：由下到上
基礎組件層：
底層使用的庫和封裝的一些工具庫（libs），比如okhttp,rxjava,rxandroid,glide等
業務組件層：
與業務相關，封裝第三方sdk，比如封裝後的支付，即時通行等
業務模塊層：
按照業務劃分模塊，比如說im模塊，資訊模塊等
library module開發問題
在把代碼抽取到各個單獨的library module中，會遇到各種問題。
最常見的就是r文件問題，android開發中，各個資源文件都是放在res目錄中，在編譯過程中，會生成r.java文件。
r文件中包含有各個資源文件對應的id，這個id是靜態常量，但是在library module中，這個id不是靜態常量，那麼在開發時候就要避開這樣的問題。
舉個常見的例子，同一個方法處理多個view的點擊事件，有時候會使用switch(view.getid())這樣的方式，
然後用case r.id.btnlogin這樣進行判斷，這時候就會出現問題，因為id不是經常常量，那麼這種方式就用不了。
[www.jianshu.com/p/704cac3eb…]( )
宿主： 就是當前運行的app
插件： 相對於插件化技術來說，就是要加載運行的apk類文件
補丁： 相對於熱修復技術來說，就是要加載運行的.patch,.dex,*.apk等一系列包含dex修復內容的文件。
qq 空間超級補丁方案
tinker
hotfix
當然就熱修復的實現，各個大廠還有各自的實現，比如餓了嗎的amigo,美團的robust,實現及優缺點各有差異，但總的來說就是兩大類
classloader 加載方案
native層替換方案
或者是參考android studio instant run 的思路實現代碼整體的增量更新。但這樣勢必會帶來性能的影響。
sophix
[www.jianshu.com/p/4d30ce3e5…]( )
底層替換方案
原理：在已經加載的類中直接替換掉原有方法，是在原有類的結構基礎上進行修改的。在hook方法入口artmethod時，通過構造一個新的artmethod實現替換方法入口的跳轉。
應用：能即時生效，andfix採用此方案。
缺點：底層替換穩定性不好，適用範圍存在限制，通過改造代碼繞過限制既不優雅也不方便，並且還沒提供資源及so的修復。
類加載方案
原理：讓app重新啟動後讓classloader去加載新的類。如果不重啟，原來的類還在虛擬機中無法重複加載。
優點：修復範圍廣，限制少。
應用：騰訊系包括qq空間，手qfix，tinker採用此方案。
qq空間會侵入打包流程。
qfix需要獲取底層虛擬機的函數，不穩定。
tinker是完整的全量dex加載。