文章目录
- 前言
- 一、最烦的就是接手别人的项目
- 二、优化历程
- 1.首先将打包完的代码在微信开发者工具打开
- 2.开始针对性的优化--vendor.js
- 3.开始针对性的优化--static
- 4.开始针对性的优化--components/uni-modules
- 总结
前言
提示：大家用uniapp做项目的初期,一定首先考虑分包问题,要不然后期会麻烦死
诶…好死不死,我接手了一个别的团队写的项目,他们在项目初期,并没有充分考虑分包的问题,而是在做的过程中,发现主包放不下了,才开始分包,然而这个时候,再开始分包,就麻烦多了。
提示：以下是我改别人项目的历程,差点熬死
一、最烦的就是接手别人的项目
最近接受了一个别人用uniapp写的项目,然后产品给出了新需求,我也按照需求,一顿抄作猛如虎,把代码写完了,写完了然后说,提交一个体验包到微信平台,然后给测试使用,这一提交不要紧,直接报错,直接告诉我主包大小超过限制(这都2024年了,微信还在2MB的限制,也是醉了),超了竟然330kb,这不少啊,但是我回想我写的代码都是在分包写的,主包就引入了一个uniapp官方的插件,和放了两张10kb的图片,咋就多出300多kb,在我没有开发新功能之前,我记得打包完是1996kb(上一个人真NM也是醉了,就给我留了4kb的空间),然后我的优化历程就开始了…
二、优化历程
1.首先将打包完的代码在微信开发者工具打开
操作方法如下(一定打开的是正式打包的代码,也就是uniapp–dist–build下的代码,而不是dev下的代码)：
这是一个微信开发者工具自带的代码依赖分析工具,挺好用的,一目了然的看到主包和分包各个包大小以及组成,大概主包的有以下6个部分组成:
其实大头就是这个vendor.js,然后就是static,这个里面都是静态的资源文件,这个好理解,然后就是components里面是自定义的组件,uni_modules是uni官方的组件,剩下的pages是就是写的各个页面的vue文件,还有一些样式文件,
2.开始针对性的优化–vendor.js
首先要弄清楚,vendor.js这个文件里面到底是包含一些什么文件,它是由webpack生成的用于存放第三方库和框架代码的JS文件，大小会根据引用的库和框架不同而有所差异这里还发现另一个问题,同一套代码,不同的电脑上打包出来的代码包大小竟然也有差异,这点更让我感到离奇,两台电脑除了配置不同,node环境也是一样的,框架的东西咱们没法动,但是引用的第三方库,咱们是可以修改的,所以引用第三方库到项目的时候,大家要慎重,没必要的就不引用了,项目后期越来越大,给主包留下足够的空间,非常有必要,而我这是二手项目,我没法确定和评估哪些依赖可以去掉,所以这块我没法下手😣。
3.开始针对性的优化–static
这个里面最好优化,把项目没用到的静态图片资源全部删除,太大的图片一定压缩,或者放到cdn,这个里面只留一些必要的图标,我的项目我从这里面优化出来了100多kb的空间,发现里面留了很多无用的图标资源(估计本项目是别的项目改的,真是醉了,不能新建一个吗?)
4.开始针对性的优化–components/uni-modules
这个里面也有优化的空间,比如一些自定义的组件,如果主包不用,千万不要放主包,不然就会占用主包的体积,谁需要放在谁的包下,但是这里会出现一个问题就是,uniapp为了开发者方便,如果把自定义组件或者uni-modules放在src下的指定目录,我们在任何地方使用的时候,可以直接使用,不用引用,其实这是好的做法,他的原理就是利用vue的全局引用,但是如果我们放到子包,你要想使用它就必须得引用到页面,才能使用,稍微麻烦一些,但是为了腾出主包的空间,让我下火海也行,如下方式引用,这样子包就可以正常使用了:
这个地方,有可能会出现同一个组件,两个子包都是用了,那就两个子包分别引入一份,毕竟子包的体积绰绰有余,咱们目的就是腾出来主包的体积,千万不要怕麻烦,这样的原则操作下来,主包体积铖铖的下来了,最后我优化完,重新打包,主包大小从2330KB变到1952KB,达到小于2MB的要求了,赶紧上传微信平台,至此,优化结束了,废了我大半天的时间,真实心累😖!
总结
给大家的建议和提示:
1.大家用uniapp做项目的初期,一定首先考虑分包问题,要不然后期会麻烦死
2.主包除了tab的这些类似必须的页面,其他统统放在分包
3.在依赖第三方框架的时候,慎重选择,不要依赖体积太大的
4.自定义组件和第三方的组件,能放子包的都放子包,能不放主包的尽量不放主包,给主包留下宽裕的空间,利于后期项目的扩展与维护,也给后来人一个良好的基础,不想我遇到的这几位前辈,就给我主包留了4kb的余地,真是你DY的!
