微信小程序版本机制和storage如何平滑兼容详解

问题背景

一款小程序默认会有三个版本（开发、体验、生产），而同一台手机打开同一个小程序只会对应一份本地存储（storage），这就会导致当我们在本地存储中记了某些信息时，因为使用过不同版本的小程序，本地存储就会出现不匹配或是被覆盖的情况。为了解决这个问题，我们来设计一个可行的方案。

小程序版本

官方文档点这里

• 开发版 develop：本地预览，本地真机调试 所对应的小程序版本，只有在当前开发者的设备上使用，一般都是开发阶段调试功能一次性生成并使用。
• 体验版 trial：本地开发完成后，一般会上传当前版本至小程序后台，小程序后台会有对应的版本记录，可以将上传的该版本设置成体验版，供有体验版权限的项目人员使用。
• 生产版 release：即发布后的线上版本，所有人可使用。

小程序的本地存储

官方文档点这里

如果熟悉web的同学，应该很容易理解，小程序的本地存储就和web本地存储一样，会有本地的 storage，具体 api 使用可以直接看官方文档，存储格式就是一个 key 对应一个 value。就像上文背景中说到的，因为小程序有多个版本，但是本地存储一个小程序只会有一个 storage，所以使用 api 去读写 storage 的时候，就没法区分小程序版本，尤其是当拥有体验版权限的项目人员，在第一次使用生产版本时，会因为存在过体验版的本地存储而影响第一次打开正式版的体验效果。 下面我们就列一下可行的解决方案。

方案1：读写加标志

因为 storage 的数据格式是 键值对 one key one value，那我们就可以在读写 storage 的时候都加上 版本 区分，这样自然而然就键值就都分开了。

我简单写下大概的伪代码

// 本地存储键名map
const STORAGE_KEY_MAP = {
  
 API_HOST: '__api_host__'
};

// 设置 开发版 字段
wx.setStorageSync(STORAGE_KEY_MAP.API_HOST + '@develop', 'dev1');

// 设置 体验版 字段
wx.setStorageSync(STORAGE_KEY_MAP.API_HOST  + '@trial', 'dev1');

// 设置 生产版 字段（就不带版本后缀了）
wx.setStorageSync(STORAGE_KEY_MAP.API_HOST , 'dev1');

// 读取
wx.getStorageSync(STORAGE_KEY_MAP.API_HOST + '@develop');
wx.getStorageSync(STORAGE_KEY_MAP.API_HOST  + '@trial');
wx.getStorageSync(STORAGE_KEY_MAP.API_HOST)

通过给键名加上版本的标志后，读写 storage 都不会再受版本的影响。这是最基础最直接的一种方式，因为本地存储的大小为10M，我们用??这个方法等于会同时存储三个版本的本地存储数据，单纯用这个方式上就会有些冗余的感觉了。为了更优雅的使用本地存储，我更推荐使用下面提供的第2种方案。

方案2：读写加标志 + 监测生产版本更新

这个方案不会影响生产版，上线后的小程序本地只会有一份数据。结合方案1，我们改进的是，通过监测生产版本更新，清空 storage。

解释下是什么意思，因为主要是体验版和生产版之间的 storage 会有影响，在一个小程序上线前，会有一批有体验权限的人，去试用此次即将上线的版本。当这同一批人在发布后打开小程序，读取 storage 就会是上次使用体验版存储在本地的数据。为了将这两个版本的 storage 隔离，我们就要使用 方案1，先将体验版的 storage 标注出来，在生产版本发布后，打开生产版时，将之前存储的标注为体验版的 storage 清除，这样我们每个版本就只会存在一个版本的 storge 了（为什么呢？因为下一次的体验版本，一定是基于上一个生产版而产生的，在上一个生产版本使用时，我们已经将之前的非生产版本 storage 已经清楚了，那么使用新体验版时，其实就回到了一个初始化的状态了）。

使用这个方案在「开发->测试->发布」这一个正向的流程中是相对比较合理的，也就是每次发版后，非生产版本的小程序重新开始记录本地存储，

这里会有三个需要注意的地方，

• 小程序的更新机制：在冷启动时，即首次打开小程序，或者小程序超过30分钟被自动销毁后打开，都会默认更新为最新版本的小程序（用户无感）。在小程序还属于热启动时（正在当次使用中，没有隐藏过前台），是不会立刻主动下载新版本的，热启动期间想要更新小程序需通过「删除小程序、重新进入小程序」手动获取最新版本的小程序。
• 小程序提供的监听版本管理的 api，即是让我们在使用本地旧版本的时候感知到是否后台有最新版本的发布。注意：非生产版本小程序没有版本号的概念，无法使用版本更新监听，可以更改编译模式设置模拟更新。
• 因为我们需要清空非生产版本的 storage，所以我们在前期设置 storage 的时候，得将 key 统一维护，这样我们才能直接知道我们会设置进 storage 的 Key Map，便于批量删除。

下面我们来写一下相关的实现

版本定义

// 版本
const APP_ENV_MAP = {
  
  develop: "develop",
  
  trial: "trial",
  
  release: "release",
};

获取当前小程序版本

使用 api getAccountInfoSync 会返回小程序版本信息

// 获取当前小程序版本
function getEnvByAccountInfo() {
  try {
    const accountInfo = wx.getAccountInfoSync();
    return accountInfo.miniProgram.envVersion; // 版本
  } catch (error) {
    return null;
  }
}

// 当前是否为生产版本
const IS_RELEASE = getEnvByAccountInfo() === APP_ENV_MAP.release;

生产新版本监测

使用 api getUpdateManager 管理小程序更新

STORAGE_KEY_MAP 是维护好的 storage key map 集合，IS_RELEASE 是判断当前版本是否为生产版小程序

// app.js
onLaunch: function () {
    // 获取小程序更新管理
    const updateManager = wx.getUpdateManager();

    // 监听是否有新版本
    updateManager.onCheckForUpdate(function (res) {
      // 所有体验版key
      const allTrialKeys = Object.values(STORAGE_KEY_MAP).map((key) =>
        getEnvStorageKey(key, APP_ENV_MAP.trial)
      );

      // 所有开发版key
      const allDevKeys = Object.values(STORAGE_KEY_MAP).map((key) =>
        getEnvStorageKey(key, APP_ENV_MAP.develop)
      );

      // 当前是生产版且存在更(gèng)新的生产版本
      if (IS_RELEASE && res.hasUpdate) {
        // 没有批量删除的api，只能这么删了
        [...allTrialKeys, ...allDevKeys].forEach((key) => {
          uni.removeStorageSync(key);
        });
      }
    });
  },

整个过程大概就是这样子

总结

到此这篇关于微信小程序版本机制和storage如何平滑兼容的文章就介绍到这了,更多相关小程序版本机制和storage平滑兼容内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！