文章目錄

• 一、 PathClassLoader 加載 Dex 機制
• 二、 PathDexList 查找 Class 機制
• 三、 類查找的順序機制

一、 PathClassLoader 加載 Dex 機制

---

Android 中 Class 加載機制 :

Java 代碼運行時 , 使用 ClassLoader 加載 Class 字節碼文件 , Class 字節碼文件 , Jar 文件 , Dex 文件 , 都必須加載到內存中 ;

在 Android 平臺中 , Android 應用運行時 , 使用 PathClassLoader 加載 Dex 文件 , 在應用啟動時 , 首先將若干 Dex 文件加載到內存中 ;

一個 Android 應用中可以存在多個 Dex 文件 , 參考 【Android 安全】DEX 加密 ( 多 DEX 加載 | 65535 方法數限制和 MultiDex 配置 | PathClassLoader 類加載源碼分析 | DexPathList ) 博客 ,

二、 PathDexList 查找 Class 機制

---

當應用運行時調用到某類 A.class 時 , 會通過 PathClassLoader 加載該類 , PathClassLoader 是一個包裝類 , 其中封裝了 PathDexList 類 , 該類中的 Element[] dexElements 成員存放著多個 Dex 文件 ;

每個 Dex 文件中封裝了多個 Class 字節碼文件 ; 查找某個具體的 A.class 時 , 主要是通過 DexPathList 的 findClass 方法 , 遍歷 Element[] dexElements 成員 ,

Element[] dexElements 數組中保存的就是內存中的 DEX 文件 , 如果 APP 中有 $3$ 個 DEX 文件 , 那么該數組就有 $3$ 個元素 ;

然后逐個遍歷 獲取該 element 中的 dexFile , 這是 DexFile 類型文件 ,

調用 DexFile 的 loadClassBinaryName 加載對應的 A.class 類 , 如果找到了 A.class 類 , 直接返回 ; 如果沒有找到 , 則繼續遍歷下一個 Element[] dexElements 元素 ;

/*package*/ final class DexPathList {/*** dex/resource (class path) 元素集合.* 應該調用 pathElements , 但是 Facebook 應用通過反射修改 dexElements .*/private final Element[] dexElements;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;} }

參考源碼地址 : libcore/dalvik/src/main/java/dalvik/system/DexPathList.java

三、 類查找的順序機制

---

在 PathDexList 查找 Class 中 , DexPathList 的 findClass 方法遍歷 Element[] dexElements 數組永遠都是從 $0$ 索引開始 , 向后遍歷 , 其中就隱含著 Dex 文件搜索的順序機制 ;

順序機制 : 如果在第 $2$ 個 Dex 文件 和 第 $3$ 個 Dex 文件中都包含該 A.class 字節碼文件 , 則只會返回第 $2$ 個 Dex 文件中的類 , 遍歷到此處就返回了 , 不會去遍歷到低 $3$ 個 Dex 文件 ;

利用上述順序加載的機制 , 將修復包的 dex 文件放在前面 , 就可以屏蔽后面出現問題的類 ;

示例 :

在已經發布的應用中 , 有 $3$ 個 Dex 文件 , 其中第 $2$ 個 Dex 文件中的 A.class 字節碼類中出現了崩潰問題 , 這里我們將修復好的 A.class 文件打包成 Dex 文件 , 將其插入到原來第 $1$ 個和第 $2$ 個 Dex 文件之間 , 這樣在類加載器加載 A.class 類時 , 按照順序先把修復的 Dex 文件加載到內存中 , 不再向后查找第 $3$ 個 Dex 文件中出現崩潰的 A.class 類了 ;

熱修復只是在前面插入一個修復好的 Dex 文件 , 不會刪除出現問題的 Dex 文件 ;

第 $1$ 個 Dex 文件一定不能出現問題 , 如果出現問題 , 就無法在該 Dex 文件之氣前插入 Dex 文件 , 這個主 Dex 文件中有 Application , MainActivity 等相關重要組件 , 無法進行替換 ;

如果第 $1$ 個 Dex 文件出現問題 , 只能發布新版本 ;

實際上熱修復機制屬于一種利用漏洞的機制 , Google 沒有正面支持該功能 , iOS 中就關閉了熱修復功能 ;

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的【Android 热修复】热修复原理 ( 类加载机制 | PathClassLoader 加载 Dex 机制 | PathDexList 查找 Class 机制 | 类查找的顺序机制 )的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。