ツリーを揺るがすパフォーマンスの最適化の実践 - 原理記事

木揺れている何A.

まず見て初心をツリーを揺るがします

図は、フロントエンドが少ないコード「シェイク」アウトを使用する当社のJSファイルを、「振る」によってツールとして理解することができる上記ツリーを揺るがす、ツリーを揺るがす記事の画像の意図を説明し、パフォーマンスがあります最適化のカテゴリ。具体的には、WebPACKのプロジェクトでは、エントリー文書、木の幹の同等があり、多くのエントリファイルは、モジュール、枝の同等の依存関係があります。実際には、特定のモジュールに依存して、実際には、これらの機能のいくつかを、使用しても。木振ることによって、モジュールが使用することを振り払うしないので、不要なコードを削除する目的を達成するために。

木揺れ以前Rich_Harrisでロールアップを実現し、後で、webpack2もツリー揺れ機能を増加させました。実際には、以前、閉鎖コンパイラをグーグルも同様のことを行って。使い方は公式サイトのドキュメントを知ってもらうことができ、3種類のツールを使用することの効果は、3つの効果のコントラストは、後に詳述します。

木の揺れのII。原理

ツリーは、揺れの性質は、無用のjsコードを排除することです。広範な従来のプログラミング言語コンパイラのデッドコードの除去は、コンパイラはいくつかのコードが出力には影響しないかを決定し、その後、これらのコードを排除することができます、と呼ばれるDCE（デッドコード削除）。

木揺れDCEの新しい実装で、Javascriptが伝統的な違いと言語をプログラミングすることはそう、ネットワークを介してロードしてから実行する例javascriptの必要性の大部分は、小さいファイルサイズがロードされ、全体の実行時間が短くなるということですファイルサイズを小さくするためにデッドコードを削除し、それがJavaScriptに多くの意味があります。

木揺れや伝統的な方法とDCE同じではありません、伝統的なDCEは、コードを排除し、実行することができない、と木揺れ建物はより使用されていないコードの排除を懸念しています。DCEと木揺れに関する次の詳細。

DCEで（1）最初の外観は大法を排除します

Dead Code 一般具有以下几个特征

•代码不会被执行，不可到达

•代码执行的结果不会被用到

•代码只会影响死变量（只写不读）

下面红框标示的代码就属于死码，满足以上特征

图4

传统编译型的语言中，都是由编译器将Dead Code从AST（抽象语法树）中删除，那javascript中是由谁做DCE呢？

首先肯定不是浏览器做DCE，因为当我们的代码送到浏览器，那还谈什么消除无法执行的代码来优化呢，所以肯定是送到浏览器之前的步骤进行优化。

其实也不是上面提到的三个工具，rollup，webpack，cc做的，而是著名的代码压缩优化工具uglify，uglify完成了javascript的DCE，下面通过一个实验来验证一下。

以下所有的示例代码都能在我们的github中找到，欢迎戳❤

github.com/lin-xi/tree…

分别用rollup和webpack将图4中的代码进行打包

图5

中间是rollup打包的结果，右边是webpack打包的结果

可以发现，rollup将无用的代码foo函数和unused函数消除了，但是仍然保留了不会执行到的代码，而webpack完整的保留了所有的无用代码和不会执行到的代码。

分别用rollup + uglify和 webpack + uglify 将图4中的代码进行打包

图6

中间是配置文件，右侧是结果

可以看到右侧最终打包结果中都去除了无法执行到的代码，结果符合我们的预期。

(2) 再来看一下Tree-shaking消除大法

前面提到了tree-shaking更关注于无用模块的消除，消除那些引用了但并没有被使用的模块。

先思考一个问题，为什么tree-shaking是最近几年流行起来了？而前端模块化概念已经有很多年历史了，其实tree-shaking的消除原理是依赖于ES6的模块特性。

ES6 module 特点：

只能作为模块顶层的语句出现
import 的模块名只能是字符串常量
import binding 是 immutable的

ES6模块依赖关系是确定的，和运行时的状态无关，可以进行可靠的静态分析，这就是tree-shaking的基础。

所谓静态分析就是不执行代码，从字面量上对代码进行分析，ES6之前的模块化，比如我们可以动态require一个模块，只有执行后才知道引用的什么模块，这个就不能通过静态分析去做优化。

这是 ES6 modules 在设计时的一个重要考量，也是为什么没有直接采用 CommonJS，正是基于这个基础上，才使得 tree-shaking 成为可能，这也是为什么 rollup 和 webpack 2 都要用 ES6 module syntax 才能 tree-shaking。

我们还是通过例子来详细了解一下

面向过程编程函数和面向对象编程是javascript最常用的编程模式和代码组织方式，从这两个方面来实验：

函数消除实验
类消除实验

先看下函数消除实验

utils中get方法没有被使用到，我们期望的是get方法最终被消除。

注意，uglify目前不会跨文件去做DCE，所以上面这种情况，uglify是不能优化的。

先看看rollup的打包结果

完全符合预期，最终结果中没有get方法

再看看webpack的结果

也符合预期，最终结果中没有get方法

可以看到rollup打包的结果比webpack更优化

函数消除实验中，rollup和webpack都通过，符合预期

再来看下类消除实验

增加了对menu.js的引用，但其实代码中并没有用到menu的任何方法和变量，所以我们的期望是，最终代码中menu.js里的内容被消除

main.js

menu.js

rollup打包结果

包中竟然包含了menu.js的全部代码

webpack打包结果

包中竟然也包含了menu.js的全部代码

类消除实验中，rollup，webpack 全军覆没，都没有达到预期

what happend？

这跟我们想象的完全不一样啊？为什么呢？无用的类不能消除，这还能叫做tree-shaking吗？我当时一度怀疑自己的demo有问题，后来各种网上搜索，才明白demo没有错。

下面摘取了rollup核心贡献者的的一些回答：

图7

rollup只处理函数和顶层的import/export变量，不能把没用到的类的方法消除掉
javascript动态语言的特性使得静态分析比较困难
图7下部分的代码就是副作用的一个例子，如果静态分析的时候删除里run或者jump，程序运行时就可能报错，那就本末倒置了，我们的目的是优化，肯定不能影响执行

再举个例子说明下为什么不能消除menu.js，比如下面这个场景

function Menu() {
}

Menu.prototype.show = function() { } Array.prototype.unique = function() { // 将 array 中的重复元素去除 } export default Menu; 复制代码

如果删除里menu.js，那对Array的扩展也会被删除，就会影响功能。那也许你会问，难道rollup，webpack不能区分是定义Menu的proptotype 还是定义Array的proptotype吗？当然如果代码写成上面这种形式是可以区分的，如果我写成这样呢？

function Menu() {
}

Menu.prototype.show = function() { } var a = 'Arr' + 'ay' var b if(a == 'Array') { b = Array } else { b = Menu } b.prototype.unique = function() { // 将 array 中的重复元素去除 } export default Menu; 复制代码

这种代码，静态分析是分析不了的，就算能静态分析代码，想要正确完全的分析也比较困难。

更多关于副作用的讨论，可以看这个

Tree shaking class methods · Issue #349 · rollup/rollupgithub.com

tree-shaking对函数效果较好

函数的副作用相对较少，顶层函数相对来说更容易分析，加上babel默认都是"use strict"严格模式，减少顶层函数的动态访问的方式，也更容易分析

我们开始说的三个工具，rollup和webpack表现不理想，那closure compiler又如何呢？

将示例中的代码用cc打包后得到的结果如下：

天啊，这不就是我们要的结果吗？完美消除所有无用代码的结果，输出的结果非常性感

closure compiler， tree-shaking的结果完美！

可是不能高兴得太早，能得到这么完美结果是需要条件的，那就是cc的侵入式约束规范。必须在代码里添加这样的代码，看红线框标示的

google定义一整套注解规范Annotating JavaScript for the Closure Compiler，想更多了解的，可以去看下官网。

侵入式这个就让人很不爽，google Closure Compiler是java写的，和我们基于node的各种构建库不可能兼容（不过目前好像已经有nodejs版 Closure Compiler），Closure Compiler使用起来也比较麻烦，所以虽然效果很赞，但比较难以应用到项目中，迁移成本较大。

说了这么多，总结一下：

三大工具的tree-shaking对于无用代码，无用模块的消除，都是有限的，有条件的。closure compiler是最好的，但与我们日常的基于node的开发流很难兼容。

tree-shaking对web意义重大，是一个极致优化的理想世界，是前端进化的又一个终极理想。

理想是美好的，但目前还处在发展阶段，还比较困难，有各个方面的，甚至有目前看来无法解

决的问题，但还是应该相信新技术能带来更好的前端世界。

优化是一种态度，不因小而不为，不因艰而不攻。

知识有限，如果错误，请不惜指正，谢谢

下一篇将继续介绍 Tree-Shaking性能优化实践 - 实践篇

本文中示例代码都能在我们的github中找到，欢迎戳❤

lin-xi/treeshakinggithub.com