【插件&熱修系列】前世此生

引言

上一個階段，咱們學習了gradle的基礎系列知識，同時用了兩個實戰例子 來鞏固所學的知識點；（PS：回顧戳這裏>>）

前面的準備，更多的是爲後面咱們實戰android的插件或者熱修作基礎儲備， 由於在插件/熱修項目中，須要經過gradle的基礎來進行編程，如：經過gradle實現插件生成等；

接下來，咱們將開始逐步進入插件/熱修的領域，在這個階段中咱們定義爲「插件&熱修系列」， 這個也是重要的基礎之一，由於這裏涉及比較多的安卓應用知識，底層知識等；

在咱們學習完「插件&熱修系列」後，再結合上一個階段學習的gradle技術知識，插件/熱修等就能在項目中輕車熟路了

概要

本章咱們將瞭解插件&熱修的前世此生，說白了就是歷史發展過程，哈哈

第1個里程碑

AndroidDynamicLoader

（1）誕生背景，2012年7月27日大衆點評的屠毅敏（Github名爲mmin18），發佈了第一個Android插件化開源項目 AndroidDynamicLoader

（2）機制，基於Fragment來實現的一個插件化框架，動態加載插件中的Fragement，來實現頁面的切換

（3）插件中的資源，經過反射調用AssetManger的 addAssetPath 方法

（4）Github地址，github.com/mmin18/Andr… PS：這個是基於Ant的構建，由於12年的時候AS尚未出來，用的是eclipse

23Code

（1）誕生背景，2013年出現了23Code

（2）機制，23Code提供了一個殼，在這個殼裏能夠動態下載插件，而後動態運行；

（3）其餘，23Code是一個自定義UI控件集合應用，直接下載一個自定義控件的demo，而且運行起來；項目的做者和開源地址目前沒有找到，找到的朋友辛苦分享下～

Atlas

（1）誕生背景，2013年3月27日淘寶的Atlas插件化框架面世

（2）機制，經過反射和輕量的hook方案來實現模塊的組件化，從而減小適配成本；同時將大量的工做放到了編譯期，提升穩定性；如：ActivityThread那幾個類的Hook、增量更新、降級、兼容等技術

（3）解決的痛點：

a) 容器化思路，解決大規模團隊協做問題;，好比：業務開發，實現每一個業務在開發階段獨立編譯、獨立調試、獨立運行，最後再以一個組件的形式集成到客戶端中，每一個業務之間並行開發互不影響

b) 實現並行開發、快速迭代和動態部署，適用於 Android 4.x 以上系統版本的大小型 App 開發。

c) 線上修復，具有客戶端動態發版和快速修復的能力

（4）github，github.com/alibaba/atl…

（5）官方教程，edu.aliyun.com/course/68/l…

第2個里程碑

dynamic-load-apk

（1）誕生背景，2014年3月30日，任玉剛的Android插件化項目dynamic-load-apk誕生， 一開始只有Activity的插件化實現，後來隨着田嘯和宋思宇的加入，實現了Service的插件化

（2）機制，從App應用層解決問題，經過建立一個ProxyActivity類由它來進行分發，啓動相應的插件Activity；這種方案統稱「靜態代理方案」

（3）實戰性，經受住了千萬級日活App的考驗（如：途牛App）

（4）Github：github.com/singwhatiwa…

CJFrameForAndroid

（1）誕生背景，2014年5月張濤的CJFrameForAndroid誕生

（2）機制，和《dynamic-load-apk》方案相似，都是採用的靜態代理方案，同時還支持了下Activity的LaunchMode的解決方案

（3）注意，此框架再也不更新

（4）做者，blog.kymjs.com/

（5）博客，www.daimajiaoliu.com/daima/4717e…

android-pluginmgr

（1）誕生背景，2014年11月houkx發佈了插件化項目android-pluginmgr

（2）機制，最先提出在AndroidManifest文件中註冊一個StubActivity來「欺騙AMS」，實際上卻打開插件中的ActivityA，可是有個短板，就是不太適用於插件化，以學習思想爲主，哈哈～

（3）Github：github.com/houkx/andro…

（4）特殊的意義，從上面的《dynamic-load-apk》思惟，到這裏的欺騙AMS思惟，到後面的hook直接欺騙AMS，實際上是一個思想的過分

（5）實戰的案例，用在遊戲行業的SDK中，具體見：segmentfault.com/a/119000001… ，神奇的這個實戰思想和咱們如今用的思想相似，或許這個就是思想的碰撞吧

TurboDex

（1）誕生背景，高中生Lody發佈框架TurboDex

（2）機制，結合了「靜態代理思想」 和 pluginmgr框架的「欺騙AMS」的思想實現

（3）特色，快速加載dex方面作的比較好

（4）Github：github.com/asLody/Turb…

Android-Plugin-Framework

（1）誕生背景，2015年5月limpoxe發佈插件化框架 Android-Plugin-Framework

（2）機制，按需hook，即須要用到哪些系統特性和api，就對哪些特性和api提供支持

（3）特色，免安裝運行插件APK ，支持獨立插件和非獨立插件

（4）Github：github.com/limpoxe/And…

第3個里程碑

DroidPlugin

（1）誕生背景，2015年8月27日，張勇的DroidPlugin發佈（360團隊）

（2）機制，Hook不少Android系統的底層代碼

（3）特色，能把任意的App都加載到宿主裏面去；能夠基於這個框架寫一個宿主App，而後就能夠把別人寫的App都看成插件來加載；

（4）優勢：

（a）宿主和插件徹底隔離，插件不依賴宿主，能夠獨立安裝運行

（b）低入侵設計，插件不須要繼承任何類

（c）插件apk和普通apk同樣的，因此插件開發沒有門檻

（d）集成簡單，開發的時候集成簡單，只須要三兩個步驟便可集成到一個新的項目中

（e）資源徹底隔離，插件之間、與Host之間實現了資源徹底隔離，不會出現資源竄用的狀況

（f）API低侵入性：極少的API。HOST程序只是須要一行代碼便可集成Droid Plugin

（g）超強隔離：插件之間、插件與Host之間徹底的代碼級別的隔離，不能互相調用對方的代碼。通信只能使用Android系統級別的通信方法。
複製代碼

（5）缺點：

（a）插件啓動速度比較慢

（b）缺少對Native層的Hook，對某些帶native代碼的apk支持很差，可能沒法運行

（c）沒法在插件中註冊一些具備特殊Intent Filter的4大組件

（d）主要問題仍是在機型的適配方面
複製代碼

（6）GitHub：github.com/DroidPlugin…

（7）誕生背景連接：www.infoq.cn/article/201…

（8）系列博客源碼分析：weishu.me/archives/

OpenAtlas

（1）誕生背景，2015年OpenAtlas項目面世（後來更名爲ACDD）；bunnyblue同窗在研究手淘客戶端以後, 發現Atlas部分混淆得不完全, 以後在此基礎上搗鼓出了OpenAtlas.

（2）機制（同Atlas），經過反射和輕量的hook方案來實現模塊的組件化，從而減小適配成本；同時將大量的工做放到了編譯期，提升穩定性；如：ActivityThread那幾個類的Hook、增量更新、降級、兼容等技術

（3）特色，經過修改並從新生成aapt命令，使得插件apk的資源id再也不是固定的0x7f，能夠修改成0x71這樣的值；解決了把插件資源合併到宿主HostApp資源後資源id衝突的問題

（4）博客系列分析：blog.imallen.wang/archives/pa…

（5）Github：github.com/HiWong/Open…

DynamicAPK

（1）誕生背景，2015年10月，攜程的插件化框架DynamicAPK誕生；基於OpenAltas框架基礎之上，融入了攜程本身特殊的業務邏輯（爲此這個網上還有朋友說攜程抄襲的風波😂）

（2）機制和特色，見上面的OpenAltas模塊

（3）誕生背景（若是是插件化模式，有以下好處）：

（a）隨着業務發展，原有攜程無線App開發團隊被分爲基礎框架、酒店、機票、火車票等多個開發團隊

（b）合做模式高效：在這種模式下，開發溝通成本大大提升，以前的協做模式難覺得繼

（c）編譯速度加快，工程被拆分爲十來個子工程以後，Android Studio編譯流程繁冗的缺點被迅速放大，在Win7機械硬盤開發機上編譯時間曾突破1小時，使人髮指的龜速編譯讓開發人員叫苦連天

（d）啓動速度加快，Google提供的MultiDex方案，會在主線程中執行全部dex的解壓、dexopt、加載操做，這是一個很是漫長的過程，用戶會明顯的看到長久的黑屏，更容易形成主線程的ANR，致使首次啓動初始化失敗

（e）產品A/B Testing，獨立開發AB版本的模塊，而不是將AB版本代碼寫在同一個模塊中。

（f）可選模塊按需下載，例如用於調試功能的模塊能夠在須要時進行下載後進行加載，減小App Size
複製代碼

（4）官方博客：mp.weixin.qq.com/s?__biz=MzA…

（5）Github：github.com/CtripMobile…

Small框架

（1）誕生背景，2015年12月底，光亮GG的Small框架發佈；

（2）願景：世界那麼大，組件那麼小。Small，作最輕巧的跨平臺插件化框架

（3）思想：組件化，APP拆分紅不一樣功能模塊，造成獨立組件，讓宿主調用

（4）使用場景：適用於將一個APK拆分爲多個公共庫插件、業務模塊插件的場景

（5）機制，經過Hook Instrumentation來啓動插件的Activity等，相似DroidPlugin

（6）數據對比：

（7）系列源碼解析：ivonhoe.github.io/2018/01/18/…

（8）Github：github.com/wequick/Sma…

這些框架的關注點

根據上面的歷史，咱們能夠看出，開源的這些框架都關注於以下幾點：

（1）插件的兼容性，包括Android系統的升級對插件化框架的影響，各個手機ROM的不一樣而對插件化的影響。

（2）插件的穩定性，好比各類奇葩的崩潰。

（3）對插件的管理，包括安裝和卸載。

插件化技術的經常使用用途

（1）遊戲行業，插件化框架更適合於遊戲領域。好比王者榮耀，常常都會有新皮膚，或者隔幾天上線一個新英雄，調整一下英雄的數據，這些都不須要從新發版。

（2）數據驅動產品，ABTest，。當產品經理爲兩種風格的設計猶豫不定時，那麼把這兩種策略作成兩個插件包，讓50%的用戶下載A策略，另外50%的用戶下載B策略，一週後看數據

（3）線上問題，不須要用戶從新下載App，分分鐘就能享受到插件新的版本

（4）搶佔市場，誰發佈新功能越快越多，對市場對用戶的佔有率就越高；由於隔三岔五就發佈一個新版本到Android各大市場，那麼用戶會不勝其煩；發版週期固定爲半個月，又會致使新功能長期積壓，半個月後才能讓用戶見到，而競爭對手早就讓用戶在使用一樣的新功能了。

（5）其餘，如：多模塊插件開發/加快編譯速度等技術提效

結尾

哈哈，該篇就寫到這裏（一塊兒體系化學習，一塊兒成長）