酷播亮新聞
本文是作者對之前文章 《移動產品基礎模塊設計規範之應用更新》 的補充和修正，希望能給你一定的啟發~
我又來打自己的臉了，啪啪啪……這次要更新的是自己一年半前寫的文章 《移動產品基礎模塊設計規範之應用更新》。
並不是之前的文章有了什麼問題，而是要擴展之前的應用更新範圍，將 Android 這個複雜的環境考慮進去。 當然，看標題也比較清楚了。
我想，當你和這片文章有緣時，一定是你也遇到了和我類似的問題，並且在尋找更好的解決方案。 那麼，我把我自己近期的思考整理出來，我們一起探討下。
這次面對的是兩個問題：
- Android 應用分渠道設置更新；
- Android 應用分地域設置更新。
為什麼會面對這兩個問題呢？
在利益面前，一些阻礙都需要也必須被跨過！ 嗯！ （嗯，是自言自語的(o o)）
比如，應用想在某些渠道發布的時候，一些功能，比如廣告、網賺等，該渠道是不允許出現的，甚至連關閉功能後（後端/後台控制），但有對應的SDK 也不 被允許。
再比如，一些城市中，對一些功能也是比較敏感的，例如帝都；再再比如，和一些城市的某些公司合作過程中，不希望讓這些合作公司知道自己做了某些功能。
等等，還有哪些問題，等待你的發現哦。
感覺，是不是很神奇？ ！
接下來，講講，如何解決上述的問題呢？
其實，主要的並不在升級管理自身，而是在控製或者說配置的邏輯上。 我會分兩部分來描述，一部分針對應用升級，另一部分針對控制（我暫且叫它控制，不清楚大家各自的工作中，這部分會起什麼有趣的名字呢？來，感興趣的也給我 留言和評論吧，一起聊聊～）
第一部分 應用更新
這部分會細化開篇提到的很久之前的文章，調整之前的一些邏輯，並補充不足。 這部分先講下新增的部分——渠道列表，後面會介紹一些應用升級相關的規劃和策略等邏輯。
1. 渠道管理
（1）原因
應用推廣使用，面對頻率較高的新增渠道，比如新增應用市場、新增應用市場活動包、新增推廣包等等，這些都需要頻繁的新增渠道，總是由後端來搞 太複雜，效率也比較低。
（2）優勢
有了這個表，能夠讓運營相關人員輕鬆搞定，並且還能協調渠道、開發配合完成工作；這個表在控制部分也會用到，後面我會具體介紹。 真是一舉多得的好辦法。
（3）思考
其實這是在應用版本升級策略中，後端/後台開發過程中必然會用到的，渠道表在後台開發中，實現成本也比較低。
（4）規劃
見下圖渠道管理：
（5）邏輯
並不復雜，通過後台新增渠道記錄，在後台展示，並能夠控制該渠道是否啟用。 當然會有一些狀態，比如：第一次添加，列表中不存在，如何提示；再次添加，列表中已存在，如何提示；第一次添加成功後，如何提示等等的處理邏輯。 看，簡單吧～相信，你和我一樣，也能考慮到。 再看看，是不是還有哪些沒考慮到的問題呢？ 比如操作者，誰添加、停用/啟用的，方便後端查看記錄，已確定責任人（這是產品很成熟，組織很完善的時候考慮的；初創團隊沒必要這麼搞，太耗精力體力和 時間了。）
其他，請自行思考補充，放到自己的小本本上唄。
2. 應用更新
這部分更多的是對文章 《移動產品基礎模塊設計規範之應用更新》 中涉及選擇更新版本以及是否強制更新的補充和修正。
- 補充修正之一： 原文章中在選擇更新版本的設置上，過於死板，不靈活。 新的版本更新將待更新版本的選擇變為填寫，並且可以跨版本以區間的方式進行設置。
- 補充修正之二： 對是否強制更新的調整上，新版本採用“更新頻率”的方式取而代之，並可在“每次啟動提示”、“每天啟動提示”以及“每周啟動提示”中做選擇，靈活性和可控 性可見一斑。
- 補充修正之三： 新增了渠道選擇，這是之前並未考慮到的。 針對渠道設置更新版本，是針對不同渠道政策的應對方式。
（1）規劃
見下圖添加新版本：
（2）邏輯
除了以下需要著重強調的兩個新增的邏輯之外，在之前的文章以及本文以上的內容中，基本上都有涉及。 這裡我們強調以下兩個位置：
- 包名。 相比之前的文章，新增包名的選擇。 目的是針對不同的包名——針對渠道以及版本——做對應的升級策略。 至於好處嘛，你猜猜看？
- 版本號（整數值）。 其實大多數安卓的應用市場會按照應用的整數值版本號，來區別在對應的市場中決定是否提示升級的。 而版本號只是在對應的位置做顯示用的值而已，不作為判斷在對應的市場決定是否升級的。
3. 版本更新列表
版本更新列表見下圖： 
版本更新列表
其實就是“應用更新”新增並確定之後生成的記錄列表。 這裡需要注意的是，這裡的邏輯與之前文章中不同。 在“應用更新”中，如果多選渠道，將在版本更新列表中根據所選渠道的數量，生成對應數量的記錄，方便後期針對單一渠道進行調整。
第二部分 控制
這部分是新增的部分，是近一年多的新發現，也會有新的感受。 針對對應的渠道或者地域，對內容或者功能進行控制，也是不可或缺的。
其實不管是根據渠道控制，還是地域，主要是看對應的渠道和地域，不允許或者由於合作關係不能出現什麼功能，來做對應的處理的。 原因我在本文開始的時候提過了，大家在這部分也要格外注意。
1. 添加渠道控制和地域控制
添加渠道控制
添加地域控制
在渠道控制中，我們發現本文開始提到的渠道管理終於出現了。 看吧，只要在渠道管理中添加了，這裡就能同步獲得了，很方便吧（得意）！
對比渠道控制和地域控制，不同的是地域控制除了地域之外，只需要考慮包名，原因是某一地域一旦需要控制對應的內容和功能，基本上不需要區分版本，只需要針對包名做 處理就可以了。 （請自行腦補，這麼處理的原因是什麼？）
2. 渠道控制和地域控制列表
渠道控制列表
地域控制列表
這裡同樣有一個地方的邏輯需要注意，在對應的控制列表中，由於添加的時候會選擇多個渠道或者地域，在對應的列表中會顯示多條記錄。 這個邏輯和版本更新列表與添加版本更新的邏輯是類似的，這樣操作會靈活很多。
以上，就是對之前文章 《移動產品基礎模塊設計規範之應用更新》 的補充和修正了。 希望能夠在這一部分，給大家一定的啟發和引導。 如有不當之處，還請提出來，感謝！
題外話：
最近可能要認真地梳理下之前寫的文章了，因為發現之前的文章存在很多不足以及嚴重的邏輯問題。 也感謝，在文章下留言評論的小伙伴，是因為他們的留言評論，我才又重新讀了自己之前的文章，也看到了自己當時的不足（有種自我升級的感覺，不是麼，笑） 。 也感謝你們，那樣不僅有了新的文章，更有了全新的我。
哦，還不是最後的最後，覺得人人都是產品經理社區中的文章被評論會發郵件通知是件很有趣的事，其實我是個郵箱重度使用者，平時都會仔細看郵件，並整理郵件內容 。 已經是最後了，我的思路和邏輯一定還存在不足和缺陷，希望大家多評論交流，那樣才能相互進步。 謝謝！
相關閱讀
本文由人人都是產品經理專欄作家@ 鄭幾塊 原創發佈於人人都是產品經理 。 未經本站許可，禁止轉載。
題圖來自 Pixabay，基於 CC0 協議