移动产品基础模块设计规范之应用更新

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