Background:

Recently, I received a project requirement to change the theme style of H5 page embedded in a set of small programs. Although the development process was bumpy, the requirement development was successfully completed. (Related program link @ hardworking Jerry: juejin.cn/post/691482…)

However, relevant quality engineers in the test found that a part of THE H5 CSS style has not changed, the display is still the original style. A close inspection of the code found no problem. After a period of investigation, it was found that most of the test machine style display normal, only a few Android phones abnormal.

Solution process:

On the test machine with the problem, most OF the H5 page styles were fine, only a few pages failed to update their CSS styles, and all of the H5 pages displayed normal HTML. This can eliminate the compatibility of the phone.

The code is fine, the compatibility is fine, so it’s probably a cache problem.

In general, the cache of wechat applet can be cleared only after the list is deleted and the applet is opened again. However, because we use the H5 page embedded in WebView, the cache does not exist in the applet, so this method cannot take effect. Re-login wechat still has no effect. Finally, uninstall wechat, re-download — login — open the small program, found that the H5 page finally displayed normal. Xi Big pu Ben!

Of course, this approach should only be used as a contingency measure, and the root of the problem should be solved from the code.

Applets kernel browser

We have learned

  • IOS side: small program javascript code is running in JavaScriptCore, is rendered by WKWebView, the environment has iOS8, iOS9, iOS10.

  • Android side: The javascript code of the small program is resolved by X5 JSCore, which is rendered by X5 based on the Mobile Chrome 37 kernel

  • Development tools: The javascript code of the applet runs in NWJS and is rendered by Chrome Webview.

To find out which browser the program is running on, visit this address

www.ip33.com/browser.htm…

Now it can be learned that the test machine with the style problem in the process of testing is using X5 kernel browser, X5 fully supports Html5 and ES6, so there is no need to worry about compatibility problems. The question then is how to clear the cache or avoid it.

HTTP caching mechanism

First of all, we need to roughly understand the HTTP caching mechanism. Web caching can be roughly divided into database caching, server-side caching (proxy server caching, CDN caching), browser caching. Browser caches also contain many things: HTTP caches, indexDB, cookies, localstorage, and so on. We will only discuss HTTP caching here.

The procedure shown in red represents strong caching. After a user initiates an HTTP request, the browser finds that the requested resource is cached locally and checks whether the cache expires. Each browser has a different cache cycle, and you don’t know how long you can wait for the cache to expire. After wandering around wechat open community, it seems that there is no really effective solution to clear webview cache. Only local means can be used to forcibly clear the cache (re-install wechat or re-log in, the latter may not be useful), and the experience is poor.

Avoid caching

The best thing to do now is to avoid caching. The browser cache is based on the URL. If the page allows caching, the browser will not send the request to the server if the same URL is accessed again within a certain period of time (before the cache expires), but will fetch the specified resource directly from the cache. If we access a different URL each time, there will be no caching.

In order for the WebView to jump to a different URL, we simply differentiate the URL by adding some special fields, such as the version number of the applet or a time stamp.

How to get the timestamp

const timeStamp =Date.parse(new Date()); 
Copy the code

If you have a better solution, please feel free to contact me.

My blog is vastcha.cn/