As the title suggests, I will continue to update the Cube Technical Interpretation series. This is the first article in Cube series. In the following articles, the author will focus more on technical details, including but not limited to: Cube card stack, Cube applet stack, quality KITE& Tool ACT, performance optimization, etc.

background

The dynamic technology of Alipay client goes through three stages. The first stage is the hybrid mode of Native + Web, based on Webview. The second stage is entity component pattern, which maps HTML described components and CSS style information to entity components, and passes the events of entity components to the JS layer for processing. The third stage is the hybrid mode of solid component + partial rasterization, and Cube is the product of the third stage.

Cube originates from the dynamic appeal of native pages, and the product form is reflected in Cube cards. With the emergence of the concept of applets, Cube is integrated into the Alipay applets technology stack, and the product form is a lightweight Alipay applets solution (as opposed to the Web applets that use browsing as the core). This article is an overview and the first in the Cube series.

Technology selection

The exact date of Cube’s birth is hard to pin down, somewhere between 16 and 17, a year after RN. The main reason for the birth of Cube is the dynamic appeal of native pages. Wallet revision frequency is high, to the research and development of the pressure is very big, so I thought of the high-frequency revision of the page dynamic. The emergence of RN and Flutter gives us a good look at how the best technology companies in the industry are looking at the topic of dynamism and their answers. At the beginning, we reached the following consensus:

  1. Independent research and development, independent control. We did not choose rn-based open source to implement our dynamic solution, nor did Flutter publish the source code after switching to Flutter. First, the evolution of the technology stack should be in our own hands and we do not want to be led by the nose. Second, the transition cost of open source projects is not low, nor is the maintenance cost.

  2. Service business, technical restraint. First of all, we do not have enough capacity and resources to support a general technology product, the service of wallet business is the first, in short, it is close to the business. Second, we refuse to just look for fancy technology demo, do the core capabilities, do the product maturity well, consider the business value is the first.

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

  • Select Javascript as the logical language;

  • Select a subset of CSS as the interface description language;

  • Self drawing (text/img/div/scroller) + native components (Input, animation, map, Audio, video…) Blend render mode.

Ali has accumulated a lot of experience in the front end, so it is natural for Cube to embrace the front end and adopt javascript and CSS. The default JS engine is QuickJS. V8 was not chosen for two reasons: it was too heavy and the memory overhead and library loading speed were not ideal; Cube scenarios most likely do not require the JIT capabilities provided by V8. We have introduced additional third-party WAMR as a Webassemby engine and support for hybrid Development of Javacript and AssemblyScript on build tools. Flutter has gained a lot of traction since it was opened as an open source source. Many articles and powerpoint presentations have stated that Flutter has the advantage of being completely independent of the platform-level rendering pipeline, and that Flutter is superior to the way that RN maps solid components. We do not believe that Flutter’s rendering pipeline will perform better than the OS’s rendering pipeline. After all, the device and OS can be vertically integrated to take advantage of some device features. In addition, whether or not to build your own rendering pipeline should depend on business needs, rather than blindly pursuing technology.

Cube’s self-built rendering pipeline is limited to self-drawn tags, including text/img/div/scroller, which are drawn directly on the view of the system using the Canvas API of the platform layer. If a subtree’s labels are self-drawn, the subtree will be “flattened” and drawn on a view. Tags other than self-drawn tags are mapped to native components and encapsulate a unified entity component mapping protocol for developers. At present, Cube’s business scenarios are mainly focused on the mobile end, and the previous Linux/RTOS platform ports are also briefly tried. If the business gradually expands to Linux/RTOS, we will consider further improvements in self-drawing, one is convergence of platform layer Canvas API to SKIA and the other is built-in Layer Compositor.

The current state

In the process of undertaking business, Cube has roughly precipitated two business forms, namely Cube cards and Cube applets.

The role of Cube card is to give native page dynamic capability of regionalization and improve business iteration and operation efficiency. Wallet access cards are also divided into two categories. One is simple cards without JS ability, which support expression and VIf&vshow to control the operation of DOM tree during construction and pursue the approximate native speed. The other is complex cards with JS capabilities, used to support some complex business. Cube cards have been widely applied in wallets, with PV exceeding 10 billion. Please refer to the screenshots of the access scenes, including but not limited to the homepage, Financial management, My TAB page, as well as the secondary pages such as card package, travel and payment results page.

Cube cards are also positioned to serve the first and second businesses in the wallet. If you want to provide dynamic capabilities for the third party developers, we recommend the widget. In addition, we are in the process of exporting Cube card capabilities to small and medium sized financial institutions and Internet companies.

Cube is the introduction of the applet stack as a rendering engine. Applets infrastructure includes: containers, front-end frameworks, rendering engines, and scripting engines. Containers can be understood as aggregation layer code between Appx/ rendering engine/scripting engine, providing functions such as package management /JSAPI/ security control/wallet core services. The default rendering engine for mobile applets is UC, and Cube applets are very limited. Cube has some advantages over UC in terms of package size/startup speed/list sliding smoothness/memory consumption, but the disadvantages are also obvious — Cube’s CSS support is inadequate and Cube’s development tools are incomplete. Based on this, Cube has invested a lot of manpower in expanding CSS capabilities since nineteen nineteen. Cube is a CSS rendering engine that supports flex/inline/block layouts, pseudo-classes and pseudo-elements, z-index and relative and absolute positioning hierarchies. We also put a lot of effort into trying to build devTools-like functionality.

These efforts improved the development efficiency to a certain extent, but still failed to meet the demands of front-end students. We have come to realize that front-end developers are less likely to accept a subset of browsers in scenarios where browser performance is not a major bottleneck. As a result, Cube applets are moving to IoT scenarios, where they won’t run in the browser, or where the experience is terrible. Cube applets as a kind of application development stack are attractive to clients trying to establish a tripartite developer ecosystem. At present our main energy on the TV screen, interested students can experience the Cube on Tmall box small program, you can download on other box and smart TV/cool meow, film and television (acz.youku.com/wow/tvact/a…

Between cards and applets, there’s actually a middle ground: a single page. The page can be a full screen or a half-screen floating in the air. Cube experimented early with h5 single-page, high-frequency marketing scenarios. The technology stack is almost identical to that of applets, except that there is no concept of a container for a single H5 page, and instead of an applets package being downloaded from the server, an H5 page is embedded with a Cube build artifact. H5 single-page access to the red envelope code business and ant forest secondary page, due to maintenance costs have been offline. Just because h5 single pages are not successful does not mean that the need for single pages does not exist. The recently explored widget is really a one-page thing — we want widgets to be front-loaded, to carry some interaction logic, but also to limit their capabilities, to be manageable, and to be suitable for three-party developers.

The technical architecture

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

For Cube applets, tinyApp-DSL subset is supported, jScore/V8 is used as the js code execution engine on mobile and QuickJS is used on IoT devices; For Cube cards, card-DSL based on thin VUE is supported. Simple cards parse the AST directly to render pages, while complex cards allow users to write simple logic in JS and drive dom tree updates through QuckJS.

On mobile, Cube and Web applets share the same container code. On IoT devices, we continue to invest in vertical integration of Appx and container. Based on the current data, Cube applets on IoT have a significant performance advantage over Cube applets on mobile. The basic performance data of Cube mini-program on TV terminal are as follows: package volume is 5.5MB, memory consumption is 32MB (for example, small program on Taobao special offer board), and cold start time is 3 ~ 4s. With the deepening of vertical integration, the basic performance of Cube applets will be further improved in the future.

I put the topic of quality system in the technical architecture because it is part of the technical architecture. Doing business development, testers can traverse user scenarios and fix bugs. The business scenarios hosted by the underlying software are only a small fraction of an infinite sample, and there is no guarantee that the business scenarios will return without problems — at worst, problems will continue to accumulate until they flare up one day. If you want to solve the problem at this point, it’s too late. Therefore, the development of basic software urgently needs some means of exposing potential problems in advance, which cannot be built with the help of a test resource but by the development team itself.

The browser’s WPT test case set is a good reference, and Cube has built such a basic capability sample set and the accompanying sample automation execution framework KITE into version iteration & code submission. Up to now, we can basically achieve one-day automatic inspection, which enables us to upgrade and reconstruct the engine in the case of a large number of business scenarios. The following is a screenshot of the inspection tool for basic engine capabilities.

The topic of development toolchains is also covered here. Cube’s direct customers are not users, but development students on the business side. Consider tools early in the project, such as debugger design, preview containers, log design, low-code build platforms, and so on. The toolchain is in some ways more important than the Cube itself in scaling the business, as it is, after all, the customer’s first impression. In our preliminary technical research, customers refused to use the tool because of its imperfection. After service access, in addition to capabilities, the business side will also provide various requirements for tools (new tool requirements will be found when assisting troubleshooting), which will run through the whole life cycle of the product and is also an important work to maintain customer stickiness. As Cube became widely used in the business, we began to focus more on tools than functionality & technology iterations per se.

Review & Future planning

Looking back over the past five years, Cube has stumbled and almost died, and it’s not easy to get here. From a personal point of view, Cube’s survival depends on “up and down persistence”. On the one hand, the decision makers above insist on investment (19 years and before there was little decent business value); On the other hand, front-line students insist on doing one thing, without technical pursuit, it is impossible to survive all kinds of ups and downs on the way. We expect Cube to be used in iot operating systems in the future, after all, application development stack is one of the core technologies of operating systems.

Cube’s future plans continue to adhere to the principle of “keeping close to business” and “restraint in technology”, so as to do well in products, provide good service for developers and polish technology. Key development directions are as follows:

  1. Since Cube card can run on 32MB memory /400Mhz RTOS device, further explore the landing on Internet of Things devices;

  2. Promote the application and implementation of Cube mini-program on TV large screen and explore the business model.

As mentioned above, I will focus more on detailed technical explanation in the following updated articles. I will give in-depth interpretation and chat on card technology stack, small program technology stack, quality KITE& ACT tool, performance optimization, etc.

Cube stack will soon be available as mPaaS as a new capability to export. If you are interested in this series of articles or Cube technology, please read the article below to learn more about mPaaS.

See you in the next article.

This article is reproduced in the public account “Alibaba Mobile Technology”, click here to learn more about mPaaS.