Android 實現應用升級方案(暨第三方自動升級服務沒法使用後的解決方案)

第三方推送升級服務再也不靠譜：
之前在作Android開發的時候，在應用升級方面都是使用的第三方推送升級服務，可是目前由於一些非技術性的問題，一些第三方廠商再也不提供自動升級服務，好比友盟，那麼當第三方推送升級服務再也不靠譜的時候，須要怎麼作？

爲何第三方推送升級服務會不靠譜：
自動升級服務由於面臨N多非技術的挑戰，好比應用市場(除了Google Play以外，國內也有愈來愈多的市場渠道會對自動更新插件的App審覈拒絕)、部分系統廠商的限制(系統廠商可能會禁止掉非系統的更新，致使更新組件報錯或者拋異常)以及部分運營商的攔截(下載CDN連接在某些地區的運營商會被禁止訪問)，甚至APK的存儲服務還會面臨政策上的風險。

解決方案：
本身實現一套推送升級服務，基本的實現思路是經過推送下載連接或者獲取下載連接的方式，來通知終端用戶有新版本更新，進而引導用戶去點擊推送的消息，下載新版本。

應用升級服務的基本流程:
1.在服務器上面上傳更新包，填寫更新的版本信息和更新日誌，將更新包存儲在服務器的文件系統（通常用雲服務器的CDN服務），將版本（Version-code），更新日誌，文件md5及其餘配置信息存儲到數據庫。
2.客戶端請求服務器並傳入客戶端的版本信息，服務端將客戶端的版本信息和數據庫中存儲的信息進行比較，若是須要更新則返回更新狀結果碼並回傳更新包的url，不然返回不更新的狀態碼。
3.客戶端收到服務器的返回結果後，進行數據的完整性校驗，主要校驗的是相關返回字段是否可以符合規則，而後對返回結果進行判斷，判斷是否須要更新，若是須要更新，則彈出對話框或者發送Notification來通知用戶有新版本更新，用戶確認後下載安裝包，安裝新版本。

基本的實現思路就是這樣，獲取升級信息的入口和檢測時機根據各自的產品需求本身定奪。另外，本身實現的推送升級服務上傳的安裝包最好是本身單獨打的渠道包，這樣纔不會在和三方市場結算的時候出現一些統計方面的問題。

本文提供的解決方案不支持增量更新，僅供全量更新需求的人蔘考。