并不是之前的文章有了什么问题，而是要扩展之前的应用更新范围，将 Android 这个复杂的环境考虑进去。当然，看标题也比较清楚了。
我想，当你和这片文章有缘时，一定是你也遇到了和我类似的问题，并且在寻找更好的解决方案。那么，我把我自己近期的思考整理出来，我们一起探讨下。
这次面对的是两个问题
1. Android 应用分渠道设置更新；
2. Android 应用分地域设置更新；
为什么会面对这两个问题呢？
在利益面前，一些阻碍都需要也必须被跨过！嗯！（嗯，是自言自语的(oo)）
比如，应用想在某些渠道发布的时候，一些功能，比如广告、网赚等，该渠道是不允许出现的，甚至连关闭功能后（后端/后台控制），但有对应的 SDK 也不被允许。
再比如，一些城市中，对一些功能也是比较敏感的，例如帝都；再再比如，和一些城市的某些公司合作过程中，不希望让这些合作公司知道自己做了某些功能。等等，还有哪些问题，等待你的发现哦。
感觉，是不是很神奇？！
接下来，讲讲，如何解决上述的问题呢？
其实，主要的并不在升级管理自身，而是在控制或者说配置的逻辑上。我会分两部分来描述，一部分针对应用升级，另一部分针对控制（我暂且叫它控制，不清楚大家各自的工作中，这部分会起什么有趣的名字呢？来，感兴趣的也给我留言和评论吧，一起聊聊～）
第一部分 应用更新
这部分会细化开篇提到的很久之前的文章，调整之前的一些逻辑，并补充不足。这部分先讲下新增的部分——渠道列表，后面会介绍一些应用升级相关的规划和策略等逻辑。
1. 渠道管理
原因：应用推广使用，面对频率较高的新增渠道，比如新增应用市场、新增应用市场活动包、新增推广包等等，这些都需要频繁的新增渠道，总是由后端来搞太复杂，效率也比较低。
优势：有了这个表，能够让运营相关人员轻松搞定，并且还能协调渠道、开发配合完成工作；这个表在控制部分也会用到，后面我会具体介绍。真是一举多得的好办法。
思考：其实这是在应用版本升级策略中，后端/后台开发过程中必然会用到的，渠道表在后台开发中，实现成本也比较低。
规划：见下图渠道管理
渠道管理
逻辑：并不复杂，通过后台新增渠道记录，在后台展示，并能够控制该渠道是否启用。当然会有一些状态，比如：第一次添加，列表中不存在，如何提示；再次添加，列表中已存在，如何提示；第一次添加成功后，如何提示等等的处理逻辑。看，简单吧～相信，你和我一样，也能考虑到。再看看，是不是还有哪些没考虑到的问题呢？比如操作者，谁添加、停用/启用的，方便后端查看记录，已确定责任人（这是产品很成熟，组织很完善的时候考虑的；初创团队没必要这么搞，太耗精力体力和时间了。）其他，请自行思考补充，放到自己的小本本上呗。
2. 应用更新
这部分更多的是对文章《移动产品基础模块设计规范之应用更新》中涉及选择更新版本以及是否强制更新的补充和修正。
补充修正之一：原文章中在选择更新版本的设置上，过于死板，不灵活。新的版本更新将待更新版本的选择变为填写，并且可以跨版本以区间的方式进行设置。
补充修正之二：对是否强制更新的调整上，新版本采用“更新频率”的方式取而代之，并可在“每次启动提示”、“每天启动提示”以及“每周启动提示”中做选择，灵活性和可控性可见一斑。
补充修正之三：新增了渠道选择，这是之前并未考虑到的。针对渠道设置更新版本，是针对不同渠道政策的应对方式。
规划：见下图添加新版本
添加新版本
逻辑：除了以下需要着重强调的两个新增的逻辑之外，在之前的文章以及本文以上的内容中，基本上都有涉及。这里我们强调以下两个位置：
1）包名。相比之前的文章，新增包名的选择。目的是针对不同的包名——针对渠道以及版本——做对应的升级策略。至于好处嘛，你猜猜看？
2）版本号（整数值）。其实大多数安卓的应用市场会按照应用的整数值版本号，来区别在对应的市场中决定是否提示升级的。而版本号只是在对应的位置做显示用的值而已，不作为判断在对应的市场决定是否升级的。
3. 版本更新列表
版本更新列表见下图：
版本更新列表
其实就是“应用更新”新增并确定之后生成的记录列表。这里需要注意的是，这里的逻辑与之前文章中不同。在“应用更新”中，如果多选渠道，将在版本更新列表中根据所选渠道的数量，生成对应数量的记录，方便后期针对单一渠道进行调整。
第二部分 控制
这部分是新增的部分，是近一年多的新发现，也会有新的感受。针对对应的渠道或者地域，对内容或者功能进行控制，也是不可或缺的。
其实不管是根据渠道控制，还是地域，主要是看对应的渠道和地域，不允许或者由于合作关系不能出现什么功能，来做对应的处理的。原因我在本文开始的时候提过了，大家在这部分也要格外注意。
1. 添加渠道控制和地域控制
添加渠道控制
添加地域控制
在渠道控制中，我们发现本文开始提到的渠道管理终于出现了。看吧，只要在渠道管理中添加了，这里就能同步获得了，很方便吧（得意）！
对比渠道控制和地域控制，不同的是地域控制除了地域之外，只需要考虑包名，原因是某一地域一旦需要控制对应的内容和功能，基本上不需要区分版本，只需要针对包名做处理就可以了。（请自行脑补，这么处理的原因是什么？）
2. 渠道控制和地域控制列表
渠道控制列表
地域控制列表
这里同样有一个地方的逻辑需要注意，在对应的控制列表中，由于添加的时候会选择多个渠道或者地域，在对应的列表中会显示多条记录。这个逻辑和版本更新列表与添加版本更新的逻辑是类似的，这样操作会灵活很多。
以上，就是对之前文章《移动产品基础模块设计规范之应用更新》的补充和修正了。希望能够在这一部分，给大家一定的启发和引导。如有不当之处，还请提出来，感谢！
题外话，最近可能要认真的梳理下之前写的文章了，因为发现之前的文章存在很多不足以及严重的逻辑问题。也感谢，在文章下留言评论的小伙伴，是因为他们的留言评论，我才又重新读了自己之前的文章，也看到了自己当时的不足（有种自我升级的感觉，不是么，笑）。也感谢你们，那样不仅有了新的文章，更有了全新的我。已经是最后了，我的思路和逻辑一定还存在不足和缺陷，希望大家多评论交流，那样才能相互进步。谢谢！
相关阅读：https://mp.weixin.qq.com/s?__biz=MzI0MDI0ODIxMw==&mid=2649512820&idx=1&sn=c54a8ecadb5478cd68cff6181809e404&scene=21#wechat_redirect
来源：pmcaff
