FWQ
分享Echarts在Taro微信小程序开发中的踩坑记录
栏目介绍Echarts在Taro微信小程序开发中的踩坑记录。 背景 近期笔者在使用Taro进行微信小程序开发,当引入Echarts图表库时,微信检测单包超限2M的一系列优化措施的踩坑记录,期望能指导读者少走一些弯路。 为什么选择Echarts? 微信小程序目录市面上使用最多的两款图表库,如下: echarts-for-weixin——echarts微信小程序版本 wx-charts——基于微信小程序的图表库 对比两款图表库优缺点刚好相反。 echarts-for-weixin:功能强大,但体积非常大 wx-charts:功能相对简单,但体积小 由于笔者对echarts使用较熟悉,且需求图表需要支持的部分功能wx-charts不支持,所以最终选择使用echarts-for-weixin,踩坑之旅就此开始。 单包超过2M,如何处理? 笔者引入echarts-for-weixin,快乐的做完需求,准备上传代码发布微信小程序体验版,坑就此开始… 当单包超过2M上限,则上传代码出现异常,出现上面弹窗提示。 微信小程序官方要求,单包不超过2M,整包不超过16M 遇到单包超过2M,优化方案有如下两种: 微信分包加载subpackages 单包体积优化(缩减代码、压缩、静态资源CDN等等) 由于笔者本次开发需求属于新功能,所以把新功能模块采用独立的分包路由加载,但分包后,还是出现单包超过2M的限制。 经过分析发现业务模块引用的echarts组件,会被Taro打包到common.js模块,导致所有的分包模块都会重复计算echarts的size,导致旧分包模块超过2M的限制。 为什么echarts-for-weixin会被打包到common.js模块? 原因是echarts被echarts-for-weixin组件和外部业务组件所依赖,导致Taro认为echarts.js被多个模块所依赖,所以打包到common.js。 为了解决此问题,采用splitChunks打包配置,将echarts单独模块打包,然后在对应的依赖页面(addChunkPages)注入依赖,配置如下: // echartChunkName echarts打包后的输出路径 mini: {…