Applet control version update best practices

Analysis of applet update mechanism

According to wechat applet Official documents Explanation , The update mechanism of the applet is mainly divided into Update when not started and Update on startup Two modes . Update on startup It will asynchronously check whether there is a new version when the applet is cold started , If there's a new version , Will download it , Wait for the next cold start to start with the new version code ; and Update when not started There will be a timer for the most recent 7 Regularly check whether there is a new version of the applet used within days , Every time 6 Once an hour , If there is a new version, it will be pre downloaded , You can directly use the latest version at the next cold start .

Applet update mechanism

Applets from the base library 1.9.90 From the beginning wx.getUpdateManager Interface , Use this interface , You can know if there is a new version of the applet 、 Whether the new version is downloaded well and the ability to apply the new version . In the officially recommended Best practices in , To ensure the user experience , The advice is only in highly necessary Pop up a box to remind the user to force the update .

And the time when we need to update is uncertain , Sometimes it's urgent bug Repair requires forced updates , Sometimes the new function of the activity needs to be forced to update if it wants to cover all users quickly , So we need a distribution mechanism that can flexibly control user version updates .

Forced update version configuration distribution

To achieve version comparison , And determine whether to force the update , First of all, we must ensure that the applet release has standard version management and inject the version number into the code , Then, the minimum version number to be updated is issued through the interface and compared with the currently open version to complete the reminder of forced update .

Version management and version injection

In our applet project standard-version Perform version number management , follow Semver Semantic version specification . Each time it is published, it passes standard-version To strike tag And update the package.json In the document version Field

Release version number selection

tag Of push Will trigger pipeline construction , stay npm run build Stage , Get by extracting package.json In the field , And pass gulp-batch-replace Plug in version number substitution , Complete the injection of version number into the code

// gulpfile.js
const gulpif = require('gulp-if');
const batchReplace = require('gulp-batch-replace');
const version = require('./package.json').version;
gulp.src('src/**/*.js').pipe(gulpif(
    isEnvJs,
    batchReplace([
        ['process.env.APP_VERSION', JSON.stringify(version)],
        ...
    ]),
))

// env.js
const env = {
    version: process.env.APP_VERSION,
    ...
}

Version configuration management

On the back-end version configuration , We have adopted a more granular version control configuration , It is divided into application level version control , Page level version control and interface level version control .

• Application level （app）

The application level configuration allows the user to enter the applet , stay app.onLaunch Phase to judge the version number

• Page level （pages）

When a user visits a page , If the page path hits the configuration path , It will trigger version number judgment

• Interface level （apis）

When a user requests a specific interface using an applet , It will trigger version number judgment

By refining the granularity of version control , If a new version is downloaded when the user accesses , However, the page or interface that the user is currently visiting does not require forced update , There is no need to pop-up a box to remind the user to perform forced update , More in-depth guarantee of user experience .

Version control configuration

Client version comparison

On the applet side , adopt Object.defineProperty() Method pair wx.request Method for proxy and global Page.onLoad Method to check the updated code .

Such as through wx.getUpdateManager() Check that a new version has been downloaded , And the current request Requested url Hit the above configuration apis Interface path in or page.onLoad Medium this.route hit pages The path configured in , You can pop up a window to remind the user to force the update .

function getVersionArr(versionStr) {
  const str = versionStr;
  return str.match(/[0-9]+/ig);
}

//  Version comparison method 
export function shouldUpgrade(currentVersion, targetVersion = '0.0.0') {
  const currentVersionArr = getVersionArr(currentVersion);
  const targetVersionArr = getVersionArr(targetVersion);
  const len = Math.max(currentVersionArr.length, targetVersionArr.length);
  while (currentVersionArr.length < len) {
    currentVersionArr.push('0');
  }
  while (targetVersionArr.length < len) {
    targetVersionArr.push('0');
  }
  for (let i = 0; i < len; i++) {
    const current = parseInt(currentVersionArr[i], 10);
    const target = parseInt(targetVersionArr[i], 10);
    if (current !== target) {
      return current < target;
    }
  }
  return false;
}

Automate forced version updates

Problem analysis

As mentioned above, the forced version update is implemented by manually changing the configuration distribution , However, there is an implicit feature in the version management of wechat side applet , Small program code package cdn There are time and number limits for caching code package versions , The current limit is 30 The applet version released within days cannot exceed 30 individual .

for example 30 It was released in a few days v1 ~ v31 this 31 A version , Before a user accesses v1 Version of the applet , Then I haven't visited again for a long time , So when you publish v31 Version when the user comes to visit , By default, the applet in the cold start phase is cached locally by the user v1 Version of the code package , When the user operation jumps to v1 Version of other subcontracting pages , Because the wechat server v1 Version of the code package cache has expired , Will lead to “ The network can't connect ” Error of .

Subcontracting failed to load error

In this case, we need an automatic access applet before 30 Functions of version numbers , And update the version number to the distributed configuration , As applet app In the start-up phase, a judgment basis for forced update .

But as mentioned earlier, our version number is based on semver Semantic version number , The format is as follows X.Y.Z The pattern of , It can be used to judge the version size , However, it is necessary to calculate whether there is a difference between the two version numbers 30 A version , This cannot be calculated .

adopt git Of tag Number extract version number

No direct access semver Before the version number of is calculated 30 The value of the version number of versions , But thanks to the fact that every time we publish it, we make tag publishable , So you can go through git Submitted in tag Count , Look back at each release 20 A version （ Here we use 20 The first is to prevent rolling back and then publishing after publishing , The same version number has been released many times ） Version number of .

git ls-remote --tags --refs --sort="v:refname" | tail -n20 | sed 's/.*\///'

Every time a version is released , Change the previous paragraph 20 individual tag The corresponding version number is updated to the background configuration , This achieves the goal of automatically updating the minimum version number , It effectively avoids user access errors caused by too frequent version release .