JavaScript 性能优化

前端工程师不但要保证完成界面的规划与开发,并且同时需要保证代码的质量,其中Javscript的运行速度则变得非常重要,此篇文章从工程师的角度入手,结合了开发者工具进行分析, 总结了一些常用的优化手段和法则.

分析执行时间

使用Chrome DevTools中的 Preformance 面板来分析 一个js库的执行时间。通常来说,一个轻量级的框架js框架(小于20k),它的解析速度最好是控制在10ms以内,如果一个库的解析时间大于16ms(1帧),则需要对他内部的执行函数进行性能分析。

使用Preformance之前需要注意三点

  1. 开始隐身模式 避免其他插件的分析数据和对浏览器造成的不必要的干扰
  2. Network面板中取消 Disable Cache 的选项,让JS文件尽量缓存在本地
  3. 多次反复提取测试数据,分析结果,减少获取信息的误差

捕捉分析数据:

《JavaScript 性能优化》

查看火焰图中对应脚本的Evalute Time, 脚本的评估时间:

《JavaScript 性能优化》

《JavaScript 性能优化》

通过Bottom-up选项卡,可以查看较为耗时的执行函数

有此图可以分析出,DOOM这个函数在ax.js 文件中被调用时,消耗的时间占比可高达10%,如果这个函数不是必须的, 或者可以被替代和优化的,需要对其进行进一步的修改和排查.

《JavaScript 性能优化》

除此之外需要注意的是,同时可通过Memory(Profile)面板来收集部分函数的执行周期对于内存的占用,从而进行对应的优化. 使用Memory面板的好处在于,你可以检测到单次执行某个操作时,所消耗的内存,跟踪到具体的Object,Array创建时所占用的内存, 单位是(byte)

《JavaScript 性能优化》

代码层面的优化手段

变量提升

这个优化层面,一般UglifyJS会在打包压缩的时候自动做,当然需要配置。一般来说,把需要使用的变量进行预先定义,又可以一定程度上优化执行的速度,例如如下一段代码:

// Normal 正常做法
for(var i=0,l=arr.length; i<l; i++){
    ...
}

// Better 最好可以
var i=0, l = arr.length;

for(; i<l; i++){
    ...
}

循环

从框架层面来讲,forEach不是一个很好的选择,对于2016年以及之前的JavaScript执行引擎来说,forEach的效率是明显低于使用纯for循环的效率,因为forEach每次执行时创建一个self-block的区域,会产生额外的消耗。当然,在目前的Chrome 60之后,forEach和for循环的性能差异已经被缩短到很小了。 不过依旧是for循环比较快. 这也就是为什么Lodash和Underscore都需要对循环进行封装的原因.

// Normal forEach
arr.forEach(function(val,index){
    ...
});

// Better
var i=0, l=arr.length, val;
for(;i<l;i++){
    val=arr[i];
    ...
}

直接访问arguments

直接访问arguments其实并没有什么问题,甚至直接作为另外一个函数的参数也是可行的,任何函数在执行时都会创建arguments类数组,这个是无法避免的,对arguments的转化往往会增大浏览器的负担

function a(){ }

// Bad
function b(){
    // const args = [ ...arguments ];  ES6
    var args = [].slice.call(arguments);
    a.apply(null,args);
}

// Better
// 不需要进行复制的时候直接传递arguments
function b(){
    a.apply(null,arguments);
}

// Better
// 直接访问可是最快的
// 当然了,arguments[1]最好是个有效值,而不是undefined
function c(){
    a.call(null,arguments[0],arguments[1])
}

数组的操作

直接访问数组的index往往比做 pop 或者 shift 要快得多. 同理,如果是添加数组元素,直接通过array[index]=val往往比push,更有效.很多时候,如果可以直接改变原数组就能得到需要的结果,就不要新建一个数组然后去push结果值


// Bad 取数组最后一位
arr.pop();

// Bad 等于创建了一个新的数组,没必要的情况下不需要这样干
arr = arr.map(function(item){
    return item+1;
})

// Better 直接取最快
arr[arr.length-1];

// Better 直接写入
var i=arr.length;
for(;i--;){
    arr[i] = arr[i]+1;
}

使用 eval 和 with

使用eval和with并没有不妥当, 当然慎用,多数场景下这两者用不上. 并且注意严格模式下的问题, 另外需要注意的是new Function 并没有能力代替eval, 因为eval在编译动态参数的时候,比new Function要简单直观的多

// 在严格模式下使用eval

'use strict';

var ev = eval;

ev(...);

加速Object的访问速度

通过 Object.freeze(obj), 可以对obj的访问进行加速, 这个优化仅限于Chrome, 另外,事先定义好构造函数所创建的的key,Chrome才会使用hide-class机制

// Bad
var a = function(){}

var b = new a();
b.x = 1;
b.y = 2;

// Better
var a = function(x,y){
    this.x = x;
    this.y = y;
}

var b = new a(1,2);
b.x = 3;
b.y = 4;

预先创建函数调用(createBounder)


// Bad
arr.forEach(function(item,index){
    ...
}.bind(this))

// Better
function a(item,index){
    ...
}

var fn = a.bind(this);

arr.forEach(fn);

优化的误区

错误1: 代码越短性能越好

很多人认为,代码库的体积越小,性能越好,, 其实这个认识绝对错误的, 例如很多框架打的招牌体积特别小,其实然并卵, 例如最典型的React的轮子, Preact, 这货吹捧的就是size比较小,然后同时兼容React API, 所谓性能优越? 那么我们来看看Slant上的评分, 看看老外怎么看: Slant React VS Preact, React以绝对的优势碾压,

再看看司徒正美是怎么评价的? 如何看待 React 的替代框架 Preact? 司徒正美的回答, 两者并不是一个量级的东西.

另外Preact的动态规划算法有React那么屌么? 答案是没有的,老外已经在issue里开喷

动态规划算法在React中的应用表现在最小差异更新,但是从issue来看,Preact 则是没有经过优化的二道贩子, React可是最短路径的精确更新,Preact是么?

另外,Google的工程师在2006年实现的 diff算法是 text diff 动态规划中目前实现最快的:

google-diff-match-patch

npm/diff-match-path js版本

当然,同类型的diff有没有? 有, 例如:

但是,你看看issue啊,体积小能代表性能好么? 最终还是会抄Google diff match patch的

kpdecker/jsdiff 看看issue

错误2: 模块加载器没有多大差别,webpack和requirejs差不多

如今很多工程已经迁移到webpack了,两种模块化的方案都可以解决问题, 但是两者存在本质的区别:

  1. 首先,Webapck的模块加载器在编译阶段就已经将依赖分析好了, 而RequireJS的依赖顺序需要在浏览器端才能得到解析,所以Webpack的调用速度比RequireJS要快,因为依赖都是按照索引存储在数组中的,全闭包贮存,通过id可以直接得到引用
  2. 即使webpackJsonp被修改,被攻击,也不影响现有的页面逻辑,照常执行,但是RequireJS 则在全局暴露了 define, require 等多个API,通过require甚至可以将定义的包导出,查看源码
  3. webpack 提供了从打包工具到模块化的一致性体验,而requirejs 打包则需要依赖rjs,并且不太容易和gulp等自动化工具进行整合
  4. 由于加载代码布局和全闭包贮存,webpack的打包在UglifyJS的压缩下变得更加彻底, 打包的体积更小
  5. loader 生态的问题

错误3: 算法越复杂,越高级,性能越好,效率越高

JavaScript 运行的场景和特殊性,决定了有些算法并不适用于js,从常用的排序算法来说, 快排(quick sort)和插入(insert sort)成为了js性能效率排序的首选,可以看benchmark:

sort test

所以每当有人面试问你排序算法的时候,我说我只记quick sort 和 insert sort, 因为测试过了,至于当对面问heap sort,merge sort…,我就会笑一笑,说明这个面试官对js根本不了解.

另外,关于Rob Pike给出的意见,值得一读,看看老怪物是怎么理解和建议的, 原文链接

Rob Pike 的 5 个编程原则

原则 1. 你没有办法预测每个程序的运行时间,瓶颈会出现在出乎意料的地方,所以在分析瓶颈原因之前,先不要盲目猜测。

原则 2. 测试(measure)。在测试之前不要优化程序,即使在测试之后也要慎重,除非一部分代码占据绝对比重的运行时间。

原则 3. 花哨的算法在 n 比较小时效率通常比较糟糕,而 n 通常是比较小的,并且这些算法有一个很大的常数。除非你确定 n 在变大,否则不要用花哨的算法。(即便 n 不变大,也要先遵循第 2 个原则。)

原则 4. 相对于朴素的算法来说,花哨的算法更容易出现Bug,更难调试。尽量使用朴素的算法和数据结构。

原则 5. 数据占主导地位(Data dominates)。如果你选择了正确的数据结构,并且已把事情组织好,那么算法的效率显而易见。编程的核心是数据结构是,不是算法。

Pike的第 1 条和第 2 条原则实际上重新强调了Tony Hoare那句名言,“过早的优化是万恶的根源”。Ken Thompson将Pike的第 3 条和第 4 条原则改写为“当遇到麻烦时,试试最简单粗暴的办法”,原则 3 和原则 4 也是 KISS 哲学的体现。Fred Brooks在《人月神话》中首先阐述了原则 5 ,原则 5 常常会被概括为“用最佳结构,写简单代码”。

优化执行顺序与代码体积

避免http请求,直接将js embed在页面中输出

这样的话,只要按照顺序的 vendor 和后续对js片段进行embed即可,效率比较高,但是会阻塞页面的加载,最好是embed在页面的尾部

使用 async 对加载进行优化 (推荐做法)

优先加载vendor, 将主要的js库和框架优先加载过来,其他的js逻辑,如果没有相互顺序的依赖,则可以使用async异步加载的做法,优化页面加载速度, 例如:

《JavaScript 性能优化》

通过Webpack-Bundle-Analyzer分析依赖的必要性

在使用Webpack作为主要构建工具的开发流程下,使用Bundle-Analyzer对打包进行分析,从而剔除一些不必要对库或者代码文件

《JavaScript 性能优化》

拆块引入

对于拆快引入的解释是,首先,一个库,一个插件,你可能只需要用到其中的某个部分,而不是整个包,那么拆块引入可以很大程度上减少代码体积,例如,引用react-virtualized插件,我们只需要用到其中的AutoSizer,和List模块,那么:


// Bad
import virtualized form 'react-virtualized';


// Better
// 只引用需要的,最小依赖原则
// 这样的做法减少接近50%的包体积
import AutoSizer from 'react-virtualized/dist/commonjs/AutoSizer'
import List from 'react-virtualized/dist/commonjs/List'

深度优化打包速度

通过cache 和 HappyPack的手段可充分利用cpu资源,加快打包速度,以往需要16s打包的代码4s完成,重新打包只需要2s. 如图:

不过相关的代码是我私人项目,所以暂不开源

《JavaScript 性能优化》

相关链接

BlueBrid-wiki/Optimization-killers

25 Techniques for Javascript Performance Optimization

Javascript 打破所有规则(break the rule)

老怪物Rob Pike 5个编程原则

    原文作者:算法小白
    原文地址: https://juejin.im/entry/59e6f1336fb9a0450808bdc3
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞