iOS 組件化之使用 Cocoapods 創(chuàng)建本地 Pod做 iOS 組件化改造這段時(shí)間踩得最深、也最值得拿出來說的一個(gè)環(huán)節(jié)就是用 Cocoapods 搭一套本地 Pod 的開發(fā)調(diào)試環(huán)境。很多人一開始就把目標(biāo)定在私有 Pod 倉庫、二進(jìn)制化、遠(yuǎn)程 Spec Repo 上結(jié)果連最基礎(chǔ)的“怎么把現(xiàn)有代碼拆成一個(gè) Pod”都沒理清楚。實(shí)際上組件化的第一步應(yīng)該是先把模塊切出來用本地 Pod 把邊界定死再考慮后續(xù)的遠(yuǎn)成、版本、二進(jìn)制分發(fā)。這篇文章就把我實(shí)際創(chuàng)建本地 Pod 的過程、Podspec 里每個(gè)字段怎么填、集成時(shí)遇到哪些坑完整過一遍。這套東西適合誰如果你負(fù)責(zé)的 App 已經(jīng)超過幾十個(gè)文件業(yè)務(wù)模塊之間靠隱式依賴互相調(diào)用編譯越來越慢或者你只是想學(xué)習(xí)組件化但不想一上來就搭一套復(fù)雜的基礎(chǔ)設(shè)施那本地 Pod 就是最順手的入口。它不需要你維護(hù) Git 倉庫、不需要配置 trunk、不需要 CI 腳本只要一個(gè) Pods 目錄就能讓工程結(jié)構(gòu)和依賴關(guān)系立刻變得清晰很多。1. 組件化思路與本地 Pod 的定位1.1 組件化到底在解決什么問題先說一個(gè)我觀察了很久的現(xiàn)象很多團(tuán)隊(duì)說要組件化但實(shí)際代碼里還是一個(gè)大 Target 堆到底所有文件都編譯進(jìn)同一個(gè) AppView、Model、網(wǎng)絡(luò)層、工具類混合在一起。這種結(jié)構(gòu)在業(yè)務(wù)少的時(shí)候沒問題等業(yè)務(wù)線多起來痛點(diǎn)會集中在四個(gè)地方。第一是編譯速度。每改一行代碼整個(gè)工程都可能觸發(fā)重新編譯尤其是越來越多人往 App 里塞第三方庫和分類。第二是團(tuán)隊(duì)協(xié)作。不同小組改同一個(gè)文件、同一個(gè)宏定義代碼合并時(shí)沖突頻發(fā)誰也不敢動公共代碼。第三是測試成本。業(yè)務(wù)模塊互相牽連單元測試很難把某個(gè)模塊孤立出來跑回歸全靠手工點(diǎn) App。第四是代碼復(fù)用。App 和擴(kuò)展、多個(gè) App 之間想共用一段邏輯只能靠復(fù)制粘貼修 bug 要改好幾個(gè)地方。組件化不是玄學(xué)它的核心是把代碼按業(yè)務(wù)或功能切成獨(dú)立模塊每個(gè)模塊只暴露必要的接口模塊之間通過明確的依賴關(guān)系通信。這樣一來編譯可以被緩存團(tuán)隊(duì)可以獨(dú)立維護(hù)各自的模塊測試也可以只拉取模塊源碼來跑。而 Cocoapods 恰好提供了現(xiàn)成的“模塊化容器”每個(gè) Pod 就是一個(gè)獨(dú)立模塊。1.2 為什么第一步要落在本地 Pod 上我見過一上來就搭私有 Spec Repo 的團(tuán)隊(duì)效果并不理想。原因很簡單倉庫、權(quán)限、CI、版本發(fā)布流程還沒成熟模塊已經(jīng)拆了一堆結(jié)果管理成本比收益還大。本地 Pod 的好處在于你用:path指向一個(gè)本地目錄CocoaPods 會把這個(gè)目錄里的源碼直接編譯進(jìn)你的工程不需要任何遠(yuǎn)端基礎(chǔ)設(shè)施。對剛起步的項(xiàng)目來說本地 Pod 有三點(diǎn)優(yōu)勢非常明顯因?yàn)樵创a在本地改完 Pod 里的代碼直接生效調(diào)試效率跟單工程一模一樣。Pod 和宿主工程是兩個(gè)物理目錄天然形成了“模塊邊界”誰依賴誰一目了然。后續(xù)要推到遠(yuǎn)端倉庫只需要給 podspec 配一個(gè) Git 地址改動量很小。所以我的建議是組件化的第一階段全部用本地 Pod 做模塊拆分。先把“邊界”這件事做好再談“版本管理”。1.3 本地 Pod、私有 Pod 與二進(jìn)制 Pod 的演進(jìn)關(guān)系這里需要把三個(gè)概念理清楚。本地 Pod 是通過:path引入的依賴的代碼就在你本機(jī)某個(gè)文件夾里適合開發(fā)和調(diào)試。私有 Pod 是指 podspec 存放在私有 Spec Repo源碼也托管在私有 Git 倉庫里其他同事可以通過 pod 命令拉取。二進(jìn)制 Pod 則是把源碼編譯成 framework 后作為靜態(tài)庫或動態(tài)庫打成 zip再掛到 Spec Repo 下適合對編譯速度有極端要求的團(tuán)隊(duì)。這三者的關(guān)系并不是并列的而是組件化成熟度的三個(gè)階段。一開始用本地 Pod業(yè)務(wù)結(jié)構(gòu)穩(wěn)定后再把代碼推到 Git 倉庫、建立私有 Spec Repo等到基礎(chǔ)庫基本不變時(shí)再考慮二進(jìn)制化。本地 Pod 是這條路徑上的起點(diǎn)也是風(fēng)險(xiǎn)最低、最容易驗(yàn)證方案的一步。2. 使用 Cocoapods 創(chuàng)建本地 Pod 的標(biāo)準(zhǔn)姿勢2.1 手動創(chuàng)建還是用 pod lib createCocoaPods 提供了一個(gè)專門用來生成 Pod 模板的命令pod lib create。它會展開一個(gè)交互式詢問包括你要用 Swift 還是 Objective-C、要不要生成測試框架、要不要 GUI 調(diào)試等然后自動生成完整的目錄骨架包括.podspec、README、LICENSE、Example工程和Sources目錄。但我實(shí)際用下來的感受是pod lib create直接生成一套模板里面有大量當(dāng)前用不到的文件。比如它會生成一個(gè)Example文件夾里面帶一個(gè)需要用pod install才能跑起來的 Demo 工程還要配置 target。對只是想快速把舊代碼拆成 Pod 的場景來說這一步有點(diǎn)重。所以我更推薦的做法是先手動創(chuàng)建最簡結(jié)構(gòu)只需要四樣?xùn)|西一個(gè)源文件目錄、一個(gè).podspec文件、一個(gè)存放資源的Assets文件夾可選、一個(gè)用來測試的宿主工程。等你能跑通本地 Pod 的接入流程再回頭看pod lib create生成的模板也不會一頭霧水。2.2 標(biāo)準(zhǔn)的本地 Pod 目錄長什么樣我通常會在主工程同級放一個(gè)Modules文件夾里面按模塊名再建子文件夾例如Workspace/ ├── MyApp.xcworkspace ├── MyApp/ │ ├── MyApp.xcodeproj │ ├── Podfile │ └── Sources/ ├── Modules/ │ └── JYNetwork/ │ ├── JYNetwork.podspec │ ├── Sources/ │ │ ├── JYNetwork.h │ │ ├── JYNetworkManager.m │ │ └── JYNetworkManager.h │ └── Assets/ │ └── network_placeholder.png這個(gè)結(jié)構(gòu)里MyApp是宿主工程JYNetwork是一個(gè)待拆出來的網(wǎng)絡(luò)模塊。每個(gè)模塊自帶 podspec 和源碼目錄宿主工程完全不直接持有模塊源碼。有一點(diǎn)要注意目錄名、podspec 文件名和 Pod 的名字盡量保持一致。如果你創(chuàng)建了一個(gè)JYNetwork文件夾但 podspec 文件叫Network.podspec其他同事看起來就會很混亂。按 CocoaPods 慣例podspec文件應(yīng)該命名為模塊名.podspec。2.3 Podfile 里如何引入本地 Pod接入本地 Pod 的寫法很簡單在 Podfile 里用:path指向模塊目錄platform :ios, 11.0 target MyApp do use_frameworks! # 本地模塊 pod JYNetwork, :path ../Modules/JYNetwork end這里的關(guān)鍵參數(shù)是:path。它告訴 CocoaPods 不要從遠(yuǎn)程 Spec Repo 拉取這個(gè) Pod 的版本而是直接用指定目錄作為源碼來源。執(zhí)行pod install后Pod 的源碼并不會拷貝到別的目錄而是通過 Pods 工程去引用../Modules/JYNetwork/Sources下的文件。需要特別注意的是:path使用的是相對路徑而這個(gè)相對路徑的基準(zhǔn)是 Podfile 所在的目錄。如果你把 Podfile 放在MyApp里那:path就應(yīng)該從MyApp路徑開始寫。換過電腦、移動過目錄后只要這個(gè)相對位置不變就能正常pod install。3. Podspec 配置每個(gè)字段有什么用填錯了會怎樣podspec 是 CocoaPods 的“身份證”里面聲明了這個(gè) Pod 叫什么、版本多少、包含哪些文件、依賴了誰。很多人直接復(fù)制別人的 podspec 模板字段倒是填滿了但不知道每個(gè)字段背后對應(yīng)的行為。我挑幾個(gè)真正影響構(gòu)建的字段展開講。3.1 基本信息與版本號Pod::Spec.new do |s| s.name JYNetwork s.version 0.1.0 s.summary A light network layer based on NSURLSession. s.homepage https://example.com/JYNetwork s.license { :type MIT, :file LICENSE } s.author { JY jyexample.com } s.source { :git , :tag s.version.to_s } s.ios.deployment_target 11.0 end這里最容易忽略的是s.version。本地 Pod 在:path模式下不太會嚴(yán)格讀取版本號但后續(xù)發(fā)布到私有 Spec Repo 時(shí)podspec 的版本號必須和 Git tag 一一對應(yīng)。比如 podspec 里寫0.1.0Git 就必須打一個(gè)0.1.0的 tag否則pod install時(shí)找不到對應(yīng)版本。另外一個(gè)容易踩坑的字段是s.source。本地模式時(shí)source里寫什么幾乎不影響編譯但如果你把它留空或者填一個(gè)不存在的地址將來發(fā)布時(shí)就會報(bào)錯。我建議從一開始就填上真實(shí)倉庫地址沒有倉庫就先填:git 并在代碼注釋里提醒自己后續(xù)補(bǔ)上。3.2 文件匹配這個(gè) Pod 編譯哪些源碼資源怎么打包s.source_files Sources/**/*.{h,m} s.public_header_files Sources/**/*.h s.resource_bundles { JYNetwork [Assets/*.png] }source_files定義的是參與編譯的源文件模式**表示遞歸匹配子目錄*.{h,m}表示只匹配.h和.m文件。假如你在這個(gè)目錄里放了 Swift 文件但source_files只匹配h/mSwift 文件就不會被編譯進(jìn)去。同理如果 Pod 是一個(gè)純 Swift 庫就得寫成*.swift。resource_bundles則是把資源文件單獨(dú)打成一個(gè) bundle。注意這里我推薦用resource_bundles而不是resources原因是resources會把資源文件直接放進(jìn)主 bundle容易出現(xiàn)文件重名覆蓋resource_bundles會為這個(gè) Pod 單獨(dú)生成一個(gè)JYNetwork.bundle加載方式需要用Bundle(for:)或Bundle(path:)取資源。一個(gè)經(jīng)常出現(xiàn)的問題是圖片放在Assets.xcassets里然后通過[UIImage imageNamed:xxx]加載。在本地主工程里這樣做沒問題但到了 Pod 里資源被打包進(jìn)獨(dú)立 bundleimageNamed:默認(rèn)只往主 bundle 找所以就找不到圖了。后面我會在常見問題里說怎么解決。3.3 依賴、系統(tǒng)框架與子組件s.dependency AFNetworking, ~ 4.0 s.frameworks [Security, SystemConfiguration] s.libraries [z, sqlite3]dependency是 Pod 之間的依賴關(guān)系聲明。宿主 App 引用JYNetworkJYNetwork依賴 AFNetworking那pod install時(shí)就會把 AFNetworking 一并拉進(jìn)來。版本號建議約束在合理范圍比如~ 4.0表示大于等于 4.0 且小于 5.0既能保證功能一致又允許小版本更新。如果 Pod 使用了系統(tǒng)框架就得在frameworks里加對應(yīng)名字。很多人在本地寫代碼時(shí)沒報(bào)錯因?yàn)樗拗鞴こ唐渌a已經(jīng) link 過 Security 框架了但 Pod 單獨(dú)編譯或發(fā)布后就變成Undefined symbols或者找不到頭文件。libraries同理如果用了zlib、sqlite3要顯式聲明s.libraries [z, sqlite3]。還有一個(gè)進(jìn)階參數(shù)subspec。當(dāng)你覺得一個(gè) Pod 太大了想拆成“默認(rèn)只帶核心功能可選帶擴(kuò)展功能”時(shí)就可以用 subspecs.subspec Core do |core| core.source_files JYNetwork/Core/**/*.{h,m} end s.subspec Mock do |mock| mock.source_files JYNetwork/Mock/**/*.{h,m} mock.dependency JYNetwork/Core end這樣其他 Pod 在聲明依賴時(shí)就可以寫dependency JYNetwork/Mock只有這個(gè) Pod 才需要把 Mock 相關(guān)代碼編譯進(jìn)去。這對提升構(gòu)建速度、控制模塊體積很有幫助但同樣也意味著你對模塊邊界的把控要更明確。3.4 編譯選項(xiàng)與 Swift 版本s.swift_version 5.0 s.pod_target_xcconfig { OTHER_LDFLAGS -lObjC }swift_version用來聲明 Pod 的 Swift 版本混編項(xiàng)目里尤其重要。如果你在本地機(jī)器用 Swift 5.7 編譯但其他同事用 Xcode 13 對應(yīng)的 Swift 5.5就可能出現(xiàn)“目標(biāo)不支持該 Swift 版本”的提示。pod_target_xcconfig是 CocoaPods 給當(dāng)前 Pod 的 target 設(shè)置的編譯參數(shù)。最常見的一項(xiàng)是OTHER_LDFLAGS -lObjC它解決的是靜態(tài)庫中 Objective-C 分類Category不加載的問題。如果你的 Pod 里大量使用 Category 擴(kuò)展系統(tǒng)類不加這一項(xiàng)運(yùn)行時(shí)會看不到擴(kuò)展方法。4. 本地 Pod 的集成與調(diào)試實(shí)戰(zhàn)4.1 初次接入從零開始跑通鏈路準(zhǔn)備一個(gè)全新的測試工程我用最小化流程演示一遍。第一步新建 Xcode 工程MyApp選擇 iOS App 模板。這一步的工程路徑和是否使用 Core Data 都不重要。第二步在工程文件同級創(chuàng)建Podfile寫入platform :ios, 11.0 target MyApp do use_frameworks! pod JYNetwork, :path ../Modules/JYNetwork end第三步在指定路徑創(chuàng)建JYNetwork模塊目錄和 podspec 文件放一個(gè)簡單的源文件。第四步終端執(zhí)行pod install。如果終端提示Using JYNetwork (0.1.0)說明本地 Pod 已經(jīng)被解析。第五步CocoaPods 會生成MyApp.xcworkspace之后必須通過.xcworkspace打開工程而不是.xcodeproj。這里我要提一個(gè)很多人栽過跟頭的細(xì)節(jié)pod install和pod update的區(qū)別。首次使用本地 Pod 時(shí)如果依賴是新增的可以用pod install但如果你改了冒號路徑、新增了 subspec或者 podspec 里的 source 發(fā)生了變化pod install可能不會重新解析已經(jīng)存在的依賴項(xiàng)。這時(shí)候要執(zhí)行pod update JYNetwork強(qiáng)制刷新這個(gè) Pod。4.2 在宿主工程里調(diào)用 Pod 中的代碼假設(shè)JYNetwork模塊里有一個(gè)NetworkManager#import JYNetwork/JYNetworkManager.h [JYNetworkManager sendRequestWithURL:url completion:^{ ... }];編譯前CocoaPods 會自動配置 header search path所以你可以直接用尖括號引用 Pod 的頭文件。但前提是這些頭文件在public_header_files范圍內(nèi)。.m文件里的私有頭文件可以放在 podspec 的 source_files 里但不要放進(jìn) public_header_files否則會造成接口過度暴露。Swift 項(xiàng)目里調(diào)用本地 Pod 的 Swift 類時(shí)需要用import JYNetwork調(diào)用 Objective-C 類時(shí)則依賴 CocoaPods 生成的橋接頭文件。一個(gè)常見的坑是use_frameworks!打開后Swift 和 OC 混編的 Pod 里類名帶了模塊名前綴像JYNetwork.NetworkManager寫代碼時(shí)容易漏掉模塊名。4.3 改代碼后如何快速生效本地 Pod 最大的優(yōu)勢就是“改完就能用”。因?yàn)?path是指向源碼目錄的所以你修改JYNetwork文件夾里的代碼后重啟 App、重新編譯改動就會生效不需要重新pod install。不過有一個(gè)例外如果你改的是 podspec 里描述的“文件集合”——比如往Sources/Api/目錄里新增了一個(gè).h文件原有source_files已經(jīng)能遞歸匹配到它那沒問題但如果新增的目錄后綴不在匹配范圍內(nèi)你就得改 podspec然后執(zhí)行pod install讓 CocoaPods 重新同步文件引用。另外建議在宿主工程里配置一個(gè)Configuration文件把 Debug 環(huán)境下的 DEBUG 宏打開這樣本地調(diào)試時(shí)能輸出網(wǎng)絡(luò)日志或者 Mock 數(shù)據(jù)Release 環(huán)境自動關(guān)掉。這種開關(guān)放在 Pod 里比散落在宿主工程里要規(guī)范得多。5. 從本地 Pod 走向規(guī)范與發(fā)布5.1 本地 Pod 的版本號怎么管理本地模式不會強(qiáng)制校驗(yàn)版本號但我不建議因此偷懶。把版本號從0.1.0開始維護(hù)每完成一定量的改動就遞增遵循語義化版本規(guī)范主版本號不兼容的 API 修改次版本號向后兼容的功能新增修訂號向后兼容的問題修復(fù)這樣做的意義是當(dāng)你后面把 podspec 推送到遠(yuǎn)程倉庫、開始用 tag 管理版本時(shí)歷史包袱已經(jīng)很小。而且宿主工程 Podfile 里可以同時(shí)使用:path和指定的版本號比如pod JYNetwork, :path ../Modules/JYNetwork在開發(fā)環(huán)境不加版本限制但發(fā)布的時(shí)候 Podfile 會鎖住一個(gè)精確版本。5.2 依賴關(guān)系的可視化與檢查一個(gè)模塊的 Podspec 里依賴了誰基本代表了模塊的上游邊界。本地 Pod 模式下最好養(yǎng)成的習(xí)慣是每個(gè) Pod 只依賴業(yè)務(wù)無關(guān)的基礎(chǔ)庫不直接依賴別的業(yè)務(wù) Pod 的具體實(shí)現(xiàn)。想快速看整個(gè)工程依賴樹用命令pod install --verbose或者在工程目錄下打開 Podfile.lock里面會記錄當(dāng)前解析后的 Pod 及版本。如果某個(gè)模塊依賴關(guān)系特別詭異比如基礎(chǔ)庫依賴了登錄模塊說明邊界設(shè)計(jì)有問題一定要趁早發(fā)現(xiàn)。我還有一個(gè)習(xí)慣沒事就跑一遍pod outdated。本地 Pod 模式下它不一定能檢測出變化但至少能幫你確認(rèn)當(dāng)前各個(gè) Pod 的來源是路徑依賴還是版本依賴避免后面某個(gè)模塊意外變成了遠(yuǎn)程版本。5.3 把本地 Pod 推到遠(yuǎn)程倉庫當(dāng)業(yè)務(wù)穩(wěn)定、代碼該獨(dú)立交付時(shí)就可以給本地 Pod 增加遠(yuǎn)程來源。核心步驟只有三步先在 Git 倉庫里創(chuàng)建JYNetwork倉庫把模塊源碼推上去并打上0.1.0的 tag。然后 cd 到模塊目錄用pod lib lint JYNetwork.podspec --allow-warnings做本地校驗(yàn)。校驗(yàn)通過后用pod repo push YOUR_PRIVATE_REPO JYNetwork.podspec把 podspec 推送到私有 Spec Repo。最后修改 Podfilepod JYNetwork, ~ 0.1.0去掉:path然后就變成普通遠(yuǎn)程 Pod 的用法。這個(gè)過程我經(jīng)歷過很多次最大的感受是只要本地階段把 podspec 寫得規(guī)范、源碼目錄結(jié)構(gòu)保持清晰切換到遠(yuǎn)程只要幾分鐘。6. 調(diào)試本地 Pod 過程中的高頻問題速查6.1 pod install 后還是找不到類這種情況一般分兩類。第一類是source_files沒包含新增的文件檢查 podspec 里的路徑匹配規(guī)則第二類是頭文件只在模塊內(nèi)部可見卻沒被聲明為 public外部工程用尖括號導(dǎo)入時(shí)自然找不到。查看是否匹配到文件可以在模塊目錄執(zhí)行pod install后打開 Pods 工程里的 Development Pods 分組看文件是否出現(xiàn)在對應(yīng) target 里。6.2 圖片和 xib 資源加載不出來這是本地 Pod 最容易踩的坑。前面我提到過Pod 使用resource_bundles打包資源后資源不在主 bundle 中。這里給出一個(gè)通用解決辦法以JYNetwork模塊里的network_placeholder.png為例正確加載方式是NSBundle *bundle [NSBundle bundleWithURL:[[NSBundle bundleForClass:[self class]] URLForResource:JYNetwork withExtension:bundle]]; UIImage *image [UIImage imageNamed:network_placeholder inBundle:bundle compatibleWithTraitCollection:nil];如果是純 Swift 片段可以用Bundle(identifier:)或者直接通過Bundle(for:)獲取。如果你在使用 xib/storyboard 時(shí)也出現(xiàn)找不到 view 的情況大概率是資源 bundle 沒對上換成上述方式一般都能解決。6.3 用了 use_frameworks! 之后靜態(tài)庫和動態(tài)庫的混編問題在 Podfile 里寫use_frameworks!后Pod 會編譯成動態(tài) framework嚴(yán)格說是靜態(tài) framework 或動態(tài) framework取決于配置這會影響#import的方式和啟動速度。如果你的工程較多使用 OC且不想引入動態(tài)庫的額外符號暴露可以把use_frameworks!改為use_frameworks! :linkage :static表示強(qiáng)制使用靜態(tài)鏈接。這個(gè)配置對本地 Pod 同樣生效能省掉一部分動態(tài)庫的加載開銷也能避免部分組件因?yàn)閯討B(tài)庫機(jī)制導(dǎo)致的-ObjC問題。6.4 pod install 時(shí)出現(xiàn) “Unable to find a specification for X”檢查是不是某個(gè)依賴沒有明確來源。如果你本地 Pod 依賴了一個(gè)遠(yuǎn)程私有 Pod但 Podfile 里沒有配置對應(yīng)的sourceCocoaPods 就找不到 spec。解決方法是把倉庫地址寫到 Podfile 頂部source https://github.com/CocoaPods/Specs.git source gityour-git-server:specs-repo.git注意即使是本地依賴也可以聲明多個(gè) sourceCocoaPods 會從這些倉庫里拉取其他 Pod 的 spec。6.5 pod install 后 Pods 目錄里的文件沒更新遇到這種情況先別反復(fù)執(zhí)行pod install因?yàn)檫@不是安裝命令的問題。刪掉 Pods 目錄和 Podfile.lock重新執(zhí)行pod install通常能解決大部分本地依賴的緩存問題。如果還不行用pod cache clean清理 CocoaPods 的緩存。6.6 本地 Pod 里用 Category 但運(yùn)行時(shí)不生效還記得 3.4 里的OTHER_LDFLAGS -lObjC吧。Category 編譯進(jìn)靜態(tài)庫后如果沒有-ObjC鏈接參數(shù)鏈接器不會加載包含 Category 的 object 文件運(yùn)行時(shí)就會表現(xiàn)成“方法不見了”。遇到這類問題先看編譯設(shè)置里是否包含-ObjC或-all_load再逐個(gè)排查是哪個(gè) pod target 出的問題。6.7 多個(gè)本地 Pod 之間互相依賴怎么辦這是組件化深入后的必經(jīng)之路。比如JYHomePage依賴JYNetworkPodspec 里寫s.dependency JYNetworkPodfile 里可以同時(shí)寫pod JYHomePage, :path ../Modules/JYHomePage pod JYNetwork, :path ../Modules/JYNetworkCocoaPods 會自動解析本地路徑之間的依賴。此時(shí)要特別留意版本號的一致性如果JYHomePage的 podspec 里寫了dependency JYNetwork, ~ 1.0而本地 JYNetwork 的 podspec version 還停留在0.9.0CocoaPods 會直接報(bào)版本沖突。解決辦法是在:path模式下兩個(gè) Pod 的 version 都要維護(hù)好或者將依賴版本寫成不帶太多限制的范圍比如 0.9.0。最后分享兩個(gè)我自己的習(xí)慣組件化沒有標(biāo)準(zhǔn)答案但有些坑是共通的。第一我始終建議 Pod 里不要直接訪問宿主工程的單例對象或全局宏。如果模塊需要宿主提供配置定義協(xié)議讓宿主去注入這樣模塊才不會變成下一個(gè)“大雜燴”。第二剛拆出來的 Pod 不要急著去做代碼整潔度重構(gòu)先把文件搬過去、編譯能過、行為不變?nèi)缓笤俪榻涌?、刪冗余。拆分和重構(gòu)同時(shí)做一旦出問題很難判斷是哪一步引入的。我見過太多團(tuán)隊(duì)一開始把組件化做成“新建幾個(gè)文件夾”最后又退回單工程就是因?yàn)檫吔鐩]立住。而本地 Pod 恰恰是那個(gè)能把邊界變成文件系統(tǒng)、變成 podspec、變成依賴樹的方案。至少在我的實(shí)踐里從第一行pod XXX, :path ../Modules/XXX寫完組件化的路就已經(jīng)往前邁了一大截。多試幾個(gè)模塊等依賴圖清晰了后面再做二進(jìn)制化、CI 自動化都會順很多。