其实APP的更新机制，跟一般的C/S产品的更新机制一样。我整理了最近踩的坑，分享一下
APP版本的生命周期：
- 设计期：根据上一个版本的用户反馈，修复bug、优化设计和开发新功能。根据近期的公司规划，上线新的功能，往往在上一版本还未上线，就开始规划了
- 开发期：根据设计期的结论，开发的周期，对更改内容进行取舍，决定当前版本应该上线的内容，实际情况设计期与开发期是有重合部分的，也就是我们常常说的临时加需求。根据开发的反馈，例如某种实现方式，花费的人力较高，决定其他的实现方式
- 测试期：公司内部测试，保证流程畅通，使用效果与设计一致，发生不一致，要么该程序，要么该设计
- 内测期：即用户接受度测试（UAT测试，User Acceptance Test)）
小公司做的多是兼容性测试，保证新版APP可用，附带用户的功能反馈这里吐槽一下，国内各个安卓手机厂商，你们是要搞出多少个神奇的自定义，要累死我们啊！还是苹果的测试舒服。
大公司的兼容性测试可能在阶段3就基本完成了。（没去过大公司，手动斜眼）内测主要是测试用户对新版本的反馈，例如改了交互和布局，用户学习成本怎么样；新功能好不好用，有没有什么改进的地方；促销活动是不是太多了，引起了用户的反感，用户是不是真的感兴趣....... - 静默更新期 （大公司请直接忽视）
由于现在就职一个小型公司，对安卓机型无法做到全覆盖。我们会先更新各大应用市场的应用和官网的下载链接，用户自行更新，根据用户反馈和兼容性问题，再决定是否大规模推送。 - 推送更新期
顺利通过静默更新期，我们就会给用户推送，弹框提醒用户可以更新，但是非强制的。只是推荐和提醒 - 强制更新期
由于新版本的不断产生，旧版本会在一定时间后，停止维护。这个时候旧版本就必须强制更新，用户不更新，不能使用。
APP的更新过程
- 静默更新期。（一般大公司可能没有静默更新期，这个主要也是为了解决兼容性测试，自己想出来的）这样做只是为了将问题暴露出来的同时，将影响降到最小的一种手段。随着各类手机管理和应用市场类APP的普及，用户在这里进行主动更新。一般两三天即可。
- 推荐更新期
因为用户打开APP时，用户可能是急需使用的，没有空闲的事件，网络环境也不好，所以只是提醒用户更新。用户自己在网络环境好，时间空闲的时候进行更新 - 强制更新期
旧版本的维护总是需要成本的，随着新版本的推出，旧版本总有停止维护的时候，这个时候最好强制用户更新。保证用户的使用，毕竟APP出现了问题，损伤了用户，最终损伤的还是公司自己。
特别对于一些创业型公司，业务逻辑和方向经常发生变动。一旦发生根本变动，例如功能取消，就需要强制用户及时更新，保证用户的行为符合现在业务逻辑。
这个一定要做好！！！不然旧用户天天使用，产生错误或者异常数据，你又无法告知用户，当时你想死的心都有了。
