某社区APP完整原型案例-第二期（附源文件下载）

本文内容为社区类APP的完整原型设计思路及文件，对于产品及交互很有参考意义，推荐大家学习。

目录：

版本应用内更新（可支持灰度、A/B TEST测试）

发布图文功能

自建敏感词管理

APP应用内更新提醒是个基建功能，APP刚做的时候就可以开始规划进去，这个功能开发时间比较短的，服务端大概半天，两个客户端半天，测试半天就好了。应用内更新提醒主要目的有两个。

第一个目的是把新功能快速覆盖到所有用户，比如双十一来了，而老板临时在十月中旬给了个新的业务需求，把审核时间都算进去后发现，用户能下载的时间是十一月八号，这个时候就需要应用内更新去提醒用户，不更新没有这个功能。

第二个目的是针对某些特殊的机型解决Bug，碰见最多的是iOS9以前的系统，这类用户是iPhone4代或5代的手机，安卓就更多了，有些特别老的机型或系统兼容不到，就会出现bug。用户通过客服反馈过来，产品经理收集给研发，改好了以后不能立马发新版本到市场，所以应用内更新提醒就可以指定给这些用户，专门指定使用这些机型的用户发布新的版本，他们通过更新去下载已经解决了问题的包即可。

客户端需要注意的问题有：

1. 是否提醒？

拿当前版本和推送消息的版本对比，如果推送的版本号高则弹出更新提示，如果当前版本号已经是最新了，则不弹出提示；

2. 有国际版的应用

产品诉求是判断用户APP当前的语言类型，去推送对应语言的更新提醒；

3. 可选更新

可选更新每天只提示一次，用户可以点击“关闭”按钮关掉提醒弹框；

4. 强制更新

用户打开后就提示，隐藏“关闭”按钮，用户不更新就无法进入APP主界面；

5. 指定用户更新

这里有一个问题要考虑进去：如果指定的用户没有登录怎么办？用户没有登录程序就没法知道是要推到哪个设备上去，一种做法是用户没有登录就不提醒了，另一种做法是在一开始设计APP的时候，就把硬件设备号和用户注册的账号捆绑一下。这样就算用户没有登录也能推送到指定账号捆绑的硬件设备上。

把账号和硬件设备捆绑还有一个长远的好处是用户账号安全，如果账号切换到别的设备登录时，硬件设备号对不上，程序可以判定账号为盗号，这个时候需要注册的手机号或邮箱去验证身份。当然这里会误伤有多台设备的人，比如测试的妹纸（真实的用户只有少部分人有多台设备的）。

6. 哪里下载更新的包

iOS的更新包需要跳转到app store去下载。这里产品经理要注意一个问题：APP审核通过并在app store释放后，服务器会有一个小时左右的延迟，所以此时如果去发布应用内更新提醒的话，用户从我们APP跳转过去的时候状态是不对的，也会出现更新失败的情况，所以iOS的应用内更新要晚至少一个小时才发布。

安卓的应用内更新不新包不走市场的服务器，是走我们自己的服务器，所以包要先传到自己的服务器上面，从自己的服务器下载，安卓在发布更新前只需要保证好新包传到服务器即可。另一点需要注意的是安卓的下载页面是可以自己定义的，可以写成一个新页面、可以写成一个弹窗、也可以只在状态栏显示下载进度，根据自己的需要来吧。

管理后台分两个部分，第一个部分是已经添加过了的版本记录，如第一张截图显示；第二个部分是发布版本的页面，每个字段必填，版本号需要按照研发给的新包版本，有个交互要注意的是，选择全部用户时，更新选项可选更新和强制更新都可以选，选择指定用户时就只能选择强制更新，道长经历的项目是这么做的，小伙伴们可以结合自己的需求去规划。