58移动开发 App 工厂
導語：App工廠，顧名思義，是一個能根據各種素材和組織形式生成App的工廠。更專業(yè)一點的描述，是根據一個具有完備組件庫以及這些組件的依賴關系，組合成一個個App。
以往的單App研發(fā)架構，由于每次打包編譯、版本發(fā)布都是一個全量的代碼集合，所以不會也不需要考慮每一個組件之間的依賴和耦合關系。在多App場景下，由于存在一套代碼，按需生成不同App所需要的代碼，原有的架構、代碼依賴關系、工程代碼組織方式都需要相應的改變。
App工廠的目標是在特定架構和業(yè)務場景下，基于一套代碼，按需生成目標App所需的代碼。一套代碼和按需生成是核心，缺一不可。特別是按需生成，意味著不攜帶任何不需要的代碼，這個在實現(xiàn)的過程中非常具有挑戰(zhàn)性。本文從iOS視角，分享58App在App工廠方面的理論和實踐的探索。
作者 | 彭飛
App工廠產生背景
業(yè)務的快速試錯催生多App
移動互聯(lián)網不論是在上半場，還是在下半場，業(yè)務的創(chuàng)新從來沒有停歇過。從微博到團購，從共享汽車到共享單車，從長視頻到短視頻，業(yè)務和模式的創(chuàng)新不斷。近幾年尤以頭條系的業(yè)務試錯見諸于各報端，從資訊到直播，再到短視頻，是一波接一波。
當前不論是大的互聯(lián)網公司，還是創(chuàng)業(yè)性的小公司，要想在新的領域摸索出一番天地，必須不斷試錯。移動領域的業(yè)務不斷試錯，要求能快速產出各業(yè)務對應的創(chuàng)新App。
集團業(yè)務的逐步擴大與細化催生多App
互聯(lián)網江湖早已三分天下，巨頭已經建立，大的互聯(lián)網平臺很難形成。但越是大的互聯(lián)網平臺，越擔心垂直細分業(yè)務的進攻。為應對進攻，集團業(yè)務也需要在一些領域逐步擴大和細化，垂直App應運而生。
垂直App與創(chuàng)新App的差距在于，垂直App是基于現(xiàn)有平臺業(yè)務細分而來，而創(chuàng)新App是平臺業(yè)務所沒有的。
另外，為了應對應用市場的分發(fā)和對包大小敏感的用戶，這幾年極速包幾乎成為各大公司的必備App。
集團業(yè)務的合并融合催生多App交叉
業(yè)務的收購、合并也是大型互聯(lián)網公司常有的事。收購合并后的業(yè)務如何融合，如何既能保持業(yè)務的獨立性，又能節(jié)省集團研發(fā)資源，還能支持一套交叉業(yè)務（又稱垂直業(yè)務）代碼在各獨立App運行，是一個重要又復雜的問題。比如今年58集團內安居客房產業(yè)務和原58房產業(yè)務的融合就是一個典型的案例。
App工廠目標、架構與實施方法
App工廠的實施目標
1.App工廠有以下目標：
標準化能力的產出，為App研發(fā)提效增速
標準化能力是實現(xiàn)App工廠的基礎，標準化能力與App業(yè)務代碼無耦合關系，比如React Native SDK，網絡庫、緩存庫等。
支持創(chuàng)新App、垂直App、極速App的生成和迭代
同一套代碼，根據配置，能按需生成不同App所需的代碼。按需生成是關鍵和核心，不給App工廠生成的App代碼攜帶任何無用代碼，增加包大小。
支持垂直業(yè)務在獨立App上的平移
App工廠依附于58App框架代碼上，馬甲包、極速包與App工廠（58App）是一個子集與全集的關系。但類似安居客App與58App是兩個獨立App，有交集（公共底層代碼或某些業(yè)務代碼），業(yè)務代碼集合不一樣。
針對獨立App的公共業(yè)務代碼，定義為垂直業(yè)務。App工廠在統(tǒng)一底層服務的前提下，也要支持垂直業(yè)務在獨立App上的平移。即一套業(yè)務代碼，能在兩個或多個獨立App上運行。
App工廠架構
名詞解釋
PODS
在iOS領域，pods特指cocoapods，是其縮寫。cocoapods是對OC或swift Cocoa 工程的依賴管理。（CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. ）
中間件
中間件在軟件領域的通用解釋是：連接軟件組件和應用的程序。在這里中間件體現(xiàn)的是連接和共用。連接的是業(yè)務層和基礎庫層，共用體現(xiàn)在業(yè)務層的公共服務。
中間件按照業(yè)務強相關與否分為業(yè)務中間件和標準中間件。
業(yè)務中間件：
與業(yè)務強相關的中間件，在某一個獨立App中通用。由于對當前App其它功能的過多依賴，所以不適用于其他獨立App。
標準中間件：
與業(yè)務弱相關的中間件，不僅在某一個獨立App中通用，在其它獨立App中也通用，與App中的業(yè)務弱相關。最常見的是標準版的RNSDK。
基礎庫
對其它pod不產生依賴的獨立庫。比如一些開源的三方庫，是常見的基礎庫。除了第三方開源的，58集團內自封裝的sdk，如果對其它pod不產生依賴，也可以歸入基礎庫范圍，比如Passport SDK，WPush SDK等；
入口工程
主要負責對App工廠生成的App所需代碼進行配置。
入口工程pods：主要負責對App工廠生成的App所需代碼進行配置，入口工程中包括的功能有：
APPInfo：對App基礎信息的設置，比如App名稱，bundle identifier，版本號，證書等；
Podfile：當前App對所需工程代碼的依賴，比如招聘馬甲包會依賴招聘業(yè)務pod以及其他基礎服務pod和三方庫pod；
Regen.sh: 一個可執(zhí)行文件（本地RD研發(fā)調試用），讀取podfile配置，拷貝App所需代碼及配置，然后生成App所需代碼；
Reng_jenkins.sh: 一個可執(zhí)行文件（Jenkins服務打包用），讀取podfile配置，拷貝App所需代碼及配置，然后生成App所需代碼；
工程庫池
工程池是App工廠總的pod代碼集合。
工程池是App工廠總的代碼集合，每一個生成App所需代碼都是從這個代碼集合中獲取，研發(fā)過程中代碼更新也會同步更新到此代碼集合中去。
業(yè)務pods：各獨立業(yè)務工程代碼，代碼集合根據業(yè)務類型來劃分，比如App首頁pod、房產pod、招聘pod；
中間件pods：App工廠中間服務代碼，是58自己封裝的，區(qū)別于外界的第三方公開代碼，故稱為中間件代碼。中間件根據對58App業(yè)務的是否強依賴分為：
業(yè)務中間件：
與58App業(yè)務強相關，但是是58App中業(yè)務中通用中間服務，其應用場景在58App的業(yè)務場景內。
標準中間件：
與58App業(yè)務弱相關，可以作為一個標準化中間件在其它獨立App上引入。
在標準中間件中可以看到有圖標加了兩條豎線，這表示此標準中間件某些功能的實現(xiàn)依賴接入App的實現(xiàn)，只開放了接口協(xié)議。
以RN基礎庫標準中間件為例：
中間件包含的內容是載體頁及熱更新的全部公共的與業(yè)務弱相關的內容，但對于一些擴展的組件（比如埋點）需要開放協(xié)議讓接入方實現(xiàn)，中間件中不實現(xiàn)此邏輯。
三方庫pods：外界的開源第三方庫代碼，基本在行業(yè)內有統(tǒng)一的引用標準；
架構解析
上圖是App工廠架構圖，大的方面分為上下兩層：入口工程和工廠池。入口工程pod對工程池中的pod進行依賴，通過podfile配置每一個入口工程所在App所需的pod代碼。
工程池中的pod分為業(yè)務層、中間件層和基礎庫層。其中中間件層根據代碼是否強依賴58App業(yè)務，分為業(yè)務中間件和標準中間件。
在架構設計上，各層pods的依賴準則為：
上層可以依賴下層，但下層不可以依賴上層。比如上層中的業(yè)務pod中的首頁（MainPage）可以依賴業(yè)務中間件中的生命周期（WBLifeCircle），但反之不能依賴。
可以隔層依賴。比如業(yè)務pod可以依賴基礎庫pod；
業(yè)務pod間不能產生依賴。比如房產pod不能依賴招聘pod。
中間件pod和三方庫pod可以單向依賴。比如RN所在pod可以對登錄服務所在pod產生單向依賴。
制定上述依賴準則，是為了在生產App時或者進行垂直業(yè)務平移時可以按需配置所需pod。
如何借助App工廠架構達成設計目標
1.如何提供標準化的能力
所謂標準化能力，可以理解為獨立無依賴的Framework或SDK，對應上述架構圖中的標準中間件。比如RN基礎庫，封裝了載體頁、熱更新等一整套公共服務，58App外的獨立App可以無縫接入。
下圖展示的一些標準中間件：
標準中間件名稱
pod名稱
功能描述
RN基礎庫
WBReactNativeLibrary
封裝了RN基礎功能，包括載體頁、熱更新、性能優(yōu)化以及一些標準化的Modules
Hybrid基礎庫
WBHybrid
封裝了Hybrid交互功能，action分發(fā)功能以及一些標準化的actions
跳轉組件
WBPageTransferDispatcher
封裝了支持基于主App跳轉協(xié)議的跳轉分發(fā)邏輯
網絡庫
WBNetwork
封裝了網絡訪問的基礎操作，網絡操作更近便利
定位
WBLocation
封裝了定位觸發(fā)的基礎策略和定位原始數據的獲取
緩存庫
WBCache
封裝了緩存的底層實現(xiàn)以及一些基本操作
…
另外，還有一些集團內其他中臺部門提供的標準化SDK，比如PassportSDK、IMSDK、Pay58SDK等。
2.如何支持創(chuàng)新App、極速App的生成
如上圖所示，在理想工程架構狀態(tài)下（即達到架構各層依賴準則），可以按需配置App所需功能，來生成馬甲包或者極速包。
當然為了應對蘋果審核（App之間必須保持差異性），還得針對馬甲包或者極速包來做一些個性化的處理。這種個性化處理在先前的馬賽克項目有完成，具體詳見馬賽克項目。
3.如何支持垂直業(yè)務的平移
垂直業(yè)務：同一業(yè)務在多個App上呈現(xiàn)的業(yè)務稱之為垂直業(yè)務。
垂直業(yè)務平移：并不是真的去移動，是指垂直業(yè)務及依賴的底層代碼是一套公共代碼，能夠運行在不同App上。
上圖所示的是租房和二手房這兩個垂直業(yè)務需要達到一套代碼，同時運行在58App和安居客App上。這就要求：
58App和安居客App共用垂直業(yè)務所依賴的底層代碼（中間件代碼+基礎庫代碼）；
垂直業(yè)務代碼及所依賴的底層代碼對58App或安居客App中的獨有代碼沒有任何耦合，這樣就不會攜帶一些無關的不需要的代碼，有利于控制包大小；
垂直業(yè)務代碼及所依賴的底層代碼必須滿足App工廠架構中的分層原則和依賴原則，這樣架構擴展性會比較靈活
如何對存量代碼實施App工廠
基于前文App工廠技術架構及各層pod的依賴準則，各層pod的依賴關系理想示意圖如下圖所示（以招聘業(yè)務pod依賴為例）：
從業(yè)務層到中間件層再到基礎庫層，從上到下單向依賴，沒有反向依賴和循環(huán)依賴
業(yè)務層之間沒有依賴
中間件層和基礎庫層可以允許有單向依賴
有了上述理想的依賴關系后，在入口工程進行生成App所需代碼進行配置時，就能按需配置，不會因為pod之間的反向依賴、循環(huán)依賴、整層依賴攜帶很多無用代碼，增加包大小。
上圖所示的招聘業(yè)務的依賴關系。黑色箭頭表示的是pod的單向依賴，紅色的雙向箭頭表示的pod的雙向依賴。
備注：服務層對應中間件層，三方庫層對應基礎庫層。
針對業(yè)務pod解耦主要處理下層pod對業(yè)務pod的依賴以及業(yè)務pod之間的依賴，如下圖所示：
如上圖中實線所示的是招聘pod所依賴的中間件層pod之間的耦合關系。
服務層pod解耦要解決以下兩種耦合關系：
pod之間的雙向耦合
pod之間的不必要單向依賴
服務層pod的解耦至關重要，直接涉及到對工具庫pod的依賴處理。如不解除服務層pod的循環(huán)依賴關系，則會導致對工具庫pod的整層依賴，沒法按需配置所依賴的pod，造成包大小無法控制。
由于基礎庫層pod是最底層pod，沒有其他的依賴pod，所以也是這三層pod解耦工作量最少的。
目前58App內的基礎庫層pod全都是放在一個pod中，這層解耦所要作的是按照功能對這個pod進行拆分，拆成一個個上層pod可依賴的單元。
如何保證APP工廠質量
App工廠的質量在版本迭代過程中的質量非常重要。如果在后續(xù)版本迭代過程中代碼沒有嚴格遵循App工廠的pod依賴準則，等到發(fā)現(xiàn)問題才去解決，會帶來很大的額外工作量。
這個是所有質量檢測的基礎。在本文看到的一些pod的依賴關系都是我們開發(fā)的pod依賴自動分析工具得出的。如果沒有這個工具，在一些中大型的App中，靠人工方式去梳理這種依賴關系，將是一個極大的工作量。在這里大概說一下思路，有更好的方式歡迎交流：
掃描本地工程目錄下所有pod代碼文件夾，及里面的類文件，建立類文件與pod工程的映射關系 filePodDict。
掃描每一個pod下面類文件中的文件依賴部分（import部分），根據頭文件依賴及上面的filePodDict，建立pod的直接依賴關系podDepenDict。
串聯(lián)所有pod的直接依賴關系，形成pod依賴最終關系podFinalDepenGraph，并輸出。最終Pod的依賴關系對應的數據結構是有向圖。
如上圖所示，是基于招聘pod和其依賴的pod構建的有向圖的示意圖（為便于識別，將兩個pod直接相互依賴的一條線畫成了虛線）。基于這個數據結構，能實現(xiàn)前文所說的App工廠依賴準則的檢測。
下層pod對上層pod反向依賴，是App工廠依賴準則首要禁止內容。比如如果中間件層的WubaRN的這個pod依賴了上層 首頁pod，會導致在業(yè)務平移過程中因為依賴WubaRN，而需攜帶不需要的首頁業(yè)務代碼。
基于上述的有向圖，反向檢測在技術上很容易實現(xiàn)：
內置一份pod與層級的映射關系
遍歷pod依賴關系有向圖，檢測當前pod所依賴的pod層級是否小于自己的層級，如果小于，則是反向依賴，并標記
將標記的反向依賴關系輸出
在App工廠中，除了業(yè)務層代碼有非常明確的原因不能有依賴和環(huán)外，其它層的pod之間即使存在環(huán)，也有辦法達到App工廠不攜帶多余代碼的目標。但撇開App工廠不說，環(huán)的存在本質上是大多數情況兩個pod之間存在公共代碼沒有下沉。所以為了使App工廠的依賴準則更簡單和更易執(zhí)行，就統(tǒng)一規(guī)定不能產生循環(huán)依賴。
檢測有向圖是否存在環(huán)，是一個基礎的數據結構問題，在此不贅述。
標準中間件是App工廠的核心，如果標準中間件在后續(xù)的業(yè)務迭代過程中被污染，即引入了不符合準則的依賴關系，將帶來額外的維護成本和解耦成本。所以如果能在單分支研發(fā)的時候以及集成分支上進行檢測，將被污染的概率降到最低。
在App工廠中，標準中間件只允許依賴基礎庫層的pod。所以檢測策略也很簡單：
遍歷所有標準中間件
遍歷每一個標準中間件所依賴的pod，并判斷所依賴的pod是否屬于基礎庫層。如果不屬于，則標記這個被污染的依賴關系。
輸出所有被污染的標準中間件及不合規(guī)的依賴關系。
App工廠的實踐經驗
App工廠在58App上有著廣泛的應用。目前已在房產垂直業(yè)務平移和招聘垂直App生成上進行了應用，并上線。
房產垂直業(yè)務平移實踐（木星計劃項目）
從去年開始，58同城房產業(yè)務和安居客房產業(yè)務進行了調整，租房和二手房業(yè)務在兩個獨立App上進行了重新拆分和整合。業(yè)務調整后原來的58同城租房和安居客二手房業(yè)務變成了垂直業(yè)務，即在58同城App和安居客App兩個獨立App上同時運行。業(yè)務的調整給技術架構帶來了很大的挑戰(zhàn)：
如何將58同城租房、安居客二手房從原有App中拆分出來？
如何在拆分過程中處理依賴代碼，最大限度降低攜帶無關代碼？
可以想象一下，如果不基于App工廠要達成上述目標，會出現(xiàn)什么情況？
要么攜帶很多對方App所不需要的，或者重復的代碼，造成包大小失控。
要么針對具體業(yè)務寫非常多的協(xié)議（Protocol），各獨立App針對協(xié)議做各自實現(xiàn)。但這個協(xié)議會非常多，尤其針對存量代碼的改造成本非常高。
于是，58無線技術部與房產技術部（安居客房產技術部、58房產技術部）一拍即合，就將App工廠應用到房產垂直業(yè)務平移中。
1.項目里程碑
這里重點介紹一下項目里程碑，以說明在多App垂直業(yè)務平移過程中，接入App工廠的思路。
編號
里程碑
依賴前置節(jié)點
1
58APP無線技術側封裝并提供垂直業(yè)務所需公共庫
/
2
58APP接入上述垂直業(yè)務公共庫
1
3
安居客APP接入上述垂直業(yè)務公共庫
1
4
租房業(yè)務適配雙APP，并支持業(yè)務在雙APP平移
1、2、3
5
二手房業(yè)務線適配雙APP，并支持業(yè)務雙APP平移
1、2、3
從上述表格及依賴關系可以看出項目主要分為三個階段：
抽離出垂直業(yè)務所依賴的公共庫
各App分別接入抽出的公共庫
垂直業(yè)務做一些適配，能同時運行在雙App上
第一個階段公共庫的抽離大概用了1個半月；第二個階段各獨立App接入公共庫用了1-2個版本（平均3個星期一個版本），主要看測試資源的情況；第三個階段垂直業(yè)務平移用了2-3個版本。
2.項目實施概述
2.1 公共庫的抽離
這里的公共庫是指垂直業(yè)務所依賴的中間件層代碼庫和基礎庫層代碼庫。這一步非常重要，如果沒有處理到位，后續(xù)業(yè)務在接入的過程中會不斷返工。
具體垂直業(yè)務對中間件代碼和基礎庫代碼的耦合分析上文已詳細介紹了，在此不重復描述。這里要討論一個實踐中很重要的問題：從兩個獨立App中抽離公共庫，如何統(tǒng)一的問題？
這個問題很復雜，以網絡中間件為例，各獨立App都有自己的封裝，而且封裝的API差異很大，很難通過調整API協(xié)議去抹平差異。這種情況下最簡單高效的方法是以一方App為基準，另一方App提兼容需求并放棄原有自己的代碼，抽離出來后共同維護。
考慮到App的體量和對業(yè)務的影響，當時商量的是以58App為基準，安居客根據二手房業(yè)務代碼的調用需求，提兼容需求。58App抽離出來后，安居客重新接入。
最終剝離出的公共庫（標準中間件）如下表所示：
中間件
功能描述
網絡庫
封裝了網絡訪問的基礎操作
數據庫
封裝了同城App內涉及到的包括城市列表、地鐵列表、商圈數據、歷史瀏覽記錄、足跡信息的存儲與讀取的接口。
Hybrid基礎庫
封裝了Hybrid交互功能，action分發(fā)功能以及一些標準化的actions
React Native基礎庫
封裝了RN基礎功能，包括載體頁、熱更新、性能優(yōu)化以及一些標準化的Modules
定位庫
封裝了定位觸發(fā)的基礎策略和定位原始數據的獲取
緩存庫
封裝了緩存的底層實現(xiàn)以及一些基本操作
路由跳轉庫
封裝了支持基于主App跳轉協(xié)議的跳轉分發(fā)邏輯
協(xié)議庫
提供給支持跨平臺業(yè)務調用底層具體實現(xiàn)的協(xié)議(Protocol)部分，具體實現(xiàn)由不同平臺各自實現(xiàn)
公共參數庫
封裝了部分公共參數的生成與獲取API，直接接入即可自動獲取到58同城App內請求頭、Cookie、以及其他公共參數
關于公共庫的剝離有兩個關鍵點要注意：
以要平移的業(yè)務所依賴的公共庫為核心，不要貪多。以業(yè)務驅動來剝離公共庫，隨著業(yè)務的逐步接入和不斷支持，公共庫的數量和能力也逐漸上去了。
技術上剝離公共庫不難，難的是最大限度降低對其它業(yè)務的影響，以及保證關聯(lián)業(yè)務上線的穩(wěn)定性。
如前文架構中介紹的，公共庫有標準中間價和業(yè)務中間件。在這里沒有具體介紹業(yè)務中間件的情況。因為業(yè)務中間件的依賴關系比較復雜。在具體拆分時一定要詳細分析拆分成本。
2.2 各獨立App接入公共庫
下表列舉了實施過程中的其中有代表性的四個中間件在各獨立App上的接入方案。
中間件
安居客二手房
58App租房
網絡庫
√安居客二手房代碼遷移到58App，使用58網絡庫，支持httpbody，安居客業(yè)務代碼做適當改動。
√58App租房代碼遷移到安居客，安居客做一個適配api層，58App房產業(yè)務代碼不需要改動。
數據庫
√安居客二手房代碼遷移到58App因業(yè)務不涉及，不用考慮數據庫問題。
√58App租房代碼遷移到安居客，只攜帶58上的數據庫及數據表，業(yè)務代碼不用改動。
Hybrid
√安居客二手房代碼遷移到58App，業(yè)務代碼做兼容改動。
√58App租房代碼遷移到安居客，攜帶58側精簡版的SDK，Action擴展能力在安居客中獨立實現(xiàn)，業(yè)務代碼不用改動。
跳轉中心
√安居客二手房代碼遷移到58App，修改業(yè)務代碼適應58跳轉協(xié)議；
√58App租房代碼遷移到安居客，不需用修改業(yè)務代碼。
……
……
……
由于是基于58App抽離出的中間件，所以58App租房代碼在平移的過程中，業(yè)務代碼基本不用改動。但安居客的業(yè)務代碼需要做相應的改動，這個成本是節(jié)省不了的。從當前上線的安居客二手房功能代碼穩(wěn)定性來看，這個部分改動很成功。
2.3 垂直業(yè)務平移
上述垂直業(yè)務依賴的公共庫在各個獨立App接入后，并不意味著垂直業(yè)務就可以平移了。App工廠的一個核心目標是不攜帶無關代碼。垂直業(yè)務除了對公共庫有依賴，還對自身App中的其它模塊代碼有依賴。只有最大限度對這些非公共庫代碼摘除依賴，即拆分成業(yè)務中間件，才能真正滿足App工廠目標。
這里不具體敘述如何去解藕業(yè)務中間件，主要介紹一下操作過程中的幾個準則，只要把握好這個準則，基本沒什么大的問題：
分析依賴代碼能否做成業(yè)務中間件。業(yè)務中間件一定要滿足前文敘述的單向依賴原則，否則在代碼攜帶過程中無法做分析。
如果依賴代碼只是少數幾個文件，不足以拆分出業(yè)務中間件。在對包大小沒有影響的前提下可以允許一些重復代碼。
拆分業(yè)務中間件的過程中一定要保證對其它業(yè)務線不要產生影響。比如房產和招聘都依賴一塊業(yè)務中間件代碼，那在滿足房產業(yè)務平移的過程中，要想辦法不要對招聘代碼產生影響。
對常見的解藕手段一定要注意選型，比如什么場景該用通知，什么場景該用runtime，什么場景該用protocol。
3.項目成果
這個項目是三方一起共同完成的，在這里僅說無線iOS側的一些成果：
成果項
成果說明
1套App工廠架構
分層架構及各層的依賴準則，用以作為pod解耦的基礎準則
2種App生成支持
支持創(chuàng)新App、獨立App垂直業(yè)務代碼生成
3種自動化質量保證工具
標準中間件污染檢測、中間件占包大小檢測、中間價靜態(tài)庫自動編譯和同步
4類核心問題兼容性方案
統(tǒng)一跳轉、Hybrid垂直業(yè)務平移、Cookie和header統(tǒng)一、個性化業(yè)務兼容
14個標準中間件
比如Hybrid中間件、RN中間件、網絡中間件、跳轉中間件等
430個類，3309個方法
14個標準中間價涉及430個類，3309個方法
上述成果只涵蓋了App工廠標準化成果，這些標準化成果不僅僅支持房產垂直業(yè)務平移，還適用于對其它業(yè)務的支持，比如58同城招聘App（已完成）、58同城租房App（即將進行）的生成和部落垂直業(yè)務平移（正在進行）。關于業(yè)務中間件的解耦與具體業(yè)務有關聯(lián)，在此沒有詳細梳理。
App工廠在木星計劃中對包大小的收益及接入后的穩(wěn)定性如下表所示：
指標
58App接入App工廠
安居客App接入App工廠
數據說明
包大小
給58租房平移到安居客App節(jié)省73MB左右
租房依賴的中間件（41.2MB）+租房依賴的三方庫（43.8MB）-安居客接入標準中間件（11.4MB）=73.6MB
給安居客二手房平移到58App節(jié)省28 MB
二手房依賴的中間件（13.08MB）+二手房依賴的三方庫（14.88MB）= 28MB
節(jié)省的包大小是按照接入App工廠前后需要攜帶的代碼計算的。
崩潰率
接入前8.22版本崩潰率千分之1.1，接入后8.23版本千分之1
接入前12.14版本崩潰率 千分之1， 接入后12.16版本 千分之1.3
安居客接入App工廠的12.16版本崩潰率升高萬分之三與App 工廠無關，主要來自其它業(yè)務的崩潰。
從上表可以看出，包大小上不論是對58App還是安居客App，都有非常大的收益。崩潰率在接入前后沒有顯著性變化，代碼上線穩(wěn)定表現(xiàn)良好。特別是針對崩潰率和功能穩(wěn)定性，涉及這么大范圍的變動，能做到沒有線上事故確實不容易。
58同城招聘App（創(chuàng)新App）生成實踐
創(chuàng)新App、極速版App都是同一類型的App，大部分基礎功能都可以使用App工廠基礎能力。由于蘋果在馬甲包審核規(guī)則上的限制，功能的相似度超過一定程度會有較大的審核風險。所以不論是創(chuàng)新App還是極速版App，基于蘋果審核的限制，肯定不能百分生成所需要的代碼，有一部分代碼需要額外開發(fā)。至于額外開發(fā)的代碼需要占多大比例，沒有確定答案，能向蘋果解釋得通業(yè)務模式差異，能通過蘋果審核就是王道。
同木星計劃項目中接入App工廠不同，創(chuàng)新App代碼的生成下面將換一個角度來描述，重點介紹pod依賴的梳理與解耦。
Pod依賴的耦合梳理的目標是：招聘pod依賴直接或間接依賴哪些pod，這些依賴關系哪些是不滿足App工廠依賴準則，如何剪除某些依賴關系達到App工廠依賴準則？
上面的依賴關系圖中有兩根灰色的虛線，整個圖被切成三部分，從上到下依次對應App工廠架構中的業(yè)務層、中間件層和基礎庫層。其中打叉號的箭頭表示的是不符合App工廠依賴準則的：
業(yè)務pod橫向依賴。比如招聘和用戶中心pod都屬于業(yè)務層，但招聘pod依賴了用戶中心pod，屬于同一層中的橫向依賴，這個依賴需要剪除。
下層pod對上層pod有依賴。比如跳轉中心pod依賴首頁pod，跳轉中心pod屬于中間件pod，首頁pod屬于業(yè)務層pod，這種依賴就是下層的中間件pod依賴了上層的業(yè)務層pod，這個依賴需要剪除。
可以看到，如果將上述不符合App工廠依賴準則的依賴解除之后，招聘pod就與個人中心pod和首頁pod沒有依賴關系了，在App代碼生成的時候也不會攜帶不需要的代碼了（個人中心、首頁pod的代碼及其依賴的一堆代碼）。
Pod間耦合解除最終是要落地到pod間代碼的調用關系解除，比如招聘pod依賴了用戶中心pod，肯定是招聘pod中的某個代碼文件依賴了用戶中心pod的代碼文件，解耦的落地是找到代碼文件中代碼的耦合并根據情況解除。
我們常用的代碼耦合解除手段有：
移動代碼文件。這是成本最低的一種手段，測試影響也相對最小，是最先推薦使用的方案。通過移動代碼文件到一個合適的podFit中后，原有兩個pod的耦合關系就自動解除了。選擇這個合適的podFit的一個原則是，原有pod本來就對這個podFit有依賴關系，增加新的代碼文件并不會帶來新的依賴。但有的時候沒有一個已有的合適的pod，這時候就要評估創(chuàng)建一個新的pod來解決這種情況了。
移動方法或公共屬性。這是成本次高的一種手段，方法或者公共屬性所處類的位置發(fā)生變化后，需要梳理各種使用的業(yè)務邏輯，尤其是要注意runtime對方法的動態(tài)調用。
編譯時耦合解除。有好多代碼間調用其實并不是必須的，比如招聘pod有一個投遞簡歷的邏輯和個人中心我的簡歷業(yè)務耦合。一旦用戶在招聘模塊投遞了一個簡歷，個人中心需要有相應的功能顯示。招聘模塊需要向個人中心模塊傳遞一個消息，這個消息的傳遞可以用通知實現(xiàn)，也可以直接調用個人中心提供的API。但無論時是哪一種實現(xiàn)方式，這個消息傳遞并不影響招聘模塊的業(yè)務獨立性，即使個人中心這個模塊功能沒有，招聘模塊也可以運行。這種情況下的解耦，只要保證在編譯時代碼不報錯，將一些直接API調用的地方改用通知，或runtime調用方式即可。
公共代碼下沉。有好多代碼間調用是運行時必須的，針對這些代碼就沒法使用編譯時耦合解除的手段，需要將這部分代碼下沉到下一層，比如中間件層。公共代碼下沉的手段和前文提到的代碼文件移動的手段有些交集，但又有差別。代碼文件強調的是代碼文件的移動，不一定要移動到下層pod；公共代碼下沉既可能是代碼文件下沉，也可能是某一個方法下沉。
基于協(xié)議的代碼隔離。還有一種常見情況需要重點提出來，就是有好多業(yè)務在不同App中表現(xiàn)形態(tài)不一樣，很難用一套代碼來解決。針對這種情況，需要抽離出一層協(xié)議，在公共代碼中通過協(xié)議來調用，在接入App中基于協(xié)議來完成不同的實現(xiàn)。
Pod解耦，尤其涉及到業(yè)務層代碼和中間件層代碼的解耦，很難有一個標準衡量哪些pod的耦合在最開始做的是對的還是錯的。因為好多業(yè)務在最開始的時候從產品層面，沒有考慮到這個業(yè)務是一個垂直業(yè)務，會在多App上平移。但是一旦有一個業(yè)務被確定要支持多App后，這個業(yè)務涉及的pod的依賴關系必須滿足App工廠的依賴準則。這一點在后續(xù)的業(yè)務持續(xù)迭代中要尤其注意。
風險控制
App工廠的整個代碼重構，涉及的面非常廣。58App今年在App工廠上對代碼的改動是之前所未有的。每個公司業(yè)務及架構不同，代碼的復雜度和重構的難度也不一樣，所以面臨的線上風險也會各有差異。在重構過程中除了要有嚴格的技術方案評審、代碼審查、全面的Case測試外，尤其要注意兩點容易被忽視但很容易出問題的點：
版本迭代合并遺漏風險
在58App中，隨著App工廠的不斷深入和業(yè)務的逐步接入，中間件層和基礎服務層拆分的越來越細了，pod的數據目前全部加起來已經超過50個了。App工廠項目進行的同時，還有日常版本需求項目并行開發(fā)。在這過程中，同一份代碼既可能會在App工廠中改動，又會有相應新需求的研發(fā)。
App工廠項目跨度比較長，比如某一個中間價是基于8.0版本拉分支出來開發(fā)的，但是可能會跨幾個版本才能上線。在這個過程中一定要不斷合并新版本代碼到當前App工廠分支。并且對一些有沖突的代碼一定要細心處理。中間件層代碼和基礎服務層代碼的變動測試一直是一個痛點，很難覆蓋所有的業(yè)務場景，所以一定要對有沖突和有改動的代碼進行細心處理，以防帶來線上問題。
數據耦合風險
數據耦合指的是某些業(yè)務代碼會操作且依賴某公共數據。但數據依賴在編譯時和大部分運行時發(fā)現(xiàn)不了，這給發(fā)現(xiàn)問題帶來很大的難度。比如App上的商圈數據、埋點數據、用戶電話撥打記錄、帖子收藏記錄等，都屬于數據耦合范疇。
與上面的版本合并遺漏問題一樣，數據耦合風險處理的原則也是對所有影響數據的業(yè)務進行詳細的梳理并解耦，要從開發(fā)、測試、灰度數據驗證等多個關鍵節(jié)點進行全面處理。
總結
任何架構都離不開業(yè)務，都是為了解決業(yè)務痛點、問題的，App工廠也不例外。由于每個公司的App架構不同、業(yè)務形式不同、部門協(xié)作研發(fā)的形式也不同，所以肯定沒有一個放之四海而皆準的App工廠理論和實現(xiàn)準則。
58App在實施的過程中，也是通過業(yè)務的不斷接入逐步完善App工廠的能力。而完善的這部分能力，有標準化的能力，也有非標準化的能力。而且標準化和非標準化隨著后續(xù)業(yè)務的迭代還可能會相互轉化。未來58App還會持續(xù)在更多業(yè)務上進行接入，以持續(xù)解決業(yè)務問題，給業(yè)務研發(fā)提效。
App工廠是團隊協(xié)作的成果，感謝參與其中的同學。App工廠從構想到實施、再到業(yè)務接入，是近年來58無線技術少有的大動作。沒有用戶價值增長部各級老板的構想、規(guī)劃、指導和組內同學的協(xié)同貫徹實施，沒有房產技術部（安居客房產技術部、58趕集房產技術部）、招聘技術部等部門的老板和同學的精密協(xié)作和業(yè)務實踐，是啟動和完成不了這么一個大的工程。
作者：
彭飛，58同城-基礎技術部-iOS技術部 架構師，iOS技術部負責人。
曾慶隆，58同城-基礎技術部-iOS技術部 架構師
王曉暉，58同城-基礎技術部-iOS技術部 高級研發(fā)工程師
總結
以上是生活随笔為你收集整理的58移动开发 App 工厂的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AIR移动平台打开图片文件
- 下一篇： 2021 年最值得了解的 Node.js