记录一次scratch-gui的“打包瘦身”方法

总所周知-gui打包引用的第三方库文件多且大，并且我们还使用的第三方库的使用方式（npm link，把生成的build当作第三方组件使用），导致首次加载的main.chunk很大。

历程

我刚来项目组的时候，用的cdn加速的方法，但是需要花钱而且还是根本上避免不了这个问题。

前期快速开发也没有在意这方面问题，先打开zip压缩，但是也有大约5M的大小，如果带宽不是很大的话也需要7~8s的加载时间。

因为需要移动端的预览页面，所以抽时间把-gui克隆了一份，尝试着把一些没用的依赖删除了。

预览只需要绘制方面的内容，block类、语言包等就没什么意义了。组件文件其实并不大，可删可不删。删完后大小差不多2.3M左右（zip压缩后，多余依赖没有完全删除）。

开发带了阶段尾声，准备好好搞搞性能优化部分。

还是在第三方依赖方面下手（使用--可以清晰的看到打包后的chunk大小）

图中可以看出最大的两个依赖（也是最需要优化），一个是的虚拟机-vm，另外一个就是语言包了。一听虚拟机，可能有的人就觉得很难搞了，其实最两个文件最难处理不是因为代码逻辑，而且静态文件。

-l10很大，是因为有很多的语言包也就是json文件。其实大多的语言都没有用的，如果不搞国际版只留个英文和简体中文的就可以，多余的json文件删了就行。注意删除的时候把js逻辑也改一下，因为有的采用的遍历，如果获取不到json可能会报错。

-vm很大，是因为有音乐扩展里面的一些音频文件包含在了里面。首次加载的时候，这个静态音频会一块加载。处理方法对应的也很简单，就是改成ajax加载就可以了，当展示音乐扩展的时候再调用。(更改教程如下)

（更改音频文件的引用路径未当前服务器路径 eg:http:127.0.0.0///drums/****.mp3）

(更改加载音频的方法为ajax请求) tip:不要同步求情，同步求情不能设置

（使用async await将异步请求改为同步，这样音频才能成功加载，否则音频数组中一直为空）

优化后的打包体积分布

打包后的开启zip压缩，足足小了一半体积（压缩），2.5M如果带宽较小的话3s左右打开还是能接收的，块的话1~2s算正常了。如果移动端的预览库把-vm音频部分也这么拆出去的话，估计也就1M左右。这算叫正常的大小了。其实其他有些库也是能拆的，但是这两个算重点。

文章中多次说明了ZIP压缩后的体积，因为有些库文件实在太大了，打包压缩后大小依旧很大，zip压缩是一定要开的。

有关-gui打包瘦身暂时就这些了，前段时间还把动态素材库、护眼模式等功能添加完成。有时间的话会写个修改记录。最近在研究，更新不一样很快，有问题或具体修改的可以加Q：询问。