美團外賣平臺化復(fù)用主要是指多端代碼復(fù)用，正如美團外賣iOS多端復(fù)用的推動、支撐與思考文章所述，多端包含有兩層意思：其一是相同業(yè)務(wù)的多入口，指美團外賣業(yè)務(wù)需要在美團外賣App（下文簡稱外賣App）和美團App外賣頻道（下文簡稱外賣頻道）同時上線；其二是指平臺上各個業(yè)務(wù)線，美團外賣不同業(yè)務(wù)線都依賴外賣基礎(chǔ)服務(wù)，比如登陸、定位等。

多入口及多業(yè)務(wù)線給美團外賣平臺化復(fù)用帶來了巨大的挑戰(zhàn)，此前我們的一篇博客《美團外賣Android平臺化架構(gòu)演進實踐》（下文簡稱《架構(gòu)演進實踐》）也提到了這個問題，本文將在“代碼復(fù)用”這一章節(jié)的基礎(chǔ)上，進一步介紹平臺化復(fù)用工作面臨的挑戰(zhàn)以及相應(yīng)的解決方案。

美團外賣平臺化復(fù)用背景

美團外賣App和美團App外賣頻道業(yè)務(wù)基本一樣，但由于歷史原因，兩端代碼差異較大，造成同樣的子業(yè)務(wù)需求在一端上線后，另一端幾乎需要重新實現(xiàn)，嚴重浪費開發(fā)資源。在《架構(gòu)演進實踐》一文中，將美團外賣Android客戶端平臺化架構(gòu)分為平臺層、業(yè)務(wù)層和宿主層，我們希望能夠在平臺化架構(gòu)中實現(xiàn)平臺層和業(yè)務(wù)層的多端復(fù)用，從而節(jié)省子業(yè)務(wù)需求開發(fā)資源，實現(xiàn)多端部署。

難點總結(jié)

兩端業(yè)務(wù)雖然基本一致，但是仍舊存在差異，UI、基礎(chǔ)服務(wù)、需求差異等。這些差異存在于美團外賣平臺化架構(gòu)中的平臺層和業(yè)務(wù)層各個模塊中，給平臺化復(fù)用帶來了巨大的挑戰(zhàn)。我們總結(jié)了兩端代碼的差異點，主要包括以下幾個方面：

基礎(chǔ)服務(wù)的差異：包括基礎(chǔ)Activity、網(wǎng)絡(luò)庫、圖片庫等底層庫的差異。

組件的實現(xiàn)差異：包括基礎(chǔ)數(shù)據(jù)Model、下拉刷新、頁面跳轉(zhuǎn)等基礎(chǔ)組件的差異。

頁面的差異：包括兩端的UI、交互、業(yè)務(wù)和版本發(fā)布時間不一致等差異。

前期探索

前期，我們嘗試通過一些設(shè)計方案來繞過上述差異，從而實現(xiàn)兩端的代碼復(fù)用。我們選擇了二級頻道頁（下文統(tǒng)稱金剛頁）進行方案嘗試，設(shè)計如下：

其中，KingKongDelegate是Activity生命周期實現(xiàn)的代理類，包含onCreate、onResume等Activity生命周期回調(diào)方法。在外賣App和外賣頻道兩端分別基于各自的基礎(chǔ)Activity實現(xiàn)WMKingKongAcitivity和MTKingKongActivity，分別會通過調(diào)用KingKongDelegate的方法對Activity的生命周期進行分發(fā)。

KingKongInjector是兩端差異部分的接口集合，包括頁面跳轉(zhuǎn)（兩端頁面差異）、獲取頁面刷新間隔時間、默認資源等，在外賣App和外賣頻道分別有對應(yīng)的接口實現(xiàn)WMKingKongInjector和MTKingKongInjector。

NetworkController則是用Retrofit實現(xiàn)統(tǒng)一的網(wǎng)絡(luò)請求封裝，PageListController是對列表分頁加載邏輯以及頁面空白、網(wǎng)絡(luò)加載失敗等異常邏輯處理。

在金剛頁設(shè)計方案中，我們采用了“代理+繼承”的方式，實現(xiàn)了用統(tǒng)一的網(wǎng)絡(luò)庫實現(xiàn)網(wǎng)絡(luò)請求，定義了統(tǒng)一的基礎(chǔ)數(shù)據(jù)Model，統(tǒng)一了部分基礎(chǔ)服務(wù)以及基礎(chǔ)數(shù)據(jù)。通過KingKongDelegate屏蔽了兩端基礎(chǔ)Acitivity的差異，同時，通過KingKongInjector實現(xiàn)了兩端差異部分的處理。但是我們發(fā)現(xiàn)這種設(shè)計方案存在以下問題：

雖然這樣可以解決網(wǎng)絡(luò)庫和圖片的差異，但是不能屏蔽兩端基礎(chǔ)Activity的差異。

KingKongInjector提供了一種解決兩端差異的處理方式，但是KingKongInjector會存在很多不相關(guān)的方法集合，不易控制其邊界。此外，多個子模塊需要調(diào)用KingKongInjector，會導(dǎo)致KingKongInjector不便管理。

由于兩端Model不同，需要實現(xiàn)這個模塊使用的統(tǒng)一Model，但是并未和其他頁面使用的相同含義的Model統(tǒng)一。

平臺化復(fù)用方案設(shè)計

通過代碼復(fù)用初步嘗試總結(jié)，我們總結(jié)出平臺化復(fù)用，需要考慮四件事情：

差異化的統(tǒng)一管理。

基礎(chǔ)服務(wù)的復(fù)用。

基礎(chǔ)組件的復(fù)用。

頁面的復(fù)用。

整體設(shè)計

我們在實現(xiàn)平臺化架構(gòu)的基礎(chǔ)上，經(jīng)過不斷的探索，最終形成適合外賣業(yè)務(wù)的平臺化復(fù)用設(shè)計：整體分為基礎(chǔ)服務(wù)層-基礎(chǔ)組件層-業(yè)務(wù)層-宿主層。設(shè)計圖如下：

基礎(chǔ)服務(wù)層：包含多端統(tǒng)一的基礎(chǔ)服務(wù)和有差異的基礎(chǔ)服務(wù)，其中統(tǒng)一的基礎(chǔ)服務(wù)包括網(wǎng)絡(luò)庫、圖片庫、統(tǒng)計、監(jiān)控等。對于登錄、分享、定位等外賣App和外賣頻道兩端有差異的部分，我們通過抽象服務(wù)層來屏蔽兩端的差異。

基礎(chǔ)組件層：包括統(tǒng)一的兩端Model、埋點、下拉刷新、權(quán)限、Toast、A/B測試、Utils等兩端復(fù)用的基礎(chǔ)組件。

業(yè)務(wù)層：包括外賣的具體業(yè)務(wù)模塊，目前可以分為列表頁模塊（如首頁、金剛頁等）、商家模塊（如商家頁、商品詳情頁等）和訂單模塊（如下單頁、訂單狀態(tài)頁等）。這些業(yè)務(wù)模塊的特點是：模塊間復(fù)用可能性小，模塊內(nèi)的復(fù)用可能性大。

宿主層：主要是初始化服務(wù)，例如Application的初始化、dex加載和其他各種必要的組件的初始化。

分層架構(gòu)能夠?qū)崿F(xiàn)各層功能的職責(zé)分離，同時，我們要求上層不感知下層的多端差異。在各層中進行組件劃分，同樣，我們也要求實現(xiàn)調(diào)用組件方不感知組件的多端差異。通過這樣的設(shè)計，能夠使得整體架構(gòu)更加清晰明朗，復(fù)用率提高的同時，不影響架構(gòu)的復(fù)雜度和靈活度。

差異化管理

需要多端復(fù)用的業(yè)務(wù)相對于普通業(yè)務(wù)而言，最大的挑戰(zhàn)在于差異化管理。首先多端的先天條件就決定了多端復(fù)用業(yè)務(wù)會存在差異；其次，多端復(fù)用的業(yè)務(wù)有個性化的需求。在多端復(fù)用的差異化管理方案中，我們總結(jié)了以下兩種方案：

差異分支管理方案。

pins工程+Flavor管理的方案。

差異分支管理

分支管理常用于多個需求在一端上線后，需要在另一端某一個時間節(jié)點跟進的場景，如下圖所示：

兩端開發(fā)1.0版本時，分別要在wm分支（外賣App對應(yīng)分支）開發(fā)feature1和mt分支（外賣頻道對應(yīng)分支）開發(fā)feature2。開發(fā)2.0版本時，feature1需要在外賣頻道上線，feature2需要在外賣App上線，則分別將feature1分支代碼合入mt分支，feature2代碼合入wm分支。這樣通過拉取新需求分支管理的方式，滿足了需求的差異化管理。但是這種實現(xiàn)方式存在兩個問題：

兩端需求差異太多的話，就會存在很多分支，造成分支管理困難。

不支持細粒度的差異化管理，比如模塊內(nèi)部的差異化管理。

pins工程+Flavor的差異化管理

在Android官網(wǎng)《配置構(gòu)建變體》章節(jié)中介紹了Product Flavor（下文簡稱Flavor）可以用于實現(xiàn)full版本以及demo版本的差異化管理，通過配置Gradle，可以基于不同的Flavor生成不同的apk版本。因此，模塊內(nèi)部的差異化管理是通過Flavor來實現(xiàn)，其原理如下圖所示：

其中Common是兩端復(fù)用的代碼，DiffHandler是兩端差異部分接口，WMDiffHandler是外賣App對應(yīng)的Flavor下的DiffHandler實現(xiàn)，MTDiffHandler是外賣頻道對應(yīng)Flavor下的DiffHandler實現(xiàn)。通過兩端分別依賴不同F(xiàn)lavor代碼實現(xiàn)模塊內(nèi)差異化管理。

對于需求在兩端版本差異化管理，也可以通過配置Flavor來實現(xiàn)，如下圖所示：

在1.0版本時，feature1只在外賣App上線，feature2只在外賣頻道上線。當2.0版本時，如果feature1、feature2需要同時在兩端上線，只需要將對應(yīng)業(yè)務(wù)代碼移動到共用SourceSet即可實現(xiàn)feature1、feature2代碼復(fù)用。

綜合兩種差異代碼實現(xiàn)來看，我們選擇使用Flavor方式來實現(xiàn)代碼差異化管理。其優(yōu)勢如下：

一個功能模塊只需要維護一套代碼。

差異代碼在業(yè)務(wù)庫不同F(xiàn)lavor中實現(xiàn)，方便追溯代碼實現(xiàn)歷史以及做差異實現(xiàn)對比。

對于上層來說，只會依賴下層代碼的不同F(xiàn)lavor版本；下層對上層暴露接口也基本一樣，上層不用關(guān)心下層差異實現(xiàn)。

需求版本差異，也只需先在上線一端對應(yīng)的Flavor中實現(xiàn)，當需要復(fù)用時移動到共用的SourceSet下面，就能實現(xiàn)需求代碼復(fù)用。

從Android工程結(jié)構(gòu)來看，使用Flavor只能在module內(nèi)復(fù)用，但是以module為粒度的復(fù)用對于差異化管理來說約束太重。這意味著同個module內(nèi)不同模塊的差異代碼同時存在于對應(yīng)Flavor目錄下，或者說需要將每個子模塊都創(chuàng)建成不同的module，這樣管理代碼是非常不便的。《微信Android模塊化架構(gòu)重構(gòu)實踐》一文中提到了一個重要的概念pins工程，pins工程能在module之內(nèi)再次構(gòu)建完整的多子工程結(jié)構(gòu)。我們通過創(chuàng)造性的使用pins工程+Flavor的方案，將差異化的管理單元從module降到了pins工程。而pins工程可以定義到最小的業(yè)務(wù)單元，例如一個Java文件。整體的設(shè)計實現(xiàn)如下：

具體的配置過程，首先需要在Android Studio工程里首先要定義兩個Flavor：wm、mt。

productFlavors {wm {}mt {} }

然后使用pins工程結(jié)構(gòu)，把每個子業(yè)務(wù)作為一個pins工程，實現(xiàn)如下Gradle配置：

最終的工程目錄結(jié)構(gòu)如下：

以名為base的pins工程為例，src/base/main是該工程的兩端共用代碼，src/base/wm是該工程的外賣App使用的代碼，src/base/mt是外賣頻道使用的代碼。同時，我們做了代碼檢查，除了base pins工程可以依賴以外，其他pins不存在直接依賴關(guān)系。通過這樣實現(xiàn)了module內(nèi)部更細粒度的工程依賴，同時配合Gradle配置可以實現(xiàn)只編譯部分pins工程，使整體代碼更加靈活。

通過pins工程+Flavor的差異化管理方式，我們既實現(xiàn)了需求級別的差異化管理，也實現(xiàn)了模塊內(nèi)的功能差異化管理。同時，pins工程更好的控制了代碼粒度以及代碼邊界，也將差異代碼控制在比module更小的粒度。

基礎(chǔ)服務(wù)的復(fù)用

對于一個App來說，基礎(chǔ)服務(wù)的重要性不言而喻，所以在平臺化復(fù)用中，往往基礎(chǔ)服務(wù)的差異最大。由于基礎(chǔ)服務(wù)的使用范圍比較廣，如果基礎(chǔ)服務(wù)的差異得不到有效的處理，讓上層感知到差異，就會增加架構(gòu)層與層之間的耦合，上層本身實現(xiàn)業(yè)務(wù)的難度也會加大。下文里講解一個我們在實踐過程中遇到的例子，來闡述我們的主要解決思路。

在前期探索章節(jié)中，我們提到金剛頁由于兩端基礎(chǔ)Activity差異，以致于要使用代理類來實現(xiàn)Activity生命周期分發(fā)。通過采用統(tǒng)一接口以及Flavor方式，我們可以統(tǒng)一兩端基礎(chǔ)Activity組件，如下圖所示：

分別將兩端WMBaseActivity和MTBaseActivity的差異接口統(tǒng)一成DialogController、ToastController以及ActionBarController等通用接口，然后在wm、mt兩個Flavor目錄下分別定義全限定名完全相同的BaseActivity，分別繼承MTBaseActivity和MTBaseActivity并實現(xiàn)統(tǒng)一接口，接口實現(xiàn)盡量保持一致。對于上層來說，如果繼承BaseActivity，其可調(diào)用的接口完全一致，從而達到屏蔽兩端基礎(chǔ)Activity差異的目的。

對于一些通用基礎(chǔ)組件，由于使用范圍比較廣，如果不統(tǒng)一或者差異較大，會造成業(yè)務(wù)層代碼實現(xiàn)差異較大，不利于代碼復(fù)用。所以我們采用的策略是外賣App向外賣頻道看齊。代碼復(fù)用前，外賣App主要使用的網(wǎng)絡(luò)庫是Volley，統(tǒng)一切換為外賣頻道使用的MTRetrofit；外賣使用的圖片庫是Fresco，統(tǒng)一切換為外賣頻道使用的MTPicasso；其他統(tǒng)一的組件還包括動態(tài)加載框架、WebView加載組件、網(wǎng)絡(luò)監(jiān)控Cat、線上監(jiān)控Holmes、日志回撈Logan以及降級限流等。兩端代碼復(fù)用時，修復(fù)問題、監(jiān)控數(shù)據(jù)能力方面保持統(tǒng)一。

對于登錄、定位等通用基礎(chǔ)服務(wù)，我們的原則是能統(tǒng)一盡量統(tǒng)一，這樣可以有效的減少多端復(fù)用中來帶的多端維護成本，多份變成一份。而對于無法統(tǒng)一的服務(wù)，抽象出統(tǒng)一的服務(wù)接口，讓上層不感知差異，從而減少上層的復(fù)用成本。

組件復(fù)用

組件化可以大大的提高一個App的復(fù)用率。對于平臺化復(fù)用的業(yè)務(wù)而言，也是一樣。多個模塊之間也是會經(jīng)常使用相同的功能，例如下拉刷新、分頁加載、埋點、樣式等功能。將這些常用的功能抽離成組件供上層業(yè)務(wù)層調(diào)用，將可以大大提高復(fù)用效果。可以說組件化是平臺化復(fù)用的必要條件之一。

面對外賣App包含復(fù)雜眾多的業(yè)務(wù)功能，一個功能可以被拆分成組件的基本原則是不同業(yè)務(wù)庫中不同業(yè)務(wù)的共用的業(yè)務(wù)功能或行為功能。然后按照業(yè)務(wù)實現(xiàn)中相關(guān)性的遠近，自上而下的依賴性將抽離出來的組件劃分為基礎(chǔ)通用組件、基礎(chǔ)業(yè)務(wù)組件、UI公共組件。

基礎(chǔ)通用組件指那些變化不大，與業(yè)務(wù)無關(guān)的組件，例如頁面加載下拉刷新組件（p_refresh），日志記錄相關(guān)組件（p_log），異常兜底組件（p_exception）。基礎(chǔ)業(yè)務(wù)組件指以業(yè)務(wù)為基礎(chǔ)的組件：評論通用組件（p_ugc），埋點組件（p_judas），搜索通用組件（p_search），紅包通用組件（p_coupon）等。UI公共組件指公用View或者UI樣式組件，與View 相關(guān)的通用組件（p_widget），與UI樣式相關(guān)的通用組件（p_theme）。

對于抽離出來的基礎(chǔ)組件，多端之間的差異怎么處理呢？ 例如兜底組件，外賣兜底樣式以黃色為主調(diào)，而外賣頻道中以綠色小團為主調(diào)，如圖所示：

我們首先將這個組件劃分為一個pins工程，對于多端的差異，在pins工程里面利用Flavor管理多端之間的差異。這樣的方案，首先組件是一個獨立的模塊，其次多端的差異在組件內(nèi)部被統(tǒng)一處理了，上層業(yè)務(wù)不用感知組件的實現(xiàn)差異。而由于基礎(chǔ)服務(wù)層已經(jīng)將差異化管理了，組件層也不用感知基礎(chǔ)服務(wù)的差異，減少了組件層的復(fù)用成本。

頁面復(fù)用

對兩端同一個頁面來說，絕大部分的功能模塊是可復(fù)用的，但是也存在不一致的功能模塊。以外賣App和美團外賣頻道首頁為例，中部流量區(qū)等業(yè)務(wù)基本相同，但是頂部導(dǎo)航欄樣式功能和中部流量區(qū)布局在兩端不一樣，如下圖所示：

針對上述問題，我們頁面復(fù)用的實現(xiàn)思路是頁面模塊化：先將頁面功能按照業(yè)務(wù)相似性以及兩端差異拆分成高內(nèi)聚低耦合的功能單元Block，然后兩端頁面使用拆分的功能單元Block像搭積木似的搭建頁面，單個的單元Block可以采用MVP模式實現(xiàn)。美團點評內(nèi)部酒旅的Ripper和到店綜合Shield頁面模塊化開發(fā)框架也是采用這樣的思路。由于我們要實現(xiàn)兩端復(fù)用，還要考慮頁面之間的差異。對于兩端頁面差異，我們統(tǒng)一使用上文中提到的Flavor機制在業(yè)務(wù)單元內(nèi)對兩端差異化管理，業(yè)務(wù)單元所在頁面不感知業(yè)務(wù)單元的差異性。對于不同的差異，單元Block可以在MVP不同層做差異化管理。

以首頁為例，首頁Block化復(fù)用架構(gòu)如下圖。兩端首頁頭部導(dǎo)航欄UI展示、數(shù)據(jù)、功能不一樣，導(dǎo)航欄整個功能就以一個Flavor在兩端分別實現(xiàn)；商家列表中部流量區(qū)部分雖然整體UI布局不一樣，但是里面單個功能Block業(yè)務(wù)邏輯、整個數(shù)據(jù)一樣，繼續(xù)將中部流量區(qū)里面的業(yè)務(wù)Block化；下方的商家列表項兩端一樣的功能，用一個公有的Block實現(xiàn)。在各個單元Block已經(jīng)實現(xiàn)的基礎(chǔ)上，兩端首頁搭建成首頁Fragment。

頁面模塊化后，將兩端不同的差異在各個單元Block以Flavor方式處理，業(yè)務(wù)單元Block所在頁面不用關(guān)心各個Block實現(xiàn)差異，不僅實現(xiàn)了頁面的復(fù)用，各個模塊功能職責(zé)分離，還提高了可維護性。

總結(jié)

美團外賣業(yè)務(wù)需要在外賣平臺和美團平臺同時部署，因此，在美團外賣平臺化架構(gòu)過程中就產(chǎn)生了平臺化復(fù)用的問題。而怎么去實現(xiàn)平臺化復(fù)用呢？筆者認為需要從不同粒度去考慮：基礎(chǔ)服務(wù)、組件、頁面。對于基礎(chǔ)服務(wù)，我們需要盡可能的統(tǒng)一，不能統(tǒng)一的就抽象服務(wù)層。組件級別，需要分塊分層，將依賴梳理好。頁面的復(fù)用，最重要的是頁面模塊化和頁面內(nèi)模塊做到職責(zé)分離。平臺化復(fù)用最大的難點在于：差異的管理和屏蔽。本文提出使用pins工程+Flavor的方案，可以使得差異代碼的管理得到有效的解決。同時利用分層策略，每層都自己處理好自己的差異，使得上層不用關(guān)心下層的差異。平臺化復(fù)用不能單純的追求復(fù)用率，同時要考慮到端的個性化。

到目前為止，我們實現(xiàn)了絕大部分外賣App和外賣頻道代碼復(fù)用，整體代碼復(fù)用率達到88.35%，人效提升70%以上。未來，我們可能會在外賣平臺、美團平臺、大眾點評平臺三個平臺進行代碼復(fù)用，其場景將會更加復(fù)雜。當然，我們在做平臺化復(fù)用的時候，要合理地進行評估，復(fù)用帶來的“成本節(jié)約”和為了復(fù)用帶來的“成本增加”之間的比率。另外，平臺化復(fù)用視角不應(yīng)該局限于業(yè)務(wù)頁面的復(fù)用，對于監(jiān)控、測試、研發(fā)工具、運維工具等也可以進行復(fù)用，這也是平臺化復(fù)用理念的核心價值所在。

參考資料

美團外賣Android平臺化架構(gòu)演進實踐

美團外賣iOS多端復(fù)用的推動、支撐與思考

微信Android模塊化架構(gòu)重構(gòu)實踐

配置構(gòu)建變體

Shield—開源的移動端頁面模塊化開發(fā)框架

作者簡介

• 曉飛，美團點評技術(shù)專家。2015年加入美團點評，外賣Android的早期開發(fā)者之一。目前是外賣Android App負責(zé)人，主要負責(zé)版本管理和業(yè)務(wù)架構(gòu)。
• 金光，美團點評高級工程師。2017年加入美團點評，主要負責(zé)代碼復(fù)用及外賣平臺化相關(guān)工作。
• 王芳，美團點評高級工程師。2017年加入美團點評，主要負責(zé)商家列表頁面等相關(guān)頁面業(yè)務(wù)。

招聘

美團外賣長期招聘Android、iOS、FE 高級/資深工程師和技術(shù)專家，Base 北京、上海、成都，歡迎有興趣的同學(xué)投遞簡歷到wukai05@meituan.com。

總結(jié)

以上是生活随笔為你收集整理的美团外卖Android平台化的复用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。