?作者 | Dustin Shahidehpour

策劃 | 言征 

iOS版Facebook（FBiOS）可以說是Meta最古老的移動代碼庫了。自2012年該應用程序被重寫以來，數千名工程師對其進行了研究，并將其交付給數十億用戶，它可以支持數百名工程師一次對其進行迭代。

FBiOS架構演變到今天，并不是有意為之的。它反映了10年以來的發展，這是由越來越多的工程師開發該App所需的技術決策、穩定性以及最重要的用戶體驗所推動的。

補充知識：

截止到2022年，該代碼庫已經走過了十周年，筆者將對這一演變背后的技術決策以及它們的歷史背景進行一些說明。

經過多年的迭代，Facebook代碼庫與典型的iOS代碼庫不同：

（1）它包含了C++、Objective-C（++）和Swift。

（2）它有幾十個動態加載的庫（dylib），以及太多的類，無法一次將它們加載到Xcode中。

（3）蘋果SDK的原始使用幾乎為零——一切都被內部抽象所包裝或替換。

（4）該應用程序大量使用代碼生成，這是由我們的自定義構建系統 Buck 推動的。

（5）如果我們的構建系統沒有大量緩存，工程師將不得不花一整天時間等待應用程序的構建。  

一、2014：建立我們自己的移動框架

2014年，對Facebook應用程序進行本地重寫已經過去兩年，這時，News Feed的代碼庫開始出現可靠性問題。當時，News Feed的數據模型得到了蘋果管理數據模型的默認框架：核心數據的支持。核心數據中的對象是可變的，這并不適合新聞提要的多線程架構。更糟糕的是，News Feed利用了雙向數據流，這源于它對Cocoa應用程序使用了蘋果事實上的設計模式：模型視圖控制器。

最終，這種設計加劇了不確定性代碼的產生，這些代碼很難調試或再現錯誤。很明顯，這種架構是不可持續的，是時候重新思考了。

在考慮新的設計時，一位工程師研究了React，Facebook的（開源）UI框架，該框架在Javascript社區中非常流行。React的聲明性設計抽象了導致Feed（在web上）出現問題的棘手命令式代碼，并利用了單向數據流，這使得代碼更易于推理。這些特征似乎很適合News Feed面臨的問題：蘋果的SDK中沒有聲明性UI。

Swift將在幾個月內發布，SwiftUI（蘋果的聲明性UI框架）將在2019年之前發布。如果NewsFeed想要有一個聲明性UI，那么團隊必須構建一個新的UI框架。

最終，這就是他們所做的。

在花了幾個月時間構建和遷移新聞提要以在新的聲明性UI和新的數據模型上運行后，FBiOS的性能提高了50%。

幾個月后，他們開源了基于React的移動UI框架ComponentKit。時至今日，ComponentKit仍然是在Facebook中構建本機UI的事實上的選擇。它通過視圖重用池、視圖展平和背景布局計算為應用程序提供了無數性能改進。它也啟發了其Android對手Litho和SwiftUI。

最終，選擇用自定義infra替換UI和數據層是一種權衡。為了獲得可以可靠維護的令人愉快的用戶體驗，新員工必須擱置他們對Apple API的行業知識，學習定制的內部基礎設施。

這將不是FBiOS最后一次做出平衡最終用戶體驗與開發者體驗和速度的決定。進入2015年，該應用的成功將引發我們所稱的功能爆炸。這也帶來了一系列獨特的挑戰。

二、2015：架構拐點

到2015年，Meta在其“移動第一”的口號上翻了一番，FBiOS代碼庫的每日貢獻者數量急劇增加。隨著越來越多的產品被集成到應用程序中，其發布時間開始縮短，人們開始注意到。到2015年底，啟動性能非常緩慢（接近30秒！），以至于有可能被手機的操作系統殺死。

經過調查，很明顯有許多因素導致啟動性能下降。為了簡潔起見，我們將只關注那些對應用程序架構有長期影響的方面：

（1）隨著應用程序的規模隨著每種產品的增長而增長，該應用程序的“前置”時間正在以無限的速度增長。

（2）該應用程序的“模塊”系統為每個產品提供了對該應用程序所有資源的無管制訪問。這導致了一個公共問題的悲劇，因為每個產品都利用它的“鉤子”來啟動，以執行計算上昂貴的操作，從而快速導航到該產品。

緩解和改善啟動所需的更改將從根本上改變產品工程師為FBiOS編寫代碼的方式。

三、2016年：Dylibs和模塊化

根據蘋果關于改進發布時間的維基，在調用應用程序的“主”功能之前，必須執行許多操作。通常，一個應用程序的代碼越多，所需時間就越長。

雖然“pre-main”在發布過程中僅貢獻了30秒的一小部分時間，但這是一個特別令人擔憂的問題，因為隨著FBiOS不斷積累新功能，它將繼續以無限的速度增長。

為了幫助緩解應用程序發布時間的無限增長，我們的工程師開始將大量產品代碼移入一個稱為動態庫（dylib）的延遲加載容器中。當代碼移動到動態加載的庫中時，不需要在應用程序的main()函數之前加載。

最初，FBiOS dylib結構如下：

創建了兩個產品dylib（FBCamera和NotOnStartup），第三個dylib（FBShared）用于在不同的dylib和主應用程序的二進制文件之間共享代碼。

dylib溶液效果很好。FBiOS能夠抑制應用程序啟動時間的無限增長。隨著時間的推移，大多數代碼都會以dylib結尾，這樣啟動時的性能就會保持快速，并且不會受到應用程序中添加或刪除產品的持續波動的影響。

dylibs的加入引發了Meta產品工程師編寫代碼方式的思想轉變。隨著dylib的添加，像NSClassFromString（）這樣的運行時API冒著運行時失敗的風險，因為所需的類存在于卸載的dylib中。由于FBiOS的許多核心抽象都是在遍歷內存中的所有類的基礎上構建的，因此FBiOS必須重新思考其核心系統的工作情況。

除了運行時失敗之外，dylibs還引入了一類新的鏈接器錯誤。如果Facebook（啟動集）中的代碼引用了dylib中的代碼，工程師將看到如下鏈接器錯誤：

Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_SomeClass", referenced from:
objc-class-ref in libFBSomeLibrary-9032370.a(FBSomeFile.mm.o)

為了解決這個問題，工程師們需要用一個特殊的函數來包裝他們的代碼，如果需要的話，可以加載dylib,比如：

int main() {
DoSomething(context);
}

看起來像這樣：
int main() {
FBCallFunctionInDylib(
NotOnStatupFramework,
DoSomething,
context
);
}

該解決方案有效，但有很多奇怪的地方：

（1）應用程序特定的dylib枚舉被硬編碼到各種調用站點中。Meta的所有應用程序都必須共享一個dylib枚舉，讀者有責任確定代碼運行的應用程序是否使用了該dylib。

（2）如果使用了錯誤的dylib枚舉，代碼將失敗，但僅在運行時失敗。考慮到應用程序中大量的代碼和功能，這個延遲的信號導致了開發過程中的許多挫折。

最重要的是，我們唯一能防止在啟動過程中引入這些調用的系統是基于運行時的，在應用程序引入最后一分鐘的回歸時，許多發布都被延遲。

最終，dylib優化抑制了應用程序發布時間的無限增長，但這意味著應用程序架構的巨大轉折點。FBiOS工程師將在接下來的幾年里重新設計應用程序，以消除dylib帶來的一些粗糙邊緣，我們（最終）推出了一個比以往任何時候都更強大的應用程序架構。

四、2017：重新思考FBiOS架構

隨著dylibs的引入，FBiOS的幾個關鍵組件需要重新思考：

（1）“模塊注冊系統”不能再基于運行時。

（2）工程師們需要一種方法來了解啟動期間的任何代碼路徑是否會觸發dylib加載。

（3）為了解決這些問題，FBiOS轉向Meta的開源構建系統Buck。

在Buck中，每個“目標”（app、dylib、library等）都用一些配置聲明，如下所示：

apple_binary(
name = "Facebook",
...
deps = [
":NotOnStartup#shared",
":FBCamera#shared",
],
)

apple_library(
name = "NotOnStartup",
srcs = [
"SomeFile.mm",
],
labels = ["special_label"],
deps = [
":PokesModule",
...
],
)

每個“目標”都列出了構建它所需的所有信息（依賴項、編譯器標志、源等），當調用“buck build”時，它會將所有這些信息構建成一個可以查詢的圖形。

$ buck query “deps(:Facebook)”
> :NotOnStartup
> :FBCamera

$ buck query “attrfilter(labels, special_label, deps(:Facebook))”
> :NotOnStartup

使用這個核心概念（以及一些特殊的醬汁），FBiOS開始生成一些buck查詢，這些查詢可以在構建過程中生成應用程序中的類和函數的整體視圖。這些信息將成為該應用程序下一代架構的基石。

五、2018：生成代碼的激增

既然FBiOS能夠利用Buck查詢依賴關系中的代碼信息，那么它就可以創建一個“function/classes->dylibs”的映射，可以在運行中生成。

{
"functions": {
"DoSomething": Dylib.NotOnStartup,
...
},
"classes": {
"FBSomeClass": Dylib.SomeOtherOne
}
}

使用該映射作為輸入，FBiOS使用它生成從調用站點抽象出dylib枚舉的代碼：

static std::unordered_map<const char *, Dylib> functionToDylib {{
{ "DoSomething", Dylib.NotOnStartup },
{ "FBSomeClass", Dylib.SomeOtherOne },
...
}};

左右滑動查看完整代碼

使用代碼生成之所以吸引人，有幾個原因：

（1）因為代碼是基于本地輸入重新生成的，所以沒有什么可簽入的，也沒有更多的合并沖突！考慮到FBiOS的工程規模每年都會翻倍，這是一個巨大的開發效率勝利。

（2）不再需要應用程序特定的dylib（因此可以重命名為“FBCallFunction”）。相反，調用將從構建期間為每個應用程序生成的靜態映射中讀取。

事實證明，將Buck查詢與代碼生成相結合是如此成功，以至于FBiOS將其作為新插件系統的基礎，最終取代了基于運行時的應用程序模塊系統。

1.左移信號

使用Buck支持的插件系統。FBiOS能夠通過將infra遷移到基于插件的架構中，以構建時警告取代大多數運行時失敗。

構建FBiOS時，Buck可以生成一個圖表，顯示應用程序中所有插件的位置，如下所示：

從這個角度來看，插件系統可以顯示構建時間錯誤，以便工程師發出警告：

（1）“插件D、E可能會觸發dylib加載。這是不允許的，因為這些插件的調用方位于應用程序的啟動路徑中。”

（2）“應用程序中沒有用于呈現配置文件的插件……這意味著導航到該屏幕將無法工作?！?/p>

（3）“有兩個插件用于呈現組（插件A、插件B）。其中一個應該刪除。”

對于舊的應用程序模塊系統，這些錯誤將是“懶惰”的運行時斷言?，F在，工程師們相信，當FBiOS成功構建時，它不會因為功能缺失、應用程序啟動期間的dylib加載或模塊運行時系統中的不變量而失敗。

2.代碼生成的代價

雖然將FBiOS遷移到插件系統提高了應用程序的可靠性，為工程師提供了更快的信號，并使應用程序可以與其他移動應用程序輕松共享代碼，但這是有代價的：

（1）插件錯誤在Stack Overflow上很難找到答案，調試時會感到有些吃力。

（2）基于代碼生成和Buck的插件系統與傳統的iOS開發有著天壤之別。

（3）插件為代碼庫引入了一層中間層。大多數應用程序都會有一個包含所有功能的注冊表文件，這些都是在FBiOS中生成的，很難找到。

毫無疑問，插件使FBiOS遠離了慣用的iOS開發，但這種權衡似乎是值得的。我們的工程師可以更改Meta的許多應用程序中使用的代碼，并確保如果插件系統運行良好，任何應用程序都不會因缺少很少測試的代碼路徑中的功能而崩潰。像News Feed和Groups這樣的團隊可以為插件構建一個擴展點，并確保產品團隊可以在不觸及核心代碼的情況下集成到其表面。

六、2020：Swift與語言架構

應用程序規模問題導致的架構變化上，但蘋果SDK的變化也迫使FBiOS重新考慮其一些架構決策。

2020年，FBiOS開始看到來自蘋果的Swift專用API的數量增加，并且越來越多的人希望在代碼庫中使用更多的Swift。終于是時候接受這樣一個事實了：Swift是FB應用程序中不可避免的租戶。

歷史上，FBiOS曾使用C++作為構建抽象的杠桿，因為C++的“零開銷”原則，這節省了代碼大小。但C++尚未與Swift互操作。對于大多數FBiOS API（如ComponentKit），必須創建某種墊片以在Swift中使用，從而導致代碼膨脹。

下面是一個圖表，概述了代碼庫中的問題：

考慮到這一點，我們開始形成一種關于何時何地使用各種代碼的語言策略：

最終，FBiOS團隊開始建議：面向產品的API/代碼不應包含C++，這樣我們就可以自由使用蘋果公司的Swift和未來的Swift API。使用插件，FBiOS可以抽象出C++實現，這樣它們仍然為應用提供動力，但對大多數工程師來說是隱藏的。

這種類型的工作流意味著FBiOS工程師構建抽象的方式發生了一些變化。自2014年以來，影響框架構建中的最大因素是對應用程序大小和表現力的貢獻度（這就是為什么ComponentKit選擇Objective-C++而不是Objective-C的原因）。

Swift的引入導致開發人員的效率降低，不急，未來還能看到更多。

七、2022年：旅程已完成1%

自2014年以來，FBiOS架構發生了很大變化：

（1）它引入了大量內部抽象，如ComponentKit和GraphQL。

（2）它使用dylibs將“pre-main”時間保持在最小，并有助于快速啟動應用程序。

（3）它引入了一個插件系統（由Buck提供支持），這樣就可以從工程師那里抽象出dylib，因此代碼很容易在應用程序之間共享。

（4）它引入了關于何時何地使用各種語言的語言指南，并開始改變代碼庫以反映這些語言指南。

與此同時，蘋果對其手機、操作系統和SDK進行了令人興奮的改進：

（1） 他們的新手機速度很快。裝載成本比以前小得多。

（2） dyld3和鏈修復等操作系統改進提供了軟件，使代碼加載更快。

（3） 他們引入了SwiftUI，這是一個用于UI的聲明性API，它與ComponentKit共享了很多概念。

（4） 他們提供了改進的SDK，以及我們可以為其構建自定義框架的API（如iOS8中的可中斷動畫）。

隨著Facebook、Messenger、Instagram和WhatsApp分享了更多的體驗，FBiOS正在重新審視所有這些優化，以了解在哪些方面可以更接近平臺正統。最終，我們發現，共享代碼的最簡單方法是使用應用程序免費提供的東西，或者構建一個幾乎無依賴性且可以在所有應用程序之間集成的東西。

我們將于2032年在這里與您見面，回顧代碼庫的20周年紀念！?