Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "Mini Program redux performance optimization methods". The editor shows you the operation process through an actual case. The operation method is simple, fast and practical. I hope this "Mini Program redux performance optimization method" article can help you solve the problem.

First of all, understand the working principle and performance key points of Mini Program.

1 how it works (official statement) the view layer of Mini Program currently uses WebView as the rendering carrier, while the logical layer uses an independent JavascriptCore as the running environment. Architecturally, WebView and JavascriptCore are independent modules and do not have a channel for direct data sharing. Currently, the data transfer between the view layer and the logic layer is actually achieved through the evaluateJavascript provided on both sides. That is, the data transmitted by the user needs to be transferred in the form of a string, and at the same time, the converted data content is spliced into a JS script, and then transferred to both sides of the independent environment by executing the JS script.

The execution of evaluateJavascript will be affected by many aspects, and the arrival of data to the view layer is not real-time.

2 performance key points (official statement)

Go to setData frequently

In some of the cases we have analyzed, some Mini Program will setData very frequently (millisecond), which leads to two consequences:

Under Android, users will feel stutter when sliding, and the operation feedback delay is serious, because the JS thread has been compiling and performing rendering, which fails to transmit user operation events to the logic layer in time, and the logic layer cannot transmit the operation processing results to the view layer in time.

There is a delay in rendering, because the JS thread of WebView has been busy, the communication time from logic layer to page layer increases, hundreds of milliseconds have elapsed since the data message received by view layer, and the rendering result is not real-time.

Every time setData passes a lot of new data

From the underlying implementation of setData, our data transfer is actually an evaluateJavascript script process, when the amount of data is too large, it will increase the compilation and execution time of the script and occupy the WebView JS thread.

SetData the backstage page.

When the page enters the backstage state (the user is not visible), you should not continue to setData. The rendering of the backstage page will not be felt by the user. In addition, the setData of the backstage page will also preempt the execution of the foreground page.

3 Measurement performance indicators when we optimize performance, indicators are very important, without indicators, you can not know whether the optimized point is effective. Can not rely solely on feeling to optimize, according to the index feedback, clear optimization results. At the same time, optimization is like a bottomless pit, so we should pay attention to the input-output ratio.

Due to the stutter reported by users, either js execution consumes too much resources and the processor does not respond, or UI rendering consumes too many resources, resulting in UI being unable to respond to user actions.

By looking at the code, we don't have the business logic that consumes a lot of computing resources, but there is a phenomenon that UI operates repeatedly and preempts resources.

4 how to measure, you can use the second parameter of setData, pass in the callback function, and count the rendering time. The code is as follows

Let startTime = Date.now () this.setData (data, () = > {let endTime = Data.now () console.log (endTime-startTime, 'rendering time')}) case study 1. Checkpoint: whether to go to setData frequently to check the result: there is a reason: the entire store is listening in redux, and as long as the store changes, the setData operation will be performed, which means that the page has nothing to do with data changes, and will also trigger the page to perform setData operations. But this operation is meaningless. Problem code:

/ / libs/redux-wechat/connect.js / / A pair of entire store is subscribe. Execute handleChangethis.unsubscribe = this.store.subscribe (handleChange.bind (this, options)); function handleChange (options) {. Omit the code const state = this.store.getState () const mappedState = mapState (state, options); this.setData (mappedState)} solution:

Listen to only part of the data in the store used on the current page, and setData only if that part of the data changes. (store does not provide listening for individual data. If you modify the redux implementation by yourself, it will be difficult. At the same time, the modification is too low-level, and it is easy to cause unexpected exceptions. Determine whether the page data is the same as the data that needs to be updated, and if so, do not do anything. The cost of this scheme is relatively low, so use it.

Code implementation:

/ / libs/redux-wechat/connect.js// if the updated data is the same as the page data, no action will be taken. Function handleChange (options) {... Omit the code const state = this.store.getState () const mappedState = mapState (state, options); / / if the updated data is the same as the page data, do nothing. If (mappedState = this.prevState) return / / newly added code this.setData (mappedState) / / Save the last data this.prevState = mappedState / / newly added code} another optimization: what if the store data changes in milliseconds, such as updating the shopping cart while also updating the shopping quantity, can you combine the two changes? Because the store data is shared, the last update is the latest data, and the request can be merged with a throttle.

ClearTimeout (this.setDataTMO) this.setDataTMO = setTimeout (() = > {this.setData (mappedState)}, 50); / / time can be adjusted depending on the situation. 2. Checkpoint: a large amount of new data is passed every setData: there is a cause:

There is store data on the page that references unused data. The data returned by the backend goes directly into the store, and the backend API returns redundant fields.

Problem code:

/ pages/user/index.jsconnect (state = > ({member: state.member,mycoupon: state.mycoupon,guessLikeList: state.recommend.guessLikeList,locationInfo: state.common & & state.common.locationInfo, / / can delete selectedseller: state.home.selectedseller,// can delete carts: state.carts.carts,// can delete... state.common}) solution:

Delete the useless connect of the page (the old business is in use, it is risky to modify and optimize through subsequent iterations) request the backend interface, get the data for optimization processing, and then transfer the data to store (high cost)

3. Checkpoint: check the setData on the backstage page. Result: there is a reason: there is a difference between redux connect design and Mini Program code:

/ / libs/redux-wechat/connect.jsfunction onLoad (options) {... Omit part of the code if (shouldSubscribe) {this.unsubscribe = this.store.subscribe (handleChange.bind (this, options)); handleChange.call (this, options)}} function onUnload () {. When part of the code / / page onUnload is omitted, the listening typeof this.unsubscribe = 'function' & & this.unsubscribe ()} during the life cycle of Mini Program, onUnload will be executed when the page is destroyed, such as the jump of A-> B-> C-> D, and the A page has been listening for changes in store. If the D page modifies the data, it will cause the AMagie Bjell C page to also perform setData operations, seizing D's resources, thus causing stutters. Solution:

Pages in the background state are directly return when setData (this method is currently used) when the page is hidden, the listener is removed.

Code implementation:

/ / because the setData in the background page will preempt the foreground resources, so do not perform the setData operation if (this.route! = = _ getActivePage (). Route) return in the background page, but because the page data in the background cannot be updated, if the D page modifies the data referenced by A, there will be a problem that A references the old data, so do a synchronization during onShow.

/ / when the background page switches to the foreground, do a data synchronization function onShow (options) {if (shouldSubscribe) {handleChange.call (this, options)} if (typeof _ onShow = 'function') {_ onShow.call (this, options)}} metric test, whether it is useful or not, it will be clear whether it is useful or not. Test platform: iphone7, Samsung S7, Mini Program development tools test flow: home-> deliver home-> join shopping cart-> settlement-> View order test metrics: call setData times, total rendering time, average single rendering time

After optimization, the number of setData decreased by 150 times on average. The more time-consuming rendering is, the more profitable the machine is, and the average rendering time of Samsung S7 reduces 826ms.

This is the end of the introduction on "Mini Program redux performance optimization methods". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.