上图是三个小程序的首页对比。可以看到，独立小程序“58城新房选房”集账号、城市、新闻于一体。 “58同城”和“安居客买房”的能力依赖于Main小程序。其他三个小程序之间存在一些细微的差异，但与房地产相关的基本功能确实是相同的。

一处开发多处运行的问题

作为业务方，我们希望业务代码可以在一个地方开发，在任何地方运行。在设计解决方案时，我们的目标是在同一个仓库中管理业务代码，同时解决方案具有更大的灵活性以适应各种环境。

在上述背景下，实际开发中将遇到以下困难：

a) 每个小程序属于不同的开发团队，采用不同的开发方案，包括原生开发、wepy、Taro等，这意味着很难在源码层面进行协同开发；

b) 业务方与平台方跨团队协作，需要最小化耦合，提高协作效率，避免相互影响；

c）需要在每个迷你计划环境中具有差异化的开发解决方案；

d) 所有业务代码都在同一个地方管理，这意味着会出现不必要的代码，需要有一个机制来保证最终打包结果大小最优；

e) 不同平台的小程序都会依赖其提供的基础能力，比如账号系统、消息等，各个平台的小程序在这部分也存在一定的差异；

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

整体架构设计

该解决方案是基于芋头1.3版实现的，其他Mini程序框架也可以使用相同的方法修改。根据现有的塔罗，不可能将一个源代码包装到同一类型的多个小程序中。因此，对现有的配置层进行扩展，增加适配层来处理每个小程序的不同点，最终实现直接封装成多个不同的小程序，整体架构主要分为四层：

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

b) 源码层指具体业务代码和通用解决方案，不详细介绍；

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

d）包装层与配置层结合使用，用于打包最终递送结果；

以新房子的建筑图为例：

1.配置层处理

1）打包脚本配置

为了支持多个小程序的开发，需要在.json中添加它以区分环境。这里我们使用-env包来设置。例如，包装58个城市小程序时，添加环境变量=。

{ "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",}

然后在`/.js`中配置，在编译时配置一些全局变量，以便在代码中使用。这里的配置将用于打包的差异化处理。我们在编译时配置大多数差异化配置，这有助于减少包装代码的大小。原理是通过两个插件的配合来删除无法访问的代码，保证未使用的代码不会被打包。

config.defineConstants = { WEAPPSOURCE: JSON.stringify(process.env.WEAPPSOURCE), WBWEAPP: '"wbweapp"', AJKWEAPP: '"ajkweapp"',}

2）差异化风格处理

现有业务中，需要同时支持58同城和安居客两个品牌。两者之间的页面结构是相同的，但是每个页面都有其自己的主题颜色。我们提取这些差异并将它们变成SASS变量，然后将它们集成到SCSS文件中。通过在编译过程中引入不同的SCSS文件，我们可以切换主题。角色。这里的主要内容是配置``.. sass。

const sassConfig = { wbweapp: '../wbweapp.scss', ajkweapp: '../ajkweapp.scss'}config.plugins.sass.resource = path.resolve(__dirname, sassConfig[process.env.WEAPPSOURCE])

3）差异化页面处理

源码层会包含所有场景的所有页面，但每个场景所需的页面只是其中的一部分，需要区分。处理方法与上述相同，差异很小。编译和包装期间的配置不同。在“ app.tsx”中，决定介绍哪些页面。我们通过将环境变量传递到按需配置和包装来找到相应的配置页面。

`/.js` 中的配置：

const pagesConfig = { wbweapp: ['pages/a'], ajkweapp: ['pages/b']}config.defineConstants = { PAGES: JSON.stringify(pagesConfig[process.env.WEAPPSOURCE])}

`app.tsx` 中的配置：

class App extends Component { config: Config = { pages: PAGES, }}

2. 适配层处理

1）差异化功能处理

功能的差异化处理是使用配置层定义的全局变量完成的。伪代码如下：

import TabBar from '../components/tabbar';export default class _C extends Component { render() { return {(WEAPPSOURCE == WBWEAPP) && } }}

以这种方式写入！==时，该组件不会打包到最终代码中，WXML文件中的代码块也不会包装到最终代码中。以上不需要特殊处理。打包时会分析依赖关系，最终不使用的文件不会被编译。

2）接口的统一封装

各平台小程序中，常用功能应统一管理。例如，对于用户信息，当用户在58同城小程序内登录时，各商家可以获得统一的用户信息，而不用进入新家页面后再次登录新家。这些功能由平台提供，业务方可以调用。但各个平台存在差异，这些差异由适配层统一封装，为业务开发提供一致的接口。

例如，获取城市信息：

export const getCityInfo = () => { if (WEAPP_SOURCE == WBWEAPP) { city_info = WBIndex.WB.getCityInfo() } else if (WEAPP_SOURCE == AJKWEAPP) { city_info = AJKIndex.Common.getCityInfo(); } }

原理分析

通过上面的介绍，我们差异化发展的需求就已经解决了。同时适配层平滑了平台接口的差异，业务开发无需关心环境。你可能会好奇，如果把所有的小程序代码集中在一起管理，最终打包后的代码大小是不是最优的？主要有以下两点：

1）开发时注意使用条件编译删除不必要的代码；

2）打包时进行依赖分析和打包优化，业务层要做的事情尽量少；

依赖性分析和优化工作主要由 @/CLI软件包完成。简化流程图如下：

首先，解析入口文件“app.tsx”。通过两次语法转换和一次语法遍历，得到依赖的样式文件、依赖的js文件、app配置等，以及入口文件app.js。该样式文件被编译到最终app.css中。依赖的JS文件被复制或生成，并将其放置在指定的目录中。应用程序配置生成app.json。

两种语法转换是不同的。第一个是通用的语法转换，例如JSX语法处理。第二次是差异化转换，根据当前转换类型是入口文件、页面文件还是组件文件，会进行一些特殊处理。第二次转换时使用了-----插件，会删除不必要的依赖引入。尽管上述组件是引入的，但它们不会在不必要的情况下包装。您需要注意此处导入的文件，不应有副作用。

解析条目文件后，将获得应用程序配置的列表。页面文件列表会循环同样的流程，获取页面样式、js、配置等，以及依赖组件列表。

组件文件的包装过程基本上与页面的包装过程相同。不同之处在于组件依赖于其他组件。

了解了整个封装流程之后，上面问题的答案就变得更加清晰了。不在配置中的页面不会被打包输出，不依赖的文件也不会被打包。

与平台小程序集成

小程序最终集成发布有独立发布、插件集成、分包集成三种方式。

多个小程序不同的集成方案

1.插件集成发布

如果通过小程序插件集成，平台小程序可以将接口统一挂载到插件变量上，将两者桥接起来。

插件的.js设置（上面介绍的文件）：

module.exports = {WB: {},}

平台小程序接口注入方法：

const plugin = requirePlugin("xinfang");plugin.WB = { getCityInfo: function() {}}

2. 分包和集成发布

如果是分包集成，可以考虑直接在App中挂载接口。

平台小程序接口注入方法（上图（））：

（）.. =（）{}

使用分包集成方案时需要注意，因为双方在各自的仓库下分别开发，最终需要一起打包发布。目前我们采用的解决方案是配置`.`将结果代码打包到平台小程序仓库中，通过git进行管理，然后由平台小程序发布。

3.独立小程序发布

解决方案与分包集成发布相同，但API是自己提供的，也挂载在App中，同时扮演平台侧和业务侧的角色。