基本信息

• Author：kaedea

• GitHub：android-dynamical-loading

---

我們很早開始就在Android項目中采用了動態加載技術，主要目的是為了達到讓用戶不用重新安裝APK就能升級應用的功能（特別是 SDK項目），這樣一來不但可以大大提高應用新版本的覆蓋率，也減少了服務器對舊版本接口兼容的壓力，同時如果也可以快速修復一些線上的BUG。

這種技術并不是常規的Android開發方式，早期并沒有完善的解決方案。從“不明覺厲”到穩定投入生產，一直以來我總想對此編寫一些文檔，這也是這篇日志的由來，沒想到前前后后竟然拖沓著編輯了一年多，所以日志里有的地方思路可能有點銜接得不是很好，如果有修正建議請直接回復。

技術背景

通過服務器配置一些參數，Android APP獲取這些參數再做出相應的邏輯，這是常有的事情。

比如現在大部分APP都有一個啟動頁面，如果到了一些重要的節日，APP的服務器會配置一些與時節相關的圖片，APP啟動時候再把原有的啟動圖換成這些新的圖片，這樣就能提高用戶的體驗了。

再則，早期個人開發者在安卓市場上發布應用的時候，如果應用里包含有廣告，那么有可能會審核不通過。那么就通過在服務器配置一個開關，審核應用的時候先把開關關閉，這樣應用就不會顯示廣告了；安卓市場審核通過后，再把服務器的廣告開關給打開，以這樣的手段規避市場的審核。

道高一尺魔高一丈。安卓市場開始掃描APK里面的Manifest甚至dex文件，查看開發者的APK包里是否有廣告的代碼，如果有就有可能審核不通過。

通過服務器怕配置開關參數的方法行不通了，開發者們開始想，“既然這樣，能不能先不要在APK寫廣告的代碼，在用戶運行APP的時候，再從服務器下載廣告的代碼，運行，再現實廣告呢？”。答案是肯定的，這就是動態加載：

在程序運行的時候，加載一些程序自身原本不存在的可執行文件并運行這些文件里的代碼邏輯。

看起來就像是應用從服務器下載了一些代碼，然后再執行這些代碼！

傳統PC軟件中的動態加載技術

動態加載技術在PC軟件領域廣泛使用，比如輸入法的截圖功能。剛剛安裝好的輸入法軟件可能沒有截圖功能，當你第一次使用的時候，輸入法會先從服務器下載并安裝截圖軟件，然后再執行截圖功能。

此外，許多的PC軟件的安裝目錄里面都有大量的DLL文件（Dynamic Link Library）,PC軟件則是通過調用這些DLL里面的代碼執行特定的功能的，這就是一種動態加載技術。

熟悉Java的同學應該比較清楚，Java的可執行文件是Jar，運行在虛擬機上JVM上，虛擬機通過ClassLoader加載Jar文件并執行里面的代碼。所以Java程序也可以通過動態調用Jar文件達到動態加載的目的。

Android應用的動態加載技術

Android應用類似于Java程序，虛擬機換成了Dalvik/ART，而Jar換成了Dex。在Android APP運行的時候，我們是不是也可以通過下載新的應用，或者通過調用外部的Dex文件來實現動態加載呢？

然而在Android上實現起來可沒那么容易，如果下載一個新的APK下來，不安裝這個APK的話可不能運行。如果讓用戶手動安裝完這個APK再啟動，那可不像是動態加載，純粹就是用戶安裝了一個新的應用，然后再啟動這個新的應用（這種做法也叫做“靜默安裝”）。

動態調用外部的Dex文件則是完全沒有問題的。在APK文件中往往有一個或者多個Dex文件，我們寫的每一句代碼都會被編譯到這些文件里面，Android應用運行的時候就是通過執行這些Dex文件完成應用的功能的。雖然一個APK一旦構建出來，我們是無法更換里面的Dex文件的，但是我們可以通過加載外部的Dex文件來實現動態加載，這個外部文件可以放在外部存儲，或者從網絡下載。

動態加載的定義

開始正題之前，在這里可以先給動態加載技術做一個簡單的定義。真正的動態加載應該是

應用在運行的時候通過加載一些本地不存在的可執行文件實現一些特定的功能;

這些可執行文件是可以替換的;

更換靜態資源（比如換啟動圖、換主題、或者用服務器參數開關控制廣告的隱藏現實等）不屬于?動態加載;

Android中動態加載的核心思想是動態調用外部的?dex文件，極端的情況下，Android APK自身帶有的Dex文件只是一個程序的入口（或者說空殼），所有的功能都通過從服務器下載最新的Dex文件完成;

Android動態加載的類型

Android項目中，動態加載技術按照加載的可執行文件的不同大致可以分為兩種：

動態加載so庫；

動態加載dex/jar/apk文件（現在動態加載普遍說的是這種）；

其一，Android中NDK中其實就使用了動態加載，動態加載.so庫并通過JNI調用其封裝好的方法。后者一般是由C/C++編譯而成，運行在Native層，效率會比執行在虛擬機層的Java代碼高很多，所以Android中經常通過動態加載.so庫來完成一些對性能比較有需求的工作（比如T9搜索、或者Bitmap的解碼、圖片高斯模糊處理等）。此外，由于so庫是由C/C++編譯而來的，只能被反編譯成匯編代碼，相比中dex文件反編譯得到的Smali代碼更難被破解，因此so庫也可以被用于安全領域。這里為后面要講的內容提前說明一下，一般情況下我們是把so庫一并打包在APK內部的，但是so庫其實也是可以從外部存儲文件加載的。

其二，“基于ClassLoader的動態加載dex/jar/apk文件”，就是我們上面提到的“在Android中動態加載由Java代碼編譯而來的dex包并執行其中的代碼邏輯”，這是常規Android開發比較少用到的一種技術，目前網絡上大多文章說到的動態加載指的就是這種（后面我們談到“動態加載”如果沒有特別指定，均默認是這種）。

Android項目中，所有Java代碼都會被編譯成dex文件，Android應用運行時，就是通過執行dex文件里的業務代碼邏輯來工作的。使用動態加載技術可以在Android應用運行時加載外部的dex文件，而通過網絡下載新的dex文件并替換原有的dex文件就可以達到不安裝新APK文件就升級應用（改變代碼邏輯）的目的。同時，使用動態加載技術，一般來說會使得Android開發工作變得更加復雜，這中開發方式不是官方推薦的，不是目前主流的Android開發方式，Github?和?StackOverflow?上面外國的開發者也對此不是很感興趣，外國相關的教程更是少得可憐，目前只有在大天朝才有比較深入的研究和應用，特別是一些SDK組件項目和?BAT家族?的項目上，Github上的相關開源項目基本是國人在維護，偶爾有幾個外國人請求更新英文文檔。

Android動態加載的大致過程

無論上面的哪種動態加載，其實基本原理都是在程序運行時加載一些外部的可執行的文件，然后調用這些文件的某個方法執行業務邏輯。需要說明的是，因為文件是可執行的（so庫或者dex包，也就是一種動態鏈接庫），出于安全問題，Android并不允許直接加載手機外部存儲這類noexec（不可執行）存儲路徑上的可執行文件。

對于這些外部的可執行文件，在Android應用中調用它們前，都要先把他們拷貝到data/packagename/內部儲存文件路徑，確保庫不會被第三方應用惡意修改或攔截，然后再將他們加載到當前的運行環境并調用需要的方法執行相應的邏輯，從而實現動態調用。

動態加載的大致過程就是：

把可執行文件（.so/dex/jar/apk）拷貝到應用APP內部存儲；

加載可執行文件；

調用具體的方法執行業務邏輯；

---

以下分別對這兩種動態加載的實現方式做比較深入的介紹。

動態加載?so庫

動態加載so庫應該就是Android最早期的動態加載了，不過so庫不僅可以存放在APK文件內部，還可以存放在外部存儲。Android開發中，更換so庫的情形并不多，但是可以通過把so庫挪動到APK外部，減少APK的體積，畢竟許多so庫文件的體積可是非常大的。

詳細的應用方式請參考后續日志?Android動態加載補充 加載SD卡的SO庫。

動態加載?dex/jar/apk文件

我們經常講到的那種Android動態加載技術就是這種，后面我們談到“動態加載”如果沒有特別指定，均默認是這個。

基礎知識：類加載器ClassLoader和dex文件

動態加載dex/jar/apk文件的基礎是類加載器ClassLoader，它的包路徑是java.lang，由此可見其重要性，虛擬機就是通過類加載器加載其需要用的Class，這是Java程序運行的基礎。

關于類加載器ClassLoader的工作機制，請參考?Android動態加載基礎 ClassLoader的工作機制。

現在網上有多種基于ClassLoader的Android動態加載的開源項目，大部分核心思想都殊途同歸，按照復雜程度以及具體實現的框架，大致可以分為以下三種形式，或者說模式?[1]。

簡單的動態加載模式

理解ClassLoader的工作機制后，我們知道了Android應用在運行時使用ClassLoader動態加載外部的dex文件非常簡單，不用覆蓋安裝新的APK，就可以更改APP的代碼邏輯。但是Android卻很難使用插件APK里的res資源，這意味著無法使用新的XML布局等資源，同時由于無法更改本地的Manifest清單文件，所以無法啟動新的Activity等組件。

不過可以先把要用到的全部res資源都放到主APK里面，同時把所有需要的Activity先全部寫進Manifest里，只通過動態加載更新代碼，不更新res資源，如果需要改動UI界面，可以通過使用純Java代碼創建布局的方式繞開XML布局。同時也可以使用Fragment代替Activity，這樣可以最大限度得避開“無法注冊新組件的限制”。

某種程度上，簡單的動態加載功能已經能滿足部分業務需求了，特別是一些早期的Android項目，那時候Android的技術還不是很成熟，而且早期的Android設備更是有大量的兼容性問題（做過Android1.6兼容的同學可能深有體會），只有這種簡單的加載方式才能穩定運行。這種模式的框架比較適用一些UI變化比較少的項目，比如游戲SDK，基本就只有登陸、注冊界面，而且基本不會變動，更新的往往只有代碼邏輯。

詳細的應用方式請參考后續日志?Android動態加載入門 簡單加載模式。

代理Activity模式

簡單加載模式還是不夠用，所以代理模式出現了。從這個階段開始就稍微有點“黑科技”的味道了，比如我們可以通過動態加載，讓現在的Android應用啟動一些“新”的Activity，甚至不用安裝就啟動一個“新”的APK。宿主APK[2]需要先注冊一個空殼的Activity用于代理執行插件APK的Activity的生命周期。

主要有以下特點：

宿主APK可以啟動未安裝的插件APK；

插件APK也可以作為一個普通APK安裝并且啟動；

插件APK可以調用宿主APK里的一些功能；

宿主APK和插件APK都要接入一套指定的接口框架才能實現以上功能；

同時也主要有一下幾點限制：

需要在Manifest注冊的功能都無法在插件實現，比如應用權限、LaunchMode、靜態廣播等；

宿主一個代理用的Activity難以滿足插件一些特殊的Activity的需求，插件Activity的開發受限于代理Activity；

宿主項目和插件項目的開發都要接入共同的框架，大多時候，插件需要依附宿主才能運行，無法獨立運行；

詳細的應用方式請參考后續日志?Android動態加載進階 代理Activity模式。

代理Activity模式的核心在于“使用宿主的一個代理Activity為插件所有的Activity提供組件工作需要的環境”，隨著代理模式的逐漸成熟，現在還出現了“使用Hack手段給插件的Activity注入環境”的模式，這里暫時不展開，以后會繼續分析。

我們目前有投入到生產中的開發方式只有簡單模式和代理模式，在設計的前期遇到不少兼容性的問題，不過好在Android 4.0以后的機型上就比較少了。

動態創建Activity模式

天了嚕，到了這個階段就真的是“黑科技”的領域了，從而使其可以正常運行。可以試想“從網絡下載一個Flappy Bird的APK，不用安裝就直接運行游戲”，或者“同時運行兩個甚至多個微信”。

動態創建Activity模式的核心是“運行時字節碼操作”，現在宿主注冊一個不存在的Activity，啟動插件的某個Activity時都把想要啟動的Activity替換成前面注冊的Activity，從而是后者能正常啟動。

這個模式有以下特點：

主APK可以啟動一個未安裝的插件APK；

插件APK可以是任意第三方APK，無需接入指定的接口，理所當然也可以獨立運行；

詳細的應用方式請參考后續日志?Android動態加載黑科技 動態創建Activity模式。

為什么我們要使用動態加載技術

說實話，作為開發我們也不想使用的，這是產品要求的！（警察蜀黍就是他，他只問我能不能實現，并木有問我實現起來難不難……好吧我們知道他們也沒得選。）

Android開發中，最先使用動態加載技術的應該是SDK項目吧。現在網上有一大堆Android SDK項目，比如Google的Goole Play Service，向開發者提供支付、地圖等功能，又比如一些Android游戲市場的SDK，用于向游戲開發者提供賬號和支付功能。和普通Android應用一樣，這些SDK項目也是要升級的，比如現在別人的Android應用里使用了我們的SDK1.0版本，然后發布到安卓市場上去。現在我們發現SDK1.0有一些緊急的BUG，所以升級了一個SDK1.1版本，沒辦法，只能讓人家重新接入1.1版本再發布到市場。萬一我們有SDK1.2、1.3等版本呢，本來讓人家每個版本都重新接入也無可厚非，不過產品可關心體驗啊，他就會問咯，“雖然我不懂技術，但是我想知道有沒有辦法，能讓人家只接入一次我們的SDK，以后我們發布新的SDK版本的時候他們的項目也能跟著自動升級？”，答曰，“有，使用動態加載的技術能辦到，只不過（開發工作量會劇增…）”，“那就用吧，我們要把產品的體驗做到極致”。

好吧，我并沒有黑產品的意思，現在團隊的產品也不錯，不過與上面類似的對話確實發生在我以前的項目里。這里提出來只是為了強調一下Android項目中采用動態加載技術的?作用?以及由此帶來的?代價。

作用與代價

凡事都有兩面性，特別是這種?非官方支持?的?非常規?開發方式，在采用前一定要權衡清楚其作用與代價。如果決定了要采用動態加載技術，個人推薦可以現在實際項目的一些比較獨立的模塊使用這種框架，把遇到的一些問題解決之后，再慢慢引進到項目的核心模塊；如果遇到了一些無法跨越的問題，要有能夠迅速投入生產的替代方案。

作用

規避APK覆蓋安裝的升級過程，提高用戶體驗，順便能?規避?一些安卓市場的限制；

動態修復應用的一些?緊急BUG，做好最后一道保障；

當應用體積太龐大的時候，可以把一些模塊通過動態加載以插件的形式分割出去，這樣可以減少主項目的體積，提高項目的編譯速度，也能讓主項目和插件項目并行開發；

插件模塊可以用懶加載的方式在需要的時候才初始化，從而?提高應用的啟動速度；

從項目管理上來看，分割插件模塊的方式做到了?項目級別的代碼分離，大大降低模塊之間的耦合度，同一個項目能夠分割出不同模塊在多個開發團隊之間?并行開發，如果出現BUG也容易定位問題；

在Android應用上?推廣?其他應用的時候，可以使用動態加載技術讓用戶優先體驗新應用的功能，而不用下載并安裝全新的APK；

減少主項目DEX的方法數，65535問題?徹底成為歷史（雖然現在在Android Studio中很容易開啟MultiDex，這個問題也不難解決）；

代價

開發方式可能變得比較詭異、繁瑣，與常規開發方式不同；

隨著動態加載框架復雜程度的加深，項目的構建過程也變得復雜，有可能要主項目和插件項目分別構建，再整合到一起；

由于插件項目是獨立開發的，當主項目加載插件運行時，插件的運行環境已經完全不同，代碼邏輯容易出現BUG，而且在主項目中調試插件十分繁瑣；

非常規的開發方式，有些框架使用反射強行調用了部分Android系統Framework層的代碼，部分Android ROM可能已經改動了這些代碼，所以有存在兼容性問題的風險，特別是在一些古老Android設備和部分三星的手機上；

采用動態加載的插件在使用系統資源（特別是Theme）時經常有一些兼容性問題，特別是部分三星的手機；

其他動態修改代碼的技術

上面說到的都是基于ClassLoader的動態加載技術（除了加載SO庫外），使用ClassLoader的一個特點就是，如果程序不重新啟動，加載過一次的類就無法重新加載。因此，如果使用ClassLoader來動態升級APP或者動態修復BUG，都需要重新啟動APP才能生效。

除了使用ClassLoader外，還可以使用jni hook的方式修改程序的執行代碼。前者是在虛擬機上操作的，而后者做的已經是Native層級的工作了，直接修改應用運行時的內存地址，所以使用jni hook的方式時，不用重新應用就能生效。

目前采用jni hook方案的項目中比較熱門的有阿里的dexposed和AndFix，有興趣的同學可以參考?各大熱補丁方案分析和比較。

動態加載開源項目

• ACDD

• DL dynamic-load-apk

• android-pluginmgr

• Direct-Load-apk

• 360 DroidPlugin

• 攜程網 DynamicAPK

• 女媧 Nuwa

• Android-Plugin-Framework

腳注

[1]?其實也說不上什么模式，這不過這些動態加載的開發方式都有自己明顯的特征，所以姑且用“形式或者模式”來稱呼好了。

[2]?為了方便區分概念，闡述一些術語：
宿主：Host，主項目APK、主APK，也就是我們希望采用動態加載技術的主項目；
插件：Plugin，可以是dex、jar或者apk文件，從主項目分離開來，我們能通過動態加載加載到主項目里面來的模塊，一個主APK可以同時加載多個插件APK；

總結

以上是生活随笔為你收集整理的Android动态加载技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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