導(dǎo)語(yǔ)：App工廠，顧名思義，是一個(gè)能根據(jù)各種素材和組織形式生成App的工廠。更專(zhuān)業(yè)一點(diǎn)的描述，是根據(jù)一個(gè)具有完備組件庫(kù)以及這些組件的依賴關(guān)系，組合成一個(gè)個(gè)App。

以往的單App研發(fā)架構(gòu)，由于每次打包編譯、版本發(fā)布都是一個(gè)全量的代碼集合，所以不會(huì)也不需要考慮每一個(gè)組件之間的依賴和耦合關(guān)系。在多App場(chǎng)景下，由于存在一套代碼，按需生成不同App所需要的代碼，原有的架構(gòu)、代碼依賴關(guān)系、工程代碼組織方式都需要相應(yīng)的改變。

App工廠的目標(biāo)是在特定架構(gòu)和業(yè)務(wù)場(chǎng)景下，基于一套代碼，按需生成目標(biāo)App所需的代碼。一套代碼和按需生成是核心，缺一不可。特別是按需生成，意味著不攜帶任何不需要的代碼，這個(gè)在實(shí)現(xiàn)的過(guò)程中非常具有挑戰(zhàn)性。本文從iOS視角，分享58App在App工廠方面的理論和實(shí)踐的探索。

作者 | 彭飛

App工廠產(chǎn)生背景
業(yè)務(wù)的快速試錯(cuò)催生多App

移動(dòng)互聯(lián)網(wǎng)不論是在上半場(chǎng)，還是在下半場(chǎng)，業(yè)務(wù)的創(chuàng)新從來(lái)沒(méi)有停歇過(guò)。從微博到團(tuán)購(gòu)，從共享汽車(chē)到共享單車(chē)，從長(zhǎng)視頻到短視頻，業(yè)務(wù)和模式的創(chuàng)新不斷。近幾年尤以頭條系的業(yè)務(wù)試錯(cuò)見(jiàn)諸于各報(bào)端，從資訊到直播，再到短視頻，是一波接一波。

當(dāng)前不論是大的互聯(lián)網(wǎng)公司，還是創(chuàng)業(yè)性的小公司，要想在新的領(lǐng)域摸索出一番天地，必須不斷試錯(cuò)。移動(dòng)領(lǐng)域的業(yè)務(wù)不斷試錯(cuò)，要求能快速產(chǎn)出各業(yè)務(wù)對(duì)應(yīng)的創(chuàng)新App。

集團(tuán)業(yè)務(wù)的逐步擴(kuò)大與細(xì)化催生多App

互聯(lián)網(wǎng)江湖早已三分天下，巨頭已經(jīng)建立，大的互聯(lián)網(wǎng)平臺(tái)很難形成。但越是大的互聯(lián)網(wǎng)平臺(tái)，越擔(dān)心垂直細(xì)分業(yè)務(wù)的進(jìn)攻。為應(yīng)對(duì)進(jìn)攻，集團(tuán)業(yè)務(wù)也需要在一些領(lǐng)域逐步擴(kuò)大和細(xì)化，垂直App應(yīng)運(yùn)而生。

垂直App與創(chuàng)新App的差距在于，垂直App是基于現(xiàn)有平臺(tái)業(yè)務(wù)細(xì)分而來(lái)，而創(chuàng)新App是平臺(tái)業(yè)務(wù)所沒(méi)有的。

另外，為了應(yīng)對(duì)應(yīng)用市場(chǎng)的分發(fā)和對(duì)包大小敏感的用戶，這幾年極速包幾乎成為各大公司的必備App。

集團(tuán)業(yè)務(wù)的合并融合催生多App交叉

業(yè)務(wù)的收購(gòu)、合并也是大型互聯(lián)網(wǎng)公司常有的事。收購(gòu)合并后的業(yè)務(wù)如何融合，如何既能保持業(yè)務(wù)的獨(dú)立性，又能節(jié)省集團(tuán)研發(fā)資源，還能支持一套交叉業(yè)務(wù)（又稱(chēng)垂直業(yè)務(wù)）代碼在各獨(dú)立App運(yùn)行，是一個(gè)重要又復(fù)雜的問(wèn)題。比如今年58集團(tuán)內(nèi)安居客房產(chǎn)業(yè)務(wù)和原58房產(chǎn)業(yè)務(wù)的融合就是一個(gè)典型的案例。

App工廠目標(biāo)、架構(gòu)與實(shí)施方法
App工廠的實(shí)施目標(biāo)

1.App工廠有以下目標(biāo)：

標(biāo)準(zhǔn)化能力的產(chǎn)出，為App研發(fā)提效增速

標(biāo)準(zhǔn)化能力是實(shí)現(xiàn)App工廠的基礎(chǔ)，標(biāo)準(zhǔn)化能力與App業(yè)務(wù)代碼無(wú)耦合關(guān)系，比如React Native SDK，網(wǎng)絡(luò)庫(kù)、緩存庫(kù)等。

支持創(chuàng)新App、垂直App、極速App的生成和迭代

同一套代碼，根據(jù)配置，能按需生成不同App所需的代碼。按需生成是關(guān)鍵和核心，不給App工廠生成的App代碼攜帶任何無(wú)用代碼，增加包大小。

支持垂直業(yè)務(wù)在獨(dú)立App上的平移

App工廠依附于58App框架代碼上，馬甲包、極速包與App工廠（58App）是一個(gè)子集與全集的關(guān)系。但類(lèi)似安居客App與58App是兩個(gè)獨(dú)立App，有交集（公共底層代碼或某些業(yè)務(wù)代碼），業(yè)務(wù)代碼集合不一樣。

針對(duì)獨(dú)立App的公共業(yè)務(wù)代碼，定義為垂直業(yè)務(wù)。App工廠在統(tǒng)一底層服務(wù)的前提下，也要支持垂直業(yè)務(wù)在獨(dú)立App上的平移。即一套業(yè)務(wù)代碼，能在兩個(gè)或多個(gè)獨(dú)立App上運(yùn)行。

App工廠架構(gòu)

名詞解釋

PODS

在iOS領(lǐng)域，pods特指cocoapods，是其縮寫(xiě)。cocoapods是對(duì)OC或swift Cocoa 工程的依賴管理。（CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. ）

中間件

中間件在軟件領(lǐng)域的通用解釋是：連接軟件組件和應(yīng)用的程序。在這里中間件體現(xiàn)的是連接和共用。連接的是業(yè)務(wù)層和基礎(chǔ)庫(kù)層，共用體現(xiàn)在業(yè)務(wù)層的公共服務(wù)。

中間件按照業(yè)務(wù)強(qiáng)相關(guān)與否分為業(yè)務(wù)中間件和標(biāo)準(zhǔn)中間件。

業(yè)務(wù)中間件：

與業(yè)務(wù)強(qiáng)相關(guān)的中間件，在某一個(gè)獨(dú)立App中通用。由于對(duì)當(dāng)前App其它功能的過(guò)多依賴，所以不適用于其他獨(dú)立App。

標(biāo)準(zhǔn)中間件：

與業(yè)務(wù)弱相關(guān)的中間件，不僅在某一個(gè)獨(dú)立App中通用，在其它獨(dú)立App中也通用，與App中的業(yè)務(wù)弱相關(guān)。最常見(jiàn)的是標(biāo)準(zhǔn)版的RNSDK。

基礎(chǔ)庫(kù)

對(duì)其它pod不產(chǎn)生依賴的獨(dú)立庫(kù)。比如一些開(kāi)源的三方庫(kù)，是常見(jiàn)的基礎(chǔ)庫(kù)。除了第三方開(kāi)源的，58集團(tuán)內(nèi)自封裝的sdk，如果對(duì)其它pod不產(chǎn)生依賴，也可以歸入基礎(chǔ)庫(kù)范圍，比如Passport SDK，WPush SDK等；

入口工程

主要負(fù)責(zé)對(duì)App工廠生成的App所需代碼進(jìn)行配置。

入口工程pods：主要負(fù)責(zé)對(duì)App工廠生成的App所需代碼進(jìn)行配置，入口工程中包括的功能有：

APPInfo：對(duì)App基礎(chǔ)信息的設(shè)置，比如App名稱(chēng)，bundle identifier，版本號(hào)，證書(shū)等；

Podfile：當(dāng)前App對(duì)所需工程代碼的依賴，比如招聘馬甲包會(huì)依賴招聘業(yè)務(wù)pod以及其他基礎(chǔ)服務(wù)pod和三方庫(kù)pod；

Regen.sh: 一個(gè)可執(zhí)行文件（本地RD研發(fā)調(diào)試用），讀取podfile配置，拷貝App所需代碼及配置，然后生成App所需代碼；

Reng_jenkins.sh: 一個(gè)可執(zhí)行文件（Jenkins服務(wù)打包用），讀取podfile配置，拷貝App所需代碼及配置，然后生成App所需代碼；

工程庫(kù)池

工程池是App工廠總的pod代碼集合。

工程池是App工廠總的代碼集合，每一個(gè)生成App所需代碼都是從這個(gè)代碼集合中獲取，研發(fā)過(guò)程中代碼更新也會(huì)同步更新到此代碼集合中去。

業(yè)務(wù)pods：各獨(dú)立業(yè)務(wù)工程代碼，代碼集合根據(jù)業(yè)務(wù)類(lèi)型來(lái)劃分，比如App首頁(yè)pod、房產(chǎn)pod、招聘pod；

中間件pods：App工廠中間服務(wù)代碼，是58自己封裝的，區(qū)別于外界的第三方公開(kāi)代碼，故稱(chēng)為中間件代碼。中間件根據(jù)對(duì)58App業(yè)務(wù)的是否強(qiáng)依賴分為：

業(yè)務(wù)中間件：

與58App業(yè)務(wù)強(qiáng)相關(guān)，但是是58App中業(yè)務(wù)中通用中間服務(wù)，其應(yīng)用場(chǎng)景在58App的業(yè)務(wù)場(chǎng)景內(nèi)。

標(biāo)準(zhǔn)中間件：

與58App業(yè)務(wù)弱相關(guān)，可以作為一個(gè)標(biāo)準(zhǔn)化中間件在其它獨(dú)立App上引入。

在標(biāo)準(zhǔn)中間件中可以看到有圖標(biāo)加了兩條豎線，這表示此標(biāo)準(zhǔn)中間件某些功能的實(shí)現(xiàn)依賴接入App的實(shí)現(xiàn)，只開(kāi)放了接口協(xié)議。

以RN基礎(chǔ)庫(kù)標(biāo)準(zhǔn)中間件為例：

中間件包含的內(nèi)容是載體頁(yè)及熱更新的全部公共的與業(yè)務(wù)弱相關(guān)的內(nèi)容，但對(duì)于一些擴(kuò)展的組件（比如埋點(diǎn)）需要開(kāi)放協(xié)議讓接入方實(shí)現(xiàn)，中間件中不實(shí)現(xiàn)此邏輯。

三方庫(kù)pods：外界的開(kāi)源第三方庫(kù)代碼，基本在行業(yè)內(nèi)有統(tǒng)一的引用標(biāo)準(zhǔn)；

架構(gòu)解析

上圖是App工廠架構(gòu)圖，大的方面分為上下兩層：入口工程和工廠池。入口工程pod對(duì)工程池中的pod進(jìn)行依賴，通過(guò)podfile配置每一個(gè)入口工程所在App所需的pod代碼。

工程池中的pod分為業(yè)務(wù)層、中間件層和基礎(chǔ)庫(kù)層。其中中間件層根據(jù)代碼是否強(qiáng)依賴58App業(yè)務(wù)，分為業(yè)務(wù)中間件和標(biāo)準(zhǔn)中間件。

在架構(gòu)設(shè)計(jì)上，各層pods的依賴準(zhǔn)則為：

上層可以依賴下層，但下層不可以依賴上層。比如上層中的業(yè)務(wù)pod中的首頁(yè)（MainPage）可以依賴業(yè)務(wù)中間件中的生命周期（WBLifeCircle），但反之不能依賴。

可以隔層依賴。比如業(yè)務(wù)pod可以依賴基礎(chǔ)庫(kù)pod；

業(yè)務(wù)pod間不能產(chǎn)生依賴。比如房產(chǎn)pod不能依賴招聘pod。

中間件pod和三方庫(kù)pod可以單向依賴。比如RN所在pod可以對(duì)登錄服務(wù)所在pod產(chǎn)生單向依賴。

制定上述依賴準(zhǔn)則，是為了在生產(chǎn)App時(shí)或者進(jìn)行垂直業(yè)務(wù)平移時(shí)可以按需配置所需pod。

如何借助App工廠架構(gòu)達(dá)成設(shè)計(jì)目標(biāo)

1.如何提供標(biāo)準(zhǔn)化的能力

所謂標(biāo)準(zhǔn)化能力，可以理解為獨(dú)立無(wú)依賴的Framework或SDK，對(duì)應(yīng)上述架構(gòu)圖中的標(biāo)準(zhǔn)中間件。比如RN基礎(chǔ)庫(kù)，封裝了載體頁(yè)、熱更新等一整套公共服務(wù)，58App外的獨(dú)立App可以無(wú)縫接入。

下圖展示的一些標(biāo)準(zhǔn)中間件：

標(biāo)準(zhǔn)中間件名稱(chēng)

pod名稱(chēng)

功能描述

RN基礎(chǔ)庫(kù)

WBReactNativeLibrary

封裝了RN基礎(chǔ)功能，包括載體頁(yè)、熱更新、性能優(yōu)化以及一些標(biāo)準(zhǔn)化的Modules

Hybrid基礎(chǔ)庫(kù)

WBHybrid

封裝了Hybrid交互功能，action分發(fā)功能以及一些標(biāo)準(zhǔn)化的actions

跳轉(zhuǎn)組件

WBPageTransferDispatcher

封裝了支持基于主App跳轉(zhuǎn)協(xié)議的跳轉(zhuǎn)分發(fā)邏輯

網(wǎng)絡(luò)庫(kù)

WBNetwork

封裝了網(wǎng)絡(luò)訪問(wèn)的基礎(chǔ)操作，網(wǎng)絡(luò)操作更近便利

定位

WBLocation

封裝了定位觸發(fā)的基礎(chǔ)策略和定位原始數(shù)據(jù)的獲取

緩存庫(kù)

WBCache

封裝了緩存的底層實(shí)現(xiàn)以及一些基本操作

…

另外，還有一些集團(tuán)內(nèi)其他中臺(tái)部門(mén)提供的標(biāo)準(zhǔn)化SDK，比如PassportSDK、IMSDK、Pay58SDK等。

2.如何支持創(chuàng)新App、極速App的生成

如上圖所示，在理想工程架構(gòu)狀態(tài)下（即達(dá)到架構(gòu)各層依賴準(zhǔn)則），可以按需配置App所需功能，來(lái)生成馬甲包或者極速包。

當(dāng)然為了應(yīng)對(duì)蘋(píng)果審核（App之間必須保持差異性），還得針對(duì)馬甲包或者極速包來(lái)做一些個(gè)性化的處理。這種個(gè)性化處理在先前的馬賽克項(xiàng)目有完成，具體詳見(jiàn)馬賽克項(xiàng)目。

3.如何支持垂直業(yè)務(wù)的平移

垂直業(yè)務(wù)：同一業(yè)務(wù)在多個(gè)App上呈現(xiàn)的業(yè)務(wù)稱(chēng)之為垂直業(yè)務(wù)。

垂直業(yè)務(wù)平移：并不是真的去移動(dòng)，是指垂直業(yè)務(wù)及依賴的底層代碼是一套公共代碼，能夠運(yùn)行在不同App上。

上圖所示的是租房和二手房這兩個(gè)垂直業(yè)務(wù)需要達(dá)到一套代碼，同時(shí)運(yùn)行在58App和安居客App上。這就要求：

58App和安居客App共用垂直業(yè)務(wù)所依賴的底層代碼（中間件代碼+基礎(chǔ)庫(kù)代碼）；

垂直業(yè)務(wù)代碼及所依賴的底層代碼對(duì)58App或安居客App中的獨(dú)有代碼沒(méi)有任何耦合，這樣就不會(huì)攜帶一些無(wú)關(guān)的不需要的代碼，有利于控制包大小；

垂直業(yè)務(wù)代碼及所依賴的底層代碼必須滿足App工廠架構(gòu)中的分層原則和依賴原則，這樣架構(gòu)擴(kuò)展性會(huì)比較靈活

如何對(duì)存量代碼實(shí)施App工廠

基于前文App工廠技術(shù)架構(gòu)及各層pod的依賴準(zhǔn)則，各層pod的依賴關(guān)系理想示意圖如下圖所示（以招聘業(yè)務(wù)pod依賴為例）：

從業(yè)務(wù)層到中間件層再到基礎(chǔ)庫(kù)層，從上到下單向依賴，沒(méi)有反向依賴和循環(huán)依賴

業(yè)務(wù)層之間沒(méi)有依賴

中間件層和基礎(chǔ)庫(kù)層可以允許有單向依賴

有了上述理想的依賴關(guān)系后，在入口工程進(jìn)行生成App所需代碼進(jìn)行配置時(shí)，就能按需配置，不會(huì)因?yàn)閜od之間的反向依賴、循環(huán)依賴、整層依賴攜帶很多無(wú)用代碼，增加包大小。

業(yè)務(wù)層pod解耦

上圖所示的招聘業(yè)務(wù)的依賴關(guān)系。黑色箭頭表示的是pod的單向依賴，紅色的雙向箭頭表示的pod的雙向依賴。

備注：服務(wù)層對(duì)應(yīng)中間件層，三方庫(kù)層對(duì)應(yīng)基礎(chǔ)庫(kù)層。

針對(duì)業(yè)務(wù)pod解耦主要處理下層pod對(duì)業(yè)務(wù)pod的依賴以及業(yè)務(wù)pod之間的依賴，如下圖所示：

中間件層pod解耦

如上圖中實(shí)線所示的是招聘pod所依賴的中間件層pod之間的耦合關(guān)系。

服務(wù)層pod解耦要解決以下兩種耦合關(guān)系：

pod之間的雙向耦合

pod之間的不必要單向依賴

服務(wù)層pod的解耦至關(guān)重要，直接涉及到對(duì)工具庫(kù)pod的依賴處理。如不解除服務(wù)層pod的循環(huán)依賴關(guān)系，則會(huì)導(dǎo)致對(duì)工具庫(kù)pod的整層依賴，沒(méi)法按需配置所依賴的pod，造成包大小無(wú)法控制。

基礎(chǔ)庫(kù)層pod解耦

由于基礎(chǔ)庫(kù)層pod是最底層pod，沒(méi)有其他的依賴pod，所以也是這三層pod解耦工作量最少的。

目前58App內(nèi)的基礎(chǔ)庫(kù)層pod全都是放在一個(gè)pod中，這層解耦所要作的是按照功能對(duì)這個(gè)pod進(jìn)行拆分，拆成一個(gè)個(gè)上層pod可依賴的單元。

如何保證APP工廠質(zhì)量

App工廠的質(zhì)量在版本迭代過(guò)程中的質(zhì)量非常重要。如果在后續(xù)版本迭代過(guò)程中代碼沒(méi)有嚴(yán)格遵循App工廠的pod依賴準(zhǔn)則，等到發(fā)現(xiàn)問(wèn)題才去解決，會(huì)帶來(lái)很大的額外工作量。

Pod依賴關(guān)系檢測(cè)

這個(gè)是所有質(zhì)量檢測(cè)的基礎(chǔ)。在本文看到的一些pod的依賴關(guān)系都是我們開(kāi)發(fā)的pod依賴自動(dòng)分析工具得出的。如果沒(méi)有這個(gè)工具，在一些中大型的App中，靠人工方式去梳理這種依賴關(guān)系，將是一個(gè)極大的工作量。在這里大概說(shuō)一下思路，有更好的方式歡迎交流：

掃描本地工程目錄下所有pod代碼文件夾，及里面的類(lèi)文件，建立類(lèi)文件與pod工程的映射關(guān)系 filePodDict。

掃描每一個(gè)pod下面類(lèi)文件中的文件依賴部分（import部分），根據(jù)頭文件依賴及上面的filePodDict，建立pod的直接依賴關(guān)系podDepenDict。

串聯(lián)所有pod的直接依賴關(guān)系，形成pod依賴最終關(guān)系podFinalDepenGraph，并輸出。最終Pod的依賴關(guān)系對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)是有向圖。

如上圖所示，是基于招聘pod和其依賴的pod構(gòu)建的有向圖的示意圖（為便于識(shí)別，將兩個(gè)pod直接相互依賴的一條線畫(huà)成了虛線）。基于這個(gè)數(shù)據(jù)結(jié)構(gòu)，能實(shí)現(xiàn)前文所說(shuō)的App工廠依賴準(zhǔn)則的檢測(cè)。

下層Pod對(duì)上層pod反向依賴檢測(cè)

下層pod對(duì)上層pod反向依賴，是App工廠依賴準(zhǔn)則首要禁止內(nèi)容。比如如果中間件層的WubaRN的這個(gè)pod依賴了上層 首頁(yè)pod，會(huì)導(dǎo)致在業(yè)務(wù)平移過(guò)程中因?yàn)橐蕾嘩ubaRN，而需攜帶不需要的首頁(yè)業(yè)務(wù)代碼。

基于上述的有向圖，反向檢測(cè)在技術(shù)上很容易實(shí)現(xiàn)：

內(nèi)置一份pod與層級(jí)的映射關(guān)系

遍歷pod依賴關(guān)系有向圖，檢測(cè)當(dāng)前pod所依賴的pod層級(jí)是否小于自己的層級(jí)，如果小于，則是反向依賴，并標(biāo)記

將標(biāo)記的反向依賴關(guān)系輸出

Pod循環(huán)依賴檢測(cè)

在App工廠中，除了業(yè)務(wù)層代碼有非常明確的原因不能有依賴和環(huán)外，其它層的pod之間即使存在環(huán)，也有辦法達(dá)到App工廠不攜帶多余代碼的目標(biāo)。但撇開(kāi)App工廠不說(shuō)，環(huán)的存在本質(zhì)上是大多數(shù)情況兩個(gè)pod之間存在公共代碼沒(méi)有下沉。所以為了使App工廠的依賴準(zhǔn)則更簡(jiǎn)單和更易執(zhí)行，就統(tǒng)一規(guī)定不能產(chǎn)生循環(huán)依賴。

檢測(cè)有向圖是否存在環(huán)，是一個(gè)基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)問(wèn)題，在此不贅述。

標(biāo)準(zhǔn)中間件污染檢測(cè)

標(biāo)準(zhǔn)中間件是App工廠的核心，如果標(biāo)準(zhǔn)中間件在后續(xù)的業(yè)務(wù)迭代過(guò)程中被污染，即引入了不符合準(zhǔn)則的依賴關(guān)系，將帶來(lái)額外的維護(hù)成本和解耦成本。所以如果能在單分支研發(fā)的時(shí)候以及集成分支上進(jìn)行檢測(cè)，將被污染的概率降到最低。

在App工廠中，標(biāo)準(zhǔn)中間件只允許依賴基礎(chǔ)庫(kù)層的pod。所以檢測(cè)策略也很簡(jiǎn)單：

遍歷所有標(biāo)準(zhǔn)中間件

遍歷每一個(gè)標(biāo)準(zhǔn)中間件所依賴的pod，并判斷所依賴的pod是否屬于基礎(chǔ)庫(kù)層。如果不屬于，則標(biāo)記這個(gè)被污染的依賴關(guān)系。

輸出所有被污染的標(biāo)準(zhǔn)中間件及不合規(guī)的依賴關(guān)系。

App工廠的實(shí)踐經(jīng)驗(yàn)
App工廠在58App上有著廣泛的應(yīng)用。目前已在房產(chǎn)垂直業(yè)務(wù)平移和招聘垂直App生成上進(jìn)行了應(yīng)用，并上線。

房產(chǎn)垂直業(yè)務(wù)平移實(shí)踐（木星計(jì)劃項(xiàng)目）

從去年開(kāi)始，58同城房產(chǎn)業(yè)務(wù)和安居客房產(chǎn)業(yè)務(wù)進(jìn)行了調(diào)整，租房和二手房業(yè)務(wù)在兩個(gè)獨(dú)立App上進(jìn)行了重新拆分和整合。業(yè)務(wù)調(diào)整后原來(lái)的58同城租房和安居客二手房業(yè)務(wù)變成了垂直業(yè)務(wù)，即在58同城App和安居客App兩個(gè)獨(dú)立App上同時(shí)運(yùn)行。業(yè)務(wù)的調(diào)整給技術(shù)架構(gòu)帶來(lái)了很大的挑戰(zhàn)：

如何將58同城租房、安居客二手房從原有App中拆分出來(lái)？

如何在拆分過(guò)程中處理依賴代碼，最大限度降低攜帶無(wú)關(guān)代碼？

可以想象一下，如果不基于App工廠要達(dá)成上述目標(biāo)，會(huì)出現(xiàn)什么情況？

要么攜帶很多對(duì)方App所不需要的，或者重復(fù)的代碼，造成包大小失控。

要么針對(duì)具體業(yè)務(wù)寫(xiě)非常多的協(xié)議（Protocol），各獨(dú)立App針對(duì)協(xié)議做各自實(shí)現(xiàn)。但這個(gè)協(xié)議會(huì)非常多，尤其針對(duì)存量代碼的改造成本非常高。

于是，58無(wú)線技術(shù)部與房產(chǎn)技術(shù)部（安居客房產(chǎn)技術(shù)部、58房產(chǎn)技術(shù)部）一拍即合，就將App工廠應(yīng)用到房產(chǎn)垂直業(yè)務(wù)平移中。

1.項(xiàng)目里程碑

這里重點(diǎn)介紹一下項(xiàng)目里程碑，以說(shuō)明在多App垂直業(yè)務(wù)平移過(guò)程中，接入App工廠的思路。

編號(hào)

里程碑

依賴前置節(jié)點(diǎn)

1

58APP無(wú)線技術(shù)側(cè)封裝并提供垂直業(yè)務(wù)所需公共庫(kù)

/

2

58APP接入上述垂直業(yè)務(wù)公共庫(kù)

1

3

安居客APP接入上述垂直業(yè)務(wù)公共庫(kù)

1

4

租房業(yè)務(wù)適配雙APP，并支持業(yè)務(wù)在雙APP平移

1、2、3

5

二手房業(yè)務(wù)線適配雙APP，并支持業(yè)務(wù)雙APP平移

1、2、3

從上述表格及依賴關(guān)系可以看出項(xiàng)目主要分為三個(gè)階段：

抽離出垂直業(yè)務(wù)所依賴的公共庫(kù)

各App分別接入抽出的公共庫(kù)

垂直業(yè)務(wù)做一些適配，能同時(shí)運(yùn)行在雙App上

第一個(gè)階段公共庫(kù)的抽離大概用了1個(gè)半月；第二個(gè)階段各獨(dú)立App接入公共庫(kù)用了1-2個(gè)版本（平均3個(gè)星期一個(gè)版本），主要看測(cè)試資源的情況；第三個(gè)階段垂直業(yè)務(wù)平移用了2-3個(gè)版本。

2.項(xiàng)目實(shí)施概述

2.1 公共庫(kù)的抽離

這里的公共庫(kù)是指垂直業(yè)務(wù)所依賴的中間件層代碼庫(kù)和基礎(chǔ)庫(kù)層代碼庫(kù)。這一步非常重要，如果沒(méi)有處理到位，后續(xù)業(yè)務(wù)在接入的過(guò)程中會(huì)不斷返工。

具體垂直業(yè)務(wù)對(duì)中間件代碼和基礎(chǔ)庫(kù)代碼的耦合分析上文已詳細(xì)介紹了，在此不重復(fù)描述。這里要討論一個(gè)實(shí)踐中很重要的問(wèn)題：從兩個(gè)獨(dú)立App中抽離公共庫(kù)，如何統(tǒng)一的問(wèn)題？

這個(gè)問(wèn)題很復(fù)雜，以網(wǎng)絡(luò)中間件為例，各獨(dú)立App都有自己的封裝，而且封裝的API差異很大，很難通過(guò)調(diào)整API協(xié)議去抹平差異。這種情況下最簡(jiǎn)單高效的方法是以一方App為基準(zhǔn)，另一方App提兼容需求并放棄原有自己的代碼，抽離出來(lái)后共同維護(hù)。

考慮到App的體量和對(duì)業(yè)務(wù)的影響，當(dāng)時(shí)商量的是以58App為基準(zhǔn)，安居客根據(jù)二手房業(yè)務(wù)代碼的調(diào)用需求，提兼容需求。58App抽離出來(lái)后，安居客重新接入。

最終剝離出的公共庫(kù)（標(biāo)準(zhǔn)中間件）如下表所示：

中間件

功能描述

網(wǎng)絡(luò)庫(kù)

封裝了網(wǎng)絡(luò)訪問(wèn)的基礎(chǔ)操作

數(shù)據(jù)庫(kù)

封裝了同城App內(nèi)涉及到的包括城市列表、地鐵列表、商圈數(shù)據(jù)、歷史瀏覽記錄、足跡信息的存儲(chǔ)與讀取的接口。

Hybrid基礎(chǔ)庫(kù)

封裝了Hybrid交互功能，action分發(fā)功能以及一些標(biāo)準(zhǔn)化的actions

React Native基礎(chǔ)庫(kù)

封裝了RN基礎(chǔ)功能，包括載體頁(yè)、熱更新、性能優(yōu)化以及一些標(biāo)準(zhǔn)化的Modules

定位庫(kù)

封裝了定位觸發(fā)的基礎(chǔ)策略和定位原始數(shù)據(jù)的獲取

緩存庫(kù)

封裝了緩存的底層實(shí)現(xiàn)以及一些基本操作

路由跳轉(zhuǎn)庫(kù)

封裝了支持基于主App跳轉(zhuǎn)協(xié)議的跳轉(zhuǎn)分發(fā)邏輯

協(xié)議庫(kù)

提供給支持跨平臺(tái)業(yè)務(wù)調(diào)用底層具體實(shí)現(xiàn)的協(xié)議(Protocol)部分，具體實(shí)現(xiàn)由不同平臺(tái)各自實(shí)現(xiàn)

公共參數(shù)庫(kù)

封裝了部分公共參數(shù)的生成與獲取API，直接接入即可自動(dòng)獲取到58同城App內(nèi)請(qǐng)求頭、Cookie、以及其他公共參數(shù)

關(guān)于公共庫(kù)的剝離有兩個(gè)關(guān)鍵點(diǎn)要注意：

以要平移的業(yè)務(wù)所依賴的公共庫(kù)為核心，不要貪多。以業(yè)務(wù)驅(qū)動(dòng)來(lái)剝離公共庫(kù)，隨著業(yè)務(wù)的逐步接入和不斷支持，公共庫(kù)的數(shù)量和能力也逐漸上去了。

技術(shù)上剝離公共庫(kù)不難，難的是最大限度降低對(duì)其它業(yè)務(wù)的影響，以及保證關(guān)聯(lián)業(yè)務(wù)上線的穩(wěn)定性。

如前文架構(gòu)中介紹的，公共庫(kù)有標(biāo)準(zhǔn)中間價(jià)和業(yè)務(wù)中間件。在這里沒(méi)有具體介紹業(yè)務(wù)中間件的情況。因?yàn)闃I(yè)務(wù)中間件的依賴關(guān)系比較復(fù)雜。在具體拆分時(shí)一定要詳細(xì)分析拆分成本。

2.2 各獨(dú)立App接入公共庫(kù)

下表列舉了實(shí)施過(guò)程中的其中有代表性的四個(gè)中間件在各獨(dú)立App上的接入方案。

中間件

安居客二手房

58App租房

網(wǎng)絡(luò)庫(kù)

√安居客二手房代碼遷移到58App，使用58網(wǎng)絡(luò)庫(kù)，支持httpbody，安居客業(yè)務(wù)代碼做適當(dāng)改動(dòng)。

√58App租房代碼遷移到安居客，安居客做一個(gè)適配api層，58App房產(chǎn)業(yè)務(wù)代碼不需要改動(dòng)。

數(shù)據(jù)庫(kù)

√安居客二手房代碼遷移到58App因業(yè)務(wù)不涉及，不用考慮數(shù)據(jù)庫(kù)問(wèn)題。

√58App租房代碼遷移到安居客，只攜帶58上的數(shù)據(jù)庫(kù)及數(shù)據(jù)表，業(yè)務(wù)代碼不用改動(dòng)。

Hybrid

√安居客二手房代碼遷移到58App，業(yè)務(wù)代碼做兼容改動(dòng)。

√58App租房代碼遷移到安居客，攜帶58側(cè)精簡(jiǎn)版的SDK，Action擴(kuò)展能力在安居客中獨(dú)立實(shí)現(xiàn)，業(yè)務(wù)代碼不用改動(dòng)。

跳轉(zhuǎn)中心

√安居客二手房代碼遷移到58App，修改業(yè)務(wù)代碼適應(yīng)58跳轉(zhuǎn)協(xié)議；

√58App租房代碼遷移到安居客，不需用修改業(yè)務(wù)代碼。

……

……

……

由于是基于58App抽離出的中間件，所以58App租房代碼在平移的過(guò)程中，業(yè)務(wù)代碼基本不用改動(dòng)。但安居客的業(yè)務(wù)代碼需要做相應(yīng)的改動(dòng)，這個(gè)成本是節(jié)省不了的。從當(dāng)前上線的安居客二手房功能代碼穩(wěn)定性來(lái)看，這個(gè)部分改動(dòng)很成功。

2.3 垂直業(yè)務(wù)平移

上述垂直業(yè)務(wù)依賴的公共庫(kù)在各個(gè)獨(dú)立App接入后，并不意味著垂直業(yè)務(wù)就可以平移了。App工廠的一個(gè)核心目標(biāo)是不攜帶無(wú)關(guān)代碼。垂直業(yè)務(wù)除了對(duì)公共庫(kù)有依賴，還對(duì)自身App中的其它模塊代碼有依賴。只有最大限度對(duì)這些非公共庫(kù)代碼摘除依賴，即拆分成業(yè)務(wù)中間件，才能真正滿足App工廠目標(biāo)。

這里不具體敘述如何去解藕業(yè)務(wù)中間件，主要介紹一下操作過(guò)程中的幾個(gè)準(zhǔn)則，只要把握好這個(gè)準(zhǔn)則，基本沒(méi)什么大的問(wèn)題：

分析依賴代碼能否做成業(yè)務(wù)中間件。業(yè)務(wù)中間件一定要滿足前文敘述的單向依賴原則，否則在代碼攜帶過(guò)程中無(wú)法做分析。

如果依賴代碼只是少數(shù)幾個(gè)文件，不足以拆分出業(yè)務(wù)中間件。在對(duì)包大小沒(méi)有影響的前提下可以允許一些重復(fù)代碼。

拆分業(yè)務(wù)中間件的過(guò)程中一定要保證對(duì)其它業(yè)務(wù)線不要產(chǎn)生影響。比如房產(chǎn)和招聘都依賴一塊業(yè)務(wù)中間件代碼，那在滿足房產(chǎn)業(yè)務(wù)平移的過(guò)程中，要想辦法不要對(duì)招聘代碼產(chǎn)生影響。

對(duì)常見(jiàn)的解藕手段一定要注意選型，比如什么場(chǎng)景該用通知，什么場(chǎng)景該用runtime，什么場(chǎng)景該用protocol。

3.項(xiàng)目成果

這個(gè)項(xiàng)目是三方一起共同完成的，在這里僅說(shuō)無(wú)線iOS側(cè)的一些成果：

成果項(xiàng)

成果說(shuō)明

1套App工廠架構(gòu)

分層架構(gòu)及各層的依賴準(zhǔn)則，用以作為pod解耦的基礎(chǔ)準(zhǔn)則

2種App生成支持

支持創(chuàng)新App、獨(dú)立App垂直業(yè)務(wù)代碼生成

3種自動(dòng)化質(zhì)量保證工具

標(biāo)準(zhǔn)中間件污染檢測(cè)、中間件占包大小檢測(cè)、中間價(jià)靜態(tài)庫(kù)自動(dòng)編譯和同步

4類(lèi)核心問(wèn)題兼容性方案

統(tǒng)一跳轉(zhuǎn)、Hybrid垂直業(yè)務(wù)平移、Cookie和header統(tǒng)一、個(gè)性化業(yè)務(wù)兼容

14個(gè)標(biāo)準(zhǔn)中間件

比如Hybrid中間件、RN中間件、網(wǎng)絡(luò)中間件、跳轉(zhuǎn)中間件等

430個(gè)類(lèi)，3309個(gè)方法

14個(gè)標(biāo)準(zhǔn)中間價(jià)涉及430個(gè)類(lèi)，3309個(gè)方法

上述成果只涵蓋了App工廠標(biāo)準(zhǔn)化成果，這些標(biāo)準(zhǔn)化成果不僅僅支持房產(chǎn)垂直業(yè)務(wù)平移，還適用于對(duì)其它業(yè)務(wù)的支持，比如58同城招聘App（已完成）、58同城租房App（即將進(jìn)行）的生成和部落垂直業(yè)務(wù)平移（正在進(jìn)行）。關(guān)于業(yè)務(wù)中間件的解耦與具體業(yè)務(wù)有關(guān)聯(lián)，在此沒(méi)有詳細(xì)梳理。

App工廠在木星計(jì)劃中對(duì)包大小的收益及接入后的穩(wěn)定性如下表所示：

指標(biāo)

58App接入App工廠

安居客App接入App工廠

數(shù)據(jù)說(shuō)明

包大小

給58租房平移到安居客App節(jié)省73MB左右

租房依賴的中間件（41.2MB）+租房依賴的三方庫(kù)（43.8MB）-安居客接入標(biāo)準(zhǔn)中間件（11.4MB）=73.6MB

給安居客二手房平移到58App節(jié)省28 MB

二手房依賴的中間件（13.08MB）+二手房依賴的三方庫(kù)（14.88MB）= 28MB

節(jié)省的包大小是按照接入App工廠前后需要攜帶的代碼計(jì)算的。

崩潰率

接入前8.22版本崩潰率千分之1.1，接入后8.23版本千分之1

接入前12.14版本崩潰率 千分之1， 接入后12.16版本 千分之1.3

安居客接入App工廠的12.16版本崩潰率升高萬(wàn)分之三與App 工廠無(wú)關(guān)，主要來(lái)自其它業(yè)務(wù)的崩潰。

從上表可以看出，包大小上不論是對(duì)58App還是安居客App，都有非常大的收益。崩潰率在接入前后沒(méi)有顯著性變化，代碼上線穩(wěn)定表現(xiàn)良好。特別是針對(duì)崩潰率和功能穩(wěn)定性，涉及這么大范圍的變動(dòng)，能做到?jīng)]有線上事故確實(shí)不容易。

58同城招聘App（創(chuàng)新App）生成實(shí)踐

創(chuàng)新App、極速版App都是同一類(lèi)型的App，大部分基礎(chǔ)功能都可以使用App工廠基礎(chǔ)能力。由于蘋(píng)果在馬甲包審核規(guī)則上的限制，功能的相似度超過(guò)一定程度會(huì)有較大的審核風(fēng)險(xiǎn)。所以不論是創(chuàng)新App還是極速版App，基于蘋(píng)果審核的限制，肯定不能百分生成所需要的代碼，有一部分代碼需要額外開(kāi)發(fā)。至于額外開(kāi)發(fā)的代碼需要占多大比例，沒(méi)有確定答案，能向蘋(píng)果解釋得通業(yè)務(wù)模式差異，能通過(guò)蘋(píng)果審核就是王道。

同木星計(jì)劃項(xiàng)目中接入App工廠不同，創(chuàng)新App代碼的生成下面將換一個(gè)角度來(lái)描述，重點(diǎn)介紹pod依賴的梳理與解耦。

Pod依賴的耦合梳理

Pod依賴的耦合梳理的目標(biāo)是：招聘pod依賴直接或間接依賴哪些pod，這些依賴關(guān)系哪些是不滿足App工廠依賴準(zhǔn)則，如何剪除某些依賴關(guān)系達(dá)到App工廠依賴準(zhǔn)則？

上面的依賴關(guān)系圖中有兩根灰色的虛線，整個(gè)圖被切成三部分，從上到下依次對(duì)應(yīng)App工廠架構(gòu)中的業(yè)務(wù)層、中間件層和基礎(chǔ)庫(kù)層。其中打叉號(hào)的箭頭表示的是不符合App工廠依賴準(zhǔn)則的：

業(yè)務(wù)pod橫向依賴。比如招聘和用戶中心pod都屬于業(yè)務(wù)層，但招聘pod依賴了用戶中心pod，屬于同一層中的橫向依賴，這個(gè)依賴需要剪除。

下層pod對(duì)上層pod有依賴。比如跳轉(zhuǎn)中心pod依賴首頁(yè)pod，跳轉(zhuǎn)中心pod屬于中間件pod，首頁(yè)pod屬于業(yè)務(wù)層pod，這種依賴就是下層的中間件pod依賴了上層的業(yè)務(wù)層pod，這個(gè)依賴需要剪除。

可以看到，如果將上述不符合App工廠依賴準(zhǔn)則的依賴解除之后，招聘pod就與個(gè)人中心pod和首頁(yè)pod沒(méi)有依賴關(guān)系了，在App代碼生成的時(shí)候也不會(huì)攜帶不需要的代碼了（個(gè)人中心、首頁(yè)pod的代碼及其依賴的一堆代碼）。

Pod間耦合解除措施

Pod間耦合解除最終是要落地到pod間代碼的調(diào)用關(guān)系解除，比如招聘pod依賴了用戶中心pod，肯定是招聘pod中的某個(gè)代碼文件依賴了用戶中心pod的代碼文件，解耦的落地是找到代碼文件中代碼的耦合并根據(jù)情況解除。

我們常用的代碼耦合解除手段有：

移動(dòng)代碼文件。這是成本最低的一種手段，測(cè)試影響也相對(duì)最小，是最先推薦使用的方案。通過(guò)移動(dòng)代碼文件到一個(gè)合適的podFit中后，原有兩個(gè)pod的耦合關(guān)系就自動(dòng)解除了。選擇這個(gè)合適的podFit的一個(gè)原則是，原有pod本來(lái)就對(duì)這個(gè)podFit有依賴關(guān)系，增加新的代碼文件并不會(huì)帶來(lái)新的依賴。但有的時(shí)候沒(méi)有一個(gè)已有的合適的pod，這時(shí)候就要評(píng)估創(chuàng)建一個(gè)新的pod來(lái)解決這種情況了。

移動(dòng)方法或公共屬性。這是成本次高的一種手段，方法或者公共屬性所處類(lèi)的位置發(fā)生變化后，需要梳理各種使用的業(yè)務(wù)邏輯，尤其是要注意runtime對(duì)方法的動(dòng)態(tài)調(diào)用。

編譯時(shí)耦合解除。有好多代碼間調(diào)用其實(shí)并不是必須的，比如招聘pod有一個(gè)投遞簡(jiǎn)歷的邏輯和個(gè)人中心我的簡(jiǎn)歷業(yè)務(wù)耦合。一旦用戶在招聘模塊投遞了一個(gè)簡(jiǎn)歷，個(gè)人中心需要有相應(yīng)的功能顯示。招聘模塊需要向個(gè)人中心模塊傳遞一個(gè)消息，這個(gè)消息的傳遞可以用通知實(shí)現(xiàn)，也可以直接調(diào)用個(gè)人中心提供的API。但無(wú)論時(shí)是哪一種實(shí)現(xiàn)方式，這個(gè)消息傳遞并不影響招聘模塊的業(yè)務(wù)獨(dú)立性，即使個(gè)人中心這個(gè)模塊功能沒(méi)有，招聘模塊也可以運(yùn)行。這種情況下的解耦，只要保證在編譯時(shí)代碼不報(bào)錯(cuò)，將一些直接API調(diào)用的地方改用通知，或runtime調(diào)用方式即可。

公共代碼下沉。有好多代碼間調(diào)用是運(yùn)行時(shí)必須的，針對(duì)這些代碼就沒(méi)法使用編譯時(shí)耦合解除的手段，需要將這部分代碼下沉到下一層，比如中間件層。公共代碼下沉的手段和前文提到的代碼文件移動(dòng)的手段有些交集，但又有差別。代碼文件強(qiáng)調(diào)的是代碼文件的移動(dòng)，不一定要移動(dòng)到下層pod；公共代碼下沉既可能是代碼文件下沉，也可能是某一個(gè)方法下沉。

基于協(xié)議的代碼隔離。還有一種常見(jiàn)情況需要重點(diǎn)提出來(lái)，就是有好多業(yè)務(wù)在不同App中表現(xiàn)形態(tài)不一樣，很難用一套代碼來(lái)解決。針對(duì)這種情況，需要抽離出一層協(xié)議，在公共代碼中通過(guò)協(xié)議來(lái)調(diào)用，在接入App中基于協(xié)議來(lái)完成不同的實(shí)現(xiàn)。

Pod解耦，尤其涉及到業(yè)務(wù)層代碼和中間件層代碼的解耦，很難有一個(gè)標(biāo)準(zhǔn)衡量哪些pod的耦合在最開(kāi)始做的是對(duì)的還是錯(cuò)的。因?yàn)楹枚鄻I(yè)務(wù)在最開(kāi)始的時(shí)候從產(chǎn)品層面，沒(méi)有考慮到這個(gè)業(yè)務(wù)是一個(gè)垂直業(yè)務(wù)，會(huì)在多App上平移。但是一旦有一個(gè)業(yè)務(wù)被確定要支持多App后，這個(gè)業(yè)務(wù)涉及的pod的依賴關(guān)系必須滿足App工廠的依賴準(zhǔn)則。這一點(diǎn)在后續(xù)的業(yè)務(wù)持續(xù)迭代中要尤其注意。

風(fēng)險(xiǎn)控制

App工廠的整個(gè)代碼重構(gòu)，涉及的面非常廣。58App今年在App工廠上對(duì)代碼的改動(dòng)是之前所未有的。每個(gè)公司業(yè)務(wù)及架構(gòu)不同，代碼的復(fù)雜度和重構(gòu)的難度也不一樣，所以面臨的線上風(fēng)險(xiǎn)也會(huì)各有差異。在重構(gòu)過(guò)程中除了要有嚴(yán)格的技術(shù)方案評(píng)審、代碼審查、全面的Case測(cè)試外，尤其要注意兩點(diǎn)容易被忽視但很容易出問(wèn)題的點(diǎn)：

版本迭代合并遺漏風(fēng)險(xiǎn)

在58App中，隨著App工廠的不斷深入和業(yè)務(wù)的逐步接入，中間件層和基礎(chǔ)服務(wù)層拆分的越來(lái)越細(xì)了，pod的數(shù)據(jù)目前全部加起來(lái)已經(jīng)超過(guò)50個(gè)了。App工廠項(xiàng)目進(jìn)行的同時(shí)，還有日常版本需求項(xiàng)目并行開(kāi)發(fā)。在這過(guò)程中，同一份代碼既可能會(huì)在App工廠中改動(dòng)，又會(huì)有相應(yīng)新需求的研發(fā)。

App工廠項(xiàng)目跨度比較長(zhǎng)，比如某一個(gè)中間價(jià)是基于8.0版本拉分支出來(lái)開(kāi)發(fā)的，但是可能會(huì)跨幾個(gè)版本才能上線。在這個(gè)過(guò)程中一定要不斷合并新版本代碼到當(dāng)前App工廠分支。并且對(duì)一些有沖突的代碼一定要細(xì)心處理。中間件層代碼和基礎(chǔ)服務(wù)層代碼的變動(dòng)測(cè)試一直是一個(gè)痛點(diǎn)，很難覆蓋所有的業(yè)務(wù)場(chǎng)景，所以一定要對(duì)有沖突和有改動(dòng)的代碼進(jìn)行細(xì)心處理，以防帶來(lái)線上問(wèn)題。

數(shù)據(jù)耦合風(fēng)險(xiǎn)

數(shù)據(jù)耦合指的是某些業(yè)務(wù)代碼會(huì)操作且依賴某公共數(shù)據(jù)。但數(shù)據(jù)依賴在編譯時(shí)和大部分運(yùn)行時(shí)發(fā)現(xiàn)不了，這給發(fā)現(xiàn)問(wèn)題帶來(lái)很大的難度。比如App上的商圈數(shù)據(jù)、埋點(diǎn)數(shù)據(jù)、用戶電話撥打記錄、帖子收藏記錄等，都屬于數(shù)據(jù)耦合范疇。

與上面的版本合并遺漏問(wèn)題一樣，數(shù)據(jù)耦合風(fēng)險(xiǎn)處理的原則也是對(duì)所有影響數(shù)據(jù)的業(yè)務(wù)進(jìn)行詳細(xì)的梳理并解耦，要從開(kāi)發(fā)、測(cè)試、灰度數(shù)據(jù)驗(yàn)證等多個(gè)關(guān)鍵節(jié)點(diǎn)進(jìn)行全面處理。

總結(jié)
任何架構(gòu)都離不開(kāi)業(yè)務(wù)，都是為了解決業(yè)務(wù)痛點(diǎn)、問(wèn)題的，App工廠也不例外。由于每個(gè)公司的App架構(gòu)不同、業(yè)務(wù)形式不同、部門(mén)協(xié)作研發(fā)的形式也不同，所以肯定沒(méi)有一個(gè)放之四海而皆準(zhǔn)的App工廠理論和實(shí)現(xiàn)準(zhǔn)則。

58App在實(shí)施的過(guò)程中，也是通過(guò)業(yè)務(wù)的不斷接入逐步完善App工廠的能力。而完善的這部分能力，有標(biāo)準(zhǔn)化的能力，也有非標(biāo)準(zhǔn)化的能力。而且標(biāo)準(zhǔn)化和非標(biāo)準(zhǔn)化隨著后續(xù)業(yè)務(wù)的迭代還可能會(huì)相互轉(zhuǎn)化。未來(lái)58App還會(huì)持續(xù)在更多業(yè)務(wù)上進(jìn)行接入，以持續(xù)解決業(yè)務(wù)問(wèn)題，給業(yè)務(wù)研發(fā)提效。

App工廠是團(tuán)隊(duì)協(xié)作的成果，感謝參與其中的同學(xué)。App工廠從構(gòu)想到實(shí)施、再到業(yè)務(wù)接入，是近年來(lái)58無(wú)線技術(shù)少有的大動(dòng)作。沒(méi)有用戶價(jià)值增長(zhǎng)部各級(jí)老板的構(gòu)想、規(guī)劃、指導(dǎo)和組內(nèi)同學(xué)的協(xié)同貫徹實(shí)施，沒(méi)有房產(chǎn)技術(shù)部（安居客房產(chǎn)技術(shù)部、58趕集房產(chǎn)技術(shù)部）、招聘技術(shù)部等部門(mén)的老板和同學(xué)的精密協(xié)作和業(yè)務(wù)實(shí)踐，是啟動(dòng)和完成不了這么一個(gè)大的工程。

作者：

彭飛，58同城-基礎(chǔ)技術(shù)部-iOS技術(shù)部 架構(gòu)師，iOS技術(shù)部負(fù)責(zé)人。

曾慶隆，58同城-基礎(chǔ)技術(shù)部-iOS技術(shù)部 架構(gòu)師

王曉暉，58同城-基礎(chǔ)技術(shù)部-iOS技術(shù)部 高級(jí)研發(fā)工程師

總結(jié)

以上是生活随笔為你收集整理的58移动开发 App 工厂的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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