携程小程序生态之Taro跨端解决方案( 二 ) _Taro

3.4 项目结构与开发规范

Taro基础壳工程是由Taro官方的模版项目拓展而来，内部增加了定制化的编译配置、Plugins和基础组件类。如图2所示，Taro基础壳工程内仅包含与公共基础功能相关的文件，这些文件可抽象成3类内容：编译配置文件、用于扩展编译过程的Plugins，以及页面基类。

文章插图
图2 Taro基础壳工程结构示意图
开发Taro模块时，开发者需要关注3块内容（扩展配置、项目文件、页面文件，参见图2），并遵守以下几项规范进行开发：

1）主包的大小直接影响着小程序启动性能，为此我们提出“非必要不打入主包”原则：除小程序启动时需要用到的文件、tabBar页面及公共基础文件外，其他文件应全部拆入分包中。Taro模块也须遵循该原则，开发者应将业务代码全部放置在自己的分包目录下，项目文件App.config.js中只增加分包页面配置。

2）为了避免合并项目时出现业务线之间文件相互覆盖或页面路径冲突，统一约定分包页面路径的前缀为“pages/业务线英文缩写”，结合“非必要不打入主包”原则使用，可以有效隔离各业务线的源码文件。

3）为确保Taro模块的业务相关内容（包括依赖包）完全放置在分包路径下，不占用主包的大小，我们提供了commonModule方案：在引用第三方依赖包前，需要开发者本地进行预编译操作，将需要引用的内容打包成放置在分包中的一个或多个commonModule文件，随后从预编译产物（commonModule）中引用所需的模块。除此之外，还可以通过commonOrigin方案获取依赖包的源码，此时会将所需依赖包的原样复制到开发者指定的文件夹目录下。

3.5 仓库管理

首先，Taro项目采用分仓开发的模式，将每个业务线的Taro模块存放在一个单独的git仓库中。将Taro模块分别存放在不同的仓库，可以保持各个业务仓库提交代码操作的独立。

其次，我们借助gitsubmodule 工具将各个Taro模块所在的仓库以及Taro基础壳工程仓库作为子目录包含到整个Taro项目的发布仓库中，为发布仓库和多业务仓建立起父子仓库的关联。建立仓库间的关联后，Taro项目可以借助git submodule 的获取子模块功能快速克隆自己所需的Taro模块源码，并且可以随时拉取各个业务仓库的最新代码。

再次，由于gitsubmodule允许一个仓库作为多个仓库的子目录，这意味着可以选取不同的Taro模块，将他们的仓库组合成新的发布仓库，结合携程小程序管理平台中各个小程序所需Taro模块的配置一起使用，可实现根据配置动态引入Taro模块的效果。

随后，通过对多个Taro模块进行组合，可以快速获得各种包含多个业务线的Taro项目，从而提高Taro模块在不同场景中的复用。

文章插图
图3 仓库管理及模块复用
然后，将Taro项目作为完整小程序的一个bundle，将Taro项目的编译产物与小程序原生壳项目进行合并，即可获取到Taro混合开发的完整小程序代码。

如图3所示，通过组合Taro模块可以获取到包含不同功能的Taro项目，接着将Taro项目与不同类型的小程序原生壳项目结合，便可以轻松获取多个Taro混合开发的小程序项目。

3.6 开发及运行架构

开发者只需安装miniTools脚手架并执行初始化命令行，即可快速获取Taro模块的开发模版和小程序原生壳工程，完成项目初始化。开发Taro模块时，开发者需要遵循开发规范，在分包目录下添加文件并编写业务代码。编写过程中，只需执行编译指令，便可将本地开发的源码编译并融合到小程序原生壳工程中，得到包含Taro模块内容的完整小程序代码了。