并不是之前的文章有了什么問題，而是要擴展之前的應(yīng)用更新范圍，將 Android 這個復(fù)雜的環(huán)境考慮進去。當(dāng)然，看標(biāo)題也比較清楚了。

我想，當(dāng)你和這片文章有緣時，一定是你也遇到了和我類似的問題，并且在尋找更好的解決方案。那么，我把我自己近期的思考整理出來，我們一起探討下。

這次面對的是兩個問題

1. Android 應(yīng)用分渠道設(shè)置更新；

2. Android 應(yīng)用分地域設(shè)置更新；

為什么會面對這兩個問題呢？

在利益面前，一些阻礙都需要也必須被跨過！嗯?。ㄠ?，是自言自語的(oo)）

比如，應(yīng)用想在某些渠道發(fā)布的時候，一些功能，比如廣告、網(wǎng)賺等，該渠道是不允許出現(xiàn)的，甚至連關(guān)閉功能后（后端/后臺控制），但有對應(yīng)的 SDK 也不被允許。

再比如，一些城市中，對一些功能也是比較敏感的，例如帝都；再再比如，和一些城市的某些公司合作過程中，不希望讓這些合作公司知道自己做了某些功能。等等，還有哪些問題，等待你的發(fā)現(xiàn)哦。

感覺，是不是很神奇？！

接下來，講講，如何解決上述的問題呢？

其實，主要的并不在升級管理自身，而是在控制或者說配置的邏輯上。我會分兩部分來描述，一部分針對應(yīng)用升級，另一部分針對控制（我暫且叫它控制，不清楚大家各自的工作中，這部分會起什么有趣的名字呢？來，感興趣的也給我留言和評論吧，一起聊聊～）

第一部分 應(yīng)用更新

這部分會細化開篇提到的很久之前的文章，調(diào)整之前的一些邏輯，并補充不足。這部分先講下新增的部分——渠道列表，后面會介紹一些應(yīng)用升級相關(guān)的規(guī)劃和策略等邏輯。

1. 渠道管理 

原因：應(yīng)用推廣使用，面對頻率較高的新增渠道，比如新增應(yīng)用市場、新增應(yīng)用市場活動包、新增推廣包等等，這些都需要頻繁的新增渠道，總是由后端來搞太復(fù)雜，效率也比較低。 

優(yōu)勢：有了這個表，能夠讓運營相關(guān)人員輕松搞定，并且還能協(xié)調(diào)渠道、開發(fā)配合完成工作；這個表在控制部分也會用到，后面我會具體介紹。真是一舉多得的好辦法。 

思考：其實這是在應(yīng)用版本升級策略中，后端/后臺開發(fā)過程中必然會用到的，渠道表在后臺開發(fā)中，實現(xiàn)成本也比較低。 

規(guī)劃：見下圖渠道管理 

渠道管理?

邏輯：并不復(fù)雜，通過后臺新增渠道記錄，在后臺展示，并能夠控制該渠道是否啟用。當(dāng)然會有一些狀態(tài)，比如：第一次添加，列表中不存在，如何提示；再次添加，列表中已存在，如何提示；第一次添加成功后，如何提示等等的處理邏輯?？?，簡單吧～相信，你和我一樣，也能考慮到。再看看，是不是還有哪些沒考慮到的問題呢？比如操作者，誰添加、停用/啟用的，方便后端查看記錄，已確定責(zé)任人（這是產(chǎn)品很成熟，組織很完善的時候考慮的；初創(chuàng)團隊沒必要這么搞，太耗精力體力和時間了。）其他，請自行思考補充，放到自己的小本本上唄。

2. 應(yīng)用更新

這部分更多的是對文章《移動產(chǎn)品基礎(chǔ)模塊設(shè)計規(guī)范之應(yīng)用更新》中涉及選擇更新版本以及是否強制更新的補充和修正。

補充修正之一：原文章中在選擇更新版本的設(shè)置上，過于死板，不靈活。新的版本更新將待更新版本的選擇變?yōu)樘顚?，并且可以跨版本以區(qū)間的方式進行設(shè)置。 

補充修正之二：對是否強制更新的調(diào)整上，新版本采用“更新頻率”的方式取而代之，并可在“每次啟動提示”、“每天啟動提示”以及“每周啟動提示”中做選擇，靈活性和可控性可見一斑。 

補充修正之三：新增了渠道選擇，這是之前并未考慮到的。針對渠道設(shè)置更新版本，是針對不同渠道政策的應(yīng)對方式。 

規(guī)劃：見下圖添加新版本

 

添加新版本?

邏輯：除了以下需要著重強調(diào)的兩個新增的邏輯之外，在之前的文章以及本文以上的內(nèi)容中，基本上都有涉及。這里我們強調(diào)以下兩個位置：

1）包名。相比之前的文章，新增包名的選擇。目的是針對不同的包名——針對渠道以及版本——做對應(yīng)的升級策略。至于好處嘛，你猜猜看？

2）版本號（整數(shù)值）。其實大多數(shù)安卓的應(yīng)用市場會按照應(yīng)用的整數(shù)值版本號，來區(qū)別在對應(yīng)的市場中決定是否提示升級的。而版本號只是在對應(yīng)的位置做顯示用的值而已，不作為判斷在對應(yīng)的市場決定是否升級的。

3. 版本更新列表

版本更新列表見下圖：

 

版本更新列表?

其實就是“應(yīng)用更新”新增并確定之后生成的記錄列表。這里需要注意的是，這里的邏輯與之前文章中不同。在“應(yīng)用更新”中，如果多選渠道，將在版本更新列表中根據(jù)所選渠道的數(shù)量，生成對應(yīng)數(shù)量的記錄，方便后期針對單一渠道進行調(diào)整。

第二部分 控制

這部分是新增的部分，是近一年多的新發(fā)現(xiàn)，也會有新的感受。針對對應(yīng)的渠道或者地域，對內(nèi)容或者功能進行控制，也是不可或缺的。

其實不管是根據(jù)渠道控制，還是地域，主要是看對應(yīng)的渠道和地域，不允許或者由于合作關(guān)系不能出現(xiàn)什么功能，來做對應(yīng)的處理的。原因我在本文開始的時候提過了，大家在這部分也要格外注意。

1. 添加渠道控制和地域控制 

 

添加渠道控制

 

添加地域控制?

在渠道控制中，我們發(fā)現(xiàn)本文開始提到的渠道管理終于出現(xiàn)了。看吧，只要在渠道管理中添加了，這里就能同步獲得了，很方便吧（得意）！

對比渠道控制和地域控制，不同的是地域控制除了地域之外，只需要考慮包名，原因是某一地域一旦需要控制對應(yīng)的內(nèi)容和功能，基本上不需要區(qū)分版本，只需要針對包名做處理就可以了。（請自行腦補，這么處理的原因是什么？）

2. 渠道控制和地域控制列表

 

渠道控制列表

 

地域控制列表?

這里同樣有一個地方的邏輯需要注意，在對應(yīng)的控制列表中，由于添加的時候會選擇多個渠道或者地域，在對應(yīng)的列表中會顯示多條記錄。這個邏輯和版本更新列表與添加版本更新的邏輯是類似的，這樣操作會靈活很多。

以上，就是對之前文章《移動產(chǎn)品基礎(chǔ)模塊設(shè)計規(guī)范之應(yīng)用更新》的補充和修正了。希望能夠在這一部分，給大家一定的啟發(fā)和引導(dǎo)。如有不當(dāng)之處，還請?zhí)岢鰜?，感謝！

題外話，最近可能要認真的梳理下之前寫的文章了，因為發(fā)現(xiàn)之前的文章存在很多不足以及嚴重的邏輯問題。也感謝，在文章下留言評論的小伙伴，是因為他們的留言評論，我才又重新讀了自己之前的文章，也看到了自己當(dāng)時的不足（有種自我升級的感覺，不是么，笑）。也感謝你們，那樣不僅有了新的文章，更有了全新的我。已經(jīng)是最后了，我的思路和邏輯一定還存在不足和缺陷，希望大家多評論交流，那樣才能相互進步。謝謝！

相關(guān)閱讀：https://mp.weixin.qq.com/s?__biz=MzI0MDI0ODIxMw==&mid=2649512820&idx=1&sn=c54a8ecadb5478cd68cff6181809e404&scene=21#wechat_redirect

來源：pmcaff