58安居客小程序平臺化與多小程序開發(fā)探索與實踐

發(fā)表時間：2021-1-11

發(fā)布人：葵宇科技

瀏覽次數(shù)：125

導(dǎo)語

本文分享58安居客小程序團(tuán)隊在小程序向平臺化轉(zhuǎn)型、多小程序同步開發(fā)過程中遇到的問題、解決方案與實踐。

背景

在提效、服務(wù)進(jìn)階的大背景下，為了讓同一支團(tuán)隊，把一個業(yè)務(wù)做精做深，提高研發(fā)效率，HBG的產(chǎn)研團(tuán)隊，進(jìn)行了新的劃分：分線開發(fā)。

分線開發(fā)以后，安居客二手房前端團(tuán)隊要維護(hù)小程序從 1 變成 4 個。

小程序	技術(shù)棧
安居客微信小程序	微信原生開發(fā)
安居客百度小程序	百度原生開發(fā)
58二手房小程序	mpvue
58同城小程序房產(chǎn)二手房業(yè)務(wù)	插件方式接入，技術(shù)不限

與此同時，隨著移動互聯(lián)網(wǎng)的流量紅利逐步減少，小程序無疑是新的流量風(fēng)口，為了搶占更多免費流量，推動業(yè)務(wù)快速發(fā)展，產(chǎn)品希望我們安居客微信、百度小程序可以同步開發(fā)，以及未來可以支持更多小程序，如快應(yīng)用等。

在多小程序技術(shù)框架不同、業(yè)務(wù)邏輯不同、基礎(chǔ)能力不同的情況下，給我們的小程序開發(fā)帶來了以下挑戰(zhàn)：

1、在人力不變的情況下，我們要如何支持多個小程序業(yè)務(wù)需求快速迭代？

2、作為平臺方，我們要如何與業(yè)務(wù)方協(xié)作開發(fā)？

3、如何支持房產(chǎn)垂直業(yè)務(wù)在其他小程序平移？

面對這種變化，我們聯(lián)合房產(chǎn)各業(yè)務(wù)前端、產(chǎn)品、UED、QA等多個團(tuán)隊，一起發(fā)起了小程序七巧板項目，也開啟了58安居客小程序打怪升級刷新副本之路，接下來我將娓娓道來我們是如何刷新副本的。

現(xiàn)狀分析與設(shè)計

1、現(xiàn)狀分析

面對多小程序同步開發(fā)的需求，我們應(yīng)該如何做呢？

1）方案一：按照小程序端配備開發(fā)資源，迭代開發(fā)速度不變，人力需要成倍增加。雖然技術(shù)不用做大的改動，但是人力成本太高。

2）方案二：做技術(shù)升級改造，實現(xiàn)技術(shù)棧業(yè)務(wù)的統(tǒng)一。房產(chǎn)小程序其中包含了很多業(yè)務(wù)（租房、商業(yè)地產(chǎn)、二手房、新房），幾百個頁面，大家都停下業(yè)務(wù)去做技術(shù)棧的統(tǒng)一，顯然是不現(xiàn)實的。

考慮到這些實際情況，技術(shù)方案上只能考慮邊做業(yè)務(wù)邊重構(gòu)，逐步去做統(tǒng)一。

2、整體設(shè)計

從業(yè)務(wù)方的角度來看，我們希望所有小程序平臺盡可能提供相同的通用能力，減少業(yè)務(wù)的適配，業(yè)務(wù)開發(fā)只需關(guān)心業(yè)務(wù)開發(fā)，以及實現(xiàn)多小程序端的適配。

從平臺方的角度來說，盡可能為業(yè)務(wù)方提供便利，減少兼容和適配成本。

針對以上情況，我們做出如下設(shè)計：

小程序七巧板架構(gòu)圖

不難看出：

1）作為平臺方，我們有以下任務(wù)：

A、多小程序提供統(tǒng)一通用平臺能力接口，即宿主環(huán)境。

B、統(tǒng)一基礎(chǔ)能力，減少宿主環(huán)境的適配

C、統(tǒng)一宿主小程序，從而達(dá)到可以快速落地其他小程序目標(biāo)。

2）作為業(yè)務(wù)方，實現(xiàn)二手房業(yè)務(wù)可在多小程序同步開發(fā)。

為了支持業(yè)務(wù)的快速落地，所以我們把平臺建設(shè)優(yōu)先級排在第一位。接下來我將從平臺化以及二手房業(yè)務(wù)適配多小程序開發(fā)兩個維度來闡述。

小程序平臺化建設(shè)

1、確認(rèn)業(yè)務(wù)方接入方式

截止到目前為止，僅微信平臺支持插件，百度和輕應(yīng)用等暫不支持插件。

考慮到插件和分包的特點以及各業(yè)務(wù)實際情況，作為平臺方我們插件和分包的接入方式均做了支持。業(yè)務(wù)方可根據(jù)自身業(yè)務(wù)場景，選擇合適的接入方式。

2、確認(rèn)平臺通用能力

宿主環(huán)境要解決什么問題？

1）提供平臺基礎(chǔ)能力和公共方法的調(diào)用

2）抹平不同平臺的差異

3）支持業(yè)務(wù)插件和分包無縫切換

4）一套代碼在宿主環(huán)境中一次測試，多端上線

梳理清楚我們要做什么之后，緊接著進(jìn)入緊鑼密鼓的調(diào)研設(shè)計中，通過全方位調(diào)研我們得知， 58同城微信小程序已經(jīng)有開發(fā)過宿主環(huán)境，但無通用SDK。房產(chǎn)的宿主環(huán)境要兼容房產(chǎn)多個小程序之間的差異，有很重業(yè)務(wù)屬性，也不能復(fù)用58同城宿主。

所以最終我們的宿主環(huán)境設(shè)計如下：

1）支持新老開發(fā)方式共存，推薦使用基于宿主環(huán)境開發(fā)

2） API方法名、出參、入?yún)⒑?8同城小程序宿主保持一致

3）安居客特有業(yè)務(wù)，加入新的API

4）提供完整demo、完善的文檔、測試環(huán)境

3、技術(shù)選型

工欲善其事必先利其器，要同時開發(fā)多個小程序以及未來可能要支持更多小程序，借助一些優(yōu)秀的框架進(jìn)行開發(fā)，一定會事半功倍。調(diào)研了Taro、WePY、uni-app、mpvue、chameleon、百度小程序轉(zhuǎn)換工具以及其他工具，結(jié)合團(tuán)隊實際情況，最后我們選擇Taro作為我們的開發(fā)框架。選擇Taro的主要原因：

1）支持逐步替換，降低項目風(fēng)險

2）團(tuán)隊有React 開發(fā)經(jīng)驗，也要維護(hù)部分React Native業(yè)務(wù)，技術(shù)棧盡量統(tǒng)一

3）支持動態(tài)編譯、條件編譯，可實現(xiàn)定制化58、安居客主題皮膚

4）提供轉(zhuǎn)換工具，可把現(xiàn)有微信小程序直接轉(zhuǎn)成 Taro，降低遷移成本

5）庫維護(hù)更新比較穩(wěn)定，社區(qū)活躍

4、小程序基礎(chǔ)能力統(tǒng)一

隨著宿主環(huán)境需求分析、技術(shù)選型、開發(fā)完成以及配合業(yè)務(wù)方接入過程中，為了減少業(yè)務(wù)方的適配，我們通用能力做了三個統(tǒng)一：

1）賬號體系：統(tǒng)一接入云賬號，統(tǒng)一賬號體系

2）微聊：統(tǒng)一多小程序微聊接入方式和版本以及通用能力，減少宿主和業(yè)務(wù)的適配

3）與TEG在云賬號、微聊等基礎(chǔ)公共能力上，盡量保持多小程序在接入方式、接口設(shè)計上統(tǒng)一，減少接入成本。

5、小程序性能優(yōu)化

前期我們以宿主環(huán)境的開發(fā)、支持業(yè)務(wù)快速接入為主，隨著業(yè)務(wù)逐步灰度接入，小程序的包大小也越來越大，性能問題也越來越明顯，以微信小程序為例，我們發(fā)現(xiàn)：

1）小程序包大小越來越大

2）小程序下載耗時明顯增加

3）小程序啟動耗時明顯增加

那么如何優(yōu)化呢？通讀了一遍官網(wǎng)的性能優(yōu)化文檔，總結(jié)出性能優(yōu)化的三大塊

1）包體積優(yōu)化（分包、圖片CDN、延遲非必須插件、分包預(yù)加載等）

2）請求優(yōu)化（請求次數(shù)、請求階段等）

3）首次渲染優(yōu)化（setData優(yōu)化、DOM渲染優(yōu)化等）

問題又來了，如何來找出我們的小程序，這三大塊需要優(yōu)化的具體影響點在哪里？

在開發(fā)工具中使用help()方法，使用其中的openVendor方法打開開發(fā)工具在小程序框架所在目錄。其中有包括以基礎(chǔ)庫命名的目錄和其他幫助文件。如其中有兩個工具wcc和wcsc。wcc工具可把 wxml 轉(zhuǎn)換為對應(yīng)的 JS 函數(shù)$gwx(path, global)，wcsc 可將 wxss 轉(zhuǎn)換為 css。而基礎(chǔ)庫目錄包括WAService.js 和 WAWebview.js 文件。結(jié)合開發(fā)者工具命令行中使用document.head可以查看小程序的整個啟動流程大致如下：

結(jié)合微信包的啟動流程和微信開發(fā)工具的Sources、Audits面板進(jìn)行性能分析。我們發(fā)現(xiàn)可以通過以下幾種方式來進(jìn)行了優(yōu)化：

1）減少包的文件大小

A、小程序本地圖片一律替換成從CDN加載

B、在平臺化過程中，隨著業(yè)務(wù)接入、灰度、全量上線，及時下掉老代碼

C、刪除歷史無用代碼

D、延遲第三方依賴的加載

2）優(yōu)化首屏數(shù)據(jù)請求，來加速首屏速度選擇。首屏非必須的數(shù)據(jù)，延遲加載

3）優(yōu)化 setData存儲和調(diào)用

A、減少 setData 的頻繁調(diào)用

B、減少 data 上的數(shù)據(jù)冗余，非必要數(shù)據(jù)不要在 data 上存儲

接下來，以安居客微信小程序為例，介紹一下針對延遲第三方依賴的加載，我們是如何做優(yōu)化的：

1）業(yè)務(wù)插件肯定是要延遲加載的，插件在各業(yè)務(wù)分包引入，這點毋庸置疑

2）賬號體系，我們是直接對接云賬號的插件，最開始的做法是在主包中直接引入，文件比較大（434kb）。后續(xù)，云賬號插件做了重構(gòu)和升級，文件大?。?0.5kb，并且支持分包引入。進(jìn)而，我們升級了云賬號插件版本、以分包的方式引入云賬號插件。最終，主包大小減少了 434kb。

3）微聊，安居客微信小程序最開始引入的是微聊 JS SDK、自己實現(xiàn) UI，文件大?。?0kb。為了統(tǒng)一多小程序微聊通用能力和復(fù)用微聊插件現(xiàn)有卡片功能，我們決定微聊統(tǒng)一接入微聊插件，微聊插件大?。?35kb。那我們應(yīng)該如何引入微聊SDK呢？顯而易見，2種方案：

A、直接在主包中引入微聊插件，對主包大小影響比較大，首頁、房源列表等可以拿到微聊消息數(shù)，現(xiàn)有功能不會受到影響。

B、不在主包中引入微聊插件，首頁、房源列表等業(yè)務(wù)拿不到微聊消息數(shù)。

首頁、房源列表效果圖如下圖，那我們該怎么辦呢？

圖左是首頁，圖右是二手房房源列表

針對上述問題和業(yè)務(wù)場景與微聊開發(fā)溝通，他們可以提供一個消息總數(shù)的接口，但是這個消息總數(shù)和微聊插件的總數(shù)可能不一致，業(yè)務(wù)上需要做一下降級，與產(chǎn)品一起溝通之后，也能接受這部分的降級。所以，最后微聊插件SDK，我們以分包的方式做了接入，盡可能的保證了主包的大小以及下載速度。

其他優(yōu)化，就不在這里一一展開了，通過以上初步優(yōu)化，我們可以看到啟動耗時時間、初次渲染時間有了明顯的下降，下圖是我們優(yōu)化后小程序性能變化，后面我們將持續(xù)優(yōu)化，為用戶提供更好的用戶體驗。

小程序下載耗時

小程序初次渲染耗時

6、規(guī)范化、流程化

俗話說的好，打江山容易守江山難，這句話在我們小程序平臺化的過程中也適用。

通過一系列開發(fā)和技術(shù)方案的落地，我們提供了宿主環(huán)境和完整的接入文檔、開發(fā)demo。配合房產(chǎn)各個業(yè)務(wù)方完成了首次接入，希望后面不費吹灰之力的更新版本即可。然而理想是豐滿的，現(xiàn)實很骨感，比如以下問題：

1）開發(fā)過程中遇到宿主環(huán)境的Bug找誰解決

2）平臺方測試和業(yè)務(wù)方測試如何配合

3）業(yè)務(wù)方測試完成后如何交接給平臺方

4）誰負(fù)責(zé)上線，新的需求怎么對接等等

通過解決這些問題并且實際落地實施，我們一起梳理一套完善的標(biāo)準(zhǔn)和規(guī)劃的開發(fā)流程，通過流程的規(guī)范化、標(biāo)準(zhǔn)化，來保證我們項目高效開發(fā)、溝通、以及項目的順利上線。

二手房業(yè)務(wù)跨平臺開發(fā)

隨著平臺化的標(biāo)準(zhǔn)化、統(tǒng)一和完善，不難看出，只要58二手房小程序也接入標(biāo)準(zhǔn)的宿主接口，那么二手房業(yè)務(wù)要適配的小程序的能力基本上就統(tǒng)一了，接下來只需要考慮業(yè)務(wù)的實現(xiàn)即可。

圖左58二手房房源列表，圖右安居客二手房房源列表

通過以上圖片對比，我們發(fā)現(xiàn)業(yè)務(wù)邏輯差異較大，想要同步開發(fā)還存在不少困難，經(jīng)過與產(chǎn)品、UED一起溝通協(xié)商，58、安居客保證頁面結(jié)構(gòu)統(tǒng)一，支持業(yè)務(wù)、皮膚差異性。借助Taro支持多小程序轉(zhuǎn)換，考慮如何實現(xiàn)定制皮膚與實現(xiàn)業(yè)務(wù)差異化即可。整體設(shè)計如下：

打包和集成

1、多程序打包

1）打包配置

我們按平臺、終端打包需要，在 package.json 增加對應(yīng) scripts，然后利用 cross-env這個包來設(shè)置環(huán)境變量，比如在打包安居客微信小程序的時候，設(shè)置環(huán)境變量 WEAPP=anjuke，代碼如下：

{

"scripts": {

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

"dev:weapp": "npm run build:weapp -- --watch",

"build:anjuke": "cross-env WEAPP=anjuke && npm run build:weapp",

"dev:anjuke": "cross-env WEAPP=anjuke && npm run dev:weapp"

}

然后在config/index.js里面利用環(huán)境變量加載對應(yīng)小程序的自定義配置，具體代碼代碼如下：

const WEAPP = process.env.WEAPP ? process.env.WEAPP : 'anjuke'
module.exports = function(merge) {
    return merge({}, config, require(`./${WEAPP}`));
};

此處 config 代表打包通用配置以及默認(rèn)配置。如 babel、源碼目錄等。
為了讓每個平臺、終端打包出來的代碼大小都是最優(yōu)的，利用配置defineConstants 屬性配置編譯時的全局變量，從而實現(xiàn)小程序按照平臺、終端、功能差異上實現(xiàn)條件編譯。我們的實踐是按照業(yè)務(wù)平臺、平臺屬性、小程序終端做了劃分：

const config = {
    defineConstants: {
        PLATFORM, // 網(wǎng)站平臺 anjuke 或 58
        PLATFORM_ABBR, // 小程序名字簡寫，用來區(qū)分同平臺同類型小程序
        RUN_END, // 運行端 weapp、swan、quickapp
        
        IS_AJK, // 是否是 anjuke
        IS_WUBA, // 是否是 58

        IS_WEAPP, // 是否是 微信
        IS_SWAN, // 是否是 百度
        IS_QUICK_APP // 是否是 快應(yīng)用
    }
}

在編譯的時候，根據(jù)目標(biāo)小程序的特性，為上面變量注入對應(yīng)的值。
2）皮膚差異化
二手房業(yè)務(wù)要同時支持58同城、安居客兩個平臺。二者之間頁面結(jié)構(gòu)是一致的，但各自有些主題色，我們將主題色提取成Sass變量，在編譯打包時，按照平臺引入平臺主題色，從而達(dá)到換膚的功能。比如在安居客小程序打包是通過plugins引入安居客主題色：

const path = require("path");
module.exports = {
    plugins: {
        sass: {
            resource: [
                "src/scss/ajktheme.scss"
            ],
            projectDirectory: path.resolve(__dirname, "..")
        }
    }
};

2、 API 適配平臺、業(yè)務(wù)差異

58、安居客在業(yè)務(wù)上存在諸多差異，如賬號鑒權(quán)、城市、房源展示邏輯等，為了保證小程序在多平臺、多終端通用功能統(tǒng)一、前端數(shù)據(jù)展示邏輯統(tǒng)一，API 接口做了平臺、業(yè)務(wù)、端的兼容，統(tǒng)一了數(shù)據(jù)接口格式，間接的支持了小程序一套代碼在多平臺、多端運行。目前我們的落地方案：

1）按照業(yè)務(wù)平臺劃分 API 域名，如安居客小程序接口使用anjuke.om域名，58小程序接口使用58.com域名

2）按照公參區(qū)分終端，如我們通過weapp 公參區(qū)分是百度、微信還是其他小程序

以房源列表為例，之前安居客和58房源展示邏輯、扣費邏輯、API接口數(shù)據(jù)格式等各不相同，重構(gòu)之后，API根據(jù)域名封裝業(yè)務(wù)邏輯，統(tǒng)一接口數(shù)據(jù)輸出格式，比如前端獲取列表數(shù)據(jù)代碼如下：

import { fetchList } from "./api";
fetchList({
    page: this.list.page,
    page_size: PAGE_SIZE,
    user_id: userInfo.userId || "",
    open_id: userInfo.openId || "",
    union_id: userInfo.udid || "",
    ...this.filterOptions
}).then(res => {
    // do some thing
})

然后我們在 api.js 底層針對58、安居客平臺適配一下API接口域名，代碼如下：

import { base } from './config';
const urlBase = isOldAjk => {
  if (IS_WUBA) return base.wbBase;
  if (isOldAjk) return base.oldAjkBase;
  if (IS_AJK) return base.ajkBase;
};

通過API 適配平臺、業(yè)務(wù)邏輯的差異，使前端邏輯在多小程序之間保持獨立、統(tǒng)一，從而達(dá)到多小程序平移的目的，前端專注于數(shù)據(jù)展示和交互即可。

3、中間層屏蔽環(huán)境、平臺差異

同一套代碼要運行在多個小程序上，雖然宿主提供了通用標(biāo)準(zhǔn)的能力，但是還有一些差異在短期沒有辦法解決。為了讓同一代碼可以在多個小程序之間無縫平移，必然要引用一些中間層屏蔽底層和環(huán)境的差異，簡化業(yè)務(wù)調(diào)用方式，提高開發(fā)效率。

以跳轉(zhuǎn)協(xié)議為例，房產(chǎn)二手房的業(yè)務(wù)要分別以插件的方式集成在58同城微信小程序、以分包的形式集成在安居客微信小程序，那插件和分包在路徑跳轉(zhuǎn)方面是不同，為此，有了我們的跳轉(zhuǎn)中間層：

export const goToPage = (wx, params, type) => {
    if (MAIN.Common.isWubaPlugin()) {
        let isObject = typeof params === 'object';
        let entry = isObject ? params : { url: params };
        entry.url = `plugin-private://${ pluginId }` + entry.url;
        MAIN.Common.goToPage(wx, entry, type);
    } else {
        MAIN.Common.goToPage(wx, params, type);
    }
};

4、統(tǒng)一跳轉(zhuǎn)協(xié)議、跳轉(zhuǎn)協(xié)議動態(tài)下發(fā)

現(xiàn)有的多個小程序，之前頁面的路由均不一樣，在路由跳轉(zhuǎn)管理上、維護(hù)和開發(fā)成本很高。針對這個問題，我們做了以下幾步做了優(yōu)化提效：

1）新開發(fā)頁面多小程序路由保持統(tǒng)一

2）借鑒58APP協(xié)議下發(fā)機(jī)制，跳轉(zhuǎn)協(xié)議統(tǒng)一改為后端下發(fā)

這樣不僅解決了路由管理維護(hù)成本，而且支持更精細(xì)化的灰度，做到優(yōu)雅降級。在我們業(yè)務(wù)統(tǒng)一逐步切換中，灰度必不可少，有完善的灰度降級方案，也有助于最大限度的降低影響。

具體到業(yè)務(wù)場景中：以微信小程序為例，提交版本給小程序?qū)徍诵枰獣r間，在從發(fā)版到更新到所有用戶，最長需要 24 小時。如果我們新改版的頁面上線了，突然發(fā)現(xiàn)某些機(jī)型打開白頁。我們可以快速將下發(fā)協(xié)議成老頁面，甚至換成一個H5的頁面，把損失降低到最小。

總結(jié)和展望

回顧過去，通過半年多技術(shù)和業(yè)務(wù)的升級和統(tǒng)一。安居客實現(xiàn)了微信、百度、快應(yīng)用等小程序的平臺化，支持房產(chǎn)垂直業(yè)務(wù)在多小程序上實現(xiàn)無縫平移，可以快速落地生成更多的小程序，同時二手房核心業(yè)務(wù)完成在多小程序的同步開發(fā)，大幅度的提升了小程序開發(fā)效率，在小程序的流量風(fēng)口上為業(yè)務(wù)落地做好后勤保障。
接下來我們會持續(xù)優(yōu)化小程序性能、完善性能監(jiān)控、JS錯誤監(jiān)控等。擁抱公司小程序協(xié)同項目，持續(xù)完善安居客小程序平臺建設(shè)，為業(yè)務(wù)快速接入、落地做好準(zhǔn)備。

寫到最后

安居客小程序?qū)崿F(xiàn)平臺化以及實現(xiàn)二手房核心業(yè)務(wù)重構(gòu)與順利落地，離不開其他前端、后端、QA等兄弟團(tuán)隊的支持與積極配合，另一方面，在我們統(tǒng)一小程序基礎(chǔ)功能，如云賬號、微聊等方面，也離不開 TEG同學(xué)的大力支持與幫助，因此在此對你們說一聲感謝。個人能力也有限，如果大家發(fā)現(xiàn)文章中的錯誤或者實現(xiàn)方案上的不完美，歡迎交流指正。

參考文獻(xiàn)

1、https://developers.weixin.qq.com/miniprogram/dev/framework/
2、https://nervjs.github.io/taro/docs/config.html
3、https://developers.weixin.qq.com/miniprogram/dev/framework/audits/performance.html

作者簡介

李永超，58集團(tuán)/資深前端工程師。

張素沙，58集團(tuán)/高級前端工程師。

閱讀推薦