Android插件化開發

時間 2019-11-13

原文原文鏈接

客戶端開發給人的印象每每是小巧，快速奔跑。但隨着產品的發展，目前產生了大量的 門戶型客戶端。功能模塊持續集成，開發人員迅速增加。不一樣的開發小組開發不一樣的功能模塊，甚至還有其餘客戶端集成進入。能作到功能模塊開發和發佈的獨立，能像Html5同樣能帥氣的解決bug並動態更新到用戶的手機，一直是客戶端開發的求之不得的特性。

1、問題提出

通常的，一個Android應用在開發到了必定階段之後，功能模塊將會愈來愈多，APK安裝包也愈來愈大，用戶在使用過程當中也沒有辦法選擇性的加載本身須要的功能模塊。此時可能就須要考慮如何分拆整個應用了。

當前問題：

1.代碼愈來愈龐大，很難維護

2.需求愈來愈多，某一模塊的小改動都要從新發布版本，發佈時間愈來愈不可控。

3.項目中某一段代碼牽涉模塊愈來愈多，應對bug反應愈來愈慢。

潛在問題：

早期的Dalvik VM內部使用short類型變量來標識方法的id，dex限制了程序的最大方法數是 65535，若是超過最大限制，沒法編譯，（此外補充一點，以前作Framework開發時候，曾遇到多方法數量超過65535編譯不經過，修改makefile，從外部（通常是源碼目錄下Vender/xx/xx/xx...）加載類既能夠解決）。

2、解決方案提出

1.用Html5代替部分邏輯

2.刪除無用代碼，減小方法數

3.插件化，將一個 App 劃分爲多個插件（Apk 或相關格式）

前兩種方法在某種條件下能夠解決問題，可是治標不治本。下面咱們重點說一下 Android插件化開發。

3、Android插件化

Android 插件化 —— 指將一個程序劃分爲不一樣的部分，好比通常 App 的皮膚樣式就能夠當作一個插件
Android 組件化 —— 這個概念實際跟上面相差不那麼明顯，組件和插件較大的區別就是：組件是指通用及複用性較高的構件，好比圖片緩存就能夠當作一個組件被多個 App 共用
Android 動態加載 —— 這個實際是更高層次的概念，也有叫法是熱加載或 Android 動態部署，指容器（App）在運⾏狀態下動態加載某個模塊，從而新增功能或改變某⼀部分行爲

在java開發中隨處可見使用jar包的插件機制進行開發，但在android中，目前較成熟的插件機制基本沒有，看到的帖子中提到了重寫dexclassloader能夠完美的解決插件問題，但都只簡要描述了原理，沒有源碼或關鍵代碼，下面對網絡中的思路進行總結．

目前插件包有兩種格式：一種是apk,一種是dex包．對插件的接入機制來講也有兩種：一種是須要安裝，一種是不須要安裝．結合插件包的格式來講插件的方式只有三種：１，apk安裝，２，apk不安裝，３，dex包．三種方式其實主要是解決兩個方面的問題：１，加載插件中的類，２，加載插件中的資源．第一個加載類的問題，這三個方式均可以很好的解決．但目前三種方式都沒有很完美的解決第２個問題．

１，apk安裝方式．插件apk安裝後，能夠在主程序中經過包名加載到插件的context,有了插件的context就能夠解決加載插件資源的問題．但出現的新問題是：若是插件a,b,c間公用一個底層jar包，那麼在abc間傳送數據時，須要進行序列化和反序列化，由於a中jar包的data類與b中jar包的data類雖然都是一樣的jar包也是一樣的類，但兩個類在java機制來是由不一樣的classloader加載的，是不一樣的類．那麼就會出現插件間jar包冗餘和數據傳遞的效率很差問題．總之能解決問題．

２，apk不安裝，這個是不推薦的方式．能夠經過dexclassloader加載到插件a中的類，但插件沒有安裝就沒法得到插件apk的context，也就沒法加載到資源，網絡上有牛人經過將主程序的context替換關鍵的對象（如classloader,assertmanager等），僞形成插件的context，而後經過僞context也能夠得到插件資源．目前我的驗證的問題爲：獲取到的layout資源中的textview顯示文本有問題，沒法顯示在layout設定的文本．同時我的猜想這種hack的方式或許有其它的未知的問題，但不排除高手已經解決了這個問題．

３，dex包，這個基本是java開發中jar包的方式．一樣經過dexclassloader加載到插件中的類，但依舊沒有context,也沒法加載到資源．要使用佈局，只能在插件中使用java代碼來寫佈局．這種方式最簡單（１，相似jar包的方式，也能夠隨意導出單個類的jar包而後轉化爲dex包，不存在打包成apk須要完整的工程和依賴關係的要求．２，底層的公用jar包全部插件能夠公共一個，傳遞數據不用反覆的序列化和反序列化．），也是最複雜的（佈局文件所有代碼寫，難調試，難維護）．

4、優缺點

插件式開發通俗的講就是把一個很大的app分紅n多個比較小的app，其中有一個app是主app。基本上能夠理解爲讓一個apk不安裝也能夠被運行。只不過這個運行是有不少限制的運行，因此才叫插件不然就叫病毒了。其實在目前淘寶、百度、騰訊、等都有成熟的動態加載框架，包括apkplug，可是它們都是不開源的。

優勢：

1.模塊解耦

2.解除單個dex函數不能超過 65535的限制

3.動態升級

4.高效開發(編譯速度更快)

基於插件的開發列舉兩個比較突出的優勢：

一、應用程序很是容易擴展，好比一個新的領域要加到舊的應用程序中，只需把這個新的領域作爲一個插件，只開發這個小的app就能夠了，舊的應用程序可能會原分不動，就連編譯打包都不須要。

二、下載更新特別省流量，假如一個應用程序有10M把它分紅兩個的話可能每次更新只須要花費5M或者更少的流量就能夠更新完。

追求完美原本就是一種性格缺陷，說在作軟件方面沒有近乎完美。基於插件開發固然不是插件越多越好能掌控好內聚和耦合度就更好了。插件增長了主應用程序中的邏輯難度。有優勢的東西也是有缺點的這是必然。

缺點：

1.增長了主應用程序的邏輯難度

2.技術有難度，目前一些成熟的框架都是閉源的