网络包热更新优化详解

前言

随着项目中的界面越来越多，webpack的热更新也越来越慢，有时会达到长达5、7秒，对开发效率影响很大。

解析过程

所以今天，我分析了热更新慢的原因。步骤如下

首先，在包中添加启动命令

-progress-watch-colors-profile首先解释这些参数的含义

-进度施工进度-观看实时监控-过程中的步骤-剖面图编制费时。重新启动项目后，可以开始观察耗时。修改文件后，检查控制台，如下所示

图中红色部分是耗时最长的地方。好吧，我找到了那个需要很长时间的地方。经过百度搜索，发现也有一个和我很相似的问题。他的理由是使用了uglifyJsPlugin插件。考虑到这一点，这个插件也用在我的项目的webpack配置中，所以我将这个插件移到生产环境中使用。修改后，我重新启动了项目。修改文件后，我检查了控制台，如下所示

效果惊人，总耗时一直在1，2s以内，效率提升了不少！如果你有这样的烦恼，也可以试试

另一个解决方案。

这个方案的思路是，在开发环境中，每个人负责一部分模块或者组件，所以hot update只能编译自己当前需要的页面，并不需要编译所有的页面。创建一个selfConfig.js设置要保存的页面，然后在webpack配置中只配置需要的页面来编译热更新。在开发环境中加速编译。

//self config . js module . exports=[' imscene '，' mLogin ']；//webpack.base.conf.js //部分密钥代码const selfconfig=require('。/self config ')；for(让moduleName of modules){ if(self config . length===0){ devEntries[moduleName]=path . join(resolve(' src ')，' modules '，moduleName，' main . js ')；} else { if(self config . includes(moduleName)){ devEntries[moduleName]=path . join(resolve(' src ')，' modules '，moduleName，' main . js ')；} } buildEntries[moduleName]=path . join(resolve(' src ')，' modules '，ModuleName，' main . js ')；}上述案例设置完成后，只会热更新两页。但是这个方案的缺点是其他页面的本地环境不会用白屏打开(因为根本没有编译)，所以这个方案还是根据适合自己的场景来使用。

注意：每次修改selfConfig.js，都需要重启webpack服务。

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