APP多版本并行更新方案

---

App为什么要更新版本

任何一款APP都不可能完美，功能也不可能完善，需要不断迭代更新完善APP。例如：随着业务的不断发展而叠加的功能、产品发展到一定程度需要大改版提升用户体验、程序出现BUG、政策原因需要紧急关闭某些功能等等。这些场景都会成为APP更新版本的理由，更新的目的是为了更好的呈现一款更加合理、更加稳定、更加完善、体验更优的APP，而不是每次的升级给目标使用用户带来困扰和体验度降低问题。

更新类型分析

● 静默更新【考虑技术问题，此功能暂不实现，做为下一版的技术研究方向】

1. 功能解释：静默更新是由手机悄悄的更新，一般用户在应用市场勾选了Wifi状态下，闲时自动更新功能，手机系统会按规则帮助用户自动更新APP，此功能和用户手动点击更新一样，只是由系统帮用户做了。
2. 适用场景： 在APP发布新版后，并没有什么紧急或较紧急的诉求希望用户尽快更新APP的，都可以选择静默更新。

● 强更新

1. 功能解释：强更新是指用户必须更新，否则不允许使用APP，非常的强制和粗暴。用户只能接受，否则无法使用。
2. 适用场景：一般是系统重构，发生了数据迁移；或者大功能上线，替代了老功能；或者是严重BUG。总之，是牺牲用户体验，也要非升不可的场景才会用上。.

● 弱更新

1. 功能解释：弱更新是指，在用户进入到APP后，弹窗提示用户升级版本，用户可以选择升，也可以不升正常用。也就是说，升不升用户说了算。是一种比较友好的用户体验，选择权交给了用户。
2. 适用场景：不希望牺牲用户体验，但是又希望用户快点升级到新版本体验新的功能或者更佳的视觉、交互体验等场景（也方便产品经理收集上线后的用户数据，做功能分析），可以使用弱更新。值得一提的是，弹窗的频率不宜太高，一般1天1次即可，否则容易引起用户反感。【提醒次数和频率做成配置功能】

● 基于Bug修订版

1. 功能解释：对于某一版的APP出现问题，且更新版本是非强制更新版。
2. 适用场景：在不希望牺牲用的体验，又不想全部更新的时候，对于已经下载有bug的版本进行bug修订版提醒，对于其它版本可不提醒，即可做到只针对某一版进行更新，而不用全量更新。若之后发布强制更新版，则直接跳过Bug修订版，直接更新。

应该如何解决

● 非强制不提示更新：对于小变动，如样式的变动等可以不提示用户进行更新，而由自己手动进行更新。
● 非强制更新：对于新功能的增加再不对原有功能造成影响的前提下，选择提示更新，用户可以更新也可以不更新。
● 强制更新：对于核心功能的优化，若不更新则退出APP。
● 在后台提供同一个接口的多种版本的方案，使不同版本可以访问不同版本的接口。
● 采用数据表记录的功能，对于第次用户的更新进行记录，用来统计每一版本发行后更新的用户数量
● 对于当前单一的版本更新信息满足不了多版并行功能，后台采用表结构的功能来发布不同版本的信息。
● 对于用户不连贯使用，产生的版本更新漏洞，采用最低兼容版本号进行区别，若小于小低版本号，不管当前最新版本是否需要更新都将进行强制更新，以保证APP的正常逻辑处理。比如用户为1.0版本，1.1版本为强制更新，而1.2版本为最新版本不需要强制更新，在1.1到1.2期间，用户未打开过APP,再次打开时，不管1.2是否强制更新，中间有一版强制更新，则要求用户强制更新。

升级样式的收集

表结构

• t_app_version

字段	类型	描述
id	int	自增主键
appType	int	app对应编号（字典维护）
appVersion	Int	app版本号
apiVersion	int	后台接口版本号：默认1.0.0
updateType	int	1：强制更新 2：提醒更新 3：可忽略更新
updateDescription	int	更新描述
url	int	app下载地址
versionType	int	版本类型
allowLowestVersion	int	允许最低版本（低于这个要强制更新）
createTime	int	创建时间
createBy	int	创建人
updateTime	int	更新时间
updateBy	int	更新人
isDel	int	是否被删除

• t_app_version_info