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

本文是作者对之前文章《 移动产品基础模块设计规范之应用更新 》的补充和修正，希望能给你一定的启发~

我又来打自己的脸了，啪啪啪……这次要更新的是自己一年半前写的文章《移动产品基础模块设计规范之应用更新》。
并不是之前的文章有了什么问题，而是要扩展之前的应用更新范围，将 Android 这个复杂的环境考虑进去。当然，看标题也比较清楚了。
我想，当你和这片文章有缘时，一定是你也遇到了和我类似的问题，并且在寻找更好的解决方案。那么，我把我自己近期的思考整理出来，我们一起探讨下。
这次面对的是两个问题：

• Android 应用分渠道设置更新；

• Android 应用分地域设置更新。

  为什么会面对这两个问题呢？
  在利益面前，一些阻碍都需要也必须被跨过！嗯！（嗯，是自言自语的(oo)）

比如，应用想在某些渠道发布的时候，一些功能，比如广告、网赚等，该渠道是不允许出现的，甚至连关闭功能后（后端/后台控制），但有对应的 SDK 也不被允许。
再比如，一些城市中，对一些功能也是比较敏感的，例如帝都；再再比如，和一些城市的某些公司合作过程中，不希望让这些合作公司知道自己做了某些功能。
等等，还有哪些问题，等待你的发现哦。
感觉，是不是很神奇？！
接下来，讲讲，如何解决上述的问题呢？
其实，主要的并不在升级管理自身，而是在控制或者说配置的逻辑上。我会分两部分来描述，一部分针对应用升级，另一部分针对控制（我暂且叫它控制，不清楚大家各自的工作中，这部分会起什么有趣的名字呢？来，感兴趣的也给我留言和评论吧，一起聊聊～）

第一部分 应用更新

这部分会细化开篇提到的很久之前的文章，调整之前的一些逻辑，并补充不足。这部分先讲下新增的部分——渠道列表，后面会介绍一些应用升级相关的规划和策略等逻辑。

1. 渠道管理

（1）原因
应用推广使用，面对频率较高的新增渠道，比如新增应用市场、新增应用市场活动包、新增推广包等等，这些都需要频繁的新增渠道，总是由后端来搞太复杂，效率也比较低。
（2）优势
有了这个表，能够让运营相关人员轻松搞定，并且还能协调渠道、开发配合完成工作；这个表在控制部分也会用到，后面我会具体介绍。真是一举多得的好办法。
（3）思考
其实这是在应用版本升级策略中，后端/后台开发过程中必然会用到的，渠道表在后台开发中，实现成本也比较低。
（4）规划
见下图渠道管理：

（5）逻辑
并不复杂，通过后台新增渠道记录，在后台展示，并能够控制该渠道是否启用。当然会有一些状态，比如：第一次添加，列表中不存在，如何提示；再次添加，列表中已存在，如何提示；第一次添加成功后，如何提示等等的处理逻辑。看，简单吧～相信，你和我一样，也能考虑到。再看看，是不是还有哪些没考虑到的问题呢？比如操作者，谁添加、停用/启用的，方便后端查看记录，已确定责任人（这是产品很成熟，组织很完善的时候考虑的；初创团队没必要这么搞，太耗精力体力和时间了。）
其他，请自行思考补充，放到自己的小本本上呗。

2. 应用更新

这部分更多的是对文章《移动产品基础模块设计规范之应用更新》中涉及选择更新版本以及是否强制更新的补充和修正。

• 补充修正之一： 原文章中在选择更新版本的设置上，过于死板，不灵活。新的版本更新将待更新版本的选择变为填写，并且可以跨版本以区间的方式进行设置。
• 补充修正之二： 对是否强制更新的调整上，新版本采用“更新频率”的方式取而代之，并可在“每次启动提示”、“每天启动提示”以及“每周启动提示”中做选择，灵活性和可控性可见一斑。
• 补充修正之三： 新增了渠道选择，这是之前并未考虑到的。针对渠道设置更新版本，是针对不同渠道政策的应对方式。

（1）规划
见下图添加新版本：

（2）逻辑
除了以下需要着重强调的两个新增的逻辑之外，在之前的文章以及本文以上的内容中，基本上都有涉及。这里我们强调以下两个位置：

• 包名。 相比之前的文章，新增包名的选择。目的是针对不同的包名——针对渠道以及版本——做对应的升级策略。至于好处嘛，你猜猜看？
• 版本号（整数值）。 其实大多数安卓的应用市场会按照应用的整数值版本号，来区别在对应的市场中决定是否提示升级的。而版本号只是在对应的位置做显示用的值而已，不作为判断在对应的市场决定是否升级的。

3. 版本更新列表

版本更新列表见下图：

版本更新列表
其实就是“应用更新”新增并确定之后生成的记录列表。这里需要注意的是，这里的逻辑与之前文章中不同。在“应用更新”中，如果多选渠道，将在版本更新列表中根据所选渠道的数量，生成对应数量的记录，方便后期针对单一渠道进行调整。

第二部分 控制

这部分是新增的部分，是近一年多的新发现，也会有新的感受。针对对应的渠道或者地域，对内容或者功能进行控制，也是不可或缺的。
其实不管是根据渠道控制，还是地域，主要是看对应的渠道和地域，不允许或者由于合作关系不能出现什么功能，来做对应的处理的。原因我在本文开始的时候提过了，大家在这部分也要格外注意。

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

添加渠道控制

添加地域控制
在渠道控制中，我们发现本文开始提到的渠道管理终于出现了。看吧，只要在渠道管理中添加了，这里就能同步获得了，很方便吧（得意）！
对比渠道控制和地域控制，不同的是地域控制除了地域之外，只需要考虑包名，原因是某一地域一旦需要控制对应的内容和功能，基本上不需要区分版本，只需要针对包名做处理就可以了。（请自行脑补，这么处理的原因是什么？）

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

渠道控制列表

地域控制列表
这里同样有一个地方的逻辑需要注意，在对应的控制列表中，由于添加的时候会选择多个渠道或者地域，在对应的列表中会显示多条记录。这个逻辑和版本更新列表与添加版本更新的逻辑是类似的，这样操作会灵活很多。
以上，就是对之前文章《 移动产品基础模块设计规范之应用更新 》的补充和修正了。希望能够在这一部分，给大家一定的启发和引导。如有不当之处，还请提出来，感谢！

题外话：

最近可能要认真地梳理下之前写的文章了，因为发现之前的文章存在很多不足以及严重的逻辑问题。也感谢，在文章下留言评论的小伙伴，是因为他们的留言评论，我才又重新读了自己之前的文章，也看到了自己当时的不足（有种自我升级的感觉，不是么，笑）。也感谢你们，那样不仅有了新的文章，更有了全新的我。
哦，还不是最后的最后，觉得产品经理社区中的文章被评论会发邮件通知是件很有趣的事，其实我是个邮箱重度使用者，平时都会仔细看邮件，并整理邮件内容。已经是最后了，我的思路和逻辑一定还存在不足和缺陷，希望大家多评论交流，那样才能相互进步。谢谢！

相关文章

移动产品基础模块设计规范之应用更新
移动产品基础模块设计规范之应用更新（2）
 
作者 @郑几块 

关键字：应用更新, 模块设计, 移动产品

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！