用戶
 找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

掃一掃,登錄網站

小程序社區 首頁 教程 實戰教程 查看內容

小程序時代:如何跨多小程序開發協作?

Rolan 2020-2-20 00:31

導語小程序端越來越多, 跨平臺開發框架逐漸成為開發小程序的主流, 目前跨平臺開發有較多的開源解決方案,本文介紹一種簡單而有效的方法,解決復雜小程序的跨團隊開發協作,希望對你有所幫助。背景目前市面上小程序 ...

導語

小程序端越來越多, 跨平臺開發框架逐漸成為開發小程序的主流 , 目前跨平臺開發有較多的開源解決方案 ,本文介紹一種簡單而有效的方法,解決復雜小程序的跨團隊開發協作,希望對你有所幫助。

背景

目前市面上小程序端越來越多,跨平臺開發框架逐漸成為開發小程序的主流。目前跨平臺開發有較多的開源解決方案,比如美團點評的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.  配置層處理

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) 差異性樣式處理

在現有業務中,需要同時支持58同城和安居客兩個品牌。二者之間頁面結構是一致的,但各自有些主題色,我們將這部分差異抽取出來,變成Sass變量,然后整合至一個scss文件中,通過編譯時引入不同的scss文件,來達到切換主題的作用。這里主要是配置`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)差異化頁面處理

源碼層中會包含所有場景下的全量頁面,但每個場景所需的頁面只是其中的一部分,需要做差異化處理。處理方法同上,略有差異點,通過編譯打包時pages的配置不同,在`app.tsx`中的pages是決定引入哪些頁面,我們通過傳入環境變量找到對應的配置頁面,實現按需配置打包。

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

功能的差異化處理,使用配置層定義的全局變量來做,偽代碼如下:

import TabBar from '../components/tabbar';

export default class _C extends Component {

render() {

return {(WEAPPSOURCE == WBWEAPP) && <TabBar/>}

}

}

這樣寫的話,當WEAPPSOURCE !== WBWEAPP時,TabBar組件不會被打包到最終代碼中,wxml文件中TabBar的代碼塊也不會有。上面的import是不需要做特殊處理,打包時會分析依賴關系,沒有被最終使用的文件不會被編譯。

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)  在打包時做依賴分析及打包優化,業務層盡可能做更少的事情;

依賴分析優化工作主要是由@tarojs/cli包來完成的,簡化后的流程圖如下:

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

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

解析完入口文件后,會得到app配置的pages列表,頁面文件列表循環通過同樣的過程,得到頁面的樣式、js、配置等,以及所依賴的組件列表。

組件文件的打包過程跟頁面是基本一致的,區別點在于組件會依賴其他組件。

理解了整個打包的流程,上面的問題答案就比較清晰了,不在pages配置里的頁面是不會最終打包輸出的,沒有被依賴到的文件也是不會經過打包處理的。

與平臺小程序集成

小程序最終的集成發布有三種方式:獨立發布、插件集成、分包集成。

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

1. 插件集成發布

如果是通過小程序插件方式集成,平臺小程序可以將接口統一掛載到插件的變量中,二者就橋接上了。

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

module.exports = {

WB: {},

}

平臺小程序接口注入方法:

const plugin = requirePlugin("xinfang");

plugin.WB = {

getCityInfo: function() {}

}

2. 分包集成發布

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

平臺小程序接口注入方法(上文AJKIndex即為getApp()):

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

采用分包集成方案的話需要注意,因為雙方是在各自倉庫下分別開發的,最終需要和到一起進行打包發布。目前我們采用的方案是配置`config.outputRoot`將結果代碼打包到平臺小程序倉庫中,通過git管理,再由平臺小程序做發布。

3.獨立小程序發布

方案跟分包集成發布是一致的,不過API由自己提供,也掛載在App中,同時扮演了平臺方和業務方。

實踐經驗分享

a) 小程序包依賴的json文件的處理,比如插件需要有插件配置文件`plugin/plugin.json`??赏ㄟ^配置`config.copy.patterns`指定需要拷貝的文件或者目錄來實現;

b) 小程序是插件和分包處理,在不同場景下的頁面跳轉路徑是不一樣的,但其實相對的路徑是一致的,在于跳轉前綴不同,可將頁面跳轉統一封裝到適配層,根據環境變量適配不同的加上對應的前綴,當需要由插件切換到分包時,跳轉部分僅需修改前綴,無需額外處理;

問題解決

前面提到一處開發多處運行的難題,得到了一一解決,整理如下:

a) 源碼層面無法進行跨團隊協作開發?

團隊間分倉庫開發,最終代碼通過微信插件方式,或者分包方式進行集成。

b) 業務方與平臺方之間的如何解耦?

通過統一的API,進行橋接,無其他耦合,API根據集成方式的不同,有不同的掛載方案。

c) 如何進行差異化開發?

針對樣式差異化,配置差異化,功能差異化均給出了方法。

d) 如何保證打包結果是最優的?

盡可能的利用編譯時的條件編譯方法,排除不必要代碼。

e) 平臺方接口的差異性如何牟平?

增加了適配層,對業務提供一致的輸入輸出接口。

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

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

總結與規劃

本文介紹了在較復雜的小程序業務場景中,跨多小程序跨團隊的協作方案,該方案幫助了新房業務在多小程序中的快速落地及迭代。

在實現了“58同城”小程序中的新房業務接入后,我們又做了“58同鎮”的新房業務對接。只需要“58同鎮”小程序提供一致的基礎能力接口,即可輕松接入。

本文內容主要為業務經驗積累,整體方案易于實施,帶來的業務開發提效卻是顯著的,希望能幫助到大家。實際業務落地過程中,還有較多的細節需要處理,無法一一列舉,歡迎提問或咨詢。

文中僅介紹了業務在微信小程序的實踐情況,實際上在百度小程序以及H5也已有相應落地實踐,具備了一定的通用性,可以放心使用。

隨著業務覆蓋的范圍越來越廣,適配層會越來越復雜,不利于維護,更有效的方案是把業務實踐總結為一套通用的接口標準,各個小程序按統一標準來實現API,業務方可以不關心所處環境的差異性,進一步提高跨團隊開發的協作效率。 

參考文獻

1. https://www.npmjs.com/package/cross-env

2. https://nervjs.github.io/taro/docs/config.html

3. https://webpack.js.org/plugins/define-plugin/

4. https://www.npmjs.com/package/uglifyjs-webpack-plugin

5. https://github.com/mishoo/UglifyJS2#compress-options 

作者簡介

陳志慶 58同城資深研發工程師

葉春喜 58同城高級研發工程師

鮮花
鮮花
雞蛋
雞蛋
分享至 : QQ空間
收藏
原作者: 陳志慶、葉春喜 來自: 58技術
上证指数十年走势图