最近使用uniapp做了第二个小程序，准确的说是在以前的某一个小程序上迭代的功能，因为重构了整个UI设计，很多自定义的样式、图片，就导致莫名其妙的包就大了很多，超出了限制，所以在上一篇简单提到的分包问题，就成了这一篇的主题。 对于使用uniapp开发的微信小程序而言，刚开始我认为分包也是一个简单的事情，就按照文档说明来配置好了，除了tabBar页面剩下的就迁移到另一个目录下，配置一下pages.json的分包规则，甚至连manifest.json里面配不配都无所谓，因为只要配置了pages.json，小程序的分包就一定生效了。
简单的配置如下：
{
"pages":[...],
"subpackages":[
"root":"order-sub", // subPackages 里的pages的路径是 root 下的相对路径，不是全路径
"name":"pack1",
"pages":[
{
"path": "bathbully-mode",
"style": {
"navigationBarTitleText": "产品型号"
}
},
{
"path": "order-detail",
"style": {
"navigationBarTitleText": "订单详情"
}
},
{
"path": "order-list",
"style": {
"navigationBarTitleText": "我的预约"
}
}
]
],
...
}
但是当我配置好重新运行预览，依然报错提示如图1所示，好像分包并没有解决什么问题，这让我不得不重新审视一下我对于分包的理解了。
图1 包过大的报错图片
。。。。。。。。。。。。。。。。。此处省略回头扒拉uniapp官方文档和微信开发者文档的过程。。。。。。 我们从头说起分包。
分包加载机制
分包加载机制就是开发者需要将小程序划分成不同的子包，在构建时打包成不同的分包，在小程序启动时，默认会下载主包并启动主包内页面，当用户进入分包内某个页面时，客户端会把对应分包下载下来，下载完成后再进行展示。 对小程序进行分包，主要是从性能考虑，可以优化小程序首次启动的下载时间，以及在多团队共同开发时可以更好的解耦协作，当然最根本的原因还开发者受制于微信团队。 如图所示，从微信开发者工具中我们可以看到，即使是分包，也是有限制的，和主包一样，单个分包也不得超过2M大小。
图2 微信开发者工具-本地配置-高级配置
在uniapp中分包优化具体逻辑：- 静态文件：分包下支持 static 等静态资源拷贝，即分包目录内放置的静态资源不会被打包到主包中，也不可在主包中使用
- js文件：当某个 js 仅被一个分包引用时，该 js 会被打包到该分包内，否则仍打到主包（即被主包引用，或被超过 1 个分包引用）
- 自定义组件：若某个自定义组件仅被一个分包引用时，且未放入到分包内，编译时会输出提示信息
分包问题处理
在图1所示的报错中，即使我之前的理解有问题也可以有迹可循的去寻找解决办法，【查看文件列表】【代码依赖分析】都是可以点击看一下我们的问题所在，如图3、图4所示。
图3 文件列表
图4 代码依赖分析
从图3中可以明显看出，最大的几个文件都是我自己用的图片，同时从图4可以看出，这几个比较大的图片还被打包进了主包之内。那么就可以从两方面考虑，一是大的图片进行压缩，二是这个被打进主包的静态文件是否在主包中有用到或者是公共的静态文件，如果既没有在主包中应用也不是公共使用的就可以考虑挪进分包之中。 果然在我将图片压缩且将没有在主包中使用的静态文件挪出去之后，不再报错，正常预览以及上传。项目文件的大小为
总结
其实前面的可以都不看，关键的总结就是：
- 主包内一定只放tabBar的页面以及公共的静态文件、公共组件，其他的都可以放在分包之内
- 不局限于一个分包，考虑到分包也有限制大小，在设计分包的时候需要考虑好组件之间的关联，分包的页面
- 学会使用微信开发者工具查看包的依赖分析
- 在uniapp中，如果使用了分包，那么不在分包目录下的都会被打入主包中
- 图片合理的进行压缩，这里提供两个压缩图片的地址
