封面只是想分享一张喜欢的图片，嘻嘻嘻
一个产品，用户除了会在意流程简不简单、好不好用、页面好不好看以外，各种小细节也很重要。
今天讲讲我接到的一个新需求------整改版本更新功能。
一、以前是这样的
1. 发版前：微信群通知用户
如果计划今晚发版，研发部就通知运营部，运营部再在群里通知各用户"我们将于YYYY年MM月DD日 hh:mm:ss发版，请大家......"
2. 发版时：接口502+页面无响应
在这之前，发版时用户仍停留在网站，但接口返回502，但502未告知给用户，所以用户不知道这时到底发生什么了，只知道页面没数据了、卡着动不了了、怎么刷新都没办法......
3. 发版后：app粗暴的强制更新
在这之前我们的项目还处于快速开发的过程，迭代间隔短频率高，有时我们会更新影响流程的重要功能，担心用户未及时更新，所以我们只提供了强制更新方案。
二、现在是这样的
这都什么时代了，还需要口口相传......
1. 发版前：升级预告
大家想想618、双十一、双十二，各大平台是不是很早就开始宣传"走过路过别错过，满三百减五十，快来加购吧~"
我们产品的用户群体有一线工人、办公室文员、喝茶的经理、车上的老总，提前告知用户，可以让经理及时换班、让工人规避做工单的风险等等。总之，有事早通知，准是没错的。
怎么通知呢？
-
在内部管理平台新增一条升级预告消息，可以包含版本号version、预告内容content、预告状态status（是否有效）、平台（区分网站和APP，因为可能不是同时都需要发版）
-
网站：
1）用户登录或主动刷新页面时，页面顶部显示升级预告，实现逻辑和app一样
-
APP：
1）充分利用消息推送、短信推送，可以根据自身业务来定，看这次更新是否需要紧急通知用户，我们仅使用消息推送。平台新增一条升级预告后，就主动推送一条app消息给用户
2）打开app后，弹框弹出升级提醒（包含"我知道了"和"不再提醒"按钮），在store记录预告消息的id。
- 点击"不再提醒"，则在store缓存中将
isRemind置为false； - 点击"我知道了"，则下次打开首页还会显示弹框。
- 每次打开首页时，从接口获取到数据，如果消息状态有效
status: true，则判断消息id同缓存中消息id是否一致：一致则表示是同一条消息，则根据缓存中的isRemind来判断是否显示消息；不一致则表示是新消息，直接显示。
2. 发版时：
场景：我们产品是全量发布，发布完成后网页能正常访问，但这时产品会进行验收，还不希望用户进行访问。
页面：pc和app的升级中页面单独写在项目中，这样可以在页面中写监听：监听到版本正常后就返回首页。
方案：发版中和验收中，运维将别人的IP设置为不能访问，将公司特定IP设置为可访问。
网站：不能访问的，nginx就设置跳转到升级中页面；能访问的就不做处理，发版时页面会接口报502（只能内部人员能看见），发版后验收时页面正常使用。
APP：app中不好重定向，所以通过配置文件来告诉前端该用户是否应该访问页面。远程存在2个json配置文件，内容就是一个对象之类的{isEntry: 1}和{isEntry: 0}，分别表示可以访问和不可访问；app打开时，前端请求json，根据是否可以访问做处理，不能访问的，前端让重定向到升级中页面，能访问的不做处理。
3. 发版后：
内部管理平台：上传新的安装包、配置升级文案等
网站：所有人正常使用
APP：所有人正常使用，打开App如果版本较低则会主动打开"版本更新"弹框。
APP可以提升用户体验的地方：
- 版本判断放在登录之前，先检查是否有更新，也就是这个接口不需要用户权限控制
- 升级页面判断是否连接了wifi，连接wifi则更新不耗流量，没连接则显示此安装包只有多大
- 提供"暂不更新"和"检查更新"的入口
总结
思考方案时，自己感觉做了一件大事；但多思考几次后，特别是写完文章后，又觉得新的升级方案其实很简单，上面说了一堆废话。
没关系，把每一件小事做好，就很好啦~~