后臺如何實現對App版本更新的管理？本文中梳理了兩種App版本更新的實現策略，分別以歷史版本和最新版本為更新依據進行展開介紹，供大家參考討論。

App升級更新方式包括：強制更新、非強制提示更新、非強制不提示更新等，這些內容我們可以依靠常識總結出來，但管理后臺不是上傳新安裝包就可以實現版本管理的，如何通過管理后臺實現對App版本的管理，以及對歷史版本的處理邏輯等內容更加值得我們去研究。

簡言之，本文闡述與解決的問題是：后臺如何實現對App版本更新的管理？

版本更新等功能是App的基礎功能，沒有經歷項目從0到1的過程，接觸這部分功能模塊就會少一些，這也是想要和大家分享的這部分經驗的原因。

回顧做過的項目，本文中梳理了兩種App版本更新的實現策略，供大家參考討論。

以歷史版本為更新依據的實現策略

標題有點繞嘴， 我們不妨先看一張原型圖：

以上圖為例，暫時忽略上傳新版本安裝包與列表查詢區，只關注版本管理列表中iOS的相關內容。

上述App的iOS版共存在4個版本：2.0（當前最新版本）、1.2、1.1與1.0，其中iOS與Android最新版本有且只能各有一個，修改版本狀態時需進行校驗。

在例子中，2.0為最新版本，1.2為提示升級、1.1為強制升級、1.0為不提示升級。各版本用戶啟動App后，依照用戶所用版本的狀態給予用戶相應的升級提示。

這種實現方案的核心在于：歷史版本均有各自的狀態，根據歷史版本的狀態決定前端的更新方式。

校驗流程如下：

上述策略的優缺點如下：

策略優勢：靈活控制各個歷史版本的升級方式，可以指定修復相應的歷史版本，不會操成大規模的“誤傷”；

策略劣勢：每次發版都需要對歷史版本進行狀態修改，如果接口變動對歷史版本產生影響，需明確出對那些歷史版本有影響，也就要求了上傳新版本的PM需要對歷史版本有重新的了解。

上述實現方式，在To C的產品中應用較多，其劣勢也可以人為規避，對于上述劣勢如果大家有解決方案，也歡迎各位留言交流。

以最新版本為更新依據的實現策略

話不多說，我們同樣先來看一張原型圖：

以上圖為例，依舊關注版本管理列表相關內容，其中iOS與Android版本狀態為有效（也就是最新版本）有且只能各有一個，該部分修改版本狀態時需進行校驗。

當前版本狀態為有效，看對應的強制更新狀態：

a、如最新版本為強制更新，則用戶啟動App后需要強制更新（所用版本不是最新版本）；

b、如最新版本為非強制，則為提示更新（如需要非提示更新，可以再增加一個字段校驗，本文不再贅述）。

這種實現方案的核心在于：根據最新版本的狀態決定前端的更新方式。

其校驗流程如下：

上述策略的優缺點如下：

策略優勢：簡單直接，無需了解歷史版本所用的接口信息；

策略劣勢：

• 存在“誤傷”，會擴大強制更新用戶的范圍，舉個例子，新上線版本存在重大BUG，需要重新發版，針對存在BUG的版本需強制更新，這樣的場景下，上述更新方式會強迫所有用戶強制更新，擴大了傷害范圍。
• 用戶不連貫使用時，會產生漏洞，舉個例子，用戶使用1.0版本，1.1版本強制更新，1.2版本非強制升級，在1.1到1.2期間，用戶未啟動App，當用戶再次使用App時，當前最新版本為1.2，版本檢查為非強制更新，這樣的場景，就影響了用戶的正常使用，因為用戶錯過了1.1的強制更新，極有可能影響接口正常使用。

可用的解決方案：在版本更新校驗時，可增加一項校驗，用戶使用版本與最新版本之間存在強制更新版本，則該次升級即為強制更新，使用該方案可以解決劣勢中的問題2。

幾句總結的話

上述兩種解決方案各有利弊，都存在很大的可優化空間，本文權作拋磚引玉，希望大家可以在基礎性功能設計上有些參考。

很多時候，能把白菜炒好吃的廚師才是好廚師，能把基礎功能設計完善的PM才是好的PM。產品之路修遠兮，需要上下而求索。

作者：張小墨，微信公眾號：月光坦克（moontank1918），某美股上市互聯網公司產品經理。

本文由 @張小墨 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議