近來建立了兩個小專欄，將會其中釋出現在的區塊鏈通訊專案所應用到的技術，以及程式化技術，有興趣可以關注一下（不一定需訂閱，推廣期價錢也便宜）。
[Android IM技術指南] 裡面介紹的是加密IM的技術應用和指南
[Android 程式化架構] 裡面介紹的是程式化的方案。
在上一節中介紹了一些Android App Bundle的特性和需要注意的地方，屬於元件化開發技術，這節要介紹的是AAB外掛化技術。
這是未來的傾向，很可能將會國內大廠提供這樣的服務來引導外掛升級流程。 對比一下普通元件化架構和AAB的架構。
可以看出，AAB的架構比普通元件化架構少了應用層，原來在應用層的邏輯被轉移到基礎層中了。 在基礎層做dex載入，res載入，lib載入，以及Activity啟動跳轉分發等功能。
之前我們說過AAB的架構非常適合做熱修復熱補丁的功能，是因為其包體細小，並且功能單一，並且google已經規劃了升級流程了。
那麼有沒辦法使用AAB做熱更新的功能呢？
畫黑板的時間到了。
上一節中提及到如果模組數量變更以及四大元件有變更的時候將需要重新將大版本更新到google市場。 其實正確的說是，模組數量變化，以及AndroidMainfest有變更的時候（四大元件，許可權申請變更）需要重新更新到google市場。
而我們的目標是不需要重新更新整個包體到google市場，要求使用者強制升級整個包體，而是做到部分靜默升級（這才是熱更新）。
為了規避這些限制，那麼就建立module的時候規範規則。
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