Wechat mini program
The demand for WeChat applets is that third-party developers can access it, and they can 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 and open them in the H5 container of WeChat, which provides the native interface of WeChat. Before the appearance of applets, there were many such services, such as shopping in JD.COM, various friends' comments in wallet/Didi Chuxing, etc. , can be considered as a "small program", embedded in WeChat, can call WeChat native interface. Should we open the corresponding interface to the third party according to this model, and then provide an entrance?
In fact, this simple solution can't meet the demand. In terms of products, WeChat applet has two other very important requirements:
Control. As a platform, it must be able to control the accessed applications and control the contents and types of applications as accurately as possible. After all, if there is an illegal application platform, it is responsible. The H5 method is so free that developers can change the content of the whole application at any time. It is difficult for the platform to detect these changes and can't control them. In addition, the development quality of H5 is uneven, and the platform can't be controlled, which is unacceptable for WeChat, which has always been clean.
Experience. As a "small program", we need to make the experience close to the native, but these ordinary H5 pages, such as shopping in JD.COM, are not very good, including the startup speed/page switching fluency, which are incomparable to the native experience.
All the technical solutions of the applet serve these two needs.
control
In order to meet the needs of management and control, technically WeChat has done two things: a small program framework and a separate JS running environment.
Frame /DSL
H5 is too free. The first thing to do is to limit its freedom. How come? Naturally, it is a framework trap, so that developers can only develop according to the rules of the framework. What kind of framework should I use?
In the era of PCSNS, Facebook had a similar scene when it was an open platform. In order to allow third-party developers to develop on Facebook platform and restrict the rights of developers, Facebook requires developers to use a set of customized DSL(FBML) for development. How to write this DSL, what it can be converted into and how to realize it are all decided by the platform, which is also convenient for static code analysis and review.
Small programs can learn from this design idea. The interface is not developed in HTML, but a set of DSL is customized, so that it can be easily controlled by a series of measures such as auditing/static code analysis/domain name restriction, which is the source of the applet framework. This framework uses wxml to describe the interface, wxss to describe the style, js to handle the logic and data, and then converts these into HTML/CSS/JS to display on webview through a series of tools, and handles the interface interaction and data update.
In this way, using a framework to limit the development mode and re-create a layer of DSL has another advantage besides control, that is, it is easy to carry out targeted optimization. What DSL is finally converted into and how to render it is determined by the framework, and the upper layer does not know it. You can use webview to render, and if possible, you can use a scheme similar to RN to realize the rendering layer.
JS environment
After defining the development mode through the framework, there is still a problem in management and control, that is, how to restrict the application-side class JS language from calling domAPI? When the applet runs on webview, dom needs to be manipulated through JS during rendering. If both the applet framework and the application JS code have the authority to operate the dom, the application may bypass the post-launch inspection in various ways, and inject JS to call the dom interface to modify the page structure and content, making it a different application from auditing. How to restrict the JS permission for an application to call dom? Wechat thought of a more innovative solution, that is, the JS runtime environment is separated from the browser and runs on a separate JS engine.
Without a browser, JS naturally has no right to call dom, and any API related to webview interface cannot be obtained. JS, the core of the applet framework, runs on webview and can operate dom freely. Through the mechanism defined by applet framework, the application side defines a fixed rendering style through wxml/wxss, while the JS side only cares about data binding, and data can be transmitted from JS engine to webview through native bridge. JS can't do any rendering-related operations, and can have complete control over the rendered content.
Independent JS running environment not only meets the requirements of management and control, but also brings some advantages and disadvantages. Its advantages are as follows:
Multiple pages can share a JS running environment, data can be easily shared, and the whole applet life cycle shares the same context, which is closer to the development experience of APP.
JS and page rendering are executed separately and in parallel, so that the page rendering will not be blocked when JS is executed, and the rendering performance will be improved.
Disadvantages are:
With the overhead of data serialization and transmission, data needs to be transmitted from JS to webview for view layer rendering, and it needs to be serialized into string format before transmission.
The JS engine of WKWebview on iOS has more JIT optimization than JavaScriptCore, and its execution speed is many times faster. JS of small programs can't enjoy this optimization when running on JavaScriptCore.
Because the control demand is too urgent, the shortcomings of this scheme are acceptable.
experience
The two main technical points of applet-the separation of framework and JS operation-come from the management and control requirements, and the experience requirements are composed of various detailed performance optimizations, which are also analyzed in many articles. Here, in a nutshell, they include:
Off-line packaging: the whole applet is packaged and distributed without opening every page to request, which reduces the second opening time and page switching time.
Pre-loading: Preload one more wkwebview in the background, which saves the time for initializing wkwebview when users open applets. In addition, for the page switching in the applet, thanks to the design of the framework, the template can be pre-rendered, and the data can be filled when switching, which speeds up the rendering.
Cache: it will not be destroyed immediately after exiting the applet, but will continue to run in the background for 5 minutes, during which the user will quickly switch back to the applet.
Vision: The first loading of applets will reject the blank screen through loading and animation transition, giving people a quick feeling and improving the recognition of applets.
The rest are built around the platform of applets, such as components, native interfaces, IDE, background management, version management, access control and other basic support.
Alipay applet
tactics
When the WeChat applet is online, the main scene is offline. I hope that businesses can develop small programs, do instant applications such as ordering food and buying tickets, and enhance the offline business experience. As the main competitor of the offline battlefield, Alipay naturally has to follow up.
What should Alipay do to make a small program? You can define another technical system according to your own situation and let the third party access it. However, in this case, if a third party wants to access WeChat and Alipay at the same time, it needs to develop two sets of programs, which is very expensive. Wechat has the first-Mover advantage and platform advantage, and it is likely to become only developing WeChat applets and giving up accessing Alipay applets, so the best way is to reduce the access cost here and let the code of WeChat applets be reused on Alipay applets. Therefore, the external framework /API/ component of Alipay applet must be close to or consistent with WeChat applet, and there is no technical choice, so we can see that many documents in the public beta version of Alipay applet are consistent with WeChat.
realize
The external interface of Alipay applet framework is the same as that of WeChat, and because the requirements of management/security and experience are the same, some strategies are similar, such as independent JS environment, offline packaging and caching strategy. However, the implementation of the applet framework is completely different from WeChat. As a DSL layer that shields the implementation details, applet framework can be freely customized by any technical means at the bottom of the framework. The underlying architecture here is based on the accumulation of ant front-end team for many years, and finally the web applet is realized on the basis of react.
reactiveness
In addition to the external web applet consistent with WeChat, the internal version of ReactNative applet has been tried. The rendering layer is not suitable for webview, but it is rendered with RN, which is also the benefit brought by the applet DSL layer. The underlying rendering engine can easily replace the implementation scheme, and even there are multiple schemes at the same time.
Many people ask why not use weex? According to my understanding, firstly, the front-end technology stack of ants is based on react, with high switching cost, while the other RN is relatively mature, highly supported by the community, constantly updated and relatively friendly.
RN itself is not cross-platform, and iOS/Android has its own writing method. In the use of RN, many people in the industry have realized the development mode based on RN that spans three terminals or two terminals (such as JDReact), that is, one-time development, which can support RN to do native rendering at both ends of iOS/Android and also support fallback to webview rendering. The small program here can also be regarded as such a scheme. The upper layer develops business through custom DSL, and when it is deployed, it is converted into different codes of three platforms by tools and runs on three platforms.
Internal application
Applets are a set of external solutions, which are mainly used to access third-party applications, because as mentioned above, many technical solutions in the framework are designed to meet the needs of third-party management and security, and many experience optimizations related to applets can actually be realized by pure H5. Using web applet to develop internal business has not brought any benefits, but increased the learning cost. But the RN applet is different. It has some advantages, including:
Compared with webview, RN has obvious performance advantages, high second opening rate and smoother interaction.
Compared with simply using RN development, using applets can shield platform differences and realize cross-platform development at one time.
The applet is supported by supporting infrastructure such as development environment /IDE/ package management, and does not need to be built repeatedly.
For business developers, applets are not a brand-new development method and can be reused in the industry. For framework implementers, RN is also a popular open source solution in the industry, with strong community support. Internally and externally, it avoids creating another technical system that can only be used internally, which greatly reduces the technical cost.
For these reasons, some businesses in Ant Wealth that should be implemented by H5 also try to use applets more to improve the user experience. At present, some services based on RN applet development have been running stably, and we will continue to try to make RN applet a high-performance and stable three-terminal unified dynamic solution in the future.