background
For the consideration of multi-end delivery and open ecology, Xianyu began to access the entire Ali mini program system. Xianyu quickly launched the first small program fishtang small program in September. Due to the new contact and unfamiliar with the small program system, there is relatively large room for optimization in overall performance, which is mainly reflected in the following problems:
-
Small programs load slowly, and the first screen time on low-end Android Vivo Y67 is close to 6s
-
Scrolling stuttered, averaging around 40fps on the iPhone 7P
-
After scrolling multi-screen data, Tab clicking is slow to switch. The waiting time for Tab switching on iPhone 7P is 3-5 seconds, and the instantaneous frame rate is less than 30fps
In addition to traditional H5 optimization methods, applets have other differences due to their architectural characteristics of logic and rendering separation. This article mainly analyzes the effect of small program framework on rendering, as well as the specific optimization means of fish pond small program.
Applets architecture
Before analyzing the specific optimization Case, we first take a look at the small program architecture. First, we need to understand the architecture to know how to optimize the specific business code. Ali applet adopts the structure of Alipay applet. Here is a page life cycle chart of Alipay applet.
At present, all small programs on the market use logic (worker) and render (webview) separation. The benefits of this are:
-
It can meet the demands of external application control. Since the business logic does not run on webView, it cannot directly operate the rendering action through the API of the browser, which means that some dynamic operations cannot be performed through scripts.
-
Multiple pages can share the same JS running environment, the whole small program life cycle can share the global application context, close to the App development experience.
-
Page rendering and business logic are executed separately, so rendering will not be stuck due to JS logic execution, which is beneficial to improve the overall rendering performance.
However, this will also cause an obvious problem, page performance is strongly dependent on the communication efficiency of webView and worker:
-
The communication between webView and worker is asynchronous. This means that when we call setData, the data changes are not immediately reflected in the page rendering, but need to be transferred asynchronously from the worker to the WebView.
-
Data needs to be serialized as a string for transfer and then transmitted via evaluateJavascript, and data size can affect transfer performance.
The architecture of the separation of applets logic and rendering makes it different from traditional H5 performance optimizations. Small program performance optimization can refer to some of the official recommended performance optimization recommendations. In brief, special attention needs to be paid to the frequency of setData operation and data transmission. Next, we will discuss a specific case of fish pond small program.
Business Layer optimization
Load slow
“BEFORE”
“AFTER”
Performance problems
From the opening of the small program to the final rendering experience a brief period of white screen.
Cause analysis,
The overall loading time, including applets container initialization, data requests, and return of request results to render, needs to be optimized for each period.
Optimization means
-
Introduction of small program instance preservation mechanism to reduce the startup time of small programs
-
The data request is advanced to page. OnLoad, and the idle Loading prompt is added in the request stage to reduce users’ anxiety through interaction
-
The first screen data is offline, pre-rendered before the first screen data arrives, and the container test request is advanced in parallel with or before the applets instance starts
-
Split the first screen data and initialize only setData corresponding to the visible view
Scroll to caton
“BEFORE”
“AFTER”
Performance problems
Page scroll off frame sense is obvious, low sticky hand degree
Cause analysis,
-
Because it needs to listen for Page scroll distance to trigger top Bar display, the Page layer listens for onScroll event and calls setData frequently in callback
-
SetData is called multiple times in the request callback to load the next page Feeds while parsing the data
-
The Feeds card internally listens for the component’s onAppear and onDisappear events and calls setData in callbacks to avoid repeating exposure burials
Optimization means
For the communication mechanism between webview and worker of small program, we need to reduce the call frequency and transmission data size of setData.
-
Optimized onScroll callback logic to only trigger setData at partial times (within a certain range of scrolling distance) and only do partial rendering
-
The request callback to load the next page Feeds optimizes the data parsing logic, calls setData only once, and uses $spliceData to render the long list following official optimization recommendations
-
Optimize the data size of setData to transmit only relevant data that will affect the view
-
Instead of listening for component onAppear and onDisappear events, listen for component onFirstAppear events and perform exposure only when the first Appear occurs
The response to Tab switchover is slow
“BEFORE”
“AFTER”
Performance problems
After loading a few pages of Feeds, tab-switching starts to lag significantly, which takes 3-5 seconds, and is even worse on some Android machines, causing occasional crashes.
Cause analysis,
Too many things were done in a short time during Tab switching: switching Tab Current state, destroying Feeds list, displaying Loading animation, initiating data request -> rendering new list. Such high concurrency and large volume of content updates blocked data consumption in the view layer of the applet, resulting in a lag feeling.
Optimization means
-
The tasks during Tab switching are disassembled and divided into four stages:
-
To switch Tab Current state, perform Tab switch animation
-
After the Tab switch animation is complete, scroll the page to the position where the Tab is Sticky
-
Destroy the Feeds list to display the Loading animation
-
Initiate a data request -> Render
-
After this disassembly, the previous “high concurrency large area” is transformed into “phased controllable” update mode, resulting in a smooth interface
Container layer optimization
Applets optimize overall performance through offline caching, data preloading, and applets survival mechanisms. However, in rich interactive scenarios, control rendering on webView will encounter many performance bottlenecks.
At present, Ali applet supports embedding native components in webView to improve the overall performance. There are a lot of video content scenes in Yitang applet, and the video components used are native components. These components are rendered outside of the WebView thread, but because they are overlaid on top of the WebView, no matter how much z-index changes are made in the WebView, the element cannot be overlaid on top of the native component.
In order to solve this problem, students of small program framework also designed a cover-view, which can cover native components. For example, the play button at the top of the video can be covered with the cover-view. Finally, online fishpond small program has a relatively large improvement in user side experience after passing the same layer rendering video component.
Benefits and Plans
After optimization, the current online fish pond applet has significantly improved compared to the previous version:
There is still a lot of room to continue to optimize the small program under this business scenario. For example, we instantiate each fish pond small program alone, so that each fish pond small program can be saved and so on. In addition, in terms of performance optimization of small programs, we believe that a container containing performance alarms can be provided in the research and development stage to remind developers of some code writing methods that may affect performance by monitoring the call frequency of setData and the size of transmitted data. In the future, we will continue to make efforts in the ecological construction of Xianyu applets, integrate the group’s RESEARCH and development resources to establish the best practices of the whole link of Xianyu applets research and development, and provide external service providers with good experience in developing tripartite applets.
The Idle Fish Team is the industry leader in the new technology of Flutter+Dart FaaS integration, right now! Client/server Java/architecture/front-end/quality engineer recruitment for the society, base Hangzhou Alibaba Xixi Park, together to create creative space community products, do the depth of the top open source projects, together to expand the technical boundary achievement!
* Send resumes to small idle fish →[email protected]