最小化layout的方案


上面提到的一个批量读写是一个，主要是因为获取一个需要计算的属性值导致的，那么哪些值是需要计算的呢？

这个链接里有介绍大部分需要计算的属性：http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html

再来看看别的情况：

面对一系列DOM操作

针对一系列DOM操作（DOM元素的增删改），可以有如下方案：

  • documentFragment

  • display: none

  • cloneNode

比如（仅以documentFragment为例）：


var fragment = document.createDocumentFragment();  

for (var i=0; i < items.length; i++){  

 var item = document.createElement("li");

 item.appendChild(document.createTextNode("Option " + i);

 fragment.appendChild(item);

}

list.appendChild(fragment);


这类优化方案的核心思想都是相同的，就是先对一个不在Render tree上的节点进行一系列操作，再把这个节点添加回Render tree，这样无论多么复杂的DOM操作，最终都只会触发一次layout。


面对样式的修改


针对样式的改变，我们首先需要知道并不是所有样式的修改都会触发layout，因为我们知道layout的工作是计算RenderObject的尺寸和大小信息，那么我如果只是改变一个颜色，是不会触发layout的。


这里有一个网站CSS triggers，详细列出了各个CSS属性对浏览器执行layout和paint的影响。


像下面这种情况，和上面讲优化的部分是一样的，注意下读写即可。

elem.style.height = "100px"; // mark invalidated  

elem.style.width = "100px";  

elem.style.marginRight = "10px";

elem.clientHeight // force layout here


但是要提一下动画，这边讲的是js动画，比如：

function animate (from, to) {  

 if (from === to) return

 requestAnimationFrame(function () {

   from += 5

   element1.style.height = from + "px"

   animate(from, to)

 })

}

animate(100, 500)

动画的每一帧都会导致layout，这是无法避免的，但是为了减少动画带来的layout的性能损失，可以将动画元素绝对定位，这样动画元素脱离文本流，layout的计算量会减少很多。

使用requestAnimationFrame

任何可能导致重绘的操作都应该放入requestAnimationFrame

在现实项目中，代码按模块划分，很难像上例那样组织批量读写。那么这时可以把写操作放在requestAnimationFrame的callback中，统一让写操作在下一次paint之前执行。


// Read

var h1 = element1.clientHeight;

// Write

requestAnimationFrame(function() {  

 element1.style.height = (h1 * 2) + 'px';

});

// Read

var h2 = element2.clientHeight;

// Write

requestAnimationFrame(function() {  

 element2.style.height = (h2 * 2) + 'px';

});

wKioL1bnWETyxqs4AADHNghKemg329.jpg

可以很清楚的观察到Animation Frame触发的时机，MDN上说是在paint之前触发，不过我估计是在js脚本交出控制权给浏览器进行DOM的invalidated check之前执行。


其他注意点


除了由于触发了layout而导致性能问题外，这边再列出一些其他细节：

缓存选择器的结果，减少DOM查询。这里要特别体下HTMLCollection。HTMLCollection是通过document.getElementByTagName得到的对象类型，和数组类型很类似但是每次获取这个对象的一个属性，都相当于进行一次DOM查询：


var divs = document.getElementsByTagName("div");  

for (var i = 0; i < divs.length; i++){  //infinite loop  

 document.body.appendChild(document.createElement("div"));

}


比如上面的这段代码会导致无限循环，所以处理HTMLCollection对象的时候要最些缓存。

另外减少DOM元素的嵌套深度并优化css，去除无用的样式对减少layout的计算量有一定帮助。

在DOM查询时，querySelector和querySelectorAll应该是最后的选择，它们功能最强大，但执行效率很差，如果可以的话，尽量用其他方法替代。

下面两个jsperf的链接，可以对比下性能。

https://jsperf.com/getelementsbyclassname-vs-queryselectorall/162

http://jsperf.com/getelementbyid-vs-queryselector/218

自己对View层的想法


上面的内容理论方面的东西偏多，从实践的角度来看，上面讨论的内容，正好是View层需要处理的事情。已经有一个库FastDOM来做这个事情，不过它的代码是这样的：


fastdom.read(function() {  

 console.log('read');

});

fastdom.write(function() {  

 console.log('write');

});


问题很明显，会导致callback hell，并且也可以预见到像FastDOM这样的imperative的代码缺乏扩展性，关键在于用了requestAnimationFrame后就变成了异步编程的问题了。要让读写状态同步，那必然需要在DOM的基础上写个Wrapper来内部控制异步读写，不过都到了这份上，感觉可以考虑直接上React了……


总之，尽量注意避免上面说到的问题，但如果用库，比如jQuery的话，layout的问题出在库本身的抽象上。像React引入自己的组件模型，用过virtual DOM来减少DOM操作，并可以在每次state改变时仅有一次layout，我不知道内部有没有用requestAnimationFrame之类的，感觉要做好一个View层就挺有难度的，之后准备学学React的代码。希望自己一两年后会过来再看这个问题的时候，可以有些新的见解。