Cube technology interpretation | Cube applet technology details

Author: Zeng Weihong (Hengshi)

This is the third article in the "Cube Technology Interpretation" series. The previously online "Alipay's Next-Generation Dynamic Technology Architecture and Selection Overview" "Cube Card Technology Stack Interpretation" welcome everyone to review.

As a technology stack for dynamic or cross-terminal development, mini programs have become a de facto standard in the industry. As a lightweight small program technology stack, Cube has the characteristics of small size, fast startup, and low memory usage. It is also more suitable for "use and go" small program scenarios. The following will focus on the Cube applet technology stack and technology evolution practices (unless otherwise specified, all data and charts are for applets).

Cube rendering applet

Module composition

From the perspective of applets, the Cube rendering engine is mainly composed of the following modules:

• Components : mainly components in the mini program specification;
• Layout : Supports Inline, Block, Flex, Inline-Block, Inline-Flex and other layout methods, and also includes calculations such as text segmentation and line breaks;
• Style : Support multiple selectors such as style analysis, style matching, style inheritance, pseudo-classes and pseudo-elements;
• Rendering : Manage rendering related Render Tree, image resource request scheduling, etc.;
• Animation: JS and CSS animation implementation;
• JS Bridge : bridge with JS engine;
• JS Engine : currently supports V8, JSC, QuickJS; among them, Android supports V8, QuickJS;
• Compositor : A compositor for animation and layers (under development).

Thread model

There are several threads in the Cube applet technology stack: Bridge, Layout, Render, Paint, UI, etc.

• Bridge thread: execute JS; DOM-like JSAPI bridged with AppX; handle JS related events;
• Layout thread: layout calculation; style calculation and matching; maintenance of Layout Tree;
• Render thread: maintain Render Tree; bind data; layer;
• Paint thread: generate drawing commands;
• UI thread: platform event distribution; UI layout.

Summary :

• Parallel layout, asynchronous drawing: Parallel here refers to JS execution, Layout layout and Render are completely processed in parallel. Since Layout, Render and Paint are not in the same thread, they are drawn asynchronously;
• Multiple threads work together, a bit like a 5-stage CPU pipeline.

worth noting is : a feature of the Web rendering engine is that DOM operations related to Node must be in the same thread as JS. This results in parsing HTML, layout, style calculation, DOM, JS (including garbage collection) all in one thread. The consequence is that the UI effect can only be seen after the document is parsed, which is one reason why the web rendering applet takes a long time to blank the screen.

The Cube applet technology stack decouples "DOM operations" and JS execution. Therefore, the GC of JS will not affect the UI rendering. This implementation is very helpful for speeding up the startup of small programs. Since layout calculation and JS execution are also uncoupled, UI interaction is generally not blocked due to JS execution.

Features of Cube applet technology stack

• Small size and fast startup: the main so is only 2.8 MB (if including Ariver, AppX, InsideSDK, the minimum overall mini program technology stack is 5.7 MB). In addition, you can enjoy the bonus of the OS (including UI initialization and caching);
• High performance: close to the original experience;
• Small memory footprint: After the small program technology stack is initialized (including Inside SDK, Cube, AppX), it only needs about 7.5 MB;
• Support both Android and iOS terminals.

Compared with web engine

The following is only for the comparison between the Mini Program scenario and the Web engine:

Technology evolution

To adapt the Mini Program business to the Cube rendering Mini Program at low cost, three tasks are required:

• Embrace Web technology and complement the common capabilities of front-end development: including CSS, small program components, etc.;
• Improve related tools: including development, debugging, profile, release, packaging, etc.;
• In view of the architectural characteristics of Cube, in-depth optimization, and to open up the difference with Web rendering. Provide a better user experience.

New Flow Layout

Initially, the Cube applet only supports Flex layout Yoga for layout calculations. Later upgraded to Flow Layout which supports Block, Flex, Inline-Block and other layout methods. So as to solve the problem that developers can only use Flex layout. Currently, the two layout engines Cube support internally. Among them, Flow Layout is mainly used in small programs, and Yoga is used in cards. The differences between the two capabilities are as follows:

Support CSS style sheets

The old version of Cube only supports inline styles and simple CSS selectors; however, the applet does not restrict CSS, so Cube expands to support CSS style sheets, style inheritance, multiple selectors, etc. As a result, Web rendering is switched to Cube rendering, and the cost of adaptation is greatly reduced. Even some small programs can be developed based on Web rendering in the small program IDE, and then packaged into Cube rendering products to preview on the real machine. Front-end students do not need to make too many modifications and adaptations.

The differences in selector support between the new and old Cube versions are as follows:

Note:

• [1] The old version of Cube refers to the previous version of wallet 10.2.0;
• The new style ability basically matches the style ability of the Web engine;
• The new style capability supports complex selectors like this one.

div > div.jartto p span.yellow a#t1 {}
.pixel-ratio-2 .web1px::before {}
div:nth-child(2n+1) {}
input[type="button"] {}
#blue,div > div.jartto p span.yellow a#t1 {}

Support automatic word segmentation, line break (Inline Text)

Initially, Cube used the text calculation and drawing capabilities provided by Android and iOS. There are three problems with this technical solution (hereinafter referred to as platform layer Text):

1. Performance issues: Especially under Android, the use of the Android platform layer interface to achieve text layout calculations, resulting in a large amount of text, the layout time takes a higher proportion of the overall rendering time;
2. Rich text features: Rich text and many text features are more troublesome to support;
3. There are differences in details or compatibility issues in implementing text effects on various platforms.

In response to the above problems, on the basis of Flow Layout, enhanced support for Inline Text layout to calculate text. Based on Inline Text, the following rich text, mixed graphics, word segmentation, automatic line wrapping, etc. can be realized relatively easily.

1. Rich text

2. Automatic wrapping and word segmentation

The text style comparison before and after Inline Text implementation is as follows:

Note :

• Assuming that the original Cube uses the platform layer interface to implement the text feature called: platform layer Text ;
• Indicates that the implementation details are imperfect or not fully supported;
• On the basis of Inline Text, a rich text component with rich functions can be realized;
• It is worth mentioning that the implementation is very delicate, and the volume of the Cube package has only increased by 170KB. Specific details will be discussed in detail in follow-up articles.

Comparison of time-consuming calculation of text layout (scenarios with more text nodes):

Use QuickJS instead of V8

Although V8 is the highest performance JS engine, it has disadvantages such as large memory footprint and slow initialization. These deficiencies will be magnified in IoT or low-end devices. Therefore, Cube uses QuickJS instead of V8 on these devices. On the one hand, it reduces memory usage, and on the other hand, it improves initialization performance.

Cube is currently adapted to multiple JS engines, as follows:

• Use V8 and JSI on Android mobile
• Use JSC on iOS
• Use QuickJS on low-end devices such as IoT

In addition, we have done some optimization work on the basis of open source QuickJS. The results of the optimization are roughly as follows (details in subsequent articles):

Support animation and multimedia components

In addition to the above-mentioned basic components and capabilities, animation and multimedia are also indispensable for some small programs. Therefore, we extended support for Video , Canvas , Lottie , Live Player and other components. And applied to TV large-screen small programs, small games and live broadcast scenes.

On low-end devices, how to increase the animation frame rate and reduce the memory usage has also been deeply optimized. The following are the renderings of the Video and Canvas components in the applet:

Small program products supporting multiple modes

Currently Cube supports a variety of small program products: Native , Cube , Shared .

• Native mode: Corresponds to the old Cube rendering applet mode. It does not support CSS style sheets and can only support inline styles and a limited number of CSS selectors. Highest performance, low compatibility;
• Cube mode: evolved from Native mode, supporting CSS style sheets and multiple CSS selectors. Good performance, supports commonly used CSS styles and features (including style inheritance, multiple CSS selectors);
• Shared mode: developed to reduce the migration of small programs for Web rendering or transition to Cube rendering. In the same small program product, both the Web rendering part of the page and the Cube rendering part of the page are supported. And the pages rendered by Cube support style sheets. This balances performance and compatibility. Compared with the small programs rendered by the Web, the small program products will not increase in volume by more than 10%.

Note 161d2c92e5073a: If you need a Native mode and Cube mode are small program products, which are larger than Shared mode .

Current job

The Cube applet works with related teams on TV and POS machines to polish the applet technology stack (including rendering engine, JS engine, AppX, Ariver container), etc.

faced by 161d2c92e50770 on TV:

• Less memory: Some devices only have 512MB of memory, which makes it easy to get stuck when scrolling through long lists;
• Need to support focus switching;
• The CPU frequency is low: some are only 1GHz.

The short- and medium-term goal is to replace WeeX single pages with small program technology stacks. The current progress is as follows:

• Mini program startup performance surpasses WeeX single page (the advantage is more obvious on low-end devices);
• In terms of memory usage, after the mini program is initialized, the memory usage is less than 10MB, and the overall memory usage of a typical mini program is about 32MB.

Specific details are summarized in detail in the follow-up article.

faced by 161d2c92e5082e on POS machines:

Running a small program for ordering food on a POS machine mainly faces the following problems:

• Less memory: Some devices have only 512MB of memory, which is prone to jams and OOM;
• Few CPU cores: some CPUs have only dual cores (hardware performance is about 1/5 of mainstream mobile phones);
• Long list of scrolling cards.

The short- and medium-term goal is to replace the App developed by Flutter with a small program technology stack. The current progress is as follows:

• The first screen launch performance of the improved 161d2c92e508bc by 30%+;
• The pages of the interactive scenes of the Mini Program, such as shopping carts, product details pages, etc., are close to Flutter App;
• The homepage scrolling frame rate reaches 50 , it is difficult for users to perceive the difference with Flutter (Flutter frame rate is 60);
• The small program memory usage has dropped by 30% (there is no stuck and OOM in the local test).

This scenario is mainly a long list with many text nodes. A lot of optimization methods are used, and follow-up articles summarize and introduce them in detail.

Summarize

In order to adapt to small programs, the Cube rendering engine has made great progress with the efforts of small partners in layout calculations, style capabilities, component support, and development tools. At the same time, in low-end devices (such as IoT devices) or performance-sensitive scenarios, the Cube applet has optimized performance and reduced memory usage. Good results have also been achieved. In the future, facing a variety of IoT devices, it is necessary to accelerate technological evolution to support more scenarios. Everyone is welcome to communicate and discuss together.

, 3 mobile technology practices & dry goods for you to think about every week!