VirtualAPK插件框架簡單使用
阿里Atlas組件框架使用
最近一段時間在研究插件化和組件化實現方案，今天也算整理一下筆記記錄一下，記得之前講述過一篇關于組件化的文章【Android 組件化之初探】,剛好對應著阿里的Atlas組件化框架，今天主要做個大致的介紹，稍后再逐個講述下各框架的接入方法以及具體使用方法。
一、模塊化、插件化和組件化
1. 模塊化、插件化和組件化的關系
在技術開發領域，模塊化是指分拆代碼，即當我們的代碼特別臃腫的時候，用模塊化將代碼分而治之、解耦分層。具體到 android 領域，模塊化的具體實施方法分為插件化和組件化。
2. 插件化和組件化的區別
一套完整的插件化或組件化都必須能夠實現單獨調試、集成編譯、數據傳輸、UI 跳轉、生命周期和代碼邊界這六大功能。
插件化和組件化最重要而且是唯一的區別的就是：
- 插件化可以動態增加和修改線上的模塊;
- 組件化的動態能力相對較弱，只能對線上已有模塊進行動態的加載和卸載，不能新增和修改。
插件化
插件化開發是將一個項目app拆分成多個模塊，這些模塊包括宿主和插件。每個模塊相當于一個apk，而組件化相當于一個lib。最終發布的時候將宿主apk和插件apk單獨打包或者聯合打包。
作用
- 并發開發
每個組負責一個插件，彼此之間沒有過多的依賴，可以單獨調試打包。有時發版其實就相當于發插件。 - 動態更新插件
通過推送插件更新來修復bug。 - 按需下載模塊
用戶需要使用到對應模塊的時候，才去下載相應模塊。 - 方法數或變量數爆棚問題
組件化
組件化開發是將一個項目app拆分成多個模塊，每個模塊都是一個組件，組件化開發過程中相互依賴或單獨調試，最終發布的時候是將這些組件合并統一成一個apk。
3. 插件化 和 組件化如何選擇
在插件化和組件化取舍的一個重要原則是：APP 是否有動態增加或修改線上模塊的需求，如果這種動態性的需求很弱，就不需要考慮插件化，一般說來，電商類或廣告類產品對這個需求比較強烈，而類似“得到 APP”這類的知識服務產品，每個功能的推出都是經過精細打磨的，對這種即時的動態性要求不高，所以不需要采用插件化。
如果你的產品對動態性的要求比較高，那么在選擇插件化之前也需要從兩個方面權衡一下。一是插件化不可避免的去 hook 一些系統的 api，也就不可避免地有兼容性的問題，因此每個插件化方案需要有專門的團隊去負責維護；二是從一個業務邏輯復雜的項目中去拆分插件化需要的時間可能是非常巨大的，需要考慮對開發節奏的影響。
因此，對大多數產品來說，組件化都是一個不錯甚至最佳的選擇，它沒有兼容性，可以更方便地拆分，并且幾乎沒有技術障礙，可以更順利地去執行。特別是對急需拆分的產品來說，組件化是一個可退可守的方案，可以更快地執行下去，并且將來要是遷移到插件化，組件化拆分也是必經的一步。
二、插件化和組件化方案
-
DynamicAPK (攜程)
DynamicAPK 已停止維護- 只支持四大組件中的Activity
- 組件需要在宿主程序的manifest中預注冊
- 不支持PendingIntent
- 插件構建需要部署aapt
- 支持大部分Android特性
- 兼容性適配一般
-
VirtualAPK （滴滴）
VirtualAPK GitHub- 四大組件全支持
- 組件不需要在宿主程序manifest中預注冊
- 支持PendingIntent
- 插件構建Gradle插件
- 支持幾乎全部的Android特性
- 兼容性適配比較高
- 兼容 Android O
- 加載apk
目前暫不支持的特性
- 暫不支持Activity的一些不常用特性（比如process、configChanges等屬性），但是支持theme、launchMode和screenOrientation屬性；
- overridePendingTransition(int enterAnim, int exitAnim)這種形式的轉場動畫，動畫資源不能使用插件的（可以使用宿主或系統的）；
- 插件中彈通知，需要統一處理，走宿主的邏輯，通知中的資源文件不能使用插件的（可以使用宿主或系統的）。
-
Atlas(阿里手淘)
atlas GitHub
Atlas 文檔
Atlas是伴隨著手機淘寶的不斷發展而衍生出來的一個運行于Android系統上的一個容器化框架，我們也叫動態組件化(Dynamic Bundle)框架。它主要提供了解耦化、組件化、動態性的支持。
Atlas-手淘組件化框架的前世今生和未來的路
阿里巴巴開源移動容器化框架Atlas的技術演進之路
atlas支持所有的代碼及資源更新，暫時不支持新增4大組件- bundle可以直接使用host中的代碼和資源
- Atlas基本上基于Module開發，這里所說的直接使用host中的代碼和資源是通過將host中的公用代碼和資源抽離成一個中間件middlewarelibrary，在各bundle中的build中通過使用providedCompile project(':middlewarelibrary')
來使用其中的代碼。 - 有時插件可能需要訪問host里面的資源或者代碼(如appname,launcher)，可以單獨建一個library存放公共資源和代碼，并且一些公共的三方庫引用也可以放到里面，這樣所有插件都只需要以provided的方式引這個library就可以，不用在每個插件里面都引用相同的庫。
- 官方demo中文件
-
RePlugin(360手機衛士)
https://github.com/Qihoo360/RePlugin
完整的：讓插件運行起來“像單品那樣”，支持大部分特性
穩定的：如此靈活完整的情況下，其框架崩潰率僅為業內很低的“萬分之一”
適合全面使用的：其目的是讓應用內的“所有功能皆為插件”
占坑類：以穩定為前提的Manifest占坑思路
插件化方案：基于Android原生API和語言來開發，充分利用原生特性
加載jar
四種方案比較與選擇
在 加載耦合插件 方面，VirtualAPK 是開源方案的首選，推薦大家使用。
通俗易懂地說——
- 如果你是要加載微信、支付寶等第三方 APP，那么推薦選擇 RePlugin；
- 如果你是要加載一個內部業務模塊，并且這個業務模塊很難從主工程中解耦，那么 VirtualAPK 是最好的選擇。
抽象地說——
- 如果你要加載一個插件，并且這個插件無需和宿主有任何耦合，也無需和宿主進行通信，并且你也不想對這個插件重新打包，那么推薦選擇 RePlugin；
- 除此之外，在同類的開源中，推薦大家選擇 VirtualAPK。
