In the recent push iterations of iOS and Android systems, the system environment has gradually developed a tendency to front-load some content and services.

At the same time, with the explosive growth of rich media content and the diversification and youth of content, how a mobile application can effectively improve dynamic operation efficiency has become an important topic of industry research and operation.

“Ant Dynamic card” is born under the dual background of the above technical capability and industry demand.

“Ant Dynamic Card” is now officially launched on mPaaS. Developers are welcome to log in ali Cloud account and go to mPaaS console for trial.

The following is a review of the new product launch of “Ant Dynamic Card”.

Click here to watch the full replay

Ant dynamic card, realize App home page agile update

Via Scape – Ant Group mPaaS Product Manager

Ant Dynamic card is based on alipay’s new card technology stack, realizing the quick update of App home page.

Ant Dynamic card Cube is a set of cross-platform and dynamic card solution developed by Ant Group itself. It serves the regional dynamic technology within application pages, is content-oriented operation, and helps product technology improve development efficiency and operation efficiency.

Each dynamic card is embedded in an area of the native page independently, and the content of the area is displayed through the card template. The home page of Alipay, epidemic Service Assistant, Ant Forest or payment page are all achieved by card.

Cards have the following advantages:

① Cross-platform consistency: a set of code to achieve multi-effect alignment.

(2) Dynamic: dynamic update of page structure style and business logic can be carried out in the card.

③ High performance: The card update is released in the form of a card pack, which is very small in size and has extreme performance and memory.

Dynamic card is a technology stack that has been deeply polished by Alipay App business. It includes client and cloud, and has stability and reliability (less than 1/100,000 crash rate). At the same time, it has a complete development debugging tools, such as compilation, preview, debugging, publishing and so on.

The application scenario of Ant dynamic card mainly focuses on content operation, which can realize the mode of dynamic research and development of a new generation of mobile terminals. With the explosive growth of rich media content and the diversification and youth of content, the Internet and traditional industries are increasingly demanding mobile application content operation in order to improve user conversion and retention rates. How to improve the dynamic operation efficiency of content has become an important topic of industry research and operation.

And their demands can be fulfilled through cards.

Why do mobile apps need dynamic cards?

The image above shows ant dynamic cards compared to native pages, Web pages, Flutter and RN. Dynamic cards have great advantages in cross-platform, development efficiency, performance, package size, access transformation cost, release granularity and so on. Especially in the issue granularity, the card can be published in a local page or a small program or sub-application level, and the release efficiency is very high, the release is visible. At the same time, the package size of the card is very small, the access cost of transformation is also very low, and has multi-terminal cross-platform consistency.

After four years of research and development, Cube has a relatively complete research and development system through the development language of class front-end. After alipay wallet and other large-scale applications, the home page, wealth Tab and life Tab have achieved a good landing effect.

The value of dynamic cards to the business lies in their ability to help developers quickly respond to operational needs. The technical goal of dynamic cards is to combine user experience with r&d efficiency.

On the client side, the card rendering effect is shown on the right side of the figure, which consists of two parts, namely card template and card data. The client gets the card template, gets the card data, and finally renders the terminal style.

A card template contains the card layout, card logic, and card style. The logic contains buried information and business logic such as what style the card should display under what circumstances.

The product value of ant dynamic cards can be explained from three dimensions:

① Development-oriented: have the characteristics of efficient development. Through the simplified VUE language, perfect debugging tools, etc., reduce the release, improve the development efficiency.

② Product-oriented/operational: have the ability to update in real time. Every time when the version is issued or the content is updated, the operation content can be updated and pushed through the preset card template. This also means that in most cases, product updates only need to be released on a single card, rather than an entire App, entire applet, or entire interface. In this way, the operation efficiency and product demand implementation efficiency are very high. Multiple business scenarios can be implemented in one implementation, and differentiated and personalized operation demands can also be met.

③ For end users: provide a smooth experience. Cards are comparable to, and even better than, the native experience. Also, thanks to smaller packages, better performance, and less memory footprint, you’ll have a smoother experience for major users.

Ant Dynamic Card’s product architecture is divided into four layers:

① Technology layer: Two modules are derived from Cube kernel, namely Cube card and lightweight applet technology stack to be released in the future.

② Product layer: the products derived from Cube card include ant dynamic card Cube and intelligent layout of ant dynamic card; Based on the small program derived from Cube high performance small program and Cube high performance small program – intelligent construction.

③ Device layer: support mobile terminal and IoT terminal. At the card level, it is more widely applicable to mobile terminals, while high-performance small programs can take into account low-end mobile devices, IoT devices or large-screen all-in-one machines.

(4) Scenario layer: applicable to digital operation scenarios of rich media, including finance, pan-entertainment, Internet, transportation, Internet of Things, etc.

For industries that attach importance to content operation, Mafeng.com dynamic card can provide high-performance and efficient content operation, which is suitable for real-time content operation of thousands of people, public opinion emergency management, operation and maintenance emergency management, or AB test of products, update of minimization function, etc. In scenarios where urgent updates or dynamic updates are required, there is no need to release a version, just update the card content.

The card supports components such as waist sealing, feed streaming, video, floating window, advertising and other natively supported components. Cube offers native and partial dynamic capabilities that support a much wider range of scenarios than Flutter and H5, which cannot support waist sealing and can only support whole page publishing.

Scenario 1: Dynamic card release and intelligent layout in operation scenario.

In the lower left corner of the figure above, two dynamic cards of different templates are presented with different data. You can publish different card templates and call different data on the back end to dynamically update cards and display thousands of faces on demand. The whole home page is the layout, you can set up different layouts for different people.

Scenario 2: Dynamic research and development of alipay combined with mPaaS new-generation mobile terminal.

The home page of Alipay is shown in the lower right corner of the figure above. The blue part is mainly native development, with the best experience and performance. The middle part is some internal dynamic sub-applications, using cube small program development, giving consideration to experience and dynamic; The bottom market barometer and other Tab details pages are developed in Cube with high performance of local or single page dynamic.

Cube intelligent layout is based on dynamic cards and intelligent engine to achieve the overall layout of the page. The page is composed of several card templates that can be dynamically rendered. The template of dynamic cards is connected with business data, and targeted at different groups of people. The intelligent engine can adjust the layout of different people and different contents through layout configuration.

Layout can also be combined with other existing mPaaS products, such as short video live broadcast, terminal intelligence, low code building, LBS, visual burying point, etc., to achieve the output of the overall solution.

Taking the dynamic intelligent layout of Alipay home page as an example, it can be seen that the layout of active and inactive groups is different. For those who are not active, the homepage is mainly about benefits and public welfare. For active users, the home page will show their deeply related businesses, such as market barometer, financial hot spots, etc. In addition, for the same users, the style and content of financial cards will be different after the opening and closing of the market. In the evening, there will be an ant forest, the number of steps to exchange energy and other card guidance.

Cube high-performance small program is a new generation of development requirements based on large screen or IoT scenarios. It is a page-level or sub-application-level solution based on Cube rendering engine. It is a high-performance, dynamic small program solution with cross-platform consistency, dynamic and high performance. At the same time in the development side reuse small program DSL subset, get started easier.

The application scenarios of Cube high-performance applets are mostly IOT scenarios with large screens or applets of some low-end devices. They are also suitable for dynamic single-page apps and applets in conventional apps. It performs better on low-end devices, where Cube high performance applets can match the native experience compared to external applets, thus saving more memory and being smoother on low-end devices.

Its core advantages mainly lie in the following two aspects:

① Efficient development: reuse of small program development language, reduce version, improve efficiency.

(2) Process experience: For large screen IoT or set-top box and other older devices, native experience can be achieved, dynamic release can also be realized, and the fluency is much higher than traditional external small programs.

The above picture compares the effect of ant dynamic card with H5.

In the case of cold start and cache on the left, the card starts faster; With a swipe and cache on the right, the card renders smoother and faster.

The above picture shows the comparison between the ant dynamic card and the original. The overall difference is not big, and the performance of the card is comparable to that of the original.

Dynamic, efficient, ant dynamic card kernel logic

Via Jingjun – Senior technical expert of Ant Group

Ant Dynamic card encapsulates an independent SDK, and realizes the card rendering ability and JS related logic ability inside THE SDK, so the application can be easily accessed to SDK. At the same time, in order to improve the discharge of the cards, the reuse of inter-card and intra-card components is realized internally.

In addition, dynamic cards implement the following scalability capabilities:

① Extension component protocol: the card provides built-in components, such as text, image, DIV, etc. By combining built-in components, most business scenarios can be achieved. But there are special scenarios where you want to extend your component capabilities. For example, the business has implemented the ability to customize some video components and live components on the client side, but it still wants these components to be able to mix and render on the card and achieve the ability of dynamic delivery. After the extension component protocol is provided, you only need to implement the extension component protocol on the existing component, and use the registered custom extension component tag to write the template to achieve the purpose of component mixed rendering in the template.

② Extend JSAPI: for some clients have capabilities, can be called in the card through JSAPI. By implementing JSAPI protocol and extending JSAPI, you can directly call the common capability on the end when writing GS logic inside the card.

After the application is connected to dynamic cards, the main task is to create cards to realize dynamic content. The SDK provides an interface for creating cards, which are card instances. A view on a page corresponds to a card. You can implement the content and logic through the View, and generate cards, which make the content dynamic. Each card has a card template, and a unified DSL is responsible for writing the layout, style and JS logic of the card template. The component tags and extension components built into the DSL can be used in the template.

The system architecture of the card is divided into the following four layers:

1. Application layer: mainly responsible for data processing, card template version management and external API protocol encapsulation.

In template management, different templates are delivered based on different client versions. Dynamic upgrade is implemented based on templates of higher versions to ensure real-time update of cards on clients and achieve dynamic rendering. You can use different versions to manage the card style and layout, and inside the template, you can also support the ability to render logic because of the support for WRITING JS logic. Within a single template, different styles of rendering can be implemented according to different server data conditions, but this will result in too much business logic in the template, which is difficult to maintain.

Therefore, it is easier to manage through versions of different templates and is suitable for most dynamic scenarios.

2. Logic layer: including JS framework and template engine, through the template engine to achieve template style parsing, attribute data binding, logical rendering, instruction construction. Instruction construction refers to constructing instructions of different nodes according to the layout and style attributes of the template and distributing them to the rendering layer for node rendering. In addition, the logic layer implements a relatively small JS framework to assist the dynamic computing power of templates.

3. Rendering layer: mainly responsible for rendering model calculation, including layout, hierarchical calculation, rendering task construction and rasterization. The rendering layer contains two different types of UI, physical UI and virtual UI. Physical UIs refer to complex components such as input fields, lists, and custom extensions. Virtual UI refers to the components drawn through Canvas CPI, including built-in text components, image components, DIY container components, etc.

4. Platform layer: Encapsulates the Canvas CPI and platform UI interface. The layout of the physical UI is implemented through the platform layer interface.

In the JS framework layer to achieve a very small JS display framework, designed to achieve high performance, so only to achieve the ability to respond, without too much expansion of the JS framework. We choose QuickJS engine as the CARD JS engine, which is small in size and high in performance, and is very suitable for dynamic card scenarios. In addition, this layer extends the capabilities of JSApi and Timer asynchronous tasks.

Card Engine layer mainly includes Card Module management, component management, simple template expression, abstract syntax tree parsing and DOM diff calculation.

The RenderEngine Layer is the core module of the entire rendering, including layout, animation capabilities (2D, 3D), Render, Layer, gestures, and other common events. Render is mainly responsible for calculating some Render related data, while Layer is mainly responsible for hierarchical calculation.

The efficiency of dynamic cards benefits from the design of thread model. The main resident threads at runtime are the following:

① Bridge thread: responsible for Js instructions, Node tree construction, and related Node style resolution and layout calculation.

② Render thread: responsible for the construction of Render tree and Layer tree as well as hierarchical rendering tree, gesture related data calculation and Render data calculation. Where Render refers to the initial number of rendering, and Layer refers to the number of layers to draw.

③ Paint thread: Responsible for the construction of Paint instructions and the final rasterization. The Paint thread is multi-threaded and supports multi-task rendering to improve rendering performance.

④ Main thread: mainly includes gesture recognition and UI management.

In addition to the above four main threads, there are also worker threads and IO related threads during initialization.

The data model mainly contains the following four trees:

NodeTree: the original NodeTree, on which layout calculations and data changes are made.

RenderTree: the number of RenderTree variants. Its hierarchy may change. For example, zIndex in the template involves some hierarchy changes, and the final hierarchy will be consistent with the actual zIndex capability after doing the Render tree calculation, so the render tree will cause the adjustment of the node hierarchy.

③ LayerTree: Its main function is hierarchical processing. Different node components may be rendered in the same Layer, and each Layer node is an independent rendering container containing many virtual nodes, all rendered in the same Layer. Therefore, each Layer node is independent of each other and can be rendered concurrently.

(4) PaintTree: Inside the nodes of each Layer there will be a virtual tree of nodes, which are rendered within a Layer but also have their own hierarchical relationships.

From the original data at the beginning, it is processed to NodeTree, RenderTree and finally to LayerTree. Finally, LayerTree is used as the rendering container. Each Layer node corresponds to an independent rendering task, which has no relationship with each other and can achieve concurrent rendering. The bottom one is a card, and it’s all the way from initialization to the final screen.

The whole process of loading AB cards at the bottom of the picture above. First, the UI thread triggers the screen, initializes it in the worker thread, enters Render for hierarchical calculation and gesture drawing task calculation, and then goes to paint thread for multi-threaded concurrent rendering, and finally returns to the UI screen.

As can be seen from the above figure, the internal rendering of A card is realized by multi-threading. The cards are independent from each other, which can support asynchronous rendering and ensure A low probability of white screen.

The production/working process of the cards is as follows: The r&d period is mainly responsible for the compilation, debugging and preview of the cards. After compiling and debugging of the card, upload and publish the card through the card association background. After the release, the newly released card can be obtained on the terminal through CardSDKName, and the card content can be dynamically rendered on the device. Different card styles and layouts can be rendered according to different card templates.

ACK tool provides card debugging and compiling functions. The ACK tool allows you to quickly migrate new projects, compile debug code, and finally preview through Playground. The client playground is integrated into the Debug package and can be compiled and previewed locally using ACK tools. The DSL uses VUE’s subset syntax, can be written with any ID of the front end, and can be compiled and previewed using ACK tools.

The following is a demonstration of the entire process from new card creation to final preview.

First, look at the commands involved through ack-h.

There are commands for card initialization, simple scaffolding, tool names, and previews.

Next, initialize the new card project with the act init command.

The basic card packet shown above contains the path, name, and other information of the card.

Open the card with VSCode.

The project files of the card are shown on the left, including the project configuration file, main.vue (card style, logic file), manifest.json (card configuration file, template number, card name), and mock.json (local mock file).

Open main.vue, where the Template field contains the card’s main node style, layout, etc. Script contains JS variable declaration, life cycle, JS logic, etc. Methods can define JS methods, and template’s click event can define onClick methods, which can write some logic of their own.

You can customize the style of the node within the style.

After creating a template, run the act Prepare && Act Server command to generate a QR code for connecting to the debugging tool.

You only need to use the debug tool to scan the QR code, and then the client can connect to the local template of the tool for debugging and preview.

Use the “act build” command to compile the local template. After compiling, you add the dist directory on the left, which is a compilation of the template.

Enter the “Act Preview” preview command, and the device will display as follows:

Make the following changes to the code.

After compiling and previewing, the device displays the following:

ACT provides the Alive directive. After modifying the template, you only need to save it and view the final effect without manually compiling or previewing it.

Next is a demonstration of a relatively complex template.

After creating a function, you need to scan the code again to establish a connection. Preview with the build command, and it looks like this:

Add a key Frame animation to the code, preview it and see how smooth it looks.

Ant Dynamic card has landed in many scenarios of Alipay wallet, with a lot of accumulation and precipitation. Practice has also proved that its performance and stability can withstand the test, and I hope it can be seen and used by more developers.

END