并不是之前的文章有了什么問(wèn)題，而是要擴展之前的應用更新范圍，將 Android 這個(gè)復雜的環(huán)境考慮進(jìn)去。當然，看標題也比較清楚了。
我想，當你和這片文章有緣時(shí)，一定是你也遇到了和我類(lèi)似的問(wèn)題，并且在尋找更好的解決方案。那么，我把我自己近期的思考整理出來(lái)，我們一起探討下。
這次面對的是兩個(gè)問(wèn)題
1. Android 應用分渠道設置更新；
2. Android 應用分地域設置更新；
為什么會(huì )面對這兩個(gè)問(wèn)題呢？
在利益面前，一些阻礙都需要也必須被跨過(guò)！嗯?。ㄠ?，是自言自語(yǔ)的(oo)）
比如，應用想在某些渠道發(fā)布的時(shí)候，一些功能，比如廣告、網(wǎng)賺等，該渠道是不允許出現的，甚至連關(guān)閉功能后（后端/后臺控制），但有對應的 SDK 也不被允許。
再比如，一些城市中，對一些功能也是比較敏感的，例如帝都；再再比如，和一些城市的某些公司合作過(guò)程中，不希望讓這些合作公司知道自己做了某些功能。等等，還有哪些問(wèn)題，等待你的發(fā)現哦。
感覺(jué)，是不是很神奇？！
接下來(lái)，講講，如何解決上述的問(wèn)題呢？
其實(shí)，主要的并不在升級管理自身，而是在控制或者說(shuō)配置的邏輯上。我會(huì )分兩部分來(lái)描述，一部分針對應用升級，另一部分針對控制（我暫且叫它控制，不清楚大家各自的工作中，這部分會(huì )起什么有趣的名字呢？來(lái)，感興趣的也給我留言和評論吧，一起聊聊～）
第一部分 應用更新
這部分會(huì )細化開(kāi)篇提到的很久之前的文章，調整之前的一些邏輯，并補充不足。這部分先講下新增的部分——渠道列表，后面會(huì )介紹一些應用升級相關(guān)的規劃和策略等邏輯。
1. 渠道管理
原因：應用推廣使用，面對頻率較高的新增渠道，比如新增應用市場(chǎng)、新增應用市場(chǎng)活動(dòng)包、新增推廣包等等，這些都需要頻繁的新增渠道，總是由后端來(lái)搞太復雜，效率也比較低。
優(yōu)勢：有了這個(gè)表，能夠讓運營(yíng)相關(guān)人員輕松搞定，并且還能協(xié)調渠道、開(kāi)發(fā)配合完成工作；這個(gè)表在控制部分也會(huì )用到，后面我會(huì )具體介紹。真是一舉多得的好辦法。
思考：其實(shí)這是在應用版本升級策略中，后端/后臺開(kāi)發(fā)過(guò)程中必然會(huì )用到的，渠道表在后臺開(kāi)發(fā)中，實(shí)現成本也比較低。
規劃：見(jiàn)下圖渠道管理
渠道管理?
邏輯：并不復雜，通過(guò)后臺新增渠道記錄，在后臺展示，并能夠控制該渠道是否啟用。當然會(huì )有一些狀態(tài)，比如：第一次添加，列表中不存在，如何提示；再次添加，列表中已存在，如何提示；第一次添加成功后，如何提示等等的處理邏輯?？?，簡(jiǎn)單吧～相信，你和我一樣，也能考慮到。再看看，是不是還有哪些沒(méi)考慮到的問(wèn)題呢？比如操作者，誰(shuí)添加、停用/啟用的，方便后端查看記錄，已確定責任人（這是產(chǎn)品很成熟，組織很完善的時(shí)候考慮的；初創(chuàng )團隊沒(méi)必要這么搞，太耗精力體力和時(shí)間了。）其他，請自行思考補充，放到自己的小本本上唄。
2. 應用更新
這部分更多的是對文章《移動(dòng)產(chǎn)品基礎模塊設計規范之應用更新》中涉及選擇更新版本以及是否強制更新的補充和修正。
補充修正之一：原文章中在選擇更新版本的設置上，過(guò)于死板，不靈活。新的版本更新將待更新版本的選擇變?yōu)樘顚?xiě)，并且可以跨版本以區間的方式進(jìn)行設置。
補充修正之二：對是否強制更新的調整上，新版本采用“更新頻率”的方式取而代之，并可在“每次啟動(dòng)提示”、“每天啟動(dòng)提示”以及“每周啟動(dòng)提示”中做選擇，靈活性和可控性可見(jiàn)一斑。
補充修正之三：新增了渠道選擇，這是之前并未考慮到的。針對渠道設置更新版本，是針對不同渠道政策的應對方式。
規劃：見(jiàn)下圖添加新版本
添加新版本?
邏輯：除了以下需要著(zhù)重強調的兩個(gè)新增的邏輯之外，在之前的文章以及本文以上的內容中，基本上都有涉及。這里我們強調以下兩個(gè)位置：
1）包名。相比之前的文章，新增包名的選擇。目的是針對不同的包名——針對渠道以及版本——做對應的升級策略。至于好處嘛，你猜猜看？
2）版本號（整數值）。其實(shí)大多數安卓的應用市場(chǎng)會(huì )按照應用的整數值版本號，來(lái)區別在對應的市場(chǎng)中決定是否提示升級的。而版本號只是在對應的位置做顯示用的值而已，不作為判斷在對應的市場(chǎng)決定是否升級的。
3. 版本更新列表
版本更新列表見(jiàn)下圖：
版本更新列表?
其實(shí)就是“應用更新”新增并確定之后生成的記錄列表。這里需要注意的是，這里的邏輯與之前文章中不同。在“應用更新”中，如果多選渠道，將在版本更新列表中根據所選渠道的數量，生成對應數量的記錄，方便后期針對單一渠道進(jìn)行調整。
第二部分 控制
這部分是新增的部分，是近一年多的新發(fā)現，也會(huì )有新的感受。針對對應的渠道或者地域，對內容或者功能進(jìn)行控制，也是不可或缺的。
其實(shí)不管是根據渠道控制，還是地域，主要是看對應的渠道和地域，不允許或者由于合作關(guān)系不能出現什么功能，來(lái)做對應的處理的。原因我在本文開(kāi)始的時(shí)候提過(guò)了，大家在這部分也要格外注意。
1. 添加渠道控制和地域控制
添加渠道控制
添加地域控制?
在渠道控制中，我們發(fā)現本文開(kāi)始提到的渠道管理終于出現了?？窗?，只要在渠道管理中添加了，這里就能同步獲得了，很方便吧（得意）！
對比渠道控制和地域控制，不同的是地域控制除了地域之外，只需要考慮包名，原因是某一地域一旦需要控制對應的內容和功能，基本上不需要區分版本，只需要針對包名做處理就可以了。（請自行腦補，這么處理的原因是什么？）
2. 渠道控制和地域控制列表
渠道控制列表
地域控制列表?
這里同樣有一個(gè)地方的邏輯需要注意，在對應的控制列表中，由于添加的時(shí)候會(huì )選擇多個(gè)渠道或者地域，在對應的列表中會(huì )顯示多條記錄。這個(gè)邏輯和版本更新列表與添加版本更新的邏輯是類(lèi)似的，這樣操作會(huì )靈活很多。
以上，就是對之前文章《移動(dòng)產(chǎn)品基礎模塊設計規范之應用更新》的補充和修正了。希望能夠在這一部分，給大家一定的啟發(fā)和引導。如有不當之處，還請提出來(lái)，感謝！
題外話(huà)，最近可能要認真的梳理下之前寫(xiě)的文章了，因為發(fā)現之前的文章存在很多不足以及嚴重的邏輯問(wèn)題。也感謝，在文章下留言評論的小伙伴，是因為他們的留言評論，我才又重新讀了自己之前的文章，也看到了自己當時(shí)的不足（有種自我升級的感覺(jué)，不是么，笑）。也感謝你們，那樣不僅有了新的文章，更有了全新的我。已經(jīng)是最后了，我的思路和邏輯一定還存在不足和缺陷，希望大家多評論交流，那樣才能相互進(jìn)步。謝謝！
相關(guān)閱讀：https://mp.weixin.qq.com/s?__biz=MzI0MDI0ODIxMw==&mid=2649512820&idx=1&sn=c54a8ecadb5478cd68cff6181809e404&scene=21#wechat_redirect
來(lái)源：pmcaff
