google工具的Coverage代码覆盖率详解

如果某个文件覆盖率低（即未使用代码比例很高），通常意味着用户加载了太多不必要的代码（要么真的是无用代码，要么是当前时点还没执行到的代码），有性能常识的同学不难推断出，这会导致页面的完全加载时间、或单页应用的启动时间变慢，在慢速网络下的性能损耗会尤其明显；此外，更多代码的解析、编译也就意味着更多的硬件资源消耗，在低端设备上也会存在明显的性能问题。

在笔者看来，Coverage 数据至少能从下面 2 个方面指导我们进行 WEB 应用的优化：

除移死代码

以 Coverage 数据为参考，我们能了解页面重无用代码的比例到底有多大。现实世界中，很多工程师可能是在遗留代码库上工作，并且遗留代码库存在的时间还很长，那么很可能这个代码库中存在大量的无用代码，但是谁也不敢删除他们，因为 JS 这门语言的动态性，你不能粗暴的把哪些看起来“没有被使用”的代码直接删掉，除非你很清楚所有的代码执行路径，很显然这对于大型应用或者遗留代码库来说是不现实的。

怎么移除死代码呢？我们可以依赖打包工具，比如 UglifyJS 在压缩代码时支持直接删除死代码的配置项。而 Webpack 2 中引入了Tree Shaking 的特性，能够自动把项目中没有用到的代码从打包中去掉，但是这种优化仅限于被 export 的代码。总而言之，死代码要尽可能想办法去掉，Coverage 工具能提供一个判断基准。

懒加载代码

如果能删的死代码都删了，但是 Coverage 数据还是居高不下，那么你应该换个角度思考。就像前文所说，JS 是动态语言，可能部分代码在页面加载时并没有用到，但是用户后来的操作会触发这些代码的执行，为什么不让这些代码在需要的时候再加载呢？聪明的你可能已经想到了，这就是懒加载的技术。

使用 Webpack 打包且没有对配置做特别调优的话，它默认会把所有依赖打包成一个巨大的文件，很容易出现首次加载覆盖率很低的情况，在 Webpack 中实现懒加载可以参考 Code Splitting 和 bundle-loader，具体的配置细节这里不展开讲。使用懒加载之后可以极大的减少页面初次下载的代码，从而提高性能。需要注意的是，懒加载优化需要在模块数量和模块大小之间把握一个平衡，否则过多的模块懒加载反而对性能不利，因为每个 HTTP 请求也是有额外开销的。

全文请查看

转载：https://segmentfault.com/a/1190000009013738?utm_source=weekly&utm_medium=email&utm_campaign=email_weekly