一、SO庫加載原理

Java Api 提供以下兩個接口加載一個 so 庫

• System. loadLibrary (String libName)：傳進(jìn)去的參數(shù)：so庫名稱， 表示的so 庫文件，位于apk壓縮文件中的 libs 目錄，最后復(fù)制到 apk安裝目錄下。
• System, load (String pathName)：傳進(jìn)去的參數(shù): so庫在磁盤中的完整 路徑。加載一個自定義外部 so庫文件。

上述兩種方式加載一個 so 庫，實(shí)際上最后都調(diào)用 nativeLoad 這個 native方法去加載 so庫，這個方法的 fileName:so 庫在磁盤中的完整路徑名。

代碼+圖文的方式簡述 so 庫加載原理，下面的代碼示例，stringFromJNI -> Java_com_taobao_jni_MainActivity_stringFromJNI 靜態(tài)注冊的 native 方 法，test->test 動態(tài)注冊的 native 方法。

我們知道 JNI 編程中，動態(tài)注冊的 native 方法必須實(shí)現(xiàn) JNI_OnLoad方法，同時實(shí)現(xiàn)一個JNINativeMethod [] 數(shù)組，靜態(tài)注冊的 native 方法必須是Java+類完整路徑+方法名的格式。

總結(jié)下：

• 動態(tài)注冊的 native 方法映射通過加載 so 庫過程中調(diào)用 JNI_onLoad 方法調(diào)用完成。
• 靜態(tài)注冊的 native 方法映射是在該native方法第一次執(zhí)行的時候才完成映射，當(dāng)然前提是該 so 庫已經(jīng) load 過。

二、SO庫熱部署實(shí)時生效可行性分析

2.1、動態(tài)注冊 native 方法實(shí)時生效

前面我們分析過 so 庫的加載原理，我們知道動態(tài)注冊的 native方法調(diào)用一次 JNI_OnLoad 方法都會重新完成一次映射，所以我們是否只要先加載原來的 so庫, 然后再加載補(bǔ)丁 so 庫，就能完成Java層 native 方法到 native 層 patch后的新方法映射，這樣就完成動態(tài)注冊native 方法的 patch 實(shí)時修復(fù)。一張圖說明

實(shí)測發(fā)現(xiàn) art 下這樣是可以做到實(shí)時生效的，但是 Dalvik下做不到實(shí)時生效，通 過代碼測試我們發(fā)現(xiàn)，實(shí)際上Dalvik 下第二次 load補(bǔ)丁 so庫，執(zhí)行的仍然是原來so 庫的 JNI_0nLoad方法，而不是補(bǔ)丁so 庫的 JNI_OnLoad 方法，所以 Dalvik 下做不到實(shí)時生效。我們來簡單分析下，既然拿到的是原來 so 庫的 JNI_OnLoad方法，那么我們首先懷疑以下兩個函數(shù)是否有問題。

• dlopen() ：返回給我們一個動態(tài)鏈接庫的句柄
• disym() ：通過一個 dlopen 得到的動態(tài)連接庫句柄，來查找一個 symbol

首先來看下 Dalvik 虛擬機(jī)下面 dlopen 的實(shí)現(xiàn)，源碼在 /bionic/linker/dlfcn.cpp 文件，方法調(diào)用鏈路：dlopen -> do_d.lopen -> find_library -> find_library_internal

findloadedlibrary 方法判斷 name 表示的 so庫是否已經(jīng)被加載過，如果加載過直接返回之前加載 so庫的句柄，沒有加載過，調(diào)用 load_library嘗試加載 so庫

看代碼注釋，也知道其實(shí)這是Dalvik虛擬機(jī)下的一個 bug，這里它是通過 basename 去做查找，傳進(jìn)來的參數(shù) name 實(shí)際上是 so庫所在磁盤的完整路徑，比如此時修復(fù)后的so庫的路徑為 /data/data/com. taobao. jni/files/libnative-lib.so。但是此時是通過 bname : libnative-lib.so 作為 key 去查找， 我們知道第一次加載原來的 so庫 System.loadLibrary ( "native-lib")；實(shí)際上已經(jīng)在solist表中存在了 native-lib 這個 key，所以 Dalvik下面加載修復(fù)后的補(bǔ)丁so拿到的還是原so庫文件的句柄，所以執(zhí)行的仍然是原來 so庫的JNI_ OnLoad方法，Art下不存在這個問題，是因?yàn)锳rt下這個地方是以name作為key 去查找而不是bname，所以art 重新load —遍補(bǔ)丁 so庫：拿到的是補(bǔ)丁 so庫的句柄，然后執(zhí)行補(bǔ)丁庫的JNI OnLoad。

所以為了解決 Dalvik 下面的這個問題，那么如果嘗試對補(bǔ)丁 so進(jìn)行改名，比如 此處補(bǔ)丁so 庫的完整路徑修改之后變成 /data/data/com.taobao.jni/files/ libnative-lib-123333.so，后面一串?dāng)?shù)字是當(dāng)前時間戳，確保這個 bname是全局唯一的，按照上面的分析，在solist 中查找的 key已經(jīng)是唯一的，所以此時可以做到Dalvik 下面動態(tài)注冊的 native 方法的實(shí)時生效。

2.2、靜態(tài)注冊 native 方法實(shí)時生效

上面通過嘗試對補(bǔ)丁 so庫進(jìn)行重命名為全局唯一的名稱可以確保第二次加載補(bǔ)丁so 庫可以做到 Dalvik 下和 Art下動態(tài)注冊方法的實(shí)時生效，但要做到靜態(tài)注冊 native 方法的實(shí)時生效還需要更多工作。

前面我們說過靜態(tài)注冊 native 方法的映射是在 native方法第一次執(zhí)行的時候就完成了映射，所以如果native方法在加載補(bǔ)丁 so 庫之前已經(jīng)執(zhí)行過了，那么是否這種時候這個靜態(tài)注冊的 native 方法一定得不到修復(fù)？幸運(yùn)的是，系統(tǒng) JNI API提供 了解注冊的接口。

UnregisterNatives 函數(shù)會把 jclazz 所在類的所有 native 方法都重新指向?yàn)?dvmResolveNativeMethod，所以調(diào)用 UnregisterNatives 之后不管是靜態(tài)注冊還是動態(tài)注冊的native方法之前是否執(zhí)行過在加載補(bǔ)丁 so的時候都會重新去做映射。所以我們只需要以下調(diào)用。

這里有一個難點(diǎn)，因?yàn)?native 方法的修改是在 so庫中，所以我們的補(bǔ)丁工具很難檢測出到底是哪個Java 類需要解注冊 native 方法。這個問題暫且放下。假設(shè)我們能知道哪個類需要解注冊native方法，然后 load補(bǔ)丁 so庫之后，再次執(zhí)行該 native 方法，這樣看起來是可以讓該 native方法實(shí)時生效，但是測試發(fā)現(xiàn)，在補(bǔ)丁 so 庫重命名的前提下，java 層 native 方法可能映射到原so庫的方法，也可能映射到補(bǔ)丁 so 庫的修復(fù)后的新方法。

首先靜態(tài)注冊的 native方法之前從未執(zhí)行，首先嘗試解析該方法?；蛘哒{(diào)用了 unregisterJNINativeMethods 解注冊方法，那么該方法將指向 meth->nativeFunc = dvmResolveNativeMethod，那么真正運(yùn)行該方法的時候，實(shí)際上執(zhí)行的是dvmResolveNativeMethod 函數(shù)。這個函數(shù)主要完成 java 層 native方法和native 層方法的映射邏輯。

gDvm.nativeLibs 是一個全局變量，它是一個hashtable，存放著整個虛擬機(jī)加載 so庫的 SharedLib 結(jié)構(gòu)指針。然后該變量作為參數(shù)傳遞給 dvmHashForeach 函數(shù)進(jìn)行 hashtable 遍歷。執(zhí)行 findMethodInLib 函數(shù)看是否找到對應(yīng)的 native函 數(shù)指針，如果第一個找到就直接return，不在進(jìn)行下次的查找。

這個結(jié)構(gòu)很重要，在虛擬機(jī)中大量使用到了 hashtable 這個數(shù)據(jù)結(jié)構(gòu)，hashtable 的實(shí)現(xiàn)源碼在 dalvik/vm/Hash.h 和 dalvik/vm/Hash.cpp 文件中，有興趣可以自行查看源碼，這里不進(jìn)行詳細(xì)分析。hashtable的遍歷和插入都是在 dvmHashTableLookup 方法中實(shí)現(xiàn)，簡單說下 java.hashtable 和 c.hashtable 的異同點(diǎn)：

• 共同點(diǎn)：兩者實(shí)際上都是數(shù)組實(shí)現(xiàn)，hashtable容量如果超過默認(rèn)值都會進(jìn)行擴(kuò)容，都是對key進(jìn)行hash計算然后跟hashtable的長度進(jìn)行取模作為 bucket。
• 不同點(diǎn)：Dalvik 虛擬機(jī)下 hashtable put/get操作實(shí)現(xiàn)方法，實(shí)際上實(shí)現(xiàn)要 比java hashmap 的實(shí)現(xiàn)要簡單一些，java hashmap 的 put實(shí)現(xiàn)需要處理 hash沖突的情況，一般情況下會通過在沖突節(jié)點(diǎn)上新增一個鏈表處理沖突, 然后get實(shí)現(xiàn)會遍歷這個鏈表通過equals方法比較value是否一致進(jìn)行查找，davlik 下 hashtable 的 put 實(shí)現(xiàn)上 (doAdd=true) 只是簡單的把指針 下移直到下一個空節(jié)點(diǎn)。get 實(shí)現(xiàn) (doAdd=false) 首先根據(jù) hash值計算出 bucket 位置，然后通過 cmpFunc函數(shù)比較值是否一致，不一致，指針下移。 hashtable 的遍歷實(shí)際就是數(shù)組遍歷實(shí)現(xiàn)

知道了 davlik 下 hashtable的實(shí)現(xiàn)原理，那我們再來看下前面提到的：補(bǔ)丁 so庫重命名的前提下，為什么 java 層 native 方法可能映射到原 so 庫的方法也可能映射到補(bǔ)丁 so庫的修復(fù)后的新方法。一張圖說明情況

所以我們可以得到結(jié)論：

對補(bǔ)丁 so庫進(jìn)行重命名后，如果這個補(bǔ)丁 so庫在hashtable中的位置比原 so庫的位置靠前，那么這個靜態(tài)注冊native方法就能夠得到修復(fù)，位置如果靠后就得不到修復(fù)。

2.3、SO實(shí)時生效方案總結(jié)

基于上面的分析，so庫的實(shí)時生效必須滿足以下幾點(diǎn)：

• so庫為了兼容Dalvik虛擬機(jī)下動態(tài)注冊native方法的實(shí)時生效，必須對so 文件進(jìn)行改名。
• 針對so庫靜態(tài)注冊native方法的實(shí)時生效，首先需要解注冊靜態(tài)注冊的 native方法，這個也是難點(diǎn)，因?yàn)槲覀兒茈y知道so庫中哪幾個靜態(tài)注冊的 native方法發(fā)生了變更。假設(shè)就算我們知道如果靜態(tài)注冊的native方法需要解注冊，重新load補(bǔ)丁 so庫也有可能被修復(fù)也有可能不被修復(fù)。
• 上面對補(bǔ)丁 so進(jìn)行了第二次加載，那么肯定是多消耗了一次本地內(nèi)存，如果 補(bǔ)丁 so庫夠大，補(bǔ)丁 so夠多，那么JNI層的OOM也不是沒可能
• 另外一方面補(bǔ)丁 so如果新增了一個動態(tài)注冊的方法而dex中沒有相應(yīng)方法, 直接去加載這個補(bǔ)丁 so文件會報NoSuchMethodError異常，具體邏輯在 dvmRegisterJNIMethod中。我們知道如果dex如果新增了—native 方法，那么走不了熱部署只能冷啟動重啟生效，所以此時補(bǔ)丁so就不能第二 次load 了。這種情況下so庫的修復(fù)嚴(yán)重依賴于dex的修復(fù)方案。

可以看到 so庫實(shí)時生效方案，對于靜態(tài)注冊的native方法有一定的局限性， 不能滿足一般的通用性，所以最后我們放棄了 so庫的實(shí)時生效需求，轉(zhuǎn)而求次實(shí)現(xiàn) so庫修復(fù)的冷部署重啟生效方案。

三、SO庫冷部署重啟生效實(shí)現(xiàn)方案

為了更好的兼容通用性，我們嘗試通過冷部署重啟生效的角度分析下補(bǔ)丁 so庫的修復(fù)方案。

3.1、接口調(diào)用替換方案

sdk提供接口替換System默認(rèn)加載so庫接口

SOPatchManager.loadLibrary(String libName) -> System.loadLibrary(String libName) 

SOPatchManager.loadLibrary接口加載 so庫的時候優(yōu)先嘗試去加載sdk 指定目錄下的補(bǔ)丁so，加載策略如下：

如果存在則加載補(bǔ)丁 so庫而不會去加載安裝apk安裝目錄下的so庫

如果不存在補(bǔ)丁so，那么調(diào)用System.loadLibrary去加載安裝apk目錄下的 so庫。

我們可以很清楚的看到這個方案的優(yōu)缺點(diǎn):

• 優(yōu)點(diǎn)：不需要對不同 sdk 版本進(jìn)行兼容，因?yàn)樗械?sdk 版本都有 System.loadLibrary 這個接口。
• 缺點(diǎn)：調(diào)用方需要替換掉 System 默認(rèn)加載 so 庫接口為 sdk提供的接口， 如果是已經(jīng)編譯混淆好的三方庫的so 庫需要 patch，那么是很難做到接口的替換。

雖然這種方案實(shí)現(xiàn)簡單，同時不需要對不同 sdk版本區(qū)分處理，但是有一定的局限性沒法修復(fù)三方包的so庫同時需要強(qiáng)制侵入接入方接口調(diào)用，接著我們來看下反射注入方案。

3.2、反射注入方案

前面介紹過 System. loadLibrary ( "native-lib"); 加載 so庫的原理，其實(shí)native-lib 這個 so 庫最終傳給 native 方法執(zhí)行的參數(shù)是 so庫在磁盤中的完整路徑，比如：/data/app-lib/com.taobao.jni-2/libnative-lib.so, so庫會在 DexPathList.nativeLibraryDirectories/nativeLibraryPathElements 變量所表示的目錄下去遍歷搜索。

sdk<23 DexPathList.findLibrary 實(shí)現(xiàn)如下

可以發(fā)現(xiàn)會遍歷 nativeLibraryDirectories數(shù)組，如果找到了 loUtils.canOpenReadOnly (path)返回為 true, 那么就直接返回該 path, loUtils.canOpenReadOnly (path)返回為 true 的前提肯定是需要 path 表示的 so文件存 在的。那么我們可以采取類似類修復(fù)反射注入方式，只要把我們的補(bǔ)丁so庫的路徑插入到nativeLibraryDirectories數(shù)組的最前面就能夠達(dá)到加載so庫的時候是補(bǔ)丁 庫而不是原來so庫的目錄，從而達(dá)到修復(fù)的目的。

sdk>=23 DexPathList.findLibrary 實(shí)現(xiàn)如下

sdk23 以上 findLibrary 實(shí)現(xiàn)已經(jīng)發(fā)生了變化，如上所示，那么我們只需要把補(bǔ)丁so庫的完整路徑作為參數(shù)構(gòu)建一個Element對象，然后再插入到nativeLibraryPathElements 數(shù)組的最前面就好了。

• 優(yōu)點(diǎn)：可以修復(fù)三方庫的so庫。同時接入方不需要像方案1 —樣強(qiáng)制侵入用 戶接口調(diào)用
• 缺點(diǎn)：需要不斷的對 sdk 進(jìn)行適配，如上 sdk23 為分界線，findLibrary接口實(shí)現(xiàn)已經(jīng)發(fā)生了變化。

我們知道在不管是在補(bǔ)丁包中還是 apk 中一個 so 庫都存在多種 cpu 架構(gòu)的 so 文件，比如"armeabi"，"arm64-v8a"，"x86"等。加載肯定是加載其中一個 so庫文件的，如何選擇機(jī)型對應(yīng)的 so 庫文件將是重點(diǎn)所在。

四、如何正確復(fù)制補(bǔ)丁 SO庫

上面提到的一個問題，這里不打算詳細(xì)介紹。有需要的參考文檔：Android動態(tài) 鏈接庫加載原理及HotFix方案介紹，這篇文檔有些觀點(diǎn)不盡正確，但是我也能知道虛擬機(jī)究竟選擇哪個abis目錄作為參數(shù)構(gòu)建PathClassLoader對象，一張圖簡單了解下原理：

實(shí)際上補(bǔ)丁 so也存在類似的問題，我們的補(bǔ)丁 so庫文件放到補(bǔ)丁包的libs目錄下面，libs目錄和.dex文件和res資源文件一起打包成一個壓縮文件作為最后的補(bǔ)丁包，libs目錄可能也包含多種abis目錄。所以我們需要選擇手機(jī)最合適的 primaryCpuAbi，然后從libs目錄下面選擇這個primaryCpuAbi子目錄插入到 nativeLibraryDirectories/nativeLibraryPathElements 數(shù)組中。所以怎么選擇primaryCpuAbi是關(guān)鍵，來看下我們sdk具體的實(shí)現(xiàn)

• sdk>=21 時，直接反射拿到 Applicationinfo 對象的 primaryCpuAbi 即可
• sdk<21 時，由于此時不支持 64 位，所以直接把Build.CPU_ABI, Build.CPU_ABI2 作為 primaryCpuAbi 即可

五、本章小結(jié)

對于 so庫的修復(fù)方案目前更多采取的是接口調(diào)用替換方式，需要強(qiáng)制侵入用戶 接口調(diào)用。目前我們的so文件修復(fù)方案采取的是反射注入的方案，重啟生效。具有更好的普遍性。如果有so文件修復(fù)實(shí)時生效的需求，也是可以做到的，只是有些限制情況。

以上就是深入理解Android熱修復(fù)技術(shù)原理之so庫熱修復(fù)技術(shù)的詳細(xì)內(nèi)容，更多關(guān)于Android so庫熱修復(fù)的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論