Taobao widgets: new open card technology!

​Private domain, that is, the self-operated space of the brand, can help the brand continue to operate its own consumers.

Taobao is also rapidly adjusting the layout of private domains: Taobao also has a lot of private domain products, such as shops, customer service, and news. In these scenarios, brand merchants need to use creativity, content and services to retain consumer groups and generate sales conversions. But doing a private domain is not just pure sales. It is also necessary to use content and services to keep people behind, so that more and more people stay in the field. This part of the permanent population is the "private domain traffic."

Merchants and brands continue to provide high-quality content and follow-up services after purchasing products. Consumers in the private domain can obtain greater value than consumers in the public domain and are more likely to generate repurchase and brand loyalty.

Therefore, businesses will eagerly hope to deepen the private domain scene of Taobao and help them better operate consumers. In the face of a large number of merchants with different attributes in different vertical industries, it is a massive task to fully meet the personalized demands of merchants. Therefore, we have introduced a tripartite ecosystem through open technology to serve brands and merchants and help them build their own private domains of Taobao.

Through Taobao's open technology, three-party developers can create creative content and services for brand merchants, and finally be touched by consumers in the private domain.

So what is Taobao's open technology?

Open technology form

Taobao's open technology currently has two main forms. Mini programs are one of them. Taobao has done a lot of business exploration and technical practice based on mini programs. Mini programs carry the personalized demands of a large number of businesses. Through mini programs, businesses can continue to release their creativity and operate their own consumers. The mini program solves the problem of connecting merchants and consumers to a certain extent.

Later, we found that the card form is more suitable for the open appeal of the scene. In the high-efficiency electric shopping mall, a front-facing and highly customizable open area can effectively increase the reach of consumers. We are also actively exploring a card technology that is suitable for e-commerce scenarios and is sufficiently flexible and open.

Therefore, today I will give you a formal introduction to the second form of Taobao's open technology.

Based on the small program technology system, for the standard, lightweight, and high-performance open card scene, we launched the brand new open card technology "widget" for the first time in the industry.

This article will further elaborate some of our technical thinking from the following four points.

• Technical design strategy
• Core technical facilities
• Business scenario access
• Technology evolution route

Technical design strategy

Open up business scenarios, embrace technological dividends, unleash business creativity, and improve operating efficiency.

Production side

Widgets provide developers with flexible and standard technology selection.

Widgets are committed to solving the open problems of scene cards, providing developers with flexible and standard technical selection to support the personalized demands of businesses, and bring more somatosensory consumer experience.

For widgets that are strongly related to R&D, we hope that developers can complete the R&D, debugging, preview, uploading and other functions of widgets/small programs in the same IDE. Therefore, "Taobao Developer Tools" is used as an editing tool and R&D service. Combining the platform to improve the efficiency of the series between tools and services, one-stop help developers of widgets to improve the overall efficiency. In addition, in the area of ​​game interactive cards, developers can also directly use the game engine's IDE to improve their own research and development efficiency.

Developers can build their own widgets based on the production environment of "Taobao Developer Tools". The entire production process of widgets is also the development model of aligning small programs. Widgets actively embrace the tripartite open ecology, and developers can use standard small programs DSL, the upper-level technology ecology of widgets aligns with the web ecology of the applet, seamlessly supporting the operation and access of the front-end framework of the applet and the game engine.

In addition to the form configuration capabilities, we also support the JsonSchema capability in "Taobao Developer Tools". Through the opening of JsonSchema, widget developers can complete the research and development of the merchant-side form configuration capabilities that match the widgets, and the configuration forms help merchants You can flexibly control the foreground attributes and background interfaces of widgets.

Placement side

Small parts in the form of cards need a powerful delivery system to support them. The distribution of widget cloud information in different scenarios requires a centralized platform to support. Based on this centralized platform, widget cards can be flexibly placed in different business scenarios.

After the developers settle in, they can obtain the size information and visual specifications of different scenes after selecting the scenes they need to research and develop, and this level of constraints can ensure the consistency of the consumer experience of the scenes. In this regard, the developers of widgets can complete the product delivery only by simple adaptation after passing our adaptation scheme, and achieve the technical goal of a set of codes running in multiple places.

To this end, we provide a complete set of delivery capabilities. After the developer completes the delivery of the widget and passes the review, the merchant needs to complete the business configuration of the widget on the merchant side and put it into the online environment. Merchants can independently choose the placement scenes, such as shops, memberships, subscriptions, live broadcasts, and so on.

The delivery of widgets in the scene can be completed after the docking of the service end of the business scene in the foreground and the delivery system is completed.

Running side

The particularity of the card itself leads to extremely high requirements for rendering, performance, and experience. The widget container provides an efficient and stable environment to ensure the efficiency of business code execution.

In terms of capabilities, through the alignment of the basic library technology protocol, we ensure the reuse of all basic/business API capabilities of the applet container, and ensure the consistency of the interface standard with the Alipay applet container. This means that developers can call all API capabilities opened by the applet at almost zero cost and get the same experience as the applet.

In terms of rendering, the traditional WebView rendering solution is relatively heavy in the form of cards, and the memory and experience problems of multiple cards coexisting in the same scene cannot be solved well. To this end, we have redesigned a set of rendering schemes that are more suitable for card scenes. Compared with the WebView rendering engine of the applet, we replaced the card scenes with a brand new rendering engine, namely Weex2.0.

Through Weex2.0's cross-platform rendering capabilities, we have maintained a very high consistency on iOS and Android. The particularity of the tripartite scene will cause the card itself to have a very low technical fault tolerance rate. Therefore, from the perspective of performance and complexity, we have also converged the overall CSS style support. The overall design of the specification of the overall style capability is compatible with the W3C standard to a large extent, and a part of the subset is realized, and the functions within the scope of the subset are consistent with the standard.

In addition, the safe operation of widgets is also very important, for which we introduced a sandbox mechanism. Through the sandbox mechanism, we can ensure that different widget environments are isolated from each other and do not affect each other. Through the reuse of the underlying technology, we have also merged the creation of multiple JavaScript virtual machines to ensure that performance and efficiency can be maximized.

Core technical facilities

Next, let's talk about our core technical facilities, including scripting engine, rendering engine and graphics engine.

Script engine

The technical product of the widget is a JavaScript source file. In the widget, we use the QuickJS virtual machine as the script execution engine. Based on QuickJS, we can obtain a lightweight and efficient JavaScript execution environment. Compared with the huge V8 engine, the startup performance and package size benefits of the QuickJS virtual machine far exceed our expectations.

In the card scenario, the quick start of the script engine is a very important and urgent task, so based on the QuickJS virtual machine, we have done a lot of customization and optimization work.

Optimization at the virtual machine level helps us use new technical features to accelerate. Based on the "ByteCode" mechanism, we have considered pre-compiling the JavaScript source code into binary when building widgets to speed up the overall rendering. In addition, we are also advancing the design of standard bytecodes. Through the optimization of bytecodes, we can obtain the double optimization of loading speed and code size.

Similarly, at the interface layer of the script engine, we unified the group standard "JSI". With the help of JSI, we can switch between different JavaScript engines, and can help us achieve homogeneous standard programming under heterogeneous containers.

Rendering engine

The rendering engine is the core of the widget. We use Taobao's self-developed rendering engine "Weex2.0". The predecessor of Weex2.0 is Weex1.0. Compared with the system UI rendering of 1.0, we switched to cross-platform C++ in 2.0. Self-painting scheme. Through C++ cross-platform development, we have used C++ at the native level to implement complex functions such as componentization, MVVM, declarative templates, and responsive updates, and also smoothed out platform-related component differences between iOS and Android.

At the interface registration level, we directly bind the native rendering interface registration to the JavaScript environment through JS Binding, with almost no serialization cost. After the sinking of the C++ framework, node update and recycling can be implemented in a more granular manner.

In the rendering pipeline, we use the thread model and layout algorithm of Flutter Engine for reference, and will finally be submitted to Skia's own rendering process. The reuse of this part of the work helps us quickly achieve the landing. In addition, because our rendering pipeline is designed for Web-oriented technical characteristics, there is no Dart Widget concept in Flutter FrameWork, and it is more in line with the front-end technology stack.

Graphics engine

Canvas is a very important component in the Web ecology. It is suitable for business scenarios that are rich in interaction and focus on interactive experience, such as game interaction, 3D rendering, chart drawing, AR rendering and other graphic scenarios.

The Canvas capability is an independent component in the widget. Thanks to the Platform View mechanism of Weex2.0, we have implemented the same-layer rendering Canvas capability in the self-drawing engine. Canvas is essentially a W3C graphics rendering standard. In the face of this standard, Taobao also self-developed a graphics engine to implement "FCanvas". FCanvas supports WebGL and Canvas2D standards. Cross-container and high-performance FCanvas graphics rendering capabilities. The widgets are also open. Similarly, Canvas2D and Weex2.0 also directly connect to the Skia graphics library.

Through the standard alignment of the applet and the transformation of the underlying SDK, we are fully compatible with and support the game engine ecology in the applet. This means that game developers can directly self-generate widget projects through our supported game engine IDE, and card-level interactive games are very suitable for forwarding in business scenarios.

Business scenario access

Widgets are cards, so the "field" embedded in the card is naturally important.

In Taobao, there are currently multiple business scenarios that support the delivery of widgets, including shops, memberships, live broadcasts, subscriptions, and so on. Due to the particularity of the scene business, the current rendering schemes for multiple scenes are not the same, which involves multiple sets of technical schemes such as DX rendering, H5 rendering, Weex rendering, and applet rendering.

In the face of a complex rendering environment, there is no shortcut. We have also considered the pros and cons of using corresponding scene rendering schemes in different scenes, which will bring two problems.

• We judge that the technical feasibility of connecting different rendering solutions to a set of DSL is relatively low. Relatively speaking, this will destroy the technical consistency of the widgets, and the consumer's front-end experience cannot be guaranteed.
• In addition, the cost of technical maintenance in multiple scenarios will continue to increase. The particularity of open services determines that the tolerance threshold of third-party developers is relatively low, and a large amount of additional troubleshooting costs will be introduced.

Therefore, in different rendering schemes, we have encapsulated the corresponding components respectively, and then realize the embedding of widgets through the invocation of the components. The initial cost of this method is relatively high, but the cross-scene consistency will be guaranteed. Developers can also avoid caring about the rendering of the scene and only need to focus on completing the development of their own business logic.

Technology evolution route

It mainly focuses on three keywords, performance, scene, and efficiency.

Optimize performance experience

Card scenes are very sensitive to loading performance and operating performance, so we will continue to optimize technical performance, further optimize memory usage and improve overall operating performance for card scenes, fully release the creativity of merchants and increase the flexibility of developers.

• Reduce graphics memory footprint, reduce memory footprint through the resource integration and pipeline optimization of FCanvas, in addition, we will provide developers with best practices to help developers use them rationally.
• To improve the loading speed of the first screen, the performance optimization of the script engine will involve two parts of work, one is the support of the pre-compilation capability, the other is the support of the runtime "JIT" capability; the other is the further slimming of the rendering engine, and the runtime optimization of the loading task Queue supports low priority and unnecessary lazy loading of resources.
• Introducing the ability of small program plug-ins, the current plug-in ecology of small programs is still in urgent need of support. We are considering supporting the access of the plug-in ecology through APIs, which can help developers directly use plug-in capabilities such as members, tasks, and crowds.

Cover more scenes

Widgets will continue to expand access to more scenarios, especially high-frequency and high-conversion scenarios such as product detail pages, and some scenarios in the public domain will gradually be opened.

• For merchants, it can meet their own diversified business demands, and have the opportunity to harvest additional traffic from the public domain, and improve the water level of brand management.
• For the scene, you can actively embrace the tripartite open ecology, and form the structured precipitation and utilization of commercial elements through the communication capabilities of small parts.
• For developers, it can help developers to continuously reap commercial benefits on multiple tracks and maximize their own benefits and efficiency.

Improve circulation efficiency

With the current steady flow of e-commerce stores, we need to better help merchants manage their marketing budgets and revenues. It is important to improve the circulation efficiency of the card itself, which can help merchants improve their overall input-output ratio.

Help developers reduce research and development costs and help businesses improve efficiency, and further improve card circulation efficiency. Make the distribution and circulation of cards in different scenarios improve efficiency and establish corresponding supporting facilities to maximize the commercial value of a card.

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