258资源分享网

导语

小程序端越来越多， 跨平台开发框架逐渐成为开发小程序的主流 ， 目前跨平台开发有较多的开源解决方案 ，本文介绍一种简单而有效的方法，解决复杂小程序的跨团队开发协作，希望对你有所帮助。

背景

目前市面上小程序端越来越多，跨平台开发框架逐渐成为开发小程序的主流。目前跨平台开发有较多的开源解决方案，比如美团点评的mpvue、滴滴的Chameleon、凹凸实验室的Taro等，都做得比较好。这些框架帮我们解决了一处开发，多处运行的难点。但是在复杂的业务场景中，最终落地也存在着许多困难，需要自己解决。以58房产的新房业务小程序为例，实际的业务场景中，既需要有独立承载功能的“58同城新房楼盘精选”小程序，也有依托于其他流量平台的入口，比如在“58同城”、“安居客买房”等都有相应的新房业务，同时还有交叉的业务场景，比如在同经纪人业务结合的“安居客经纪人网店”中展示新房楼盘。这其中既有微信小程序，也有百度小程序。

这些业务有较多的共同点，比如基础功能逻辑是一致的，但是也存在很多差异性，比如商业逻辑，页面皮肤以及一些差异功能点。

新房首页对比

上图为三个小程序的首页对比，可以看到独立的小程序“58同城新房楼盘精选”集成了账号、城市、消息，在“58同城”和“安居客买房”这些能力则是依赖主体小程序。另外三个小程序之间还有些细微差别，但是楼盘相关的基础功能确是相同的。

一处开发多处运行的难题

作为业务方，我们希望业务代码也可以一处开发，到处运行。方案设计之时，我们的目标便是业务代码在同一仓库管理，同时方案具备较大的灵活性以适配各种环境。

在上述的背景下，实际开发中会遇到如下困难：

a) 各个小程序归属的开发团队不一样，使用的开发方案也不一样，有原生开发、wepy、Taro、mpvue等，意味着在源码层面是难以进行协作开发的；

b) 业务方与平台方之间是跨团队协作，需要尽量减少耦合，提高协作效率，同时避免相互影响；

c) 需要具备在各个小程序环境中的差异化开发方案；

d) 所有业务代码同一地方管理，意味着会有不必要的代码，需要有机制保障最终的打包结果大小是最优的；

e) 在不同平台小程序中，会依赖他们各自提供的基础能力，比如账户体系，消息等，这部分在各平台小程序中也存在着一定差异性；

f) 在不同场景下需要具备不同的接入方案，支持微信插件方式接入平台小程序，也要支持业务分包方式接入平台小程序。

整体架构设计

本方案基于Taro 1.3版本实现，其他小程序框架也可使用相同的方法做改造。在现有Taro基础上，无法支持到一份源码打包成多个同类型的小程序，因此在现有配置层进行扩展处理，并添加适配层，对于各个小程序不同点进行处理，最终实现直接打包到多个不同的小程序中，整体的架构主要分为四层： 

a) 配置层，用于解决在不同场景下的差异化，包括环境变量、主题样式、页面配置等；

b) 源码层，为具体的业务代码，常见方案，不做具体介绍；

c) 适配层，用于对接不同方案下小程序提供的接口，并牟平不同小程序提供的接口差异，为源码层提供统一的接口；

d) 打包层，与配置层相结合，用于打包最终交付结果；

以新房为例的架构图：

1） 打包脚本配置

若要支持多小程序开发，需在package.json中增加scripts，用于区分环境。这里我们用的是cross-env这个包来设置，比如在打包58同城小程序时，加入环境变量WEAPPSOURCE=wbweapp。

{

"build:weapp": "taro build --type weapp",

"build:wbweapp": "cross-env WEAPPSOURCE=wbweapp taro build --type weapp",

"dev:wbweapp": "cross-env WEAPPSOURCE=wbweapp npm run build:weapp -- --watch",

}

然后在`config/index.js`配置defineConstants，用来配置一些编译时的全局变量供代码中使用，这里的配置会用于做打包的差异化处理。大部分的差异化配置，我们都放到了编译时来进行配置，有助于降低代码打包后的大小。其原理是通过webpack的define-plugin和uglifyjs-webpack-plugin两个插件配合来删除掉不可达代码，保证不使用的代码不会被打包。

config.defineConstants = {

WEAPPSOURCE: JSON.stringify(process.env.WEAPPSOURCE),

WBWEAPP: '"wbweapp"',

AJKWEAPP: '"ajkweapp"',

}

2） 差异性样式处理