mpvue小程序上傳提示體積超過500KB問題處理

1、前言

本文爲針對微信小程序發佈過程當中提示的"如下文件體積超過500KB，已經跳過壓縮以及ES6轉ES5處理，如在該文件有使用到ES6特性，請使用其它工具轉換成ES5或壓縮，不然可能會在低版本設備上運行有風險：. static/js/vendorjs"

使用到的技術棧:

• 1.mpvue [mpvue.com/]
• 2.webpack [www.webpackjs.com/]

2、問題描述

使用mpvue小程序開發打包發佈上傳時，會出現如下的報錯：

或者在進行真機預覽時出現代碼上限警告出錯提示：

前者在mpvue issue中有人提相似問題，答覆是能夠不用理會，不影響上傳，筆者親自試過，確實只是提示性錯誤，最終代碼仍是能上傳而且能夠正常運行，這個問題也不大，但後者，由於咱們的小程序常常會有用到使用真機調試的狀況，所以，這種報錯狀況不解決，會對開發時真機模擬形成很大困擾。既然問題來了，需求明確，咱們看下如何解決。

3、問題分析

1.分析vendor.js

依據錯誤提示，打開工程dist目錄下/static/js/vendor.js,能夠發現這是一個公共包，若是在多個頁面或者模塊使用到有相關的代碼，那麼該代碼會被Webpack識別爲公共代碼，公共代碼都會被抽離到這裏來，從保留的註釋，咱們大概能知道哪些內容是公共部份。

再回到業務邏輯代碼，搜索相似的關鍵字，能夠發現，產生這類問題的根源基本上是咱們的業務邏輯代碼中在不經意或者須要時引入了過多的第三方包，例如相似下圖的代碼模擬：

2.分析打包依賴（webpack-bundle-analyzer）

安裝依賴

在工程 build目錄的 webpack.dev.conf.js配置文件中添加分析配置，關鍵代碼以下：

這裏將分析結果訪問端口設置爲9800,設置完成啓動後命令行有相應的輸出，點擊連接可訪問。

而後，能夠獲得相似以下的分析報告，這裏要注意，選擇 Stat按鈕

3.分析打包配置

回到webpack打包配置部份，找到公共代碼抽離部份，能夠發現CommonChunkPlugin
(因該工程使用的是mpvue相對較舊的以前版本，對應的webpack使用的是CommonChunkPlugin)

CommonsChunkPlugin主要是用來提取第三方庫和公共模塊，避免首屏加載的bundle文件或者按需加載的bundle文件體積過大，從而致使加載時間過長

這裏抽取的是第三方公共包部份。

注：webpack4以前使用的是webpack.optimize.CommonsChunkPlugin，以後則是使用config.optimization.splitChunk來進行公共代碼抽離

4、解決方案

1.改造webpack進行拆包處理

經過分析工程，以本工程爲例，能夠發如今分析報告中佔據大塊面積的包模塊主要集中在劃紅線部份：

（包模塊佔的面積越大，說明其打包體積越大）

2.進一步拆包

步驟一：

上圖所示的內容將會被統一打包入Vendor.js,在不改變業務邏輯，例如刪除無用引用等狀況下，須要對Vendor.js打包內容進一步拆分。
方法就是：建多一個CommonsChunkPlugin對Vendor.js裏邊的內容，依據匹配列表進行二次拆分。

這裏要留意:
chunks:['vendor'] 顯式指定要拆分的模塊
name:'commons' 指定拆分後生成的新模塊名
拆分規則：則依據module.resource返回的模塊名做匹配判斷，在minChunks自定義拆分函數中做相應的處理，當結果返回true，webpack則會認爲該部份須要進一步抽離, 這裏忽略count:引用次數，結果是隻要有引用則抽離。

步驟二：

上一步驟解決了webpack配置問題，會生成多一個叫commons.js的公共包，但還需解決另外一個問題，打包文件對該文件的引用。 文件引用的關鍵代碼在node_modules/mpvue-loader/lib/mp-compiler/templates.js
咱們須要對該文件進行改造：

在mpvue-loader/lib/mp-compiler中，有對樣式，模板和JS邏輯打包處理的文件邏輯，這裏咱們要改造的是JS引用部份，將原來的:

改形成:

這裏的做用就是生成對各依賴文件引用，注意順序，先引用commons.js而後才引用vendor.js
這裏有個問題：mpvue-loader是官方維護的，這裏的改動是本地的module_modules目錄，那麼在團隊合做時，其它人只要從新安裝包，豈不是又被覆蓋了？ 因此，咱們引入瞭如下幾中方案當中的第3種：
1.將mpvue-loader拷出來放入工程目錄單獨維護
2.將mpvue-loader拷一份，放入內部私服維護
3.編寫單獨腳本，生成引用，在打包啓動命令中引用
綜合考慮，咱們選擇第3種方案，首先須要：

創建引用改造文件check-vendor.js

打包時先執行覆蓋文件，再執行打包命令

配置script入口

這樣就確保每次打包時會動態插入新引用的commons.js文件

3.其它方案

經過翻閱其它資料，還有其它方案，好比：
小程序分包
但因考慮到工程業務儘可能不更改，新舊版本兼容等問題，這裏採用了自行修改webpack打包機制方案，儘可能作到對業務邏輯代碼影響最小。

4.按需導入

還有一種方案，就是須要分析業務邏輯代碼中有些包是否能夠只導入須要的部份，例如i18,依據業務判斷是否須要那麼多的語言包之類，等等，例如如下介紹的方法：
Webpack優化技巧，構建效率提高50%

5、優化結果

經過以上的一系列步驟優化，最終對好比下：

優化打包前：

優化打包後：

最終效果：正常上傳，錯誤提示消失，真機調試可正常進行。

6、總結

1.舊工程改造思考

經過以上分析和解決步驟，考慮到工程是否適合升級新版本mpvue，對現有業務邏輯影響有多大等評估，最終咱們選擇了不動業務邏輯，改造webpack的方式進行。若是風險不太大，建議可考慮小程序分包方案。

2.後續兼容，鎖包處理

考慮到mpvue升級兼容等問題，把package.json相關依賴固化在某一版本，所以去除全部^符號，保留~或者不保留該符號，相對穩定地來處理版本升級的兼容問題。

最簡示例DEMO已上傳到Github: mp-compress 有須要的朋友歡迎參考。