小程序時(shí)代：如何跨多小程序開(kāi)發(fā)協(xié)作?現(xiàn)在是小程序的時(shí)代，自從出了微信小程序后，這幾年隨著互聯(lián)網(wǎng)的發(fā)展，也出現(xiàn)了很多其它小程序的迭代更新的發(fā)展，如百度小程序，頭條小程序，抖音小程序等等，以后跨多小程序開(kāi)發(fā)協(xié)作是額外的發(fā)展趨勢(shì)，而且這股趨勢(shì)就在當(dāng)下。今天作為長(zhǎng)沙小程序的專業(yè)公司智企云就來(lái)跟我們一起分享解讀一下如何跨多小程序開(kāi)發(fā)協(xié)作?主要是以58為案例，希望對(duì)你能有所幫助。

　　小程序端越來(lái)越多，跨平臺(tái)開(kāi)發(fā)框架逐漸成為開(kāi)發(fā)小程序的主流，目前跨平臺(tái)開(kāi)發(fā)有較多的開(kāi)源解決方案，本文介紹一種簡(jiǎn)單而有效的方法，解決復(fù)雜小程序的跨團(tuán)隊(duì)開(kāi)發(fā)協(xié)作，希望對(duì)你有所幫助。

　　背景

　　目前市面上小程序端越來(lái)越多，跨平臺(tái)開(kāi)發(fā)框架逐漸成為開(kāi)發(fā)小程序的主流。目前跨平臺(tái)開(kāi)發(fā)有較多的開(kāi)源解決方案，比如美團(tuán)點(diǎn)評(píng)的mpvue、滴滴的Chameleon、凹凸實(shí)驗(yàn)室的Taro等，都做得比較好。這些框架幫我們解決了一處開(kāi)發(fā)，多處運(yùn)行的難點(diǎn)。但是在復(fù)雜的業(yè)務(wù)場(chǎng)景中，最終落地也存在著許多困難，需要自己解決。以58房產(chǎn)的新房業(yè)務(wù)小程序?yàn)槔?，?shí)際的業(yè)務(wù)場(chǎng)景中，既需要有獨(dú)立承載功能的“58同城新房樓盤精選”小程序，也有依托于其他流量平臺(tái)的入口，比如在“58同城”、“安居客買房”等都有相應(yīng)的新房業(yè)務(wù)，同時(shí)還有交叉的業(yè)務(wù)場(chǎng)景，比如在同經(jīng)紀(jì)人業(yè)務(wù)結(jié)合的“安居客經(jīng)紀(jì)人網(wǎng)店”中展示新房樓盤。這其中既有微信小程序，也有百度小程序。

　　這些業(yè)務(wù)有較多的共同點(diǎn)，比如基礎(chǔ)功能邏輯是一致的，但是也存在很多差異性，比如商業(yè)邏輯，頁(yè)面皮膚以及一些差異功能點(diǎn)。

　　新房首頁(yè)對(duì)比

　　上圖為三個(gè)小程序的首頁(yè)對(duì)比，可以看到獨(dú)立的小程序“58同城新房樓盤精選”集成了賬號(hào)、城市、消息，在“58同城”和“安居客買房”這些能力則是依賴主體小程序。另外三個(gè)小程序之間還有些細(xì)微差別，但是樓盤相關(guān)的基礎(chǔ)功能確是相同的。

　　一處開(kāi)發(fā)多處運(yùn)行的難題

　　作為業(yè)務(wù)方，我們希望業(yè)務(wù)代碼也可以一處開(kāi)發(fā)，到處運(yùn)行。方案設(shè)計(jì)之時(shí)，我們的目標(biāo)便是業(yè)務(wù)代碼在同一倉(cāng)庫(kù)管理，同時(shí)方案具備較大的靈活性以適配各種環(huán)境。

　　在上述的背景下，實(shí)際開(kāi)發(fā)中會(huì)遇到如下困難：

　　a) 各個(gè)小程序歸屬的開(kāi)發(fā)團(tuán)隊(duì)不一樣，使用的開(kāi)發(fā)方案也不一樣，有原生開(kāi)發(fā)、wepy、Taro、mpvue等，意味著在源碼層面是難以進(jìn)行協(xié)作開(kāi)發(fā)的;

　　b) 業(yè)務(wù)方與平臺(tái)方之間是跨團(tuán)隊(duì)協(xié)作，需要盡量減少耦合，提高協(xié)作效率，同時(shí)避免相互影響;

　　c) 需要具備在各個(gè)小程序環(huán)境中的差異化開(kāi)發(fā)方案;

　　d) 所有業(yè)務(wù)代碼同一地方管理，意味著會(huì)有不必要的代碼，需要有機(jī)制保障最終的打包結(jié)果大小是最優(yōu)的;

　　e) 在不同平臺(tái)小程序中，會(huì)依賴他們各自提供的基礎(chǔ)能力，比如賬戶體系，消息等，這部分在各平臺(tái)小程序中也存在著一定差異性;

　　f) 在不同場(chǎng)景下需要具備不同的接入方案，支持微信插件方式接入平臺(tái)小程序，也要支持業(yè)務(wù)分包方式接入平臺(tái)小程序。

　　整體架構(gòu)設(shè)計(jì)

　　本方案基于Taro 1.3版本實(shí)現(xiàn)，其他小程序框架也可使用相同的方法做改造。在現(xiàn)有Taro基礎(chǔ)上，無(wú)法支持到一份源碼打包成多個(gè)同類型的小程序，因此在現(xiàn)有配置層進(jìn)行擴(kuò)展處理，并添加適配層，對(duì)于各個(gè)小程序不同點(diǎn)進(jìn)行處理，最終實(shí)現(xiàn)直接打包到多個(gè)不同的小程序中，整體的架構(gòu)主要分為四層：

　　a) 配置層，用于解決在不同場(chǎng)景下的差異化，包括環(huán)境變量、主題樣式、頁(yè)面配置等;

　　b) 源碼層，為具體的業(yè)務(wù)代碼，常見(jiàn)方案，不做具體介紹;

　　c) 適配層，用于對(duì)接不同方案下小程序提供的接口，并牟平不同小程序提供的接口差異，為源碼層提供統(tǒng)一的接口;

　　d) 打包層，與配置層相結(jié)合，用于打包最終交付結(jié)果;

　　以新房為例的架構(gòu)圖：

　　1. 配置層處理

　　1) 打包腳本配置

　　若要支持多小程序開(kāi)發(fā)，需在package.json中增加scripts，用于區(qū)分環(huán)境。這里我們用的是cross-env這個(gè)包來(lái)設(shè)置，比如在打包58同城小程序時(shí)，加入環(huán)境變量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，用來(lái)配置一些編譯時(shí)的全局變量供代碼中使用，這里的配置會(huì)用于做打包的差異化處理。大部分的差異化配置，我們都放到了編譯時(shí)來(lái)進(jìn)行配置，有助于降低代碼打包后的大小。其原理是通過(guò)webpack的define-plugin和uglifyjs-webpack-plugin兩個(gè)插件配合來(lái)刪除掉不可達(dá)代碼，保證不使用的代碼不會(huì)被打包。

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

　　2) 差異性樣式處理

　　在現(xiàn)有業(yè)務(wù)中，需要同時(shí)支持58同城和安居客兩個(gè)品牌。二者之間頁(yè)面結(jié)構(gòu)是一致的，但各自有些主題色，我們將這部分差異抽取出來(lái)，變成Sass變量，然后整合至一個(gè)scss文件中，通過(guò)編譯時(shí)引入不同的scss文件，來(lái)達(dá)到切換主題的作用。這里主要是配置`config/index.js`中的`config.plugins.sass.resource` 。

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

　　3)差異化頁(yè)面處理

　　源碼層中會(huì)包含所有場(chǎng)景下的全量頁(yè)面，但每個(gè)場(chǎng)景所需的頁(yè)面只是其中的一部分，需要做差異化處理。處理方法同上，略有差異點(diǎn)，通過(guò)編譯打包時(shí)pages的配置不同，在`app.tsx`中的pages是決定引入哪些頁(yè)面，我們通過(guò)傳入環(huán)境變量找到對(duì)應(yīng)的配置頁(yè)面，實(shí)現(xiàn)按需配置打包。

　　`config/index.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) 差異化功能處理

　　功能的差異化處理，使用配置層定義的全局變量來(lái)做，偽代碼如下：

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

　　這樣寫(xiě)的話，當(dāng)WEAPPSOURCE !== WBWEAPP時(shí)，TabBar組件不會(huì)被打包到最終代碼中，wxml文件中TabBar的代碼塊也不會(huì)有。上面的import是不需要做特殊處理，打包時(shí)會(huì)分析依賴關(guān)系，沒(méi)有被最終使用的文件不會(huì)被編譯。

　　2) 接口統(tǒng)一封裝處理

　　在各個(gè)平臺(tái)方小程序中，通用功能都應(yīng)該是統(tǒng)一管理的。比如用戶信息，用戶在58同城小程序內(nèi)進(jìn)行登錄，各業(yè)務(wù)都能拿到統(tǒng)一的用戶信息，而不是進(jìn)入新房頁(yè)面后再做一次新房的登錄。這些功能，由平臺(tái)方提供接口，供業(yè)務(wù)方調(diào)用。但各個(gè)平臺(tái)存在差異性，這些差異性就由適配層做統(tǒng)一的封裝，對(duì)業(yè)務(wù)開(kāi)發(fā)提供一致的接口。

　　比如獲取城市信息：

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

　　原理解析

　　通過(guò)以上介紹，已經(jīng)解決了我們對(duì)差異化開(kāi)發(fā)的要求，同時(shí)適配層將平臺(tái)接口差異牟平，業(yè)務(wù)開(kāi)發(fā)也不需要關(guān)心所處環(huán)境。大家可能比較好奇，所有的小程序代碼都放在一起管理，最終打包出來(lái)的代碼大小是不是最優(yōu)的?主要是以下兩點(diǎn)：

　　1) 在開(kāi)發(fā)中注意利用條件編譯來(lái)刪除不必要的代碼;

　　2) 在打包時(shí)做依賴分析及打包優(yōu)化，業(yè)務(wù)層盡可能做更少的事情;

　　依賴分析優(yōu)化工作主要是由@tarojs/cli包來(lái)完成的，簡(jiǎn)化后的流程圖如下：

　　首先是解析入口文件`app.tsx`，通過(guò)兩次語(yǔ)法轉(zhuǎn)換，一次語(yǔ)法遍歷，得到了依賴的樣式文件、依賴的js文件、app的配置等，以及入口文件app.js。樣式文件編譯成最終的app.css，依賴的js文件，通過(guò)拷貝或生成，放到指定的目錄中，app配置生成app.json。

　　兩次語(yǔ)法轉(zhuǎn)換是不一樣的，第一次是通用的語(yǔ)法轉(zhuǎn)換，比如jsx語(yǔ)法的處理。第二次是差異化的轉(zhuǎn)換，會(huì)根據(jù)當(dāng)前轉(zhuǎn)換的類型是入口文件、頁(yè)面文件或組件文件做一些特殊處理。第二次轉(zhuǎn)換時(shí)使用了babel-plugin-danger-remove-unused-import插件，會(huì)刪除不必要的依賴引入。上文提到的TabBar組件，雖然是被引入了，但在不需要的場(chǎng)景下TabBar組件就不會(huì)被打包。這里需要注意引入的文件，不應(yīng)該存在副作用。

　　解析完入口文件后，會(huì)得到app配置的pages列表，頁(yè)面文件列表循環(huán)通過(guò)同樣的過(guò)程，得到頁(yè)面的樣式、js、配置等，以及所依賴的組件列表。

　　組件文件的打包過(guò)程跟頁(yè)面是基本一致的，區(qū)別點(diǎn)在于組件會(huì)依賴其他組件。

　　理解了整個(gè)打包的流程，上面的問(wèn)題答案就比較清晰了，不在pages配置里的頁(yè)面是不會(huì)最終打包輸出的，沒(méi)有被依賴到的文件也是不會(huì)經(jīng)過(guò)打包處理的。

　　與平臺(tái)小程序集成

　　小程序最終的集成發(fā)布有三種方式：獨(dú)立發(fā)布、插件集成、分包集成。

　　多個(gè)小程序的不同集成方案

　　1. 插件集成發(fā)布

　　如果是通過(guò)小程序插件方式集成，平臺(tái)小程序可以將接口統(tǒng)一掛載到插件的變量中，二者就橋接上了。

　　插件的index.js設(shè)置(上文WBIndex即為引入的此文件)：

　　module.exports = {WB: {},}

　　平臺(tái)小程序接口注入方法：

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

　　2. 分包集成發(fā)布

　　如果是分包集成的話，可以考慮將接口直接掛載在App中。

　　平臺(tái)小程序接口注入方法(上文AJKIndex即為getApp())：

　　getApp().Common.getCityInfo = function() {}

　　采用分包集成方案的話需要注意，因?yàn)殡p方是在各自倉(cāng)庫(kù)下分別開(kāi)發(fā)的，最終需要和到一起進(jìn)行打包發(fā)布。目前我們采用的方案是配置`config.outputRoot`將結(jié)果代碼打包到平臺(tái)小程序倉(cāng)庫(kù)中，通過(guò)git管理，再由平臺(tái)小程序做發(fā)布。

　　3.獨(dú)立小程序發(fā)布

　　方案跟分包集成發(fā)布是一致的，不過(guò)API由自己提供，也掛載在App中，同時(shí)扮演了平臺(tái)方和業(yè)務(wù)方。

　　實(shí)踐經(jīng)驗(yàn)分享

　　a) 小程序包依賴的json文件的處理，比如插件需要有插件配置文件`plugin/plugin.json`?？赏ㄟ^(guò)配置`config.copy.patterns`指定需要拷貝的文件或者目錄來(lái)實(shí)現(xiàn);

　　b) 小程序是插件和分包處理，在不同場(chǎng)景下的頁(yè)面跳轉(zhuǎn)路徑是不一樣的，但其實(shí)相對(duì)的路徑是一致的，在于跳轉(zhuǎn)前綴不同，可將頁(yè)面跳轉(zhuǎn)統(tǒng)一封裝到適配層，根據(jù)環(huán)境變量適配不同的加上對(duì)應(yīng)的前綴，當(dāng)需要由插件切換到分包時(shí)，跳轉(zhuǎn)部分僅需修改前綴，無(wú)需額外處理;

　　問(wèn)題解決

　　前面提到一處開(kāi)發(fā)多處運(yùn)行的難題，得到了一一解決，整理如下：

　　a) 源碼層面無(wú)法進(jìn)行跨團(tuán)隊(duì)協(xié)作開(kāi)發(fā)?

　　團(tuán)隊(duì)間分倉(cāng)庫(kù)開(kāi)發(fā)，最終代碼通過(guò)微信插件方式，或者分包方式進(jìn)行集成。

　　b) 業(yè)務(wù)方與平臺(tái)方之間的如何解耦?

　　通過(guò)統(tǒng)一的API，進(jìn)行橋接，無(wú)其他耦合，API根據(jù)集成方式的不同，有不同的掛載方案。

　　c) 如何進(jìn)行差異化開(kāi)發(fā)?

　　針對(duì)樣式差異化，配置差異化，功能差異化均給出了方法。

　　d) 如何保證打包結(jié)果是最優(yōu)的?

　　盡可能的利用編譯時(shí)的條件編譯方法，排除不必要代碼。

　　e) 平臺(tái)方接口的差異性如何牟平?

　　增加了適配層，對(duì)業(yè)務(wù)提供一致的輸入輸出接口。

　　f) 支持不同平臺(tái)小程序的多種接入方案?

　　支持了插件接入與分包接入。

　　長(zhǎng)沙小程序開(kāi)發(fā)公司智企云總結(jié)與規(guī)劃

　　本文介紹了在較復(fù)雜的小程序業(yè)務(wù)場(chǎng)景中，跨多小程序跨團(tuán)隊(duì)的協(xié)作方案，該方案幫助了新房業(yè)務(wù)在多小程序中的快速落地及迭代。

　　在實(shí)現(xiàn)了“58同城”小程序中的新房業(yè)務(wù)接入后，我們又做了“58同鎮(zhèn)”的新房業(yè)務(wù)對(duì)接。只需要“58同鎮(zhèn)”小程序提供一致的基礎(chǔ)能力接口，即可輕松接入。

　　本文內(nèi)容主要為業(yè)務(wù)經(jīng)驗(yàn)積累，整體方案易于實(shí)施，帶來(lái)的業(yè)務(wù)開(kāi)發(fā)提效卻是顯著的，希望能幫助到大家。實(shí)際業(yè)務(wù)落地過(guò)程中，還有較多的細(xì)節(jié)需要處理，無(wú)法一一列舉，歡迎提問(wèn)或咨詢。

　　文中僅介紹了業(yè)務(wù)在微信小程序的實(shí)踐情況，實(shí)際上在百度小程序以及H5也已有相應(yīng)落地實(shí)踐，具備了一定的通用性，可以放心使用。

　　隨著業(yè)務(wù)覆蓋的范圍越來(lái)越廣，適配層會(huì)越來(lái)越復(fù)雜，不利于維護(hù)，更有效的方案是把業(yè)務(wù)實(shí)踐總結(jié)為一套通用的接口標(biāo)準(zhǔn)，各個(gè)小程序按統(tǒng)一標(biāo)準(zhǔn)來(lái)實(shí)現(xiàn)API，業(yè)務(wù)方可以不關(guān)心所處環(huán)境的差異性，進(jìn)一步提高跨團(tuán)隊(duì)開(kāi)發(fā)的協(xié)作效率。