详解如何webpack使用DllPlugin

前言

(时光飞逝,转眼又偷懒了一个多月)

什么是DLL

DLL(Dynamic Link Library)文件为动态链接库文件,在Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于系统中。当我们执行某一个程序时,相应的DLL文件就会被调用。

举个例子:很多产品都用到螺丝,但是工厂在生产不同产品时,不需要每次连带着把螺丝也生产出来,因为螺丝可以单独生产,并给多种产品使用。在这里螺丝的作用就可以理解为是dll。

为什么要使用Dll

通常来说,我们的代码都可以至少简单区分成业务代码和第三方库。如果不做处理,每次构建时都需要把所有的代码重新构建一次,耗费大量的时间。然后大部分情况下,很多第三方库的代码并不会发生变更(除非是版本升级),这时就可以用到dll:把复用性较高的第三方模块打包到动态链接库中,在不升级这些库的情况下,动态库不需要重新打包,每次构建只重新打包业务代码。

还是上面的例子:把每次构建,当做是生产产品的过程,我们把生产螺丝的过程先提取出来,之后我们不管调整产品的功能或者设计(对应于业务代码变更),都不必重复生产螺丝(第三方模块不需要重复打包);除非是产品要使用新型号的螺丝(第三方模块需要升级),才需要去重新生产新的螺丝,然后接下来又可以专注于调整产品本身。

基本用法

使用dll时,可以把构建过程分成dll构建过程和主构建过程(实质也就是如此),所以需要两个构建配置文件,例如叫做webpack.config.jswebpack.dll.config.js

1. 使用DLLPlugin打包需要分离到动态库的模块

DllPluginwebpack内置的插件,不需要额外安装,直接配置webpack.dll.config.js文件:

module.exports = {=
 entry: {
  // 第三方库
  react: ['react', 'react-dom', 'react-redux']
 },
 output: {
  // 输出的动态链接库的文件名称,[name] 代表当前动态链接库的名称,
  filename: '[name].dll.js',
  path: resolve('dist/dll'),
  // library必须和后面dllplugin中的name一致 后面会说明
  library: '[name]_dll_[hash]'
 },
 plugins: [
 // 接入 DllPlugin
  new webpack.DllPlugin({
   // 动态链接库的全局变量名称,需要和 output.library 中保持一致
   // 该字段的值也就是输出的 manifest.json 文件 中 name 字段的值
   name: '[name]_dll_[hash]',
   // 描述动态链接库的 manifest.json 文件输出时的文件名称
   path: path.join(__dirname, 'dist/dll', '[name].manifest.json')
  }),
 ]
}

我们先来看看,这一步到底做了什么。执行:webpack --config webpack.dll.config,然后到指定的输出文件夹查看输出:

  • react.dll文件里是使用数组保存的模块,索引值就作为id;
  • react.manifest.json文件里,是用来描述对应的dll文件里保存的模块

里暴露出刚刚构建的所有模块,如下:

{
 "name":"react_dll_553e24e2c44987d2578f",
 "content":{
  "./node_modules/webpack/node_modules/process/browser.js":{"id":0,"meta":{}},"./node_modules/react/node_modules/fbjs/lib/invariant.js":{"id":1,"meta":{}},"./node_modules/react/lib/Object.assign.js":{"id":2,"meta":{}},"./node_modules/react/node_modules/fbjs/lib/warning.js":{"id":3,"meta":{}}
  //省略相似代码
 }
}

2. 在主构建配置文件使用动态库文件

webpack.config中使用dll要用到DllReferencePlugin,这个插件通过引用 dll 的 manifest 文件来把依赖的名称映射到模块的 id 上,之后再在需要的时候通过内置的 webpack_require 函数来 require 他们.

 new webpack.DllReferencePlugin({
  context: __dirname,
  manifest: require('./dist/dll/react.manifest.json')
 }),

第一步产出的manifest文件就用在这里,给主构建流程作为查找dll的依据:DllReferencePlugin去 manifest.json 文件读取 name 字段的值,把值的内容作为在从全局变量中获取动态链接库中内容时的全局变量名,因此:在 webpack_dll.config.js 文件中,DllPlugin 中的 name 参数必须和 output.library 中保持一致。

3. 在入口文件引入dll文件。

生成的dll暴露出的是全局函数,因此还需要在入口文件里面引入对应的dll文件。

<body>
 <div id="app"></div>
 <!--引用dll文件-->
 <script src="../../dist/dll/react.dll.js" ></script>
</body>

作用

首先从前面的介绍,至少可以看出dll的两个作用

分离代码,业务代码和第三方模块可以被打包到不同的文件里,这个有几个好处:

  1. 避免打包出单个文件的大小太大,不利于调试
  2. 将单个大文件拆成多个小文件之后,一定情况下有利于加载(不超出浏览器一次性请求的文件数情况下,并行下载肯定比串行快)

提升构建速度。第三方库没有变更时,由于我们只构建业务相关代码,相比全部重新构建自然要快的多。

注意事项

从前面可以看到dll带来的优点,但并不意味着我们就应该把除业务代码外的所有代码全部都丢到dll中,举一个例子:
1.对于lodash这种第三方库,正确的用法是只去import所需的函数(用什么引什么),例如:

// 正确用法
import isPlainObject from 'lodash/isPlainObject'

//错误用法
import { isPlainObject } from 'lodash'

这两种写法的差别在于,打包时webpack会根据引用去打包依赖的内容,所以第一种写法,webpack只会打包lodash的isPlainObject库,第二种写法却会打包整个lodash。现在假设在项目中只是用到不同模块对lodash里的某几个函数并且没有对于某个函数重复使用非常多次,那么这时候把lodash添加到dll中,带来的收益就并不明显,反而导致2个问题:

  1. 由于打包了整个lodash,而导致打包后的文件总大小(注意是总大小)比原先还要大
  2. 在dll打包太多内容也需要耗费时间,虽然我们一般只在第三方模块更新之后才进行重新预编译(就是dll打包的过程),但是如果这个时间太长的话体验也不好、

实践与反思

放一张自己在一个比较大的项目中单纯使用dll之后的收益,提取的内容是 react相关的第三方库,和fish组件,构建时间从120s降低到80s左右(当然这个时间还是有点恐怖),构建前appjs的大小是680kb,拆分业务代码和第三方代码分别是400kb和380kb(这就是拆分后大小大于拆分前大小的例子),从这一点来看,对于常见第三方库是否要放进dll可能比较明确(比如react系列打包一般肯定不亏),但是还有一些就要结合具体的项目内容来进行判断和取舍。(强烈推荐使用webpack-bundle-analyzer插件进行性能分析)

总结

本文介绍了Dllplugin的思想,基本用法和应用场景(关于使用的部分更详细的内容可以看官方文档),结合个人的一些实践经验,对于常见第三方库是否要放进dll可能比较明确(比如react系列打包一般肯定不亏),但是还有一些就要结合具体的项目内容来判断,例如我上面的实践的例子就说明目前的拆分还不够好。这一块也欢迎大家一起探讨。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 详解基于DllPlugin和DllReferencePlugin的webpack构建优化

    一个基于vue-cli webpack2模板创建的项目.项目中使用到了vue+vue-router+axios+muse-ui+iview 现在构建一次需要的时间大概是40s左右.真心受不了.虽然在开发过程中,我们不太需要关心构建时间.但是如果在开发hybridApp时,构建的次数就会增多. 一般我们可以把项目分为三部分. 分类 说明 变动频率 vendor_library 核心库 低 vendor 一般项目依赖 中等 code 业务逻辑 高 vendor_library:比如vue,vue-r

  • 详解如何webpack使用DllPlugin

    前言 (时光飞逝,转眼又偷懒了一个多月) 什么是DLL DLL(Dynamic Link Library)文件为动态链接库文件,在Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于系统中.当我们执行某一个程序时,相应的DLL文件就会被调用. 举个例子:很多产品都用到螺丝,但是工厂在生产不同产品时,不需要每次连带着把螺丝也生产出来,因为螺丝可以单独生产,并给多种产品使用.在这里螺丝的作用就可以理解为是dll. 为什么要使用Dll 通

  • 详解通用webpack多页面自动导入方案

    目录 前言 思考 安装glob 创建工具类 getEntry getHtmlWebpackPlugin 二次封装 应用 前言 在之前,我写了一个webpack的模板.在平时我写栗子或者是写几个页面的时候会用到它.当这个模板需要多个页面时需要手动到webpack.config.ts文件中配置entry和HtmlWebpackPlugin,有点麻烦. 思考 我们项目中的页面都是存放在src/pages/*.html中的,我们可以搜索这里文件夹下的html文件我们可以利用node中的glob包中的.s

  • 详解Vue-cli webpack移动端自动化构建rem问题

    相信很多小伙伴想着自己的移动端项目能够自动转换为rem,这才符合前端的潮流,如果用自己手写或者编辑器插件来改动十分不方便还容易出错,我在网上找了很多的方法发现以下问题: 1 照着老的视频教程去弄,发现node npm webpack px2rem的各种插件版本都不一样,根本没用 2 网上的教程缺斤少俩,不完整,搞得我整了半天搞不定,想想干脆手动vscode 的cssrem设置算了,但老子还是不服气,东拼西凑还是整出来了,最后还是研究出了以下方法希望对大家的移动端自动化构建rem有帮助 1 安装v

  • 详解基于webpack搭建react运行环境

    最近由于项目需要,所以尝试使用webpack搭建react运行环境,在克服了一系列困难后,终于能在页面输出"Hello World",特地把整个过程记录下来,利人利己. 首先我创建了一个文件夹webpack-helloworld-demo,之后的大部分操作都会在这个文件夹下进行. 1.初始化文件夹 npm init //初始化一个package.json文件 git init //产生.git文件,便于之后版本提交回退 2.搭建webpack环境 npm install webpack

  • 详解vue-cli + webpack 多页面实例配置优化方法

    本文介绍了vue-cli + webpack 多页面实例配置优化方法,分享给大家 vue+webpack是否有多页面 目前使用vue来做项目,估计大部分都是单页面(SPA)应用,一个轻型的 MVVM 框架,谁用了MVVM框架,就再也回不去JQ时代了,哈哈. 在手机端的项目,使用vue + vue-router是high到爆,不仅仅是我们开发的而言,最主要的用户体检也是开足马力,体检感杠杠的. 那问题来了,使用vue+webpack的单页面是爽到爆,那如果是多页面也能不能high到爆呢?那当然呀,

  • 详解基于webpack和vue.js搭建开发环境

    前言 在对着产品高举中指怒发心中之愤后,真正能够解决问题的是自身上的改变,有句话说的好:你虽然改变不了全世界,但是你有机会改变你自己.秉承着"不听老人言,吃亏在眼前"的优良作风,我还是决定玩火自焚. 问题所在 之前的项目总结为以下内容: 1.AMD模块规范开发,使用requirejs实现,使用rjs打包,最终导致的结果是,输出的项目臃肿,肿的就像一坨狗不理--不忍直视 2.使用gulp进行打包,这一点貌似没有可吐槽的地方,毕竟都是被grunt折磨过来的-- 3.数据的渲染使用模板引擎,

  • 详解用webpack把我们的业务模块分开打包的方法

    webpack我自己还在摸索学习中,今天给大家分享个用webpack把我们的业务模块分开打包的方法,顺便留个笔记 如何用webpack打包这3个js? 只需修改webpack的配置文件webpack.config.js: // entry是入口文件,可以多个,代表要编译那些js entry:['./src/main.js','./src/login.js','./src/reg.js'], 这样就可以全部打包,最终生成./build/js/build.js 1,那么如果我们想最后生成不同的文件,

  • 详解vue-cli + webpack 多页面实例应用

    关于vue.js vue.js是一套构建用户界面的 轻型的渐进式前端框架.它的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件.使用vue可以给你的开发带来极致的编程体验. 关于vue-cli Vue-cli是vue官方提供的一个命令行工具(vue-cli),可用于快速搭建大型单页应用.该工具提供开箱即用的构建工具配置,带来现代化的前端开发流程.只需一分钟即可启动带热重载.保存时静态检查以及可用于生产环境的构建配置的项目. 疑问 vue-cli主要是用于构建单页应用的脚手架,但

  • 详解用webpack的CommonsChunkPlugin提取公共代码的3种方式

    Webpack 的 CommonsChunkPlugin 插件,负责将多次被使用的 JS 模块打包在一起. CommonsChunkPlugin 能解决的问题 在使用插件前,考虑几个问题: 对哪些 chunk 进行提取,这决定了 chunks ,children 和 name 要怎么配置 common chunk 是否异步,这决定了 async 怎么配置 common chunk 的粒度,这决定了 minChunks 和 minSize 怎么配置 以下是官方给出的常用的场景: 提取两个及两个以上

  • 详解使用webpack打包编写一个vue-toast插件

    本文介绍了使用webpack打包编写一个vue插件,分享给大家.具体如下: 一.说明: 需求:创建一个toast插件 思路:利用vue组件创建模板,使用webpack打包生成插件再全局使用. # 项目目录: |_ package.json |_ webpack.config.js |_ .babelrc |_ dist |_ src |_ index.html |_ lib |_ index.js |_ vue-toast.vue 1.1 webpack基础 1.基础插件 - html-webp

随机推荐