This article mainly describes the difficulties encountered in the support process of Jingdong Menxiang business. In the face of problems, we have explored and practiced in the direction of efficiency improvement and quality assurance. Here, we will share with you the ideas and solutions for solving problems in the practice process. I also hope to bring you some new inspiration

1. Background

1.1 Detailed introduction of JD Gate

1.1.1. JD.com's detailed business

The store details page is called Menxiang for short. The Menxiang business includes pages such as store details, list, order collection, search, and store arrival. It was first launched on JD.com’s main website APP in 2020. It was initially used as an offline high-quality merchant of JD Daojia. The model is stationed in JD.com's main website, and users can complete the complete shopping process such as store information viewing, product browsing, delivery timeliness confirmation, coupon collection, car addition, and order placement in one stop in Menxiang. With the subsequent development of the business, Menxiang has successively undertaken more business model scenarios such as Tianxuan, hourly purchase, drug delivery, front warehouse, etc., and gradually formed a feature of instant retail, covering home and store scenarios, and undertaking line General integrated business system for online and offline

1.1.2. Detailed business form

The door detailed business involves Jiamenxiang (hourly purchase, medicine delivery), and store details (POP, Wanjia); the technology stack involves JD applets [2], WeChat applets [3], H5, RN; the page involves stores 20+ home page, order making, search, evaluation, qualification, list, etc.

1.2. Pain points faced in the process of Menxiang’s business support

There is a large difference in door details between the Jingdong app and the WeChat applet
Due to historical reasons, we are faced with the need to maintain two sets of door details for the Jingdong app and the Jinggou applet at the same time
The demand for business planning is huge, the iterations of double-ended requirements are frequent, and the R&D resources are tight and cannot be digested in a short time
Double-ended business scenarios and different technology stacks pose great challenges to quality assurance

1.3. Jinggou Mini Program Business Party’s Appeal to Menxiang

It is expected that the detailed functions of the Jinggou applet will be aligned with the Jingdong app
Iteration of new requirements hopes to quickly synchronize to the WeChat domain
It is expected that the throughput of R&D requirements will increase, and more requirements can be quickly absorbed

2. Technical solution

2.1. Preliminary program research

In terms of preliminary technical solution research, we also learned about various popular multi-terminal frameworks such as RN, Flutter, Taro, uni-app, etc., and carried out research on multi-terminal support, development ecology, front-end framework support, and learning costs. Research and comparison; since JD APP and WeChat applets are to be supported, multi-terminal frameworks that support applets such as Taro3[1], uni-app[10], mpvue[11], chameleon[12], WePY[13], etc. are given priority. ;Combining the compatibility of the front-end framework, the support of Jingdong applet [2] and the team's own situation (the team is familiar with React), after comprehensive consideration, it was finally decided to use the Taro framework for multi-terminal reconstruction.

2.2. Formulation and practice of technical solutions

2.2.1. Thinking about the problems that need to be solved

How to better support multi-terminal needs such as JD applets, WeChat applets, and H5?
How to avoid repeated development of new requirements during the transformation process?
How to shorten the R&D lead time?
How can we improve efficiency in the development process?
How to ensure the quality of research and development in the rapid iteration process?
How to flexibly support more business scenarios?
How to ensure page performance?

2.2.2. Formulate solutions

2.2.2.1. Multi-terminal solution for detailed business

The entire solution builds a complete set of multi-terminal and floor-based solutions through the front-end, server, and platform. The server-side splits the door detail function into multiple domain services, domain models, and extension points based on the PaaS architecture. The front-end is based on the iPaas floor , Component standard formulation, detailed multi-terminal and floor-based schemes, the management platform connects with Huangliu digital platform and iHub platform through Odysseus (small program transaction digital platform), and manages business, pages, floors, components, data, etc. And online release, the following is the panorama of the overall solution

2.2.2.2. Front-end technical framework of door details

The front-end is based on Taro3[1] + React[8] + Recoil[7] as the technical base, and splits the door detailed business into networks, addresses, buried points, coupons, business cards, shopping carts, etc. according to the principles of basic functions and basic components. 50+ function points, the page standard adds the door detail rendering engine part to the iPaas page protocol, manages the floor and code through the iHub platform, and finally renders it by the page container. The following is based on the pain points faced by the door details in the process of multi-portal Architecture diagram and some of our plans in the implementation process

2.2.3. Implementation process of technical solutions

1) Classification of business functions and splitting of floors and components

According to the structure, the door detailed homepage is divided into header, list, footer, pop-up layer, etc., and divided into page header, store information, member floor, discount promotion, product list, settlement slip, shopping cart, etc. according to the floor 12+ floor components

2) Difference processing in the process of multi-terminal adaptation

Although the multi-terminal framework has helped us solve cross-platform development scenarios, there are still some workloads that need to be adapted and processed according to specific platforms due to differences in the underlying principles and implementation methods of basic capabilities between different platforms. Let's sort out the door first The 40+ underlying capabilities of the small program platform used in the details, enumerate and compare the functional differences on the multi-terminal platform, and formulate an intermediate adaptation layer for platform differences to standardize the API uniformly (eg: login, address, buried point, routing, system information, etc. )

3) Ways to improve efficiency during the development process

Componentization: Component encapsulation is divided into two layers. The bottom layer is the functional component of the smallest unit, and the upper layer is the principle encapsulation of the smallest reusable business component, which effectively reduces the redundancy of the same and similar codes. At the same time, the tool jscpd[4] will also be used regularly Conduct code audit to further find similar code fragments for optimization

Layerization: Combining related business components to improve the maximum reusability of capabilities, such as: store information floor, discount promotion floor, etc., and the floor components are developed according to the page schema protocol, and some capabilities can be customized
MVVM mode: Use react hook[6] to refine the logic and data processing in the original page to the View Mode layer, so that the clear separation between logic and UI is easy to maintain, and it can also significantly increase the chance of code reuse

4) Dealing with new requirements during the renovation process

The old door details are developed using the native language of JD.com’s small program, and the new door details are developed using Taro+React. Before the new door details are fully released, new requirements require dual-end support, which means that the same requirements will be developed twice. After exploration, we packaged Taro components into native components that can be directly referenced by applets through the hybrid development model [9], which solved the problem of repeated development of old and new projects

2.3. Performance optimization of door details applet

Menxiang also exposed some performance problems during the public beta phase. We divided them into two categories according to the scenarios: experience performance and start-up performance. Let me share with you the relevant cases and solutions here, hoping to give some help to friends who have similar difficulties. new ideas

2.3.1, experience performance optimization

The most frequent user operations on the door detailed homepage are functions such as category switching and list sliding, which are also the part with more user feedback. The following is a related case analysis for the above two types of problems:

2.3.1.1. Product list rendering performance optimization

After the multi-terminal transformation of the door details, we collected user experience feedback through questionnaire surveys, and found that some users reported that there was a freeze phenomenon when scrolling the product list. We use Taro's debug environment log to analyze and find that the volume of setData keeps increasing during page loading, and the time-consuming keeps increasing

debug environment log:

setData time-consuming trend curve:

After investigation, it was found that the large amount of data caused frame loss when the list was paged and rendered. In order to solve the problem of large-scale rendering and repeated rendering, the original two-dimensional array data structure of the product list is optimized to a linked list + recursive method for hierarchical nested tile rendering, reducing multi-level calculations on the data, and page-by-page loading and rendering control on the view On a single page, the following is the optimized list effect:

List effect:

setData time-consuming trend curve:

Time-consuming comparison of split-screen data rendering before and after optimization:

The left side of the figure above shows the effect of the list before optimization. You can see that the freeze when loading the requested data is more obvious, especially as the amount of data increases, the freeze time is getting longer and longer. On the right is the optimized effect, which still maintains efficient rendering performance after loading more than a dozen pages. After the above optimization, the data rendering time of each screen is maintained at about 200ms, and the rendering is still efficient when there is a lot of paged data loading.

2.3.1.2. List rendering logic optimization when switching categories

During the business support process of the front warehouse, it was found that in some special scenarios, the waiting time was long when switching categories, and the user experience was poor. After analysis, it is found that when loading data in the classification list, the front-end processing logic is to automatically load the next page of data when the product is not full of one screen, and to complete the product list so that the user can see more product data, but when the interface makes a polling request, it causes Users wait longer

The left side of the figure above is the logic of product loading when the classification is switched before optimization. In order to reduce the user’s waiting time, the classification rendering logic is optimized (as shown on the right side of the figure), and the processing logic after the classification is clicked is adjusted. Only the data under the current classification is requested. Cross-level classification interface requests are no longer made. Classified rendering time is reduced from n (number of interface requests)*250 (interface request time)+200ms (front-end rendering time) to 250ms+200ms.

2.3.2. Startup performance optimization

We analyze the start-up process of the detailed applet, sort out each link of start-up and the corresponding time-consuming data, and formulate an optimization plan. The main directions of optimization are as follows:

Jingdong small program package compression (zip the jdapkg file, reducing the file size from 8.6MB to 3.4MB)
Reuse of small program template packages (to avoid multiple small program cold start downloads)
The detailed mini-program template package is built into the APP (reducing the time-consuming download of the mini-program package)
Preload the applet template package when the APP starts (reducing the time spent on cold startup of the applet)
Mini-program engine loading time-consuming optimization (preheating the mini-program engine)
Small program engine starts main thread lag optimization (logic layer and rendering layer are processed in parallel)
Small program code construction package. jdapkg optimization (engine common code extraction)
The information interface of the applet is changed from synchronous to asynchronous (the average online time is reduced by 158ms)
Small program network library timeout and retry mechanism optimization
Time-consuming optimization of the main interface of the door details (asynchronization of data not necessary for the first screen)
Detailed business code package reduction (code optimization, subpackage, etc., package size reduced from 3.4MB to 648KB)

Using the public template package, multiple merchants share a code package to reduce repeated downloads

Optimize the average start-up time of the Qianmen applet is 2227.7ms. After the above optimization measures are implemented, the overall start-up time is reduced to 954ms, and the startup speed is increased by 57.6%. We also take this opportunity to express our heartfelt thanks to the program engine team for their strong support!

2.4. Exploration of ISV co-construction scheme and quality assurance

2.4.1. Why do we need to conduct co-construction and exploration?

There is a large influx of demand on the business side, and some of the functions that are not detailed and general-purpose belong to the individual needs of special scenarios. In the case of shortage of R&D resources, we are also thinking about how to improve the throughput of demand, in order to better support the business. , After in-depth communication with the business, it was found that some business sides also have their own R&D teams, which can independently develop personalized needs. Stream ISV platform access, and open some independent floors to the independent access of the business side. The specific co-construction process is as follows:

After the transformation and exploration of the system ISV solution, the waiting time for personalized demand has been significantly shortened. Compared with the previous two quarters, the overall acceptance of personalized demand has increased by more than 30%. The large increase in demand is also a test for the system and new architecture. In order to ensure the stability of the system, we have formulated the co-construction process specification and related performance, quality and other constraints on the access, development, and launch of the co-construction requirements.

2.4.2. How to ensure the quality of research and development?

We also found some problems during the multi-team and multi-person collaboration process. In order to avoid some common problems, we have formulated relevant development specifications here, and added some necessary verification links during the entire requirement development and online process. The specific details are as follows:

Unified standard specification (directory structure specification, git branch specification, code writing specification, development specification, file specification, online specification, etc.)
Review the front-end and back-end technical solutions after requirements review and before development
Use tools (ESLint) for code specification scanning and grammar specification checking
Conduct code review and estimate the scope of influence before going online
Checklist (important processes, core functions, special scenarios) inspection during launch
After going online, grayscale cuts and observes monitoring, abnormalities, customer complaints and other systems
The bottom-up solution supports one-click downgrade of online pages and functions

3. Technology precipitation and business empowerment

3.1. Capability precipitation in the process of technological transformation

Multi-terminal and floor-based development framework, supporting ISV access and co-construction
The specification page can program the floor-based protocol, and some capabilities can be dynamically configured
Standardized floor component development templates to reduce component development and configuration process
The basic function library precipitates 16 basic APIs, 25 basic components, 50+ business components, and 3 packaged plug-ins
Self-developed multi-terminal debugging tool (nuclear), published 2 public account articles, and 2 patents that have entered the review stage of the National Patent Office
Build tools cola-cli, cola-server
Small program standardization door details empower SDK

3.2. Benefits brought by multi-terminalization

Basic capabilities enable new businesses (pre-warehouse door details, store details, POP door details, etc.) to increase development efficiency by more than 40%
95%+ functions of Menxiang on the Jingdong app can be directly reused in WeChat applets and H5 terminals, greatly improving the throughput of multi-terminal requirements under limited R&D resources
After 4 months of multi-terminal transformation, the needs of the door detail business in the Jinggou applet that have lagged for more than 2 years have been filled
20+ mini-program empowerment (eg: Jinggou mini-program, JD Supermarket mini-program, Hourbuy, etc.)

The development framework, basic function library, and general development templates accumulated in the process of multi-terminal multi-level floorization of door details have also been well practiced in businesses such as store door details, store store details, and pop door details.

3.3. Detailed quick support for the front door

During the second phase construction of JD app’s pre-warehouse, the component and function reuse rate of the mini-program’s door details reached 95%+. Based on the multi-terminal framework capability, the detailed empowerment of the front-end warehouse door to the Jinggou mini-program was completed within 2 days. The business side It is expected that the front-end warehouse door detail capability can be introduced into the Jingdong Supermarket mini-program (WeChat). It is also in this process that we combine the multi-terminal and floor-based capabilities of door details with the capabilities of Odysseus platform authentication, model management, data management, visualization, and configuration, and provide business parties with one-click access through the combination of scaffolding and platforms. Build a one-stop empowerment service. Through this standardized method, it not only supports the small program requirements of Jingdong Supermarket, but also expands the standardized door-to-door capabilities in Huangliu SDK. One-click trigger can complete the entire Huangliu SDK empowerment within 5 minutes. Package construction

4. Future Outlook

With the increasing number of scenarios involved in the door details business, the general floor components are gradually unable to meet all differentiated scenarios. However, putting all floors in the public template package is undoubtedly a test of the size of the small program package. Based on the one-code multi-terminal framework and Our self-developed small program publishing system thinking can classify and manage detailed batches of small programs, build them according to type and demand when building, split a public template package into multiple templates, and build and release them separately in a differentiated way

At the same time that the iPaas2.0 construction platform in JD’s front-end technology domain is gradually improving, Menxiang’s business benefits from the multi-terminal and floor-based framework, and it has also taken a step forward for the multi-terminal visualization construction of the Menxiang applet, providing more Provide standardized door details for business scenarios