簡單的說。UpdatePlugin是一款可以讓你任意作的、用於進行app更新的簡單框架。為什麼你會需要用此框架呢？
我們都知道，雖然app更新功能其實很簡單：
訪問更新介面api -> 與本地應用判斷是否需要更新 -> 下載apk -> 安裝。 so easy!
但是耐不住這世間有種叫做PM的生物，腦洞能突破天際的，就算一個app更新，都能給你玩出花來。老司機都懂的。。。當然也有各種技術原因。所以，這也是為啥這個框架能存在的主要原因。
話不多說。先上鍊接：github.com/yjfnypeu/Up…
原理
幸好雖然需求是多變的，但是基本流程還是一致的。所以，這也是UpdatePlugin的主要原理所在：
基於對更新流程的梳理，UpdatePlugin針對整個更新流程中，所有可能需要被定製的節點，都分別拆分出來了對應的介面。下方的流程圖展示了各個節點以及其觸發的順序
可以看出，框架提供了非常強大的可定製性，目前提供的可定製介面已達到13個之多.
下面將向你展示出所有的可定製節點及其作用說明, 你可以結合上方的流程圖。對照著進行檢視。
- 網路任務
- CheckWorker:更新介面api網路訪問任務
- 用於定製請求更新api介面的網路任務，支援使用同步&非同步網路操作。
- DownloadWorker:檔案下載任務
- 用於定製apk檔案的下載網路任務。支援使用同步&非同步網路操作。
- CheckWorker:更新介面api網路訪問任務
- 回撥通知
- CheckCallback:執行更新檢查時的回撥通知
- DownloadCallback:執行檔案下載時的回撥通知
- 此處的兩個回撥通知節點，主要用於將更新任務狀態通知給使用者。
- 介面通知
- CheckNotifier:有新版本需要下載時的通知提醒
- DownloadNotifier:檔案下載時進度通知提醒
- InstallNotifier:檔案下載完成啟動安裝任務前的通知提醒
- 此處的三個節點均為在更新流程中，需要被展示出來提醒使用者以進行更新的UI通知節點。配合下方的更新策略節點。基本可以配置出任意的UI展示效果。
- 執行策略
- UpdateStrategy:更新策略
- 此介面用於定製更新時各節點通知的顯示邏輯，即上方的三個介面通知的顯示邏輯
- InstallStrategy:安裝策略
- 此處用於提供給使用者進行安裝操作的定製，如當你使用熱修復、外掛化時，可在此針對熱修復、外掛化環境。有針對性的定製對應的安裝策略即可。
- UpdateStrategy:更新策略
- 資料支援
- CheckEntity:更新介面api
- 更新資料api介面
- UpdateParser:更新介面資料解析器
- 解析更新api介面所返回的資料，並提供給框架內部使用
- UpdateChecker:更新資料檢查器
- 用於對通過解析器所解析返回的實體類進行檢查。判斷是否需要進行更新操作。
- FileCreator:檔案建立器
- 指定apk檔案的下載路徑
- FileChecker:檔案檢查器
- 對下載的檔案進行安全性檢查。避免出現下載檔案與實際需要的檔案不匹配的問題：如更新api介面被DNS劫持替換。
- CheckEntity:更新介面api
當然從這裡看起來。好像太麻煩了。大部分的其實就只需要一個拿來就能用的就行了。所以框架對上面提供的介面節點。大部分都提供了預設實現。大部分使用者都可以直接拿來後進行簡單配置後直接使用。且經過長時間的維護。保證了穩定性：
// 建立使用的更新配置，此配置建議在Application中進行初始化
UpdateConfig.getConfig()
// url 與 checkEntity方法可任選一種填寫，且至少必填一種。
// 資料更新介面資料，此時預設為使用GET請求
.setUrl(url)
// 類似url方法。CheckEntity方法可填寫url,params,method。可在此設定為使用post請求
.setCheckEntity(checkEntity)
.setUpdateParser(new UpdateParser() {
@Override
public Update parse(String response) throws Exception {
/* 此處根據上面url介面返回的資料response進行update類組裝。框架內部會使用此組裝的update例項判斷是否需要更新以做進一步工作*/
return update;
}
})
// 然後在啟動頁。啟動後臺更新任務(可選項)
// 後臺更新邏輯為：當此更新任務檢查更新失敗、或者檢查到當前無更新時：
// 延遲指定時間time(毫秒)後。重啟更新任務。
UpdateBuilder.create().checkForDaemon(time);
// 在關於設定頁面。點選檢查更新時。進行前臺更新
UpdateBuilder.create().check();
複製程式碼以上即是最簡單的用法。
特性
最大的特性：非常強大的可定製性！且得益於此類設計，框架本身提供的預設實現中。也提供了非常多的友好的特性：
- 支援斷點下載
- 支援Android 7.+ 應用安裝方式
- 支援接入任意更新api
- 支援定製強制更新、忽略此版本更新邏輯
- 支援對apk進行安全檢查，防止類似DNS劫持後被替換更新apk包的情況
- 支援指定apk下載檔案地址
- 支援定製各種網路任務。適配更多網路使用場景
- 支援定製各種更新策略。比如預設使用的WIFI下預設直接下載後再通知更新，非WIFI下先通知更新再啟動下載等。
- 支援定製安裝策略。比如在外掛化、熱修復環境下進行定製使用
- 支援任意定製更新流程中的各種通知：檢查到有更新時的通知、下載時的進度條通知、下載完成後安裝之前的通知。
- 支援兩種不同的檔案校驗方式：MD5檔案驗證或者PackageManager解析Apk驗證。
若你有更多需要的特性。歡迎結合上方的可定製節點作用說明來進行靈活定製。
進階
下面列出了一些你可能會感興趣的問題：
-
如何快速定位問題？
你可以通過對控制檯使用標籤UpdatePluginLog進行日誌過濾，以方便的進行快速問題定位：
-
如果我不需要進行api版本檢查，而是直接從下載檔案開始走流程可以嗎？
這種情況雖然很少，但是有朋友的確遇到過...佩服一波腦洞...
這種情況。可以考慮直接建立出UpdateBuilder與Update物件。然後直接通過 Launcher.launchDownload(update, builder) 方法進行啟動。
-
如何在熱修復、外掛化等其他環境下進行使用？
對於這種非正式的app更新操作。建議的做法是：對不同的執行環境，建立對應的不同的UpdateConfig例項提供使用，比如：
// 此為外掛化環境。配置更新外接外掛邏輯 UpdateConfig pluginUpdateConfig = // 使用createConfig建立一個單獨的更新配置 UpdateConfig.createConfig() // 針對你當前的外掛化環境進行各種介面定製配置 ... // 配置外掛化環境下所需要使用的安裝策略。 .setInstallStrategy(pluginInstallStrategy); // 儲存好外掛更新配置。並在外掛化環境下需要下載對應外掛的時候。啟動外掛更新任務 UpdateBuilder.create(pluginUpdateConfig)// 指定使用外掛更新配置 .setUrl(pluginCheckUrl) .check(); 複製程式碼熱修復、應用商城等的使用方式均類似。都建立一個自身的更新配置提供使用即可！