The practice of multi-terminal integration technology for merchants and stores

Brief Description

After the store browsing loop was closed, the code could not be reused due to the separation of data and rendering on each end, which increased the R&D cost. At the same time, the technology stack had not been upgraded and unified for many years, which seriously lagged behind the competing stores, and the support for ISV openness also stagnated. In response to this series of problems, the store R&D team launched a multi-end integration cost reduction and efficiency improvement project, and was determined to upgrade and rewrite all multi-end rendering, solving all the above problems from the bottom-level capabilities, so that store browsing has moved from the original repeated development 1.0 era to a new set of code multi-end reuse 2.0 new era.

background

The store team provides JD.com's hundreds of thousands of merchants with the ability to quickly build pages and display them on different apps, M sites, and Jinggou mini-programs. It also introduces ISV service providers to provide merchants with customized floor development, helping them to improve product sales conversion rates. Secondly, ISV template sales can also bring JD.com millions of additional income each year.

For many years, the store decoration end and the browsing end of merchants have been maintained by different teams. In the first half of 2021, due to business adjustments, all closed loops were transferred to the Zhipu team. In the early stage of the closed loop, we sorted out the business status of each end and found several major problems. First, the display effects of each browsing end are inconsistent. There are inconsistencies in the page functions of the APP end, M station and Jinggou store. Second, the technology stacks of each system are not unified. There are applications developed in C language on the server side. On the front end, the technology stacks are also diverse, which makes the maintenance costs of these systems very high. If a requirement is to be displayed on all ends, it needs to be developed on each end, which is very stressful, and the testing and online costs are also very high. Third, after the business loop is closed, human resources have not increased, which is equivalent to the original resources only developing the decoration end business, and now need to undertake the business needs of 3 browsing ends.

At the same time, in terms of rendering technology, competing stores have completely switched to self-developed mini-program rendering, which is much higher than JD Store's RN development technology in terms of both demand development efficiency and ISV template development efficiency. At the same time, as the infrastructure capabilities of the mini-programs of various businesses of the competing APP are fully rolled out, other businesses can also be easily displayed in competing stores. However, because the JD Store APP is rendered with RN technology, external floors cannot be inserted between floors.

Therefore, considering the current business situation, the multi-terminal integration of the store is imperative, and a set of codes must be implemented to be displayed on all terminals. Secondly, in terms of store rendering technology, RN must be abandoned and the technology of competing stores must be aligned. Only in this way can the development efficiency of the team and the ISV service provider be improved, while expanding the store's infrastructure capabilities to access other businesses.

Existing rendering process on each end

To solve the problem that after merchants change templates, they can make them take effect in real time on the APP side. The Zhipu Decoration System currently adopts the "XML template to JSON dynamic distribution solution". The structure and style of each set of templates are defined through XML. After the merchant decorates the store, the server will parse the decoration data and the XML-defined style into JSON format and send it to each display end. The biggest advantage of doing this is that the APP side does not need to integrate the version, and different template styles can be changed online at any time. However, this also creates a big problem, because M Station and Mini Program can support Js template rendering, but now they can only parse this set of JSON data to get the template for rendering.

At the same time, due to the inconsistency of the browser maintenance team, the servers of each team repackaged the JSON data after receiving it, which directly resulted in the interface data format being completely inconsistent. Secondly, each team's front-end also developed a parsing library to parse the JSON data, so these parsing libraries could not be reused at all.

Secondly, because the application is independent and supports many terminals, there are also many online deployment projects.

Problems that the solution needs to solve

In view of the above background and the current status of rendering on each end, the integration of multiple terminals of the store needs to consider four aspects: First, the server data must be unified and output a set of standard data format definitions. Secondly, the front end needs to unify the rendering of multiple terminals and develop a set of codes that can be used on different terminals. Thirdly, after the front-end rendering is integrated, the performance of the homepage of the stores on each end cannot be reduced and the user experience cannot be affected. Finally, the integration of multiple terminals of the store also needs to solve the efficiency problem of ISV developing floor templates.

Since there is a lot of content, let’s focus on the “front-end rendering fusion solution” and the “first screen performance guarantee solution” on each end.

Front-end rendering fusion solution

01Scheme Design

Since the store currently uses the "XML template to JSON dynamic distribution solution", there are multiple sets of parsing libraries to parse this set of data, resulting in duplicate workload problems.

Therefore, the first set of integration solutions is the "coexistence of APP-side parsing library and mini-program parsing library". In the left figure, for the unified data sent by the server, a unified parsing library is developed on the front end. This parsing library contains two sets of logic. One is to achieve reuse between JD APPs through the RN parsing library, and then convert it into an H5 unified M station store and decoration-side preview through JDReact. The other set of logic is to achieve the unification of Jinggou mini-program stores and JD mini-program businesses through the mini-program parsing library.

This solution has relatively little change to the existing APP business and is a semi-integrated solution. Because two sets of parsing logic still need to be maintained, it can only reduce the workload by 30%-40%. At the same time, the problems analyzed above have not been solved. First, H5 and mini programs also need to be parsed by the parsing library to get the template style, which is inefficient; second, ISVs can only develop RN templates, and the efficiency has not been improved; third, it still lags behind the technical unification and scalability of competing stores.

The second set of solutions is the "multi-terminal unified RN solution". This solution completely upgrades the browsing and rendering technology of all terminals of the entire store. In the above right picture, through JD's open source Taro technology solution, a static resource multi-terminal fusion project is first developed. On the APP side, an H5 offline package is issued through the JDHybrid solution of the JD Platform Business Department, and the offline package is pre-downloaded to the user APP. When the user opens the store, the offline package resources are injected into the store's native page webview container, reducing page and static resource requests, and access performance has been greatly improved. On the M and PC sides, Taro converts the H5 page to support the store M station and the PC preview page. On the mini program side, the mini program package is directly issued to support business scenarios such as Jinggou mini program stores and JD mini programs.

This solution completely solves all the above problems, and the team can reduce 60-70% of the workload when facing multi-terminal business needs. At the same time, h5 and mini programs can directly obtain template styles, and the rendering performance has also been improved; ISVs no longer need to develop inefficient RN templates, and through multi-terminal integration solutions, a set of templates can be displayed on each terminal; in terms of overall technology and scalability, it has also achieved alignment with competing stores.

Currently, the APP store page has achieved the co-display of native floors and webview floors. We are also developing the JD Mini Program to be embedded in the store homepage for display, while increasing webview reuse to ensure performance. After it goes online, the store homepage will have the infrastructure capability to render native + H5 + mini programs at the same time. As long as other businesses follow this technical system, they can also quickly render H5 floors and mini program floors in the store.

02Overview of the overall solution

The entire "multi-terminal unified RN-free solution" includes four main solutions: H5 and APP integration, H5 and mini-program integration, Nodejs service, and ISV cross-terminal openness; as well as four expansion solutions: exception, disaster recovery, performance, and monitoring;

Since there are many solutions, I will not describe them in detail here. If you are interested in this solution, you can contact our Zhipu team for communication.

First screen performance guarantee plan

In terms of the performance of the first screen of each terminal, the current rendering time of the first screen of the store's native floors and mixed RN floors on the iOS and Android terminals fluctuates between 0.7 and 1 second; the M station store takes about 4 seconds; and the Jinggou mini program store takes about 2.5 seconds. Therefore, the current rendering time of the three terminals is the reference benchmark for this multi-terminal integration.

01Core Safeguard Measures

On the IOS side, the Hybrid offline package is used to reduce the request time for pages and static resources, and the webview container initialization is started when the store is just entered. Secondly, the more time-consuming images are put at the end for lazy loading requests. Through these measures, under the premise of rendering 5 floors on the first screen, the time consumed by the user for the first screen is roughly around 800 milliseconds, and the overall time is consistent with the performance of online native + RN rendering. There are two points that can be further optimized here, such as starting the data interface request when clicking on the entrance of the store. Secondly, the current server-side data interface takes time to return all the data on the homepage. If it is changed to only return the first screen data, or add caching measures, this can also effectively reduce the time consumed by data requests, which will eventually be reflected in the reduction of the first screen time consumption.

On the Android side, the server data interface request starts when the user clicks the store entrance. When the user enters the store, the data request time has been reduced by nearly half. At the same time, with the Hybrid offline package solution, the first screen time on the Android side is kept consistent with that on the online side. There are also several points that can be further optimized, such as optimizing the interface time consumption, and moving the webview initialization and static resource injection forward to the time of entering the store. This can also effectively improve the store's access performance.

02 Comprehensive Safeguard Measures

In addition to the optimization measures used above, some optimization measures are also used for different terminals. Static resource file merging measures are also used on the APP side to reduce the performance of loading online H5 pages when the offline package fails to load. Skeleton screens, floors and pictures are also lazy loaded.

On the mini program side and M site, skeleton screen, lazy loading, and H5 browser offline caching solutions are also used to improve page performance.

Fusion benefits

01Improved first screen performance

After multi-terminal integration, the first screen performance of the new homepage on iOS and Android is basically the same as the rendering performance of online native + RN. M Station and Jinggou Mini Program are not yet fully launched, and it is estimated that there will be a significant improvement.

02ISV openness capabilities improvement

Currently, the only RN customized templates available to ISVs in the store are for the APP side. RN is limited by the technology itself and cannot support three terminals well. At the same time, the complex development environment and difficult debugging greatly affect the ISV development efficiency. Compared with the ISV development of competing stores, the average development time of the same set of templates with similar effects is 1-2 times longer. However, based on the Taro specification technology stack used for multi-terminal integration, and the fact that the store has now realized a unified base for multi-terminal rendering, ISV only needs to develop one set of code and make slight adjustments to support three terminals, and the efficiency will also be greatly improved.

03Efficiency and other improvements

In terms of labor efficiency, the manpower involved in multi-terminal rendering has been reduced by 56% and the working hours have been reduced by 66%. The data interface has also been unified on the server side, reducing labor costs by 30%-50%.

At the same time, in terms of technical patents and article accumulation, 3 technical patents have been approved, and two are in the writing stage. Secondly, 4 technical articles are also being written.

Technology Outlook

After more than a decade of development, the front-end technology has evolved rapidly in terms of technology stacks and frameworks. However, the number of display terminals that businesses need to support is increasing. If each terminal needs to be developed repeatedly, the manpower consumption will be unbearable. Therefore, it is necessary to balance various factors and find the best combination of front-end technologies. The principle is to use one set of code for multi-terminal adaptation and reuse.

However, due to the development of Internet technology and the trade-offs of the interests of various manufacturers, it is still impossible to unify a standard technology stack in front-end rendering that can run on the software provided by various manufacturers. Therefore, various compatible technologies have emerged, whether it is development specification compatibility, underlying engine compatibility, or configuration-based compatibility, etc., which are all efforts to pursue unification by all parties.

The simplest way is to make users accept it quickly, and the technology with the lowest learning and use cost will last forever. Perhaps one day, the technical specifications based on the W3C system will gradually be accepted by various manufacturers and adapted and compatible with the underlying engine.