The WeChat applet has been online for more than half a year, and most of the technical principles are also introduced in articles. This article attempts to discuss the source of the WeChat applet technical solution from the perspective of demand, as well as the recent public beta of the Alipay applet technical solution considerations.
WeChat applet
The requirement of WeChat applet is to allow third-party developers to access and use the interface provided by WeChat to develop applications embedded in WeChat. For this requirement, the simplest solution is to let external developers develop pure H5 applications, open them in WeChat's H5 container, and the container provides the WeChat native interface. Before there were mini-programs, there were already many such business accesses, such as shopping on JD.com, various friends in the wallet Dianping/Didi Chuxing, etc., all of which can be considered as a "mini-program" embedded in WeChat. To be able to call the WeChat native interface, should we follow this mode, open the corresponding interface to third parties, and then provide an entry?
In fact, this simple solution cannot meet the needs. There are two other important requirements for the WeChat applet on the product:
- Control. As a platform, it must have the ability to manage and control the applications accessed, and it must be able to control the content and types of applications as precisely as possible. After all, if there is an illegal application platform, it must be held responsible. The H5 method is too free, and developers can change the entire application at any time. content, it is difficult for the platform to detect these changes and cannot control. In addition, the development quality of H5 is uneven, and the platform cannot be controlled, which is unacceptable for WeChat, which has always been obsessed with cleanliness.
- experience. As a "small program", the experience needs to be close to the original, and the experience of ordinary H5 pages such as JD.com shopping is not very good, including the problem of startup speed/page switching fluency, which is incomparable with the native experience.
The technical solutions of all Mini Programs serve these two needs.
Control
In order to meet the needs of management and control, WeChat has technically done two things: the applet framework and the separation of the JS runtime environment.
Framework/DSL
H5 is too free. The first thing to do is to limit its freedom. How to limit it? Naturally, it is to be a framework, so that developers can only develop according to the rules of the framework. So what framework should be used?
In the era of PC SNS, Facebook had a similar scenario as an open platform. In order to allow third-party developers to develop on the Facebook platform and at the same time to restrict the developer's authority, Facebook required developers to use a custom set of DSL (FBML). ) to develop, and how this DSL can be written, what it can eventually be converted into, and how to execute it, the platform has the final say, and it is also very convenient for code scanning and review.
The applet can just learn from this design idea. The interface is not developed using HTML, but a set of custom DSL, so that it can be easily controlled with a series of measures such as auditing/code scanning/domain name restriction. This is the applet. Set of sources for frames. This framework uses wxml to describe the interface, wxss to describe the style, js to process the logic and data, and then through a series of tools to convert these into HTML/CSS/JS to display on the webview, and handle interface interaction and data update.
In this way, using a set of frameworks to limit the development method and re-creating a layer of DSL, in addition to management and control, has another advantage, that is, it is easy to carry out targeted optimization. It is made to be rendered by webview, and the rendering layer can also be implemented by itself with a solution similar to RN.
JS environment
After the development method is limited by the framework, there is still a problem in management and control, that is, how to restrict the application-side JS-like language to call the dom API? The applet runs on the webview, and the DOM must be manipulated through JS during rendering. If the applet framework and the application JS code have permission to operate the DOM, the application may bypass the inspection after going online in various ways, inject JS to call the dom interface to Modify the page structure and content to become an application that is different from the review. How can I limit the permissions of the application's JS to call the dom? WeChat has come up with a more innovative solution, that is: the JS runtime environment is separated from the browser and runs on a separate JS engine.
Without the browser, JS naturally does not have the calling authority of dom, and any API related to the webview interface cannot be obtained. The core JS of the applet framework runs on the webview and can freely manipulate the dom. Through the mechanism defined by the applet framework, the application side defines a fixed rendering style through wxml/wxss, the JS side only cares about data binding, and the data can be transferred from JS through the native bridge. The engine is passed to the webview, and the JS side cannot do any rendering-related operations, and can have complete control over the rendered content.
In addition to meeting the management and control requirements, the independent JS runtime environment also brings some additional advantages and disadvantages. The advantages are:
- Multiple pages can share a JS runtime environment, data can be easily shared, and the same context is shared throughout the applet life cycle, which is closer to the APP development experience.
- JS and page rendering are separated and executed in parallel, so that the page rendering will not be stuck when JS is executed, and the rendering performance will be improved.
The downside is:
- In addition to the overhead of data serialization and transmission, the data needs to be transferred from JS to the webview to be rendered by the view layer, and it needs to be serialized into a string format for transmission.
- The JS engine of WKWebview on iOS has more JIT optimization than JavaScriptCore, and the execution speed is many times faster. The JS of applet running on JavaScriptCore cannot enjoy this optimization.
Since the management and control requirements are too rigid, the disadvantages of this solution are acceptable.
experience
The two main technical points of the applet - the separation of the framework and the JS operation are derived from the management and control requirements, and the experience requirements are composed of various detailed performance optimizations, which have been analyzed in many articles. Here is a brief description, including :
- Offline package: The whole applet is packaged and distributed, and there is no need to open every page to request, reducing the time for the second opening and page switching.
- Preloading: Preloading one more wkwebview in the background saves the time of initializing wkwebview when the user opens the applet. In addition, for page switching in a small program, thanks to the design of the framework, it is possible to pre-render the template, and then fill in the data when switching to speed up the rendering speed.
- Cache: It will not be destroyed immediately after exiting the applet, and will continue to run in the background for 5 minutes, during which time the user switches back to the applet quickly.
- Visual: The first time the applet is loaded, it transitions through loading and animation, rejecting the white screen, giving people a fast feeling, and at the same time improving the identity of the applet.
The rest is to build around the small program platform, such as components, native interfaces, IDE, background management, version management, permission control and other basic support.