您好,登錄后才能下訂單哦!
這篇文章主要介紹了webpack使用DllPlugin的方法,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
什么是DLL
DLL(Dynamic Link Library)文件為動態鏈接庫文件,在Windows中,許多應用程序并不是一個完整的可執行文件,它們被分割成一些相對獨立的動態鏈接庫,即DLL文件,放置于系統中。當我們執行某一個程序時,相應的DLL文件就會被調用。
舉個例子:很多產品都用到螺絲,但是工廠在生產不同產品時,不需要每次連帶著把螺絲也生產出來,因為螺絲可以單獨生產,并給多種產品使用。在這里螺絲的作用就可以理解為是dll。
為什么要使用Dll
通常來說,我們的代碼都可以至少簡單區分成業務代碼和第三方庫。如果不做處理,每次構建時都需要把所有的代碼重新構建一次,耗費大量的時間。然后大部分情況下,很多第三方庫的代碼并不會發生變更(除非是版本升級),這時就可以用到dll:把復用性較高的第三方模塊打包到動態鏈接庫中,在不升級這些庫的情況下,動態庫不需要重新打包,每次構建只重新打包業務代碼。
還是上面的例子:把每次構建,當做是生產產品的過程,我們把生產螺絲的過程先提取出來,之后我們不管調整產品的功能或者設計(對應于業務代碼變更),都不必重復生產螺絲(第三方模塊不需要重復打包);除非是產品要使用新型號的螺絲(第三方模塊需要升級),才需要去重新生產新的螺絲,然后接下來又可以專注于調整產品本身。
基本用法
使用dll時,可以把構建過程分成dll構建過程和主構建過程(實質也就是如此),所以需要兩個構建配置文件,例如叫做webpack.config.js
和webpack.dll.config.js
。
1. 使用DLLPlugin
打包需要分離到動態庫的模塊
DllPlugin
是webpack
內置的插件,不需要額外安裝,直接配置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的兩個作用
分離代碼,業務代碼和第三方模塊可以被打包到不同的文件里,這個有幾個好處:
避免打包出單個文件的大小太大,不利于調試
將單個大文件拆成多個小文件之后,一定情況下有利于加載(不超出瀏覽器一次性請求的文件數情況下,并行下載肯定比串行快)
提升構建速度。第三方庫沒有變更時,由于我們只構建業務相關代碼,相比全部重新構建自然要快的多。
注意事項
從前面可以看到dll帶來的優點,但并不意味著我們就應該把除業務代碼外的所有代碼全部都丟到dll中,舉一個例子:
1.對于lodash
這種第三方庫,正確的用法是只去import
所需的函數(用什么引什么),例如:
// 正確用法 import isPlainObject from 'lodash/isPlainObject' //錯誤用法 import { isPlainObject } from 'lodash'
這兩種寫法的差別在于,打包時webpack會根據引用去打包依賴的內容,所以第一種寫法,webpack只會打包lodash的isPlainObject庫,第二種寫法卻會打包整個lodash
。現在假設在項目中只是用到不同模塊對lodash里的某幾個函數并且沒有對于某個函數重復使用非常多次,那么這時候把lodash
添加到dll中,帶來的收益就并不明顯,反而導致2個問題:
由于打包了整個lodash
,而導致打包后的文件總大小(注意是總大小)比原先還要大
在dll打包太多內容也需要耗費時間,雖然我們一般只在第三方模塊更新之后才進行重新預編譯(就是dll打包的過程),但是如果這個時間太長的話體驗也不好、
實踐與反思
放一張自己在一個比較大的項目中單純使用dll之后的收益,提取的內容是 react相關的第三方庫,和fish
組件,構建時間從120s降低到80s左右(當然這個時間還是有點恐怖),構建前appjs的大小是680kb,拆分業務代碼和第三方代碼分別是400kb和380kb(這就是拆分后大小大于拆分前大小的例子),從這一點來看,對于常見第三方庫是否要放進dll可能比較明確(比如react系列打包一般肯定不虧),但是還有一些就要結合具體的項目內容來進行判斷和取舍。(強烈推薦使用webpack-bundle-analyzer
插件進行性能分析)
感謝你能夠認真閱讀完這篇文章,希望小編分享的“webpack使用DllPlugin的方法”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。