Cube technology interpretation | Alipay's next-generation dynamic technology architecture and selection overview

Author: Into String

" As the title says, the author will continue to update the "Cube Technology Interpretation" series of articles. This article is the first article in the Cube series, and the subsequent articles will focus more on technical explanations, including but not limited to: Cube card technology stack, Cube An article on the mini program technology stack, an article on quality KITE&tool ACT, an article on performance optimization, etc. Thank you for your attention to [Alibaba Mobile Technology]."

background

The dynamic technology of Alipay's client has gone through three stages. The first stage is the hybrid mode of native+web, with webview as the cornerstone. The second stage is the entity component mode, which maps the components described by html and css style information to the entity components, and passes the events of the entity components to the js layer for processing. The third stage is the hybrid mode of physical components + partial rasterization, and Cube is the product of the third stage.

Cube originated from the dynamic appeal of the native page, and the product form is expressed in the Cube card. With the emergence of the concept of applets, Cube has been integrated into the Alipay applet technology stack, and the product form is a lightweight Alipay applet solution (as opposed to web applets that use browsing as the core). This article is a review and the first article in the Cube series.

Technology selection & evolution

The exact birth time of Cube is difficult to determine, roughly between 16 and 17, which is one year later than RN (ReactNative). The main reason for the birth of Cube is the dynamic appeal of native pages. The high frequency of wallet revisions puts a lot of pressure on research and development, so I thought of making the high-frequency revision pages dynamic. The emergence of RN and Flutter gave us a good perspective on how the industry's outstanding technology companies view the topic of dynamics and their answers. In the initial stage, we reached the following consensus:

1. independently developed and controlled independently. We did not choose RN-based open source code to implement our dynamic solution, nor did Flutter switch to Flutter after publishing the source code. This is done in consideration of two points. First, the evolution of the technology stack should be in your own hands, and you don’t want to be led by your nose; second, the cost of productization of open source projects is not low, and the subsequent maintenance costs are also Not low;

2. service business, technical restraint . First of all, we don't have enough capacity and resources to support a common technology product. Serving the wallet business is the first thing. Simply put, it is to follow the business. Secondly, we refuse to just ask for fancy technical demos. We must do a good job in core competence and product maturity, and consider getting business value first.

Based on the above two consensuses, our technology selection is as follows:

1. Choose Javascript as the logic language;
2. Select a certain subset of CSS as the interface description language;
3. Self-drawing (text/img/div/scroller) + native components (input, animation, map, audio, video...) hybrid rendering mode.

Ali has a lot of accumulation in the front-end. Cube chooses to embrace the front-end, and it is natural to adopt javascript and css. I did not choose v8. There are two judgments: v8 is too heavy, and the memory speed and initialization speed are not ideal; the application scenario of Cube is likely to not require the jit capability provided by v8. We additionally introduced a third-party (161444b1537504 https://github.com/bytecodealliance/wasm-micro-runtime ) as a webassemby engine, and supports mixed development of javacript and assemblyscript on the compilation and construction tools. After Flutter is open sourced, it is sought after by many people. In many articles and ppts, I have seen the expression "The advantages of Flutter's rendering pipeline completely independent of the platform layer", which I think is much more advanced than the way RN maps entity components. We don't think that the performance of Flutter's rendering pipeline is better than that of the operating system. After all, the device and the operating system can be vertically integrated to take advantage of some device features. In addition, whether to build a rendering pipeline by itself should depend on business demands, and should not blindly pursue technology.

Cube’s self-built rendering pipeline is limited to self-drawing tags, including text/img/div/scroller as mentioned above, using the canvas api of the platform layer to draw directly on the system’s view; if the tags of a certain subtree are all self-drawing Label, this subtree will be "flattened" and drawn on a view. Labels other than self-drawing labels are all used to map native components, and a unified entity component mapping protocol is encapsulated and provided to developers. At present, Cube’s business scenarios are mainly concentrated on the mobile terminal, and it is also a simple attempt to migrate to the previous linux/rtos platform. If the follow-up business gradually expands to linux/rtos, we will consider further improving self-rendering. One is to converge the canvas api of the platform layer to skia, and the other is the built-in layer compositor.

Current state

In the process of undertaking business, Cube roughly precipitated two business forms, namely Cube card and Cube applet.

The function of the Cube card is to give the native page dynamic capabilities of regionalization and improve business iteration and operational efficiency. The cards connected to the wallet are also divided into two categories. One is simple cards without js capabilities, which support expressions and vif&vshow to control the operation of the DOM tree during construction, pursuing a speed similar to native; the other is with js capabilities Complex cards are used to support some complex businesses. Cube cards have been used on a large scale in wallets, with a pv of more than 10 billion. Refer to screenshots for access scenarios, including but not limited to tab pages such as homepage, financial management, and mine, as well as secondary pages such as card package, travel, and payment result pages.

The positioning of the Cube card is also to give priority to the one- and two-party business in the wallet. If we want to provide three-party developers with the ability to dynamically change the area, we recommend the small program widget. In addition, we are beginning to export Cube card capabilities to small and medium-sized financial institutions and Internet companies.

Cube is used as a rendering engine to introduce the applet technology stack. The applet infrastructure includes: containers, front-end frameworks, rendering engines, and scripting engines. The container can be understood as the aggregation layer code between Appx/rendering engine/script engine, providing package management/JSAPI/security control/wallet core services and other functions. The default rendering engine of the applet on the mobile terminal is UC, and the application of the Cube applet is very limited. Compared with UC, Cube has some advantages in package size/startup speed/list sliding fluency/memory consumption, but the disadvantages are also very obvious-Cube supports insufficient CSS capabilities, and Cube's development tools are not perfect. Based on this, Cube has invested a lot of manpower to expand css capabilities since 19 years. Cube is a more complete rendering engine that supports CSS in addition to the browser core. It supports layout methods such as flex/inline/block, pseudo-classes and pseudo-elements, z-index, and relative and absolute positioning level management. We also put a lot of effort into trying to build tools similar to devtools.

These efforts have improved development efficiency to a certain extent, but still cannot meet the demands of front-end students. We gradually realized that in scenarios where browser performance is not the main bottleneck, front-end developers are unlikely to accept a subset of browsers. As a result, the Cube applet began to turn to the IoT scene, facing the browser can not run, or experience extremely poor scenes. As a kind of application development stack, the Cube applet is attractive to customers who are trying to establish a three-party developer ecosystem. At present, our main energy is on the big screen of the TV. Interested students can experience the Cube applet on the Box, or download Kumiao Movies and TVs on other boxes and smart TVs (161444b15375f0 https://acz.youku. com/wow/tvact/act/cibn?spm=a2hpd.20022520.sort.1!2~3~P~A ).

There is actually a middle ground between the card and the applet, that is, a single page. This page can be full screen or half screen floating in the air. Cube tried the h5 single page in the early days, oriented to high-frequency marketing scenarios. Its technology stack is almost the same as the mini program. The difference is that the h5 single page does not have the concept of a container. What is downloaded from the server to the end is not a mini program package but an h5 page embedded with Cube build products. The h5 single page has accessed the red envelope code business and the secondary page of Ant Forest, because the maintenance cost has been offline one after another. The unsuccessful h5 single page does not mean that the single page requirement does not exist. The recently explored small program widgets actually belong to the category of single pages-we hope that widgets can make the service front-end, carry a certain amount of interaction logic, but also limit its capabilities, facilitate management and control, and are suitable for third-party developers.

Technology Architecture

There are two large modules inside Cube, one is CubeKit, which is responsible for docking the js engine and encapsulating platform differences, as well as development and debugging tools. The other is CubeCore, which is the rendering core logic implemented in C++ code.

For Cube applets, the tinyApp-dsl subset is supported, jscore/v8 is used as the execution engine of js code on the mobile terminal, and quickjs is used on IoT devices; for Cube cards, card-dsl based on simplified vue is supported. Simple cards directly parse the AST to render the page, and complex cards allow users to write some simple logic in js, and use quckjs to drive the update of the dom tree.

On the mobile side, Cube and Web applet share the same container code. For IoT devices, we continue to invest manpower into the vertical integration of Appx and containers. Judging from the current data, the Cube applet on the IoT has a lot of basic performance advantages over the mobile Cube applet. The basic performance data of the Cube applet on the TV is: the package size is 5.5mb, the memory consumption is 32mb (Taobao special board applet is an example), and the cold start takes 3 to 4 seconds. With the deepening of vertical integration, the basic performance of Cube applets will be further improved in the future.

The topic of quality system, I put it in the technical architecture, because it is a part of the technical architecture. For business development, testers can traverse user scenarios and fix bugs if there are bugs. The business scenarios carried by the basic software are only a small part of the infinite sample. There is no problem with the return of the business scenarios, and there is no guarantee that the engine will be free. The worst case is that the problems continue to accumulate until a sudden outbreak occurs one day. At this time, I want to solve the problem again, and it has been hard to come back. Therefore, the R&D of basic software urgently needs some means of exposing potential problems in advance. This means cannot be built by the R&D team with the help of a certain test resource.

The browser’s WPT test case collection provides a good reference. Cube has also built such a basic capability sample collection and the supporting sample automated execution framework KITE, which is invested in version iteration & code submission. Up to now, we can basically achieve single-day granular automatic inspection, which supports us to upgrade and refactor the engine in the case of a large number of business scenarios. The following figure is a screenshot of the engine basic capability inspection tool.

I will also talk about the topic of development tool chain here. Cube's direct customers are not users, but business-side developers. At the beginning of the project, tools should be considered, such as debugger design, preview container, log design, low-code build platform, and so on. In the process of expanding the business, the tool chain is to some extent more important than Cube itself, after all, it is the customer's first impression. When we encountered early technical research, customers refused to use the tool because of imperfect tools. After business access, in addition to capabilities, the business side will also provide various requirements for tools (new tool requirements will also be found when assisting in troubleshooting), throughout the entire life cycle of the product, and it is also an important work to maintain customer stickiness. With the large-scale application of Cube to the business, the energy we invest in tools has gradually surpassed the function & technology iteration itself.

Review & future planning

Looking back on the past 5 years, Cube stumbled all the way and almost died in the middle. It is not easy to get to this day. From a personal perspective, Cube can survive by relying on "up and down persistence." On the one hand, the above decision makers insist on investing (there is almost no decent business value in 19 years and before); on the other hand, the frontline students insist on doing one thing, without technical pursuit, it is impossible to survive the bumps on the way. We look forward to applying Cube to the IoT operating system in the future. After all, the application development technology stack is one of the core technologies of the operating system.

Cube's future plans will continue to adhere to "close to business" and "technical restraint", to do a good job of products, provide developers with good services, and polish technologies. The key development directions are as follows:

1. In view of the fact that Cube cards can run on 32MB RAM/400Mhz RTOS devices, further explore the landing on IoT devices;
2. Promote the application and landing of the Cube applet on the big screen of the TV, and explore the business model.

As mentioned earlier, I will focus more on detailed technical explanations in subsequent update articles, and conduct in-depth interpretations and chats on card technology stack, applet technology stack, quality KITE&tool ACT, performance optimization, etc. If you are interested in this series of articles or Cube, you can continue to follow us.

See you in the next article.

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