一 基础操作
如果你的项目刚刚开始,恭喜你选择了一条最简单的路,如下为微信官方示例,将项目目录安排如下,并在 app.json subpackages
字段中做对应声明即可。
其中pages数组中的页面为主包中的页面,subpackages中的每一项对应一个分包。
├── app.js
├── app.json
├── app.wxss
├── packageA
│ └── pages
│ ├── cat
│ └── dog
├── packageB
│ └── pages
│ ├── apple
│ └── banana
├── pages
│ ├── index
│ └── logs
└── utils
{
"pages":[
"pages/index",
"pages/logs"
],
"subpackages": [
{
"root": "packageA",
"pages": [
"pages/cat",
"pages/dog"
]
}, {
"root": "packageB",
"name": "pack2",
"pages": [
"pages/apple",
"pages/banana"
]
}
]
}
但在实际操作中,大部分人并不会在开发初始就合理规划目录,为分包做好准备。
而是在开发过程中,发现项目"超重"了,无法进行正常发布,才开始了解分包。
项目目录千奇百怪,照搬官方文档遇到各种问题。
这种情况下,你就更需要这篇文章了。
二 路径重合问题
上面讲到,首先pages数组中的页面为主包中的页面,subpackages中的每一项对应一个分包,可以得到,如果一个页面不能既在pages中又在subpackages中,否则报错。
但有时我们明明没有重复定义页面,还是爆了类似错误,比如下面的情况,我相信有些人的项目目录是这样的。
├── app.js
├── app.json
├── app.wxss
├── pages
│ ├── index
│ └── logs
└── utils
于是他们配置如下:
{
"pages":[
"pages/index"
],
"subpackages": [
{
"root": "pages",
"pages": [
"logs"
]
}
]
}
然后喜提bug:
“pages/index” 不应该在 [subpackages] [0] 中
尽管pages/index并未在[subpackages] [0]处定义。
官方对此解释如下:
声明
subpackages
后,将按subpackages
配置路径进行打包,subpackages
配置路径外的目录将被打包到 app(主包) 中
subpackage
的根目录不能是另外一个subpackage
内的子目录
我的理解是,当你将分包的根路径设置为pages时,pages路径下的内容就属于该分包了,所以你再将pages/index页面划分给主包是不被允许的。
也就是说分包的分路径下不能包含其他包的内容。
而下面这种形式是允许的,因为它们没有互相包含。
{
"pages":[
"pages/index"
],
"subpackages": [
{
"root": "pages/packageA",
"pages": [
"logs"
]
}
]
}
三 tabbar 必须在主包中
这条在官方文档中也有说明:
tabBar
页面必须在 app(主包)内
这条比较容易理解,tabBar
页面必须放在app.json中的外层pages中而不能放在subpackages(分包)中。否则报错:
“pages/index” 不应该在 [subpackages] [0] 中
四 主包大小问题和公共资源读取问题
辛苦分包完成,还是无法运行成功,原来是某一个包仍然"超重",这时可以使用开发者工具的代码依赖分析工具查看各包的大小情况。
这时我们可能会发现主包太大了,但是外层pages中并没有几个页面,这是为啥?
点开代码依赖分析工具发现主包中包含了大量的公共资源,比如公用组件,api这种,原因也在上面写到了:
声明
subpackages
后,将按subpackages
配置路径进行打包,subpackages
配置路径外的目录将被打包到 app(主包) 中
有小机灵鬼会想,我把这些公共资源单独放在一个包里不就可以了吗。一试,项目都起不来了。
子包可以使用主包的资源,但是主包不可以使用子包的资源,子包之间的资源也不通用。
所以公共资源一点要放在主包里。
如果主包太大了,只能将公共资源放在对应的子包中,而不能跨包调用哦。
五 wepy子包跳转问题
如果你使用的是wepy框架2.x一下,可能会存在wpx跳转到wpx页面跳转失败问题,这时将上面的subpackages改为subPackages即可。