[Android組件化]AAB插件化架構

近來創建了兩個小專欄，將會其中發佈如今的區塊鏈通信項目所應用到的技術，以及進程化技術，有興趣能夠關注一下（不必定需訂閱，推廣期價錢也便宜）。

[Android IM技術指南] 裏面介紹的是加密IM的技術應用和指南

[Android 進程化架構] 裏面介紹的是進程化的方案。

在上一節中介紹了一些Android App Bundle的特性和須要注意的地方，屬於組件化開發技術，這節要介紹的是AAB插件化技術。

這是將來的傾向，極可能將會國內大廠提供這樣的服務來引導插件升級流程。 對比一下普通組件化架構和AAB的架構。

能夠看出，AAB的架構比普通組件化架構少了應用層，原來在應用層的邏輯被轉移到基礎層中了。 在基礎層作dex加載，res加載，lib加載，以及Activity啓動跳轉分發等功能。

以前咱們說過AAB的架構很是適合作熱修復熱補丁的功能，是由於其包體細小，而且功能單一，而且google已經規劃了升級流程了。

那麼有沒辦法使用AAB作熱更新的功能呢？

畫黑板的時間到了。

上一節中說起到若是模塊數量變動以及四大組件有變動的時候將須要從新將大版本更新到google市場。 其實正確的說是，模塊數量變化，以及AndroidMainfest有變動的時候（四大組件，權限申請變動）須要從新更新到google市場。

而咱們的目標是不須要從新更新整個包體到google市場，要求用戶強制升級整個包體，而是作到部分靜默升級（這纔是熱更新）。

爲了規避這些限制，那麼就創建module的時候規範規則。

1.儘可能保持Base模塊做爲最基礎的資源保持不變，儘可能放一些大的so庫，和範用性的第三方庫，例如rxjava，glide，retrofit，okhttp，視頻和直播流等框架。 Application module，基礎狀態通常發佈後通常都不須要修改，也不能變動。若是變動了，至關於國內發佈出去的插件化包殼，發佈出去就沒法變動了。並且沒法使用熱修復（求google爸爸放過），想修復只能從新發版了。

2.Common層，有一個到兩個module應該就足夠了，放一些公用資源和View，小型的so文件，公用信息類和通訊框架，應該是足夠的。

3.一個module只有一個Activity或以Fragment爲基礎，再也不新增Activity頁面，若是新增Activity至關於新增一個module的業務。 若是一個業務有多個頁面，那就選用Fragment顯示，很早之前就有大神提出單Activity多Fragment方案（Fragmentation），google今年發佈新的組件Navigattion組件，這個親測能用，可是fragment必定要聲明全路徑（包名+類名），還不是正式版，因此你們懂的。也能夠選用單Activity多View架構（Conductor）

4.權限的聲明，基礎組件的權限仍是放到Common層中申請和處理。可是添加權限聲明，至關於更改AndroidManifest，那麼將須要從新發版，若是埋點的時候請慎重。

5.dynamic module和 application module的包名請使用同一個，否則會出現類引用不到的問題（估計是有驗證）

6.請儘可能在Application初始化的時候使用SplitInstallManagerFactory加載dynamic module，若是頁面中有使用Activity或者View沒在初始化的狀態會由於引用不到而奔潰的。請必定要保證加載dynamic module，再去跳轉，加載module後有success的回調的。

7.主頁固然是放到Application module中，保證必定能加載主頁顯示。資源使用反射，activity、service跳轉前請必定要使用判空，由於一旦跳轉不到就會崩潰。

8.dynamic module生成的apk，請儘可能保證在10M一下，升級能夠作到靜默升級，超過10M，須要提示下載。dynamic module是支持應用內移除和添加的，應用跳轉前能夠加入loading，保持友好的響應。

9.若是使用ARouter，應該能夠正常跳轉，可是移除跳轉類，那麼將會出現ARouter的toast提示。

10.dynamic module，只是延遲下載。如何配置動態加載，那麼就須要經過修改common中的配置了，你可使用json腳本配置，也能使用SharePreference來記錄開關狀態來完成。

11.能夠提早創建多個module做爲埋點，只要使用同樣的架構來填充業務代碼就能夠運行。固然代碼更改，請儘可能有效的控制，通常的交互儘可能控制在一兩個module中，這樣更新量將會減小，否則靜默升級將不穩定。

12.需不須要每一個module都申請Service呢？其實這裏能夠折中的方法，先使用common module中預先埋一兩個service，必要時做爲代碼填寫處理。而後發新版的時候，再將代碼轉移到對應的業務中。contentProvider也如此。

13.還有一個須要考究的問題，就是混淆保持的問題。

羣1已滿，能夠進羣2學習組件化

組件化QQ羣：763094035