uni-app升级思路(前端角度)

uni-app升级思路(前端角度)

一、前言

1.1 升级

App类应用升级是所有应用必备的功能，可能是新功能的迭代，亦或是紧急bug的修复，无论何种需求，站在在我们开发者的角度，都希望用户能够 尽快 升级到 最新版本。

1.2 全量更新

重新安装完整应用，需用户操作，需调用系统的安装程序，应用需要重新启动。

1.3 增量更新

增量安装应用，无需用户操作，无需调用系统安装程序，可以做到用户无感知（如果产品需求需要提示，我们也可以做）。

PS: 增量更新必须基于一个 基线版本（比如某次全量更新版本，增量 的含义就是基于该版本做的差分），否则可能造成不可预知的问题。

1.4 应用版本号命名规范（举例）

比如1.2.3，第一位为 主版本号 ，第二位为 次版本号 ，第三位为 修订版本号 。

当应用有大的新功能迭代或者uni-app的基座有更新时，我们会修改前两位，发布 全量包 ；当有小功能迭代或者有紧急bug修复时我们会修改第三位，发布 增量包 。

全量包的后缀名为 .apk ，增量包的后缀名为 .wgt 。

二、升级思路

假如当前最新版本为6.0.3，应用如果要更新到该版本，6.0.0版本之前的所有版本升级需要两步：首先需要先 直接 全量升级到 6.0.0版本，第二步应用重启，重新请求接口，直接 增量更新到6.0.3版本；6.0.0和6.0.2版本可 直接 增量更新到6.0.3版本。

依据上述思路，后端最简单的做法就只需要维护 最新的基线版本 和 最新的增量包 就可以实现需求了。

三、前端升级核心诉求

前端的升级完全受后端控制。从前端角度而言，只需要 后端给出三个字段就可以了：是否需要升级、是全量升级还是增量更新、更新包url（请求升级接口时，前端会将应用当前版本号传给后台）。

后端可以参考第二点的升级思路，也可以摒弃，然后按照自己的思想来做，后端如何维护增量和全量版本以及如何通过管理后台设置升级策略，前端并不关心。后端唯一需要把握的原则是： 增量包的更新必须依赖它自己的基线版本 ，即从1.0.2版本不能直接升级到6.0.3增量更新版本。