Google Closure Compiler 高级模式及更多思考（转）-白红宇

Google Closure Compiler 高级模式及更多思考（转）

阅读量：5319 次

发布时间：2019-06-14

本文共 6141 字，大约阅读时间需要 20 分钟。

前言

　　是的一员，在 2009 年底被 Google 释出，早先，有的，主要就压缩率上进行了对比，另外有的，对 CC 的高级模式做了些介绍。

　　本文将详细介绍 CC 的高级模式部分，更重要的是，阐述 CC 高级模式背后的思考

　　CC 是真正的编译器

　　Closure Compiler 和 YUICompressor 并不是同类产品，虽然 CC 和 YC 同样产出压缩后的 JS 文件，但是 YC 只做了词法上的扫描，而 CC 并不只是一个 compressor 那么简单，器如其名，它是一个compiler。

　　对于一个 compiler，一般地，它需要做到：

检查源文本中语法、语义、语用上的错误；

根据分析产出物（符号表、语法树等）产出目标 / 中间代码；

优化。

　　代码错误一般来自三个方面：

语法（Syntax）

表示构成语言句子的各个记号之间的组合规律。大体上，parser / interpreter 在词法分析和语法分析阶段，产生符号表、语法树等分析产出物，具体见编译原理教科书……

语法上的错误，如：

doSomething(;) // SyntaxError: Unexpected token ;

根据语法规则，在非 for 语句中的 ; 意义是分隔符，而分隔符前的 ( 并没有配对)，因此报错。

语义（Semantics）

表示各个记号的特定含义（各个记号和记号所表示的对象之间的关系）。compiler 需要根据语义分析产出中间代码，对于不产生中间代码的语言如 JS，则在运行时的解释期间指出错误。

语义上的错误，如：

0 = {}; // ReferenceError: Invalid left-hand side in assignment

根据赋值运算符 = 的意义，左操作数不能为字面量，所以虽然这个赋值语句包含了必需的左操作数、运算符、右操作数，仍然出错。

语用（Pragmatics）

表示在各个记号所出现的行为中，它们的来源、使用和影响。

语用上的错误，如：

doSomething(); // ReferenceError: doSomething is not defined

在这里直接调用了一个未定义的函数，导致出错。在一些其他场景中，虽然程序运行正确无误，但是仍然可以优化（这种优化并不是技巧上的），比如：

function doSomethingElse() {}(function() { return; doSomethingElse(); // No Exception but Redundant: Unreachable code})();

　　在这里，doSomethingElse 函数之前由于有 return，因此这个函数调用将永远不能执行，这种冗余代码对整个程序来说毫无用处，可以去掉。

　　对于 Closure Compiler 来说，它处理的对象是 js，不需要产生其他中间代码或汇编代码 / 机器码，因此输出的还是 js，但是是经过分析的、优化后的 js；另外，它也可以选择输出 parse tree（使用–print_tree 参数），所以，CC 的确完成了一个编译器需要实现的功能。

　　CC 功能概述

　　在详细讨论 CC 的高级模式前，还是简明介绍一下功能体系。

　　编译级别

　　CC 的 compilation_level 包括三个级别：

WHITESPACE_ONLY

只删除空白、注释。

SIMPLE_OPTIMIZATIONS

在 WHITESPACE_ONLY 基础上将局部变量和参数转成短名称。

ADVANCED_OPTIMIZATIONS

更加激进的重命名、移除垃圾代码、内联函数。

　　可以看到，SIMPLE_OPTIMIZATIONS 级别的 CC，和 YC 无异，没做什么真正的编译工作，所以说，使用了高级模式的 CC 才是四肢健全的 CC 。

　　约束条件

　　使用 CC 有一定约束条件，这影响到我们的编码风格：

WHITESPACE_ONLY
- 不认可 JS 1.5 以上版本的语言特性
- 不保留注释

SIMPLE_OPTIMIZATIONS
- 完全禁用 with 和 eval
- 字符串中引用的函数名 / 参数名不会改动（CC 不改动所有字符串）

ADVANCED_OPTIMIZATIONS 模式下的约束放到下文详述

　　注解

　　Annotations 也是 CC 的重要组成部分，使用 JSDoc 风格，用以辅助高级模式下的编译，下文详述。

　　使用 CC 高级模式

　　在 CC 下，启用高级模式的方法是加入参数 --compilation_level ADVANCED_OPTIMIZATION。

　　作为一个 compiler，CC 的高级模式下，额外的优化政策是：

更激进的重命名，如 obj.property 改为 a.b，将深度过高的命名空间平坦化等；

移除垃圾代码，如删除未被调用的方法定义，警告逻辑死角（return 后的语句等）；

将函数内联，如 a call b, b call c，a()，那么直接执行 c()。

　　要达到高级模式的预期优化效果，开发者必须对自己做一些约束，因为 js 是弱类型、动态性的。否则

js 的这种灵活将使 compiler 无能为力。

　　总体上，这种约束包括限定某些 js 编码风格，以及使用相应的 JSDoc 注解。

　　以下详述具体的约束以及代码的检查 / 优化效果：

　　强类型的模拟

@param 和 @type 中定义的类型会在编译期间得到检查，同样避免了在运行时检查，提高性能。

@const 标记常量，当常量被写时会报错。

模拟枚举，将同类可枚举常量定义为一个对象字面量，使用 @enum 标记：

var STATUS = { LOADING: 3, COMPLETE: 4};

编译结果中 STATUS.LOADING 会被直接替换为 3，其实完全模拟了 C 等语言中的枚举。

使用 @constructor 标注函数为构造器，它仅能被实例化，而不可用作普通方法，甚至是工厂方法，CC 会确保构造器被合法使用，否则报错。这样确保开发者不必在运行时判断，构造器函数到底以怎样的形式被调用。

在表达式中也可以使用 @type 来限定类型，这对于 JSON 特别有用，如

var data = /** @type {UserModel} */({ firstName : 'foo', lastName : 'bar'});

在这里 UserModel 是个构造器，也可以使用 @typedef 来自定义复杂的数据类型。

　　域可见性的模拟

使用 @private 标注私有域，私有域被外部引用会报错。开发者也可以按照“国际惯例”给私有域加上_ 前缀或后缀，以提醒自己 / 协作者这是一个私有域，@private 注解用来告诉 CC；这样，开发者可以不必使用诸如老道的“模块模式”等技巧来真正地隐藏私有变量，将检查工作丢给CC，让开发尽可能朴实简单。

类似有 @protect

　　类系统的模拟

使用 @extends 标注继承关系，继承体系会被优化。

使用 @interface 标注接口，接口是类似 function ThisIsAInterface(obj) {}的函数体为空的构造器定义，编译后将移除其相关代码。同时，标注 @implements 的构造器必须实现implemented 的接口的所有方法（正如其他 OO 语言一样），否则，CC 报错。这同样简化了接口 / 实现的约束，靠 CC 来保证实现关系的可靠性。

　　条件编译的模拟

使用 @define 标记状态开关，适用于调试 logger 等开发 / 发布状态需要分离的模式。
可以在编译时指定参数来标识 define 参数的状态。这其实就是一个条件编译，真给力……

　　对象平坦化及属性名缩减

对象属性会被编译为单变量，比如 foo.bar to foo$bar，这种标记方法看起来很像 java 中被编译出来的内部类~~之后 foo$bar 被进一步缩短。对象之所以能被平坦化是因为在 js 中对象可以看做是一群引用 / 原始数据类型的容器。

但是，js 对象实际上更复杂，所以被平坦化后会带来一些副作用，比如如果在对象（字面量）中使用 this 指针，则编译后的结果会导致 this 指向错误。所以 Google 建议仅在 constructor 和 prototype methods 中使用 this，这意味着，在所谓类单例（对象字面量）和类的静态方法（绑定到constructor 上的函数）中都避免使用 this 指针。

在缩减对象属性 / 方法的名称长度时，有另外一个注意点，那就是必须始终使用 dot syntax（.运算符），而不使用 quoted string（[] 运算符），除非索引名是一个变量。这是因为 CC 始终不处理字符串中的内容，所以，var o = { longName: 0 }; o["longName"] 会被翻译为var a = { b: 0 }; a["longName"] 导致出错。实在想使用 quoted string，则在定义的时候也要使用 quoted string。

对于全局变量，如果出现以 window.property 的形式引用的，必须始终定义为 window.porperty 形式：

window.property = 1;var property = 1; // wrong!

否则也会杯具，CC 可不会 window.property 翻译为 window.a。

　　垃圾代码的移除

一个函数声明却未被调用时，默认地，声明体将被干掉。

在这种机制下，如果一个方法是以 for in 的形式调用的，那么原方法也会被干掉，因为这种动态特征使得 CC 无法清楚方法是否确实在 for in 的时候被调用了。

对于一些 unreachable 的代码，CC 将报警告。

如果要产出一份被调用的公共接口，例如库，使用称作 export 的方法将函数导出，防止函数定义被
CC 回收。具体的做法是将函数绑定到某个容器，比如：

function displayNoteTitle(note) { alert(note['myTitle']);}// Store the function in a global property referenced by a string:window['displayNoteTitle'] = displayNoteTitle;

对于需要 export 的函数，均使用 quoted string 风格。

　　背后的思考

　　根据以上高级模式优化的行为分析可知，CC 附加给开发者的约束主要有：

强制以强类型的静态语言风格编写 js，将关注点从运行时的动态技巧转移到组织代码、编写逻辑
本身。而可能由弱类型系统和动态特征产生的问题和风险则交给 CC，即通过开发者与 CC 达成一种

编码约定而规避掉。

严格要求区分面向开发者的代码和面向机器的代码。

虽然不像 C 等语言会编译产生目标代码，但是 CC 在一定程度上也生成了面向机器的 js，包括压缩空白、缩减标识符、条件编译和冗余代码去除。这和第一点其实是一脉相承的，同样要求开发者将关注点转移到开发本身。

使用规范化的接口方式。

这不仅包括要求开发者使用恰当的 annotation（extend, interface, …），同时也给整个 OO-JS 打下了一个框架，开发者必须使用同样的模式进行 OO 编码。另外，要求使用 export 技术统一导出公共接口更强化了这一点。总之，这一点进一步限定了开发者的编码风格，但是带来的好处是明显的：可读、可控、一致性。