前言
知乎 iOS 用戶端從一開始圍繞問答社群到目前涵蓋 Feed，會員，商業，文章，想法等多個業務線的綜合内容生産與消費平台。項目的複雜程度已經在超級 App 的範疇。單周釋出與業務并行開發也逐漸變成主流。同時在知乎 iOS 平台，技術選型一直也都比較開（sui）放（yi）。較早了引入了 Swift 進行業務開發，清單引入了需要 OC++ 的 ComponentKit 作為核心引擎。是以在這種多業務方團隊，技術形态複雜，元件倉庫數量多等場景下，也同樣遇到了各種超級 App 團隊都面臨的一些問題。
問題如下：
- 如何統一開發環境
- 提高編譯速度
- 提高打包速度
- 二進制元件調試
- 多元件聯合調試
- 多元件聯合打包
- 限制元件依賴關系等
當然在思考解決上面這些問題前，知乎 iOS 項目也同樣經曆過元件化的工作。與衆多元件化拆分方案殊途同歸，進行了業務劃分，主倉庫代碼清空，業務線及 SDK 進行獨立倉庫管理。引入基于路由，基于協定聲明的元件間通信等機制等，這裡就不多贅述了。
簡介
核心介紹的項目名稱為 Venom，靈感來源于電影《毒液》。Venom 的使用者端是一款為開發人員打造 Mac App，應用内置了工程建構需要的全套 Ruby Gem 和 Cocoapods 等其相關建構環境。核心目标是解決工程建構，二進制建構，元件管理，調試工具等一系列開發過程中的繁瑣耗時任務。
是以當一台全新的 Mac 電腦希望運作工程時， 隻需要 3 步：
- 安裝 Venom For Mac 用戶端。
- 使用 Venom 打開工程點選 Make 按鈕。
- 建構完成點選 XCode 按鈕打開工程。（當然預設己裝 XCode ）
從此告别 ruby，cocoapods 版本不對，gem 問題，bundle 問題以及權限問題等困擾。因為建構環境内置，使得建構環境與工程師本地環境隔離，極大的降低了工程 setup 的成本。
完整的 Venom 包含了 3 個部分：
- Venom App
- Venom 核心
- Venom Server
下面會着重介紹用戶端和核心相關的技術方案，資料服務目前僅為元件的附加資訊提供 API 支援。
Venom 核心介紹
在引入 Venom 前，一直使用 Cocoapods 的 Podfile 進行元件的引用。但如果希望對 pod 指令的 DSL 進行擴充，發現是不夠友善的。索性在 Cocoapods 上層建立自己的元件描述檔案，每一個描述檔案最終都會被轉化為一次 podfile 的 pod 調用。
如上圖，使用 Venom 方式內建的項目，由在 VenomFiles 目錄内的組建描述檔案組成。
元件描述檔案
VenomFile.new do |v|
v.name = 'XXModuleA'
v.git = '[email protected]:Team-iOS-Module/XXModule.git'
v.tag = '1.0.0'
v.binary = false
v.use_module_map = true
v.XX...
end 元件描述檔案可以了解是 pod 指令的一個超集，在包含了 pod 的原有功能基礎上，擴充其他功能（膠水代碼建立，二進制化與源碼切換等）。
元件調試
同時在與 VenomFile 同級别還設計了一個 Customization.yml 的檔案。當開發過程中，需要對某個元件進行源碼二進制的切換，或者源碼路徑的切換，版本引用的切換等，不會直接改動 VenomFile，會改動 Customization.yml 來進行。在建構過程中的優先，Customization.yml > Venomfile 。為了每個工程師的改動不會互相影響，Customization.yml 是非 git 托管的。而 VenomFiles 内的檔案隻有更新版本号或其他配置改動，才會更新。
建構過程
所有元件都通過一個個 Venomfile 檔案方式管理在主工程倉庫中，通過目錄對元件進行層級劃分管理。
原來的 Podfile 檔案通過嵌入 Venom 進行建構職責的接管。
使用 Venom 後 pod install 的實際過程就如下圖：
整體上來看， Venom 核心提供了一套擴充 pod 屬性的描述檔案，開發階段通過 customization.yml 進行可配置的建構。建構過程中，依賴 Venomfile 檔案的唯一辨別進行二進制庫和源碼的關聯。通過對 Cocoapods 建構過程的 hook 實作二進制與源碼的引用切換。二進制化方案可參考 ：
Xinyu Zhao：知乎 iOS 基于 CocoaPods 實作的二進制化方案40 贊同 · 15 評論文章
指令接口
Venom 核心除了主要的建構職責，還提供了一系列的 ipc 指令。通過這些 ipc 指令，上層的 Venom 用戶端就可以更容易的操作每個元件，進行定制化的開發組織。來建構工程。
例如：
// 修改元件二進制使用方式，使用二進制
venom ipc customization \
--path /Users/abc/Developer/zhihu/abc/def \
--edit \
--name ZHModuleABC \
--binary
// 修改元件二進制使用方式，使用源碼
venom ipc customization \
--path /Users/abc/Developer/zhihu/abc/def \
--edit \
--name ZHModuleABC \
--source
// 修改 yml 檔案中指定元件的路徑
venom ipc customization \
--path /Users/abc/Developer/zhihu/abc/def \
--edit \
--name ZHModuleABC \
--pod_path /path/to/ZHModuleABC
// reset 某個元件在 customization 中的 change，不指定 name 參數會給整個檔案置成空
venom ipc customization \
--path /xxx \
--reset \
--name ZHModuleABC Venom App 介紹
通過對 Venom 核心的簡單介紹，其實可以認為，隻通過指令行版的工具，就可以達到用到的大部分功能。但因為實際開發情況一般不會一個人一次隻處理一個子產品，是以希望以一種所見即所得方式來讓業務工程師不用關心下層的邏輯，學習指令。可以快速建立起開發環境是我們的主要目标。
用戶端主要子產品
Venom App 内置了全套的 guby gem 環境來運作指令。通過 CLITask 來通路 Venom-core 以及 git 等其他指令（venom 核心一樣内置在 Venom App 内）。
這樣很好的控制了執行指令的環境，特别是對新入職的員工是十分友好的。
核心功能
開發元件關聯
正常情況下 clone 下來的主工程（殼工程）内是沒有代碼的，隻有空的工程檔案群組件描述檔案。Venom 工具劃分了2個區域，普通元件和定制元件。
因為每個開發者維護的元件其實是有限的幾個，一般都會将源碼放在固定目錄，是以通過設定用戶端的自動掃描路徑。在 Venom 界面上，如果在掃碼路徑下發現了相關元件，則可以一鍵關聯本地目錄元件，這樣元件會切換到定制元件的模式進行開發。
特定版本關聯
在開發過程中，有時需要對某一個依賴庫的特定版本進行調試或連調。是以也支援通過 tag，commit，branch 等方式，進行特定源碼的切換和關聯。
源碼與二進制切換
某些特殊場景下，可能希望工程以所有元件都是源代碼方式建構，排查問題。那麼也可以通過 2 種不同的構模組化式一鍵切換。（當然全源碼建構一次需要十足的耐心）
二進制模式下搜尋與調試
二進制化後，大部分情況下都工作在二進制模式下，但有時在進行源碼搜尋時，希望可以全局搜尋。是以在建構過程中，會把目前版本的源碼目錄也引用到工程目錄下。
是以在工程進行檢索代碼時，是完全沒問題的。有了源碼，在雲端進行二進制打包時，通過 fdebug-prefix-map （Clang command line argument reference ）這個參數重新在二進制檔案中改寫 Debug 模式的源代碼路徑。這樣即使在二進制模式下，也可以直接關聯源碼進行斷點調試。
元件依賴關系分析
當元件很多後，就會出現一些工程師對元件所處層級不夠了解，導緻出現依賴混亂的問題。是以在建構結束後會通過對元件層級的檢查，進行元件依賴層級的判斷。
總結
在推進所有工程師使用 Venom 用戶端後，相當于在開發環節有了一個強有力的抓手。由于 App 的自動更新功能，可以在平台下提供給開發者更多的工具，而開發者隻需要更新用戶端使用。通過工具化用戶端的開發，我們重構了原有散落在各處的腳步，工具集中整合在一起。使得開發工具維護更統一，更新也更及時，開發人員上手成本也更低。
Venom 核心承擔的是開發環境管理，工程組織與建構管理，提高工程效率工作。但上線後，我們還陸續在此基礎上提供了一些其他功能。
- 多倉庫 MR 自動填充送出
- 本地非獨立業務倉庫單元測試
- 個人開發者賬号真機調試
- 無用圖檔掃描工具
- 輕量的 app 網絡和日志檢視等
作者:付三歲
出處:https://zhuanlan.zhihu.com/p/69526642