This is the third article in the series of “Cube Technology Interpretation”. Welcome to review the previous online “Alipay new generation dynamic Technology Architecture and Selection Overview” and “Cube Card Technology Stack Interpretation”.

Rubik’s Cube has been widely used in alipay App. Meanwhile, it supports external commercial output on mPaaS side. Developers are welcome to log in mPaaS console to experience and use it.

Cube mini program is another form of Cube technology besides Cube card. It will mainly be applied to smart TV, POS machine and other IoT fields. Currently, it is still in development and polishing.

Applets have become the de facto standard in the industry as a technology stack for dynamic or cross-end development. Cube, as a lightweight small program technology stack, has the characteristics of small volume, fast startup, low memory consumption, and is also suitable for “ready-to-go” small program scenarios.

The Cube applet technology stack and technology evolution practices will be highlighted below (unless otherwise noted, all data and charts are for applet).

Render applet

modules

From a small program perspective, the Cube rendering engine is mainly composed of the following modules:

  • Components: Mainly Components in the applets specification;

  • Layout: Supports Inline, Block, Flex, inline-block, inline-flex and other Layout methods, including text segmentation, line breaking and other calculation;

  • Style: supports Style parsing, Style matching, Style inheritance, pseudo-class and pseudo-element selectors, etc.

  • Rendering: manage 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; Android supports V8, QuickJS;

  • Compositor: Synthesizer for animation and layers (in development).

Threading model

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

  • Bridge thread: executes JS; JSAPI of the DOM class bridged with AppX; Handle JS related events;

  • Layout thread: Layout calculation; Style calculation and matching; Maintain Layout Tree;

  • Render thread: Maintain Render Tree; Binding data; Layered;

  • Paint thread: generates draw commands;

  • UI threads: platform event distribution; The UI layout.

Summary:

  • Parallel Layout, asynchronous rendering: By parallel I mean JS execution, Layout, and Render all in parallel. Layout, Render, Paint, etc., are not in the same thread, so it is asynchronous;

  • Multiple threads work together, sort of like a CPU level 5 pipeline.

** One of the features of the Web rendering engine is that node-related DOM operations must be on the same thread as JS. This results in parsing HTML, layout, style calculations, DOM, AND JS (including garbage collection) all in one thread. The consequence is that you can’t see the UI until you’ve parsed the document, which is one reason why Web rendering applets tend to have long white screens.

Cube applet technology stack, decouples “DOM operations” from JS execution. So JS GC does not affect UI rendering. This implementation is very helpful for speeding up the startup of small programs. Because layout calculation and JS execution are also decoupled, UI interactions are generally not blocked by JS execution.

Features of Cube applets technology stack

  • Small size, fast startup: the main SO is only 2.8 MB (if you include Ariver, AppX, InsideSDK, the overall applets stack minimum is 5.7MB). The bonus of OS (including UI initialization and caching);

  • High performance: Close to native experience;

  • Small memory footprint: after the applets stack is initialized (including Inside SDK, Cube, AppX), it only needs about 7.5MB;

  • Supports both Android and iOS terminals.

Compare with a Web engine

The following is a comparison with a Web engine only for the applets scenario:

Technology evolution

  • Three aspects need to be done to adapt the small program business to the Cube rendering applet at a low cost:

  • Embrace Web technology and complement the common capabilities of front-end development: CSS, small program components, etc.

  • Improve related tools, including development, debugging, Profile, publishing, packaging, etc.

  • In view of Cube’s architectural characteristics, in-depth optimization, and open the difference with Web rendering. Provide a better user experience.

New Flow Layout

The original Cube applet uses only Flex Layout Yoga for layout calculations. Flow Layout supports Block, Flex, inline-block and other layouts. This solves the problem of developers having to use only Flex layouts. Both layout engines Cube are currently supported internally. Flow Layout is mainly used in small programs, Yoga in cards. The differences between the two abilities are as follows:

Support for CSS style sheets

Older versions of Cube only supported inline styles and simple CSS selectors; However, the applet does not constrain CSS, so the Cube extension supports CSS style sheets, style inheritance, multiple selectors, and so on. Therefore, Web rendering is switched to Cube rendering, and the adaptation cost is greatly reduced. Even some applets can be developed in the applets IDE based on Web rendering and then packaged as Cube renderings to preview on the real machine. Front-end students do not need to modify and adapt too much.

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

Note:

  • [1] Old Cube refers to wallet version before 10.2.0;

  • The new styling capabilities are basically benchmarking the styling capabilities of the Web engine;

  • New style capabilities support 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 {}
Copy the code

Support automatic word breaking, Inline Text

Initially Cube used the text computing 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 problems: Especially under Android, the interface of Android platform layer is used to realize text layout calculation, resulting in a high proportion of layout time in the overall rendering time in the case of more text;

  2. Rich text features: Rich text and many text features are cumbersome to support;

  3. There are details differences or compatibility problems in the implementation of text effects on different platforms.

To solve the above problems, the Flow Layout based on enhanced support for Inline Text Layout calculation Text. Using Inline Text, you can easily implement rich Text, Text mixing, word segmentation, line wrapping, etc.

1. Rich text

2. Wrap and participle

Inline Text looks like this before and after:

Note:

  • Suppose the original Cube adopts the platform layer interface to implement the Text feature called: platform layer Text;

  • √ indicates incomplete or not fully supported implementation details.

  • Rich Text components can be implemented based on Inline Text.

  • It’s worth noting that this implementation is pretty neat, increasing the Cube package size by only 170KB. The details will be discussed in detail in the following article.

Comparison of computing time for text layout (scenario with many text nodes) :

Use QuickJS instead of V8

Although V8 is the most efficient JS engine, it has some shortcomings such as large memory footprint and slow initialization. These deficiencies are magnified on IoT or low-end devices. So Cube uses QuickJS instead of V8 on these devices. On the one hand, the memory footprint is reduced, on the other hand, the initialization performance is improved.

There are currently multiple JS engines in Cube, as follows:

  • Use V8 and JSI on Android mobile

  • JSC is used on iOS

  • Use QuickJS on low-end devices such as IoT

In addition, we made some optimizations based on open source QuickJS. The results of the optimization are roughly as follows (detailed in a future article) :

Support for animation and multimedia components

In addition to the basic components and capabilities mentioned above, animation and multimedia are also indispensable to some applets. 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 scene.

On low-end devices, how to improve animation frame rate and reduce memory footprint has also been deeply optimized. Here’s how the Video and Canvas components look in the applet:

Small program artifacts that support multiple modes

Currently, Cube supports applets of many modes: Native, Cube, and Shared.

  • Native mode: the counterpart of the old Cube render applet mode does not support CSS stylesheets, only supports inline styles and a limited number of CSS selectors. The highest performance, low compatibility;

  • Cube mode: Evolved from Native mode, supports CSS stylesheets and a variety of CSS selectors. Good performance, support for common CSS styles and features (including style inheritance, multiple CSS selectors);

  • Shared mode: Developed to reduce Web rendering applets migration or transition to Cube rendering. Support both Web rendering of part of the page and Cube rendering of part of the page in the same widget. And Cube rendered pages support stylesheets. This balances performance and compatibility. Applets do not increase in size by more than 10% compared to Web rendered applets.

Note: If Web artifacts are required, Native and Cube applets are larger than Shared.

Research and development progress

Cube applets work with related teams on TV and POS to polish the applets stack (including rendering engine, JS engine, AppX, Ariver container, etc.).

Problems faced on TV:

  • Low memory: some devices only have 512MB memory, long list scrolling is easy to jam;

  • Need to support focus switching;

  • CPU frequency is low: some only 1GHz.

The short and medium term goal is to replace WeeX single pages with applets technology stack. The current progress is as follows:

  • Small program startup performance is better than WeeX single page (more obvious advantage on low-end devices);

  • Memory usage after initialization, the memory usage of a small program is less than 10MB, and the total memory usage of a typical small program is about 32MB.

Specific details will be summarized in detail in subsequent articles.

Problems in POS:

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

  • Low memory: some devices only have 512MB memory, which is easy to freeze and OOM.

  • Few CPU cores: some cpus only have dual cores (hardware performance is about 1/5 of that of mainstream phones);

  • Long list of scroll 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:

  • Small program first screen startup performance increased by 30%+;

  • The pages of interaction scenarios that the App focuses on, such as shopping cart, product details page, etc., are close to Flutter App.

  • When the scrolling frame rate of the homepage reaches 50, users can hardly perceive the difference with the Flutter (the Flutter frame rate is 60).

  • – Applet memory usage decreased by 30% (no freezes and OOM in local tests)

This scenario is primarily a long list with many text nodes. A lot of optimization methods are adopted, which will be summarized and introduced in detail in subsequent articles.

conclusion

The Cube rendering engine has made great progress in layout calculations, styling capabilities, component support, and development tools for applets. At the same time, in low-end devices (such as IoT devices) or performance-sensitive scenarios, the performance optimization of Cube applets and the reduction of memory consumption also achieved good results.

With a wide variety of IoT devices in the future, technology evolution needs to be accelerated to support more scenarios. Welcome to join the discussion.

This article is transferred from the public account “Alibaba Mobile Technology”, by Zeng Weihong (Hengshi)