APP升级二三事：APP升级场景及功能设计总结

　　App升级，不可忽略的功能特性。对升级的场景和功能设计做了一些分析与总结，希望能帮到正在设计该部分的产品经理。
　　升级场景
　　在APP启动时，判断当前版本号，若存在最新版本，则做升级提示；
　　在APP的设置中，穿插“检查最新版本”的功能；
　　由于目前appstore的政策限制，对于iOS应用，不允许出现“检测最新版本”，以及不允许出现版本更新提示的功能，但凡发现，可能会面临下架的风险。这也意味着对后台接口的兼容要求再一次提高，对于历史相对久远的版本，建议有两点设计：
　　接口返回数据需判断版本信息，新逻辑的业务数据不在接口中返回。如V3。0之前版本不支持航司直连的机票预定，则用户搜索时，V3。0之前的版本不返回航司直连的机票信息。
　　保留接口错误的弹框文案由接口提供，如涉及到强制升级，对于旧版本的数据访问，则返回提示“该部分功能需版本升级后方可使用”。
　　对于appstore的政策，意味着不能要求用户强制升级，因此在接口的文案上，需要适时做一些用户提醒。
　　补充：appstore这样的政策希望达到的效果明显，一来杜绝app泛滥的更新提示，二来鼓励用户使用appstore的自动更新，能够更好体验各种APP最新版本的功能。
　　升级提示
　　这部分内容针对Android版本，以及iOS的企业级应用（企业级应用无需通过appstore审核，版本更新不受appstore控制）。
　　AB两个页面主要的场景为普通升级，其中非wifi环境下，需要给用户做提示。需要注意的是尽量把取消下载的按钮设计隐晦一些，能够提高更新的百分比。
　　C页面主要针对强制升级，不区分wifi环境。
　　热升级
　　对于移动应用，当频繁遇到BUG修复，需要重新发包，对于用户体验而言简直就是一团糟。这个问题在游戏上的暴露更加明显，因此有了热更新这种方法：无需发版本，直接通过补丁资源包的形式，对APP进行修复升级，升级的过程中不需要用户强制退出。除了游戏外，业务型app，目前市面上发现的仅有12306。
　　普通升级：
　　热升级：
　　优势以及比较明显：流程短、时间少、无需暂停app的使用即可完成升级。虽然还未使用过，据说能提高3倍左右的升级效率，但从直面上不难理解这样的效果。
　　https证书包过期
　　为了防止数据传输过程中的“裸奔”情况，在客户端与服务器会有一套HTTPS证书，进行加密、解密。但这样的证书往往具有时效性，比如一年。再临近一年到期的时候再来考虑升级证书包，很可能会出现旧版本闪退的问题，因此在功能设计上，要考虑将证书包设置为后台可配置，可更新。
　　苹果公司推出iOS9系统的时候，为了提升应用程序与Web服务之间的连接安全，苹果要求所有应用程序的HTTP协议全部升级为HTTPS协议。由于iOS平台的封闭性，遭遇到的安全问题相比于Android来说要少得多，这就导致了许多iOS开发人员对于安全性方面没有太多的深入，但苹果公司强调每个开发者都应该致力于保证客户的数据的安全。
　　善用第三方
　　不少数据监控的第三方平台都会提供各类的升级SDK，在调用之前需要先继承平台提供的SDK，这样经过调用之后我们就可以通过平台实现更新接口的提示功能了，默认的平台一般会提供静默安装，更新提示弹窗，强制更新等几种，可以根据自身APP的需求来确定更新的方式。
　　频繁升级问题
　　目前一些大厂的APP保持着24周的迭代速度，过于频繁的更新也会导致用户的反感，特别是包含自带升级提示的应用。问题主要集中几个方面：
　　烦1：升级后的引导页面
　　如果不是大版本的升级，引导页要尽量避免，特别是对于一些老用户而言，即便在设计上多么别出心裁，也要记得在引导页上加如“跳过”的选项。
　　烦2：升级后的数据丢失
　　这属于低级错误，一些本地数据，包括登录的用户名、密码、浏览记录等要妥善地保持在本地，升级之后也能让老用户正常使用，而不是突然就换了一个新世界。
　　烦3：无意义的升级
　　功能无新增、无优化、修复了几个交互就更新，对于用户而言，消耗了下载的成本，却得不到想要的结果，这就是一种打扰。
　　总结
　　应用升级可以分为普通升级和强制升级两种，一般不太建议使用强制升级（用户体验很差），除非是一些严重的线上
　　针对业务的需要，可以有针对性地设计升级的提示语，尽量能够在描述上吸引升级，以便用户能享受升级后所带来的良好体验。
　　升级需要考虑https证书包的替换问题，避免旧版本的过期导致应用的闪退问题。
　　严格控制迭代的速度，过晚、过早都会是问题。