从Mpx资源构建优化看splitChunks代码分割

背景

MPX是滴滴出品的一款增强型小程序跨端框架，其核心是对原生小程序功能的增强。具体的使用不是本文讨论的范畴，想了解更多可以去官网了解更多。

回到正题，使用MPX开发小程序有一段时间了，该框架对不同包之间的共享资源有一套自己的构建输出策略，其官网有这样一段描述说明：

总结关键的两点：

• 纯js资源：主包引用则输出主包，或者分包之间共享也输出到主包
• 非js资源，包括wxml、样式、图片等：主包引用则输出主包，分包之间共享则输出到各自分包

很好奇MPX内部是怎么做到上面这种效果的，尤其是js资源，于是就拜读了@mpxjs/webpack-plugin@2.6.61揭开其实现的细节。

mpx怎么实现的

首先简单介绍下MPX是怎么整合小程序离散化的文件结构，它基于webpack打包构建的，用户在Webpack配置中只需要配置一个入口文件app.mpx，它会基于依赖分析和动态添加entry的方式来整合小程序的离散化文件，，loader会解析json配置文件中的pages域和usingComponents域中声明的路径，通过动态添加entry的方式将这些文件添加到Webpack的构建系统当中，并递归执行这个过程，直到整个项目中所有用到的.mpx文件都加入进来。

重点来了，MPX在输出前，其借助了webpack的SplitChunksPlugin的能力将复用的模块抽取到一个外部的bundle中，确保最终生成的包中不包含重复模块。

js资源模块的输出

@mpxjs/webpack-plugin插件是MPX基于webapck构建的核心，其会在webpack所有模块构建完成的finishMoudles钩子中来实现构建输出策略，主要是配置SplitChunks的cacheGroup，后续webpack代码优化阶段会根据SplitChunks的配置来输出代码。

apply(compiler) {      ...     // 拿到webpack默认配置对象splitChunks     let splitChunksOptions = compiler.options.optimization.splitChunks     // 删除splitChunks配置后，webpack内部就不会实例化SplitChunkPlugin     delete compiler.options.optimization.splitChunks     // SplitChunkPlugin的实例化由mpx来接管,这样可以拿到其实例可以后续对其options进行修正     let splitChunksPlugin = new SplitChunksPlugin(splitChunksOptions)     splitChunksPlugin.apply(compiler)     ...          compilation.hooks.finishModules.tap('MpxWebpackPlugin', (modules) => {             // 自动跟进分包配置修改splitChunksPlugin配置             if (splitChunksPlugin) {               let needInit = false               Object.keys(mpx.componentsMap).forEach((packageName) => {                 if (!splitChunksOptions.cacheGroups.hasOwnProperty(packageName)) {                   needInit = true                   splitChunksOptions.cacheGroups[packageName] = getPackageCacheGroup(packageName)                 }               })               if (needInit) {                 splitChunksPlugin.options = SplitChunksPlugin.normalizeOptions(splitChunksOptions)               }            }     }) 

可以看出在所有模块构建完成时，针对不同的packageName来生成其对应的cacheGroups，主要体现在getPackageCacheGroup方法的实现。然后拿到SplitChunksPlugin实例的句柄，对其options进行重写规格化。

function isChunkInPackage (chunkName, packageName) {   return (new RegExp(`^${packageName}\/`)).test(chunkName) }  function getPackageCacheGroup (packageName) {   if (packageName === 'main') {     return {       name: 'bundle',       minChunks: 2,       chunks: 'all'     }   } else {     return {       test: (module, chunks) => {         return chunks.every((chunk) => {           return isChunkInPackage(chunk.name, packageName)         })       },       name: `${packageName}/bundle`,       minChunks: 2,       minSize: 1000,       priority: 100,       chunks: 'all'     }   } } 

getPackageCacheGroup会为小程序的每个包生成一个代码分割组，也就是生成每个包对应的cacheGroups。

例如一个小程序项目有主包和A、B两个分包，其生成的cacheGroups内容如下：

{   default: {     automaticNamePrefix: '',     reuseExistingChunk: true,     minChunks: 2,     priority: -20   },   vendors: {     automaticNamePrefix: 'vendors',     test: /[\/]node_modules[\/]/,     priority: -10   },   main: { name: 'bundle', minChunks: 2, chunks: 'all' },   A: {     test: [Function: test],     name: 'A/bundle',     minChunks: 2,     minSize: 1000,     priority: 100,     chunks: 'all'   },   B: {     test: [Function: test],     name: 'B/bundle',     minChunks: 2,     minSize: 1000,     priority: 100,     chunks: 'all'   } 

分包代码分割输出bundle的优先级是最高的（priority: 100），所以会优先处理分包中的打包；否则会执行main中的代码打包规则，它会处理所有包之间的共享模块的打包以及主包中被复用的模块。

下面来看分包和主包的打包规则。

1、针对分包中的模块:

{   test: (module, chunks) => {     // 依赖当前模块的所有chunks是否都是当前分包下的chunk     return chunks.every((chunk) => {       return isChunkInPackage(chunk.name, packageName)     })   },   name: `${packageName}/bundle`,   minChunks: 2,   minSize: 1000,   priority: 100,   chunks: 'all' } 

分包中的模块被抽离到当前分包下的bundle文件中，需满足：

• 该模块没有被其他包引用，包括主包和其他分包（test函数逻辑）
• 至少被该分包下的2个chunk引用（minChunks:2）
• 抽离后的bundle大小最少满足 约1kb（minSize: 1000）

2、针对主包中的模块：

{   name: 'bundle',   minChunks: 2,   chunks: 'all' } 

会抽取到主包的bundle文件的条件：

• 该模块至少被2个chunk引用（minChunks:2），这个chunk不区分主分包中的chunk

3、针对分包间共享的模块：

分包间共享的模块，不满足SplitChunks为每个分包设置的分包独享规则，即该模块只在当前分包引用，没有在其他包中被引用过。

test: (module, chunks) => {     return chunks.every((chunk) => {       return isChunkInPackage(chunk.name, packageName)     }) } 

所以，最终会走到main的cacheGroup的打包规则中，也就是主包的打包规则中。

这样，MPX通过配置SplitChunksOptions.cacheGroups来实现将主包中的js模块和分包共享的js模块都输出到主包，分包单独引用的模块输出到当前分包下。

组件和静态资源

对于组件和静态资源，MPX在webpack构建的thisCompilation钩子函数中会在compilation上挂载一个有关打包的__mpx__对象，包含静态资源、组件资源、页面资源等属性，也包含静态的非js资源的输出处理等：

compiler.hooks.thisCompilation.tap('MpxWebpackPlugin', (compilation, { normalModuleFactory }) => {     ...     if (!compilation.__mpx__) {         mpx = compilation.__mpx__ = {              ...              componentsMap: {                 main: {}               },               // 静态资源(图片，字体，独立样式)等，依照所属包进行记录，冗余存储，同上               staticResourcesMap: {                 main: {}               },               ...               // 组件和静态资源的输出规则如下：               // 1. 主包引用的资源输出至主包               // 2. 分包引用且主包引用过的资源输出至主包，不在当前分包重复输出               // 3. 分包引用且无其他包引用的资源输出至当前分包               // 4. 分包引用且其他分包也引用过的资源，重复输出至当前分包           getPackageInfo: ({ resource, outputPath, resourceType = 'components', warn }) => {             let packageRoot = ''             let packageName = 'main'             const { resourcePath } = parseRequest(resource)             const currentPackageRoot = mpx.currentPackageRoot             const currentPackageName = currentPackageRoot || 'main'             const resourceMap = mpx[`${resourceType}Map`]             const isIndependent = mpx.independentSubpackagesMap[currentPackageRoot]             // 主包中有引用一律使用主包中资源，不再额外输出             if (!resourceMap.main[resourcePath] || isIndependent) {               packageRoot = currentPackageRoot               packageName = currentPackageName               ...             }             resourceMap[packageName] = resourceMap[packageName] || {}             const currentResourceMap = resourceMap[packageName]              let alreadyOutputed = false             if (outputPath) {               outputPath = toPosix(path.join(packageRoot, outputPath))               // 如果之前已经进行过输出，则不需要重复进行               if (currentResourceMap[resourcePath] === outputPath) {                 alreadyOutputed = true               } else {                 currentResourceMap[resourcePath] = outputPath               }             } else {               currentResourceMap[resourcePath] = true             }              return {               packageName,               packageRoot,               outputPath,               alreadyOutputed             }           },           ...         }     } } 

这样webpack构建编译非js资源时会调用compilation.__mpx__.getPackageInfo方法返回非js的静态资源的输出路径，在该方法内部制定了如下资源的的输出规则：

1. 主包引用的资源输出至主包
2. 分包引用且主包引用过的资源输出至主包，不在当前分包重复输出
3. 分包引用且无其他包引用的资源输出至当前分包
4. 分包引用且其他分包也引用过的资源，重复输出至当前分包

这样，mpx在处理项目中的静态资源时，会调用该方法获得静态资源的输出路径。

下面以一个简单例子来说明，

例如对项目中的图片会调用@mpxjs/webpack-plugin提供的url-loader进行处理，与webpack的url-loader类似，对于图片大小小于指定limit的进行base64处理，否则使用file-loader来输出图片（此时需要调用getPackageInfo方法获取图片的输出路径），相关代码：

 let outputPath    if (options.publicPath) { // 优先loader配置的publicPath     outputPath = url     if (options.outputPathCDN) {       if (typeof options.outputPathCDN === 'function') {         outputPath = options.outputPathCDN(outputPath, this.resourcePath, context)       } else {         outputPath = toPosix(path.join(options.outputPathCDN, outputPath))       }     }   } else {       // 否则，调用getPackageInfo获取输出路径     url = outputPath = mpx.getPackageInfo({       resource: this.resource,       outputPath: url,       resourceType: 'staticResources',       warn: (err) => {         this.emitWarning(err)       }     }).outputPath   }      ...      this.emitFile(outputPath, content);      ... 

最终，图片资源会调用compilation.__mpx__.getPackageInfo方法来获取图片资源的输出路径进行产出。

同样对于css资源、wxml资源以及json资源，mpx内部是通过创建子编译器来抽取的，这里就不做深入介绍。

splitChunks的用法

webpack的splitChunks插件是用来进行代码拆分的，通过上面的分析可以看出MPX内部是通过内置splitChunks的cacheGroups配置项来主动实现对小程序js模块实现分割优化的。webpack常见的代码分割方式有三种：

• 多入口分割：webpack的entry配置项配置的手动入口，也包括可以使用compilation.addEntry程序添加的入口
• 动态导入：通过模块的内联函数来分离代码，如通过import('./a')
• 防止重复：使用splitChunks来去重和分离chunk

前两种在我们日常的开发中比较常见，第三种是通过webpack的optimization.splitChunks配置项来配置的。

通常情况下，webpack配置项optimization.splitChunks会有默认配置来实现代码分割，上面我们说到MPX在为不同包生成cacheGroups时，细心的同学会发现我们最终生成的包多了两个配置组：

{     default: {     automaticNamePrefix: '',     reuseExistingChunk: true,     minChunks: 2,     priority: -20   },   vendors: {     automaticNamePrefix: 'vendors',     test: /[\/]node_modules[\/]/,     priority: -10   },   ... } 

这是webpack为optimization.splitChunks.cacheGroups配置的默认组，除此之外optimization.splitChunks还有一些其他默认配置项，如下代码所示：

splitChunks: {     chunks: "async",     minSize: 30000,     minChunks: 1,     maxAsyncRequests: 5,     maxInitialRequests: 3,     automaticNameDelimiter: '~',     name: true,     cacheGroups: {         vendors: {             test: /[\/]node_modules[\/]/,             priority: -10         },     default: {             minChunks: 2,             priority: -20,             reuseExistingChunk: true         }     } } 

上面默认配置的实现的效果是：满足下面4个条件的模块代码会抽离成新的chunk

• 来自node_modules中的模块，或者至少被2个chunk复用的模块代码
• 分离出的chunk必须大于等于3000byte，约30kb
• 按需异步加载chunk时，并行请求的最大数不超过5个
• 页面初始加载时，并行请求的最大数不超过3个

下面来介绍下这些配置项的作用：

• chunks：表示webpack将对哪些chunk进行分割，可选值为async、all、initial
  • async：对于异步加载的chunks进行分割
  • initial：对非异步加载的初始chunks进行分割
  • all：对所有chunks进行分割
• minSize: 分割后的chunk要满足的最小大小，否则不会分割
• minChunks: 表示一个模块至少应被minChunks个chunk所包含才能分割
• maxAsyncRequests: 表示按需加载异步chunk时，并行请求的最大数目；这个数目包括当前请求的异步chunk以及其所依赖chunk的请求
• maxInitialRequests: 表示加载入口chunk时，并行请求的最大数目
• automaticNameDelimiter: 表示拆分出的chunk的名称连接符，默认为_。如chunkvendors.js
• name: 设置chunk的文件名，默认为true，表示splitChunks基于chunk和cacheGroups的key自动命名。
• cacheGroups: 通过它可以配置多个组，实现精细化分割代码；
  • 该对象配置属性继承splitChunks中除cacheGroups外所有属性，可以在该对象重新配置这些属性值覆盖splitChunks中的值
  • 该对象还有一些特有属性如test、priority和reuseExistingChunk等

针对cacheGroups配置补充一点：

cacheGroups配置的每个组可以根据test设置条件，符合test条件的模块，就分配到该组。模块可以被多个组引用，但最终会根据priority来决定打包到哪个组中。