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

This article mainly introduces the example analysis of the deep digging array of Vue performance optimization, which is very detailed and has a certain reference value. Interested friends must read it!

Background

Recently, we are using Vue to reconstruct a history project, an examination system, with a large number of questions, so the performance of the core components has become a focus. Let's start with two pictures to take a look at the style of the core component Paper.

From the picture, it is divided into the answer area and the selection panel area.

Disassemble the interaction logic slightly:

Answer mode and learning mode can be switched between each other to control the correct answer.

Single selection and judgment questions directly click to record the correctness of the answer, multi-choice is to select the answer and click OK to record the correctness.

The selection panel records the questions that have been done, divided into six states (undone, undone and currently selected, wrong, wrong and currently selected, right, right and currently selected), distinguished by different styles.

Click on the selection panel, and the answer area can be cut to the corresponding question number.

Based on the above considerations, I feel that I must have three responsive data:

CurrentIndex: the serial number of the currently selected topic.

Questions: the information of all topics is an array that maintains the questions, options, correctness and other information of each question.

CardData: the topic grouping information, which is also an array, classifies different topics by chapter name.

Each item of the array is structured as follows:

CurrentIndex = 0 / / Index questions used to mark the currently selected topic questions = [{secId: 1, / / id tid: 1 of the chapter to which it belongs, / / topic id content: 'topic content' / / topic description type: 1, / / question type, 1 ~ 3 (single, multiple) Judge) options: ['option 1,' option 2, 'option 3,' option 4,] / / description of each option choose: [1, 2, 4], / / multiple selection-record the option done: true, / / mark whether the current topic has been done answerIsTrue: undefined / / mark whether the current topic is correct}] cardData = [{startIndex: 0 / / used to record the starting index that loops the packet data This value is equal to the cumulative length of the previous data. SecName: 'chapter name', secId: 'chapter id', tids: [1, 2, 3, 11] / / id of all topics below this section}]

Because the title can slide between left and right, so I take three data from questions to render each time, using the Slide component of cube-ui, as long as I cut three data dynamically according to this.currentIndex combined with computed characteristics.

All this looks good, especially before the writing of the core components of a history project is coming to an end.

However, the turning point occurs in the rendering selection panel style step.

The logic of the code was simple, but something happened that confused me.

{{item.secName}} {{index + item.startIndex + 1}}

In fact, it is to use cardData to generate DOM elements, which is a grouped data (first with the chapter as the dimension, and there is a corresponding topic at the bottom of the chapter). The above code is actually a loop nested within another loop.

However, as long as I switch topics or click on the panel, or trigger any change in responsive data, the page will get stuck!

Explore

At present, the first reaction must be that the execution time of js in a certain step is too long, so I tracked it with the Performance tool that comes with Chrome and found that the problem lies in the function call getItemClass, which takes up 99% of the time and takes more than 1 second. Took a look at your own code:

GetItemClass (index) {const ret = {} / / if it is the right topic, but ret ['item_true'] = this.questions [index] is not currently selected. / / if it is the right topic and ret ['item_true_active'] = this.questions [index] is currently selected. / / if the problem is wrong, but ret ['item_false'] = this.questions [index] is not currently selected. / / if the problem is wrong and ret ['item_false_active'] = this.questions [index] is currently selected. / / if it is an undone topic, but ret ['item_undo'] = this.questions [index] is not currently selected. / / if it is an undone topic and ret ['item_undo_active'] = this.questions [index] is currently selected. Return ret}

This function is mainly used to calculate the style of each small circle on the selection panel. At each step, getter is performed on the questions. At first glance, there seems to be no problem, but since I have seen the source code of Vue before, I feel wrong after thinking about it.

First of all, webpack will convert the template of the .vue file into the render function, that is, when the component is instantiated, it is actually the process of evaluating the responsive attribute, so that the responsive attribute can add renderWatcher to the dependency, so when the responsive property changes, it can trigger the component to re-render.

Let's first understand what the concept of renderWatcher is. First of all, there are three kinds of watcher in the source code of Vue. Let's just look at the definition of renderWatcher.

/ / at vue/src/core/instance/lifecycle.jsnew Watcher (vm, updateComponent, noop, {before () {if (vm._isMounted) {callHook (vm, 'beforeUpdate')}, true / * isRenderWatcher * /) updateComponent = () = > {vm._update (vm._render (), hydrating)} / / at vue/src/core/instance/render.jsVue.prototype._render = function (): VNode {. Const {render, _ parentVnode} = vm.$options try {vnode = render.call (vm._renderProxy, vm.$createElement)} catch (e) {. } return vnode}

Analyze the process a little bit: when instantiating a Vue instance, you will go to options to get the render function generated by template compilation, and then execute renderWatcher to collect dependencies. _ render returns the vnode of the component, passing in the _ update function to execute the patch of the component, resulting in a view.

Secondly, from the analysis of the template I wrote, in order to render the DOM of the selection panel, there are two layers of for loops, each of which executes the getItemClass function, and the interior of the function evaluates the responsive array of questions by getter. At present, the time complexity is O (n ²). As shown in the figure above, we have about 2000 topics, and we assume that there are 10 chapters, each chapter has 200 topics. Within the getItemClass, the questions has been evaluated six times, so the calculation is roughly about 12000. According to the execution speed of js, it is impossible to be so slow.

So does the problem arise from the complexity of O (n ³) in the process of getter questions?

So, I opened the source code of Vue, and because I had studied the source code deeply before, I easily found the part of vue/src/core/instance/state.js that converts data to getter/setter.

Function initData (vm: Component) {. / / observe data observe (data, true / * asRootData * /)}

The response that defines the data of a component starts with the observe function, which is defined in vue/src/core/observer/index.js.

Export function observe (value: any, asRootData:? boolean): Observer | void {if (! isObject (value) | | value instanceof VNode) {return} let ob: Observer | void if (hasOwn (value) '_ ob__') & & value.__ob__ instanceof Observer) {ob = value.__ob__} else if (shouldObserve & &! isServerRendering () & & (Array.isArray (value) | | isPlainObject (value)) & & Object.isExtensible (value) & &! value._isVue) {ob = new Observer (value)} if (asRootData & & ob) {ob.vmCount++} return ob}

The observe function accepts objects or arrays and instantiates the Observer class internally.

Export class Observer {value: any; dep: Dep; vmCount: number Constructor (value: any) {this.value = value this.dep = new Dep () this.vmCount = 0 def (value,'_ ob__', this) if (Array.isArray (value)) {if (hasProto) {protoAugment (value, arrayMethods)} else {copyAugment (value, arrayMethods) ArrayKeys)} this.observeArray (value)} else {this.walk (value)}} walk (obj: Object) {const keys = Object.keys (obj) for (let I = 0 I < keys.length; items +) {defineReactive (obj, keys [I])}} observeArray (items: Array) {for (let I = 0, l = items.length; I < l; items +) {observe (items [I])}

The constructor of Observer simply declares the dep and value attributes and points the _ ob _ attribute of value to the current instance. Take a chestnut:

/ / the initial options export default {data: {msg: 'message', arr: [1], item: {text: 'text'} / / when instantiating vm Become the following data: {msg: 'message', arr: [1, _ _ ob__: {value:..., dep: new Dep (), vmCount:...}], item: {text: 'text', _ _ ob__: {value:..., dep: new Dep (), vmCount:...}} _ _ ob__: {value:..., dep: new Dep (), vmCount:...}}

That is, after each object or array is observe, there is an extra _ ob _ attribute, which is an instance of Observer. So what's the significance of doing this? we'll analyze it later.

Continue to analyze the following parts of the Observer constructor:

/ / if it is an array, first tamper with some methods of the array (push,splice,shift, etc.) to enable it to support responsive if (Array.isArray (value)) {if (hasProto) {protoAugment (value, arrayMethods)} else {copyAugment (value, arrayMethods, arrayKeys)} / array elements or arrays or objects, recursively call the observe function Make it a responsive data this.observeArray (value)} else {/ / traversal object, so that each of its key values can also become responsive data this.walk (value)} walk (obj: Object) {const keys = Object.keys (obj) for (let I = 0 I < keys.length; itemPlus) {/ / convert the key value of the object to getter / setter, / / getter collection dependency / / setter notifies watcher to update defineReactive (obj, keys [I])}} observeArray (items: Array) {for (let I = 0, l = items.length; I < l; items +) {observe (items [I])}}

First of all, call initData,initData in initState to get the user-configured data object and then call the observe,observe function to instantiate the Observer class. In its constructor, first point the _ ob _ attribute of the object to the Observer instance (this step is to detect that a responsive foreshadowing can be triggered after adding or deleting attributes to the object), then iterate through the key value of the current object and call defineReactive to convert it into getter / setter.

So, let's analyze defineReactive.

/ / if it is an array, first tamper with some methods of the array (push,splice,shift, etc.) to enable it to support responsive if (Array.isArray (value)) {if (hasProto) {protoAugment (value, arrayMethods)} else {copyAugment (value, arrayMethods, arrayKeys)} / array elements or arrays or objects, recursively call the observe function Make it a responsive data this.observeArray (value)} else {/ / traversal object, so that each of its key values can also become responsive data this.walk (value)} walk (obj: Object) {const keys = Object.keys (obj) for (let I = 0 I < keys.length; itemPlus) {/ / convert the key value of the object to getter / setter, / / getter collection dependency / / setter notifies watcher to update defineReactive (obj, keys [I])}} observeArray (items: Array) {for (let I = 0, l = items.length; I < l; items +) {observe (items [I])}}

First, we can see from defineReactive that each responsive property has an instance of Dep, which is used to collect watcher. Because both getter and setter are functions and refer to dep, closures are formed, and dep is always in memory. Therefore, if you use the responsive attribute a when rendering the component, you will go to the above statement 1. The dep instance will collect the component renderWatcher, because when an is assigned to setter, dep.notify () will be called to notify renderWatcher to update, thus triggering a new round of watcher for responsive data collection.

So what exactly are statements 2 and 3 for?

Let's give a chestnut analysis.

{{person}} export default {data () {return {person: {name: 'Zhang San', age: 18}} this.person.gender = 'male' / / component view will not be updated

Because Vue cannot detect the added properties of an object, there is no time to trigger an update of renderWatcher.

To do this, Vue provides an API, this.$set, which is an alias for Vue.set.

Export function set (target: Array | Object, key: any, val: any): any {if (Array.isArray (target) & & isValidArrayIndex (key)) {target.length = Math.max (target.length, key) target.splice (key, 1) Val) return val} if (key in target & &! (key in Object.prototype)) {target [key] = val return val} const ob = (target: any). _ _ ob__ if (target._isVue | | (ob & & ob.vmCount)) {process.env.NODE_ENV! = 'production' & & warn (' Avoid adding reactive properties to a Vue instance or its root $data'+'at runtime-declare it upfront in the data option.') return Val} if (! ob) {target [key] = val return val} defineReactive (ob.value Key, val) ob.dep.notify () return val}

The set function takes three arguments, the first of which can be Object or Array, and the rest key and value, respectively. What if you use this API to add an attribute to person?

This.$set (this.person, 'gender',' male') / / component view re-render

Why can re-rendering be triggered by the set function? Notice this sentence, ob.dep.notify (), where does ob come from, then you have to go back to the previous observe function, in fact, data becomes like this after observe processing.

{person: {name: 'Zhang San', age: 18, _ _ ob__: {value:..., dep: new Dep ()}}, _ _ ob__: {value:..., dep: new Dep ()}} / / as long as it is an object, the _ _ ob__ attribute is defined, which is an instance of Observer class.

From the template point of view, the view depends on the attribute value of person. RenderWatcher is collected into the Dep instance of the person property, corresponding to statement 1 defined by the defineReactive function. At the same time, the function of statement 2 is to collect renderWatcher into person._ ob _. Dep, so when adding attributes to person, calling the set method can get person._ ob _ .dep and trigger renderWatcher updates.

Then it is concluded that the function of statement 2 is to detect the addition and deletion of attributes in the case that the responsive data is an object and cause re-rendering.

Take another chestnut to explain the function of sentence 3.

{{books}} export default {data () {return {books: [{id: 1, name: 'js'}]}

Because the component evaluates the books, which is an array, it goes to the logic of statement 3.

If (Array.isArray (value)) {/ / statement 3 dependArray (value)} function dependArray (value: Array) {for (let e, I = 0, l = value.length; I < l; iSuppli +) {e = value [I] e & e.simplified obliteration _ & e.__ob__.dep.depend () if (Array.isArray (e)) {dependArray (e)}

Logically, each item of the loop books, if the item is an array or object, gets item._ ob _ .dep and collects the current renderWatcher into the dep.

What would have happened without this sentence? Consider the following:

This.$set (this.books [0], 'comment',' awesome') / / does not trigger component updates

If it is understood that renderWatch does not evaluate this.books [0], so changing it does not require component updates, then this understanding is wrong. The correct thing is that because an array is a collection of elements, any internal changes need to be reflected, so statement 3 is to collect renderWatcher into every item._ ob _. Dep within the array when renderWatcher evaluates the array, so that whenever there is an internal change, you can get the renderWatcher through dep and inform it of the update.

Then combined with my business code, the analysis shows that the problem occurs in statement 3.

{{item.secName}} {{index + item.startIndex + 1}} getItemClass (index) {const ret = {} / / if it is the right topic, but ret ['item_true'] = this.questions [index] is not currently selected. / / if it is the right topic and ret ['item_true_active'] = this.questions [index] is currently selected. / / if the problem is wrong, but ret ['item_false'] = this.questions [index] is not currently selected. / / if the problem is wrong and ret ['item_false_active'] = this.questions [index] is currently selected. / / if it is an undone topic, but ret ['item_undo'] = this.questions [index] is not currently selected. / / if it is an undone topic and ret ['item_undo_active'] = this.questions [index] is currently selected. Return ret}

First of all, cardData is a grouped data, and there is a loop inside the loop. Assuming that there are 10 chapters with 200 topics in each chapter, then the getItemClass function will actually be executed 2000 times, getItemClass will evaluate questions 6 times, each time it will go to dependArray, and each time dependArray will loop 2000 times, so it is roughly estimated that 2000 * 6 * 2000 = 2400 times. If you assume that there are 4 statements executed once, then the statements will be executed nearly 100 million times. The performance is naturally in-situ explosion!

Now that the cause has been analyzed from the source, it is necessary to find a way to solve the problem from the source.

Split component

Many people understand that splitting components is for reuse, and of course it's more than that. Splitting components is more about maintainability and semantics. When colleagues see your component name, they can probably guess the functions inside. On the other hand, I split the components here to isolate component rendering caused by irrelevant responsive data. As can be seen from the image above, whenever any responsive data changes, Paper will re-render. For example, when I click the favorites button, the Paper component will re-render, as long as the DOM of the favorites button is rerouted.

In nested loops, do not use functions

The reason for the performance problem is that I used getItemClass to calculate the style of each small circle, and questions was evaluated in the function, so the time complexity changed from O (n ²) to O (n ³) (because the dependArray of the source code will also cycle). In the final solution, I abandoned the getItemClass function and directly changed the data structure of cardData's tids to tInfo, that is, calculating the style when constructing the data.

This.cardData = [{startIndex: 0, secName: 'chapter name', secId: 'chapter id', tInfo: [{id: 1, klass:' item_false'}, {id: 2, klass: 'item_false_active'}]}]

In this way, there will be no problem of O (n ³) time complexity.

Make good use of cach

I found that the writing in getItemClass is not very good. In fact, I should use a variable to cache quesions, so that it will not evaluate questions many times, and then go to the dependArray of the source code many times.

Const questions = this.questions// good / / bad// questions [0] this.questions [0] / / questions [1] this.questions [1] / / questions [2] this.questions [2]. / / the former will only evaluate this.questions once, while the latter will evaluate more than three times. Thank you for reading the article "sample Analysis of dig Array for Vue performance Optimization". Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.