kangyana
commented
1 year ago 3. 优化解析时间 - 开启多进程打包
运行在 Node.js 之上的 webpack 是单线程模式的，也就是说，webpack 打包只能逐个文件处理， 当 webpack 需要打包大量文件时，打包时间就会比较漫长。
1. thread-loader（webpack4 官方推荐）
把这个 loader 放置在其他 loader 之前，
放置在这个 loader之后的 loader 就会在一个单独的 worker【worker pool】 池里运行，
一个 worker 就是一个 nodeJS 进程【node.js proces】，
每个单独进程处理时间上限为600ms，各个进程的数据交换也会限制在这个时间内。
thread-loader 使用起来也非常简单，只要把 thread-loader 放置在其他 loader 之前， 那 thread-loader 之后的 loader 就会在一个单独的 worker 池(worker pool)中运行。
module.exports = {
// ...
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
// 创建一个 js worker 池
use: [
'thread-loader',
'babel-loader'
]
},
{
test: /\.s?css$/,
exclude: /node_modules/,
// 创建一个 css worker 池
use: [
'style-loader',
'thread-loader',
{
loader: 'css-loader',
options: {
modules: true,
localIdentName: '[name]__[local]--[hash:base64:5]',
importLoaders: 1
}
},
'postcss-loader'
]
}
// ...
]
// ...
}
// ...
}注意：thread-loader 放在了 style-loader 之后，这是因为 thread-loader 后的 loader 没法存取文件也没法获取 webpack 的选项设置。
官方上说每个 worker 大概都要花费 600ms ，所以官方为了防止启动 worker 时的高延迟，提供了对 worker 池的优化：预热：
// ...
const threadLoader = require('thread-loader');
const jsWorkerPool = {
// options
// 产生的 worker 的数量，默认是 (cpu 核心数 - 1)
// 当 require('os').cpus() 是 undefined 时，则为 1
workers: 2,
// 闲置时定时删除 worker 进程
// 默认为 500ms
// 可以设置为无穷大， 这样在监视模式(--watch)下可以保持 worker 持续存在
poolTimeout: 2000
};
const cssWorkerPool = {
// 一个 worker 进程中并行执行工作的数量
// 默认为 20
workerParallelJobs: 2,
poolTimeout: 2000
};
threadLoader.warmup(jsWorkerPool, ['babel-loader']);
threadLoader.warmup(cssWorkerPool, ['css-loader', 'postcss-loader']);
module.exports = {
// ...
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
use: [
{
loader: 'thread-loader',
options: jsWorkerPool
},
'babel-loader'
]
},
{
test: /\.s?css$/,
exclude: /node_modules/,
use: [
'style-loader',
{
loader: 'thread-loader',
options: cssWorkerPool
},
{
loader: 'css-loader',
options: {
modules: true,
localIdentName: '[name]__[local]--[hash:base64:5]',
importLoaders: 1
}
},
'postcss-loader'
]
}
// ...
]
// ...
}
// ...
}注意：请仅在耗时的 loader 上使用。
2. HappyPack
注意：包作者推荐使用 thread-loader，并宣布将不再继续维护 happypack，所以不推荐使用它。
在 webpack 构建过程中，实际上耗费时间大多数用在 loader 解析转换以及代码的压缩中，
HappyPack 可利用多进程对文件进行打包(默认cpu核数-1)，对多核cpu利用率更高。
HappyPack 可以让 webpack 同一时间处理多个任务，发挥多核 CPU 的能力，
将任务分解给多个子进程去并发的执行，子进程处理完后，再把结果发送给主进程。
Happypack 的处理思路是将原有的 webpack 对 loader 的执行过程从单一进程的形式扩展多进程模式，原本的流程保持不变。
使用 HappyPack 也有一些限制，它只兼容部分主流的 loader，具体可以查看官方给出的 兼容性列表。
const path = require('path')
const webpack = require("webpack");
const HappyPack = require('happypack'); // 多进程loader
// node 提供的系统操作模块
const os = require('os');
// 构造出共享进程池，根据系统的内核数量，指定进程池个数，也可以其他数量
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
const createHappyPlugin = (id, loaders) => new HappyPack({
// 用唯一的标识符 id 来代表当前的 HappyPack 是用来处理一类特定的文件
id: id,
// 如何处理 .js 文件，用法和 Loader 配置中一样
loaders: loaders,
// 其它配置项(可选)
// 代表共享进程池，即多个 HappyPack 实例都使用同一个共享进程池中的子进程去处理任务，以防止资源占用过多
threadPool: happyThreadPool,
// 是否允许 HappyPack 输出日志，默认是 true
verbose: true
// threads：代表开启几个子进程去处理这一类型的文件，默认是3个，类型必须是整数
});
const clientWebpackConfig = {
// ...
module: {
rules: [
{
test: /\.(js|jsx)$/,
// 把对 .js .jsx 文件的处理转交给 id 为 happy-babel 的 HappyPack 实例
use: ["happypack/loader?id=happy-babel"],
// 排除 node_modules 目录下的文件
// node_modules 目录下的文件都是采用的 ES5 语法，没必要再通过 Babel 去转换
exclude: /node_modules/,
}
]
},
// ...
plugins: [
createHappyPlugin('happy-babel', [{
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env', "@babel/preset-react"],
plugins: [
["import", { "libraryName": "antd", "style": true }],
['@babel/plugin-proposal-class-properties',{loose:true}]
],
cacheDirectory: true,
// Save disk space when time isn't as important
cacheCompression: true,
compact: true,
}
}]),
// ...
]
}注意，当项目较小时，多进程打包反而会使打包速度变慢。
1. 分析打包速度
优化 webpack 构建速度的第一步是知道将精力集中在哪里。 我们可以通过
speed-measure-webpack-plugin测量你的 webpack 构建期间各个阶段花费的时间：每一个项目，都有自己的打包性能问题，下面我们对打包的每一个环节进行优化。
2. 分析影响打包速度环节
打包就是从入口文件开始将所有的依赖模块打包到一个文件中的过程。 当然，在打包过程中涉及各种编译、优化过程。
打包过程中，常见影响构建速度的地方有哪些？
1. 开始打包，我们需要获取所有的依赖模块
搜索所有的依赖项，这需要占用一定的时间，即搜索时间，那么我们就确定了：
我们需要优化的第一个时间就是 搜索时间。
2. 解析所有的依赖模块（解析成浏览器可运行的代码）
webpack 根据我们配置的
loader解析相应的文件。 日常开发中我们需要使用loader对 js ，css ，图片，字体等文件做转换操作，并且转换的文件数据量也是非常大。 由于 nodejs 单线程的特性使得这些转换操作不能并发处理文件，而是需要一个个文件进行处理。我们需要优化的第二个时间就是 解析时间。
3. 将所有的依赖模块打包到一个文件
将所有解析完成的代码，打包到一个文件中，为了使浏览器加载的包更新（减小白屏时间），所以 webpack 会对代码进行优化。 JS 压缩是发布编译的最后阶段，通常 webpack 需要卡好一会，这是因为压缩 JS 需要先将代码解析成 AST 语法树，然后需要根据复杂的规则去分析和处理 AST，最后将 AST 还原成 JS，这个过程涉及到大量计算，因此比较耗时，打包就容易卡住。
我们需要优化的第三个时间就是 压缩时间。
4. 二次打包
当更改项目中一个小小的文件时，我们需要重新打包，所有的文件都必须要重新打包，需要花费同初次打包相同的时间，但项目中大部分文件都没有变更，尤其是第三方库。
我们需要优化的第四个时间就是 二次打包时间。