uni-app升级思路(前端角度)
文章目录
- `uni-app`升级思路(前端角度)
- 一、前言
- 1.1 升级
- 1.2 全量更新
- 1.3 增量更新
- 1.4 应用版本号命名规范（举例）
- 二、升级思路
- 三、前端升级核心诉求
一、前言
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增量更新版本。
