其實APP的更新機制，跟一般的C/S產品的更新機制一樣。我整理了最近踩的坑，分享一下
APP版本的生命周期：
- 設計期：根據上一個版本的用戶反饋，修復bug、優化設計和開發新功能。根據近期的公司規劃，上線新的功能，往往在上一版本還未上線，就開始規劃了
- 開發期：根據設計期的結論，開發的周期，對更改內容進行取舍，決定當前版本應該上線的內容，實際情況設計期與開發期是有重合部分的，也就是我們常常說的臨時加需求。根據開發的反饋，例如某種實現方式，花費的人力較高，決定其他的實現方式
- 測試期：公司內部測試，保證流程暢通，使用效果與設計一致，發生不一致，要么該程序，要么該設計
- 內測期：即用戶接受度測試（UAT測試，User Acceptance Test)）
小公司做的多是兼容性測試，保證新版APP可用，附帶用戶的功能反饋這里吐槽一下，國內各個安卓手機廠商，你們是要搞出多少個神奇的自定義，要累死我們啊！還是蘋果的測試舒服。
大公司的兼容性測試可能在階段3就基本完成了。（沒去過大公司，手動斜眼）內測主要是測試用戶對新版本的反饋，例如改了交互和布局，用戶學習成本怎么樣；新功能好不好用，有沒有什么改進的地方；促銷活動是不是太多了，引起了用戶的反感，用戶是不是真的感興趣....... - 靜默更新期 （大公司請直接忽視）
由于現在就職一個小型公司，對安卓機型無法做到全覆蓋。我們會先更新各大應用市場的應用和官網的下載鏈接，用戶自行更新，根據用戶反饋和兼容性問題，再決定是否大規模推送。 - 推送更新期
順利通過靜默更新期，我們就會給用戶推送，彈框提醒用戶可以更新，但是非強制的。只是推薦和提醒 - 強制更新期
由于新版本的不斷產生，舊版本會在一定時間后，停止維護。這個時候舊版本就必須強制更新，用戶不更新，不能使用。
APP的更新過程
- 靜默更新期。（一般大公司可能沒有靜默更新期，這個主要也是為了解決兼容性測試，自己想出來的）這樣做只是為了將問題暴露出來的同時，將影響降到最小的一種手段。隨著各類手機管理和應用市場類APP的普及，用戶在這里進行主動更新。一般兩三天即可。
- 推薦更新期
因為用戶打開APP時，用戶可能是急需使用的，沒有空閑的事件，網絡環境也不好，所以只是提醒用戶更新。用戶自己在網絡環境好，時間空閑的時候進行更新 - 強制更新期
舊版本的維護總是需要成本的，隨著新版本的推出，舊版本總有停止維護的時候，這個時候最好強制用戶更新。保證用戶的使用，畢竟APP出現了問題，損傷了用戶，最終損傷的還是公司自己。
特別對于一些創業型公司，業務邏輯和方向經常發生變動。一旦發生根本變動，例如功能取消，就需要強制用戶及時更新，保證用戶的行為符合現在業務邏輯。
這個一定要做好！！！不然舊用戶天天使用，產生錯誤或者異常數據，你又無法告知用戶，當時你想死的心都有了。
