Compared to Taro 1/2, Taro 3 is a runtime-heavy, compile-time framework with some performance loss. Therefore, Taro 3 provides a series of performance optimizations to improve the performance of Taro 3 applications.
This optimization has proven to significantly reduce update lag in Taro3, especially on low-end machines.
Taro3 uses the mini program's
template for rendering and does not normally use native custom components. This leads to the problem that all
setData updates are called from the page object, and if we have a complex page structure, the performance of the updates will be degraded.
The data structure of
setData when the hierarchy is too deep.
The main idea for this problem is to borrow the native custom component of the mini program to achieve a local update effect, thus improving the update performance.
setData data structure.
There are two ways for developers to implement this optimization.
For mini program that do not support template recursion (WeChat, QQ, Jingdong mini-program), Taro will use native custom components to assist recursion after the DOM level reaches a certain number.
The simple understanding is that after the DOM structure exceeds N levels, the native custom component will be used for rendering. N is 16 levels by default, and can be changed by modifying the configuration item baseLevel to modify N.
8 or even
4 layers can be very effective in improving performance during updates. However, the setting is global and can cause several problems.
flexlayouts will fail across native custom components, which is one of the most impactful issues.
- The descendant selector across custom components of the
SelectorQuery.selectmethod needs to be written Add
.the-ancestor >>> .the-descendant
To solve the problem of inflexible global configuration, we have added a base component
CustomWrapper. Its role is to create a native custom component from which the
setData of the descendant nodes will be called to achieve a local update effect.
Developers can use it to wrap modules that are experiencing update performance issues and improve performance when updating. Because the
CustomWrapper component needs to be used manually, developers can be aware that "this layer uses a custom component and needs to avoid two problems with custom components".
Usually it is not necessary to turn on, please use it according to the actual situation.
When the amount of data rendered at first time is very large, it may cause the page to be white screened for some time. Therefore, Taro provides [prerender] function to solve this problem.
For long list scenarios, Taro provides the VirtualList component to help developers optimize.
It rends only the components in the currently visible area, and the components in the non-visible area will be rendered after the user scrolls to the visible area, thus reducing the number of components actually rendered and optimizing the rendering performance.
The componentWillPreload hook provided in Taro 1 / 2 is deprecated in Taro 3.
In the mini program, there is a delay from calling the routing jump API such as
Taro.navigateTo to triggering
onLoad on the mini program page, so some network requests can be advanced to the moment before the jump is initiated.
Taro 3 provides the
Tato.preload API, which allows you to pass the content to be preloaded as a parameter, and then get the preloaded content after the new page is loaded via
Two factors that have a significant impact on the performance of the mini program are the amount of data in
setData and the number of calls to the
setData function per unit time.
setData data in the project will be very useful to help pinpoint the problem when performance issues are encountered. Developers can search to locate the location of the
.setData call by going to the
dist/taro.js file in the Taro project and then print the data.
In Taro, a batch bundle update operation is done on
setData, so more often than not, only the size of the setData data needs to be considered.
The following is our list of writing issues that developers need to be aware of
Suppose there is such a structure.
Taro3's current handling of node deletion is flawed. When
isShowModal changes from
false, the modal popup disappears. At this point, the
Modal component's sibling nodes are updated, and the
setData data is the DOM node information for the
In general, the impact is not too great and the developer does not need to be mentally burdened by it. However, if the DOM structure of the sibling node to be deleted is very complex, such as a floor component, the side effect of the delete operation will result in a large amount of
setData data, which will affect performance.
We can currently isolate the delete operation by optimizing it in this way.
We are optimizing the algorithm for deleting nodes to completely circumvent this unnecessary setData, which was released in v3.1.
Assuming that the values of the properties of the base components (such as
Input, etc.) are non-basic types, try to keep the object references.
Assume the following writing style：
Every time we render, React does a shallow comparison of the properties of the base component, and when we find that the reference to
markers is different, we will update the component properties. This results in more
setData and more
References to objects can be maintained by means of
state, closures, etc.
Basic components (such as
Input, etc.) that set non-standard properties are currently
setData along with these additional properties, which are not actually ignored by the mini program, so this part of
setData is redundant.
For example, the standard properties of the
Text component are
decode. If we set an additional property
something for it, then this additional property will also be setData.