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)會(huì)集中在四個(gè)地方。第一是編譯速度。每改一行代碼整個(gè)工程都可能觸發(fā)重新編譯尤其是越來越多人往 App 里塞第三方庫和分類。第二是團(tuán)隊(duì)協(xié)作。不同小組改同一個(gè)文件、同一個(gè)宏定義代碼合并時(shí)沖突頻發(fā)誰也不敢動(dòng)公共代碼。第三是測(cè)試成本。業(yè)務(wù)模塊互相牽連單元測(cè)試很難把某個(gè)模塊孤立出來跑回歸全靠手工點(diǎn) App。第四是代碼復(fù)用。App 和擴(kuò)展、多個(gè) App 之間想共用一段邏輯只能靠復(fù)制粘貼修 bug 要改好幾個(gè)地方。組件化不是玄學(xué)它的核心是把代碼按業(yè)務(wù)或功能切成獨(dú)立模塊每個(gè)模塊只暴露必要的接口模塊之間通過明確的依賴關(guān)系通信。這樣一來編譯可以被緩存團(tuán)隊(duì)可以獨(dú)立維護(hù)各自的模塊測(cè)試也可以只拉取模塊源碼來跑。而 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 會(huì)把這個(gè)目錄里的源碼直接編譯進(jìn)你的工程不需要任何遠(yuǎn)端基礎(chǔ)設(shè)施。對(duì)剛起步的項(xiàng)目來說本地 Pod 有三點(diǎn)優(yōu)勢(shì)非常明顯因?yàn)樵创a在本地改完 Pod 里的代碼直接生效調(diào)試效率跟單工程一模一樣。Pod 和宿主工程是兩個(gè)物理目錄天然形成了“模塊邊界”誰依賴誰一目了然。后續(xù)要推到遠(yuǎn)端倉庫只需要給 podspec 配一個(gè) Git 地址改動(dòng)量很小。所以我的建議是組件化的第一階段全部用本地 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)庫或動(dòng)態(tài)庫打成 zip再掛到 Spec Repo 下適合對(duì)編譯速度有極端要求的團(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)姿勢(shì)2.1 手動(dòng)創(chuàng)建還是用 pod lib createCocoaPods 提供了一個(gè)專門用來生成 Pod 模板的命令pod lib create。它會(huì)展開一個(gè)交互式詢問包括你要用 Swift 還是 Objective-C、要不要生成測(cè)試框架、要不要 GUI 調(diào)試等然后自動(dòng)生成完整的目錄骨架包括.podspec、README、LICENSE、Example工程和Sources目錄。但我實(shí)際用下來的感受是pod lib create直接生成一套模板里面有大量當(dāng)前用不到的文件。比如它會(huì)生成一個(gè)Example文件夾里面帶一個(gè)需要用pod install才能跑起來的 Demo 工程還要配置 target。對(duì)只是想快速把舊代碼拆成 Pod 的場(chǎng)景來說這一步有點(diǎn)重。所以我更推薦的做法是先手動(dòng)創(chuàng)建最簡結(jié)構(gòu)只需要四樣?xùn)|西一個(gè)源文件目錄、一個(gè).podspec文件、一個(gè)存放資源的Assets文件夾可選、一個(gè)用來測(cè)試的宿主工程。等你能跑通本地 Pod 的接入流程再回頭看pod lib create生成的模板也不會(huì)一頭霧水。2.2 標(biāo)準(zhǔn)的本地 Pod 目錄長什么樣我通常會(huì)在主工程同級(jí)放一個(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其他同事看起來就會(huì)很混亂。按 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 的源碼并不會(huì)拷貝到別的目錄而是通過 Pods 工程去引用../Modules/JYNetwork/Sources下的文件。需要特別注意的是:path使用的是相對(duì)路徑而這個(gè)相對(duì)路徑的基準(zhǔn)是 Podfile 所在的目錄。如果你把 Podfile 放在MyApp里那:path就應(yīng)該從MyApp路徑開始寫。換過電腦、移動(dòng)過目錄后只要這個(gè)相對(duì)位置不變就能正常pod install。3. Podspec 配置每個(gè)字段有什么用填錯(cuò)了會(huì)怎樣podspec 是 CocoaPods 的“身份證”里面聲明了這個(gè) Pod 叫什么、版本多少、包含哪些文件、依賴了誰。很多人直接復(fù)制別人的 podspec 模板字段倒是填滿了但不知道每個(gè)字段背后對(duì)應(yīng)的行為。我挑幾個(gè)真正影響構(gòu)建的字段展開講。3.1 基本信息與版本號(hào)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模式下不太會(huì)嚴(yán)格讀取版本號(hào)但后續(xù)發(fā)布到私有 Spec Repo 時(shí)podspec 的版本號(hào)必須和 Git tag 一一對(duì)應(yīng)。比如 podspec 里寫0.1.0Git 就必須打一個(gè)0.1.0的 tag否則pod install時(shí)找不到對(duì)應(yīng)版本。另外一個(gè)容易踩坑的字段是s.source。本地模式時(shí)source里寫什么幾乎不影響編譯但如果你把它留空或者填一個(gè)不存在的地址將來發(fā)布時(shí)就會(huì)報(bào)錯(cuò)。我建議從一開始就填上真實(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 文件就不會(huì)被編譯進(jìn)去。同理如果 Pod 是一個(gè)純 Swift 庫就得寫成*.swift。resource_bundles則是把資源文件單獨(dú)打成一個(gè) bundle。注意這里我推薦用resource_bundles而不是resources原因是resources會(huì)把資源文件直接放進(jìn)主 bundle容易出現(xiàn)文件重名覆蓋resource_bundles會(huì)為這個(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 找所以就找不到圖了。后面我會(huì)在常見問題里說怎么解決。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í)就會(huì)把 AFNetworking 一并拉進(jìn)來。版本號(hào)建議約束在合理范圍比如~ 4.0表示大于等于 4.0 且小于 5.0既能保證功能一致又允許小版本更新。如果 Pod 使用了系統(tǒng)框架就得在frameworks里加對(duì)應(yīng)名字。很多人在本地寫代碼時(shí)沒報(bào)錯(cuò)因?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)去。這對(duì)提升構(gòu)建速度、控制模塊體積很有幫助但同樣也意味著你對(duì)模塊邊界的把控要更明確。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 對(duì)應(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í)會(huì)看不到擴(kuò)展方法。4. 本地 Pod 的集成與調(diào)試實(shí)戰(zhàn)4.1 初次接入從零開始跑通鏈路準(zhǔn)備一個(gè)全新的測(cè)試工程我用最小化流程演示一遍。第一步新建 Xcode 工程MyApp選擇 iOS App 模板。這一步的工程路徑和是否使用 Core Data 都不重要。第二步在工程文件同級(jí)創(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 會(huì)生成MyApp.xcworkspace之后必須通過.xcworkspace打開工程而不是.xcodeproj。這里我要提一個(gè)很多人栽過跟頭的細(xì)節(jié)pod install和pod update的區(qū)別。首次使用本地 Pod 時(shí)如果依賴是新增的可以用pod install但如果你改了冒號(hào)路徑、新增了 subspec或者 podspec 里的 source 發(fā)生了變化pod install可能不會(huì)重新解析已經(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 會(huì)自動(dòng)配置 header search path所以你可以直接用尖括號(hào)引用 Pod 的頭文件。但前提是這些頭文件在public_header_files范圍內(nèi)。.m文件里的私有頭文件可以放在 podspec 的 source_files 里但不要放進(jìn) public_header_files否則會(huì)造成接口過度暴露。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)勢(shì)就是“改完就能用”。因?yàn)?path是指向源碼目錄的所以你修改JYNetwork文件夾里的代碼后重啟 App、重新編譯改動(dòng)就會(huì)生效不需要重新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)境自動(dòng)關(guān)掉。這種開關(guān)放在 Pod 里比散落在宿主工程里要規(guī)范得多。5. 從本地 Pod 走向規(guī)范與發(fā)布5.1 本地 Pod 的版本號(hào)怎么管理本地模式不會(huì)強(qiáng)制校驗(yàn)版本號(hào)但我不建議因此偷懶。把版本號(hào)從0.1.0開始維護(hù)每完成一定量的改動(dòng)就遞增遵循語義化版本規(guī)范主版本號(hào)不兼容的 API 修改次版本號(hào)向后兼容的功能新增修訂號(hào)向后兼容的問題修復(fù)這樣做的意義是當(dāng)你后面把 podspec 推送到遠(yuǎn)程倉庫、開始用 tag 管理版本時(shí)歷史包袱已經(jīng)很小。而且宿主工程 Podfile 里可以同時(shí)使用:path和指定的版本號(hào)比如pod JYNetwork, :path ../Modules/JYNetwork在開發(fā)環(huán)境不加版本限制但發(fā)布的時(shí)候 Podfile 會(huì)鎖住一個(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里面會(huì)記錄當(dāng)前解析后的 Pod 及版本。如果某個(gè)模塊依賴關(guān)系特別詭異比如基礎(chǔ)庫依賴了登錄模塊說明邊界設(shè)計(jì)有問題一定要趁早發(fā)現(xiàn)。我還有一個(gè)習(xí)慣沒事就跑一遍pod outdated。本地 Pod 模式下它不一定能檢測(cè)出變化但至少能幫你確認(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外部工程用尖括號(hào)導(dǎo)入時(shí)自然找不到。查看是否匹配到文件可以在模塊目錄執(zhí)行pod install后打開 Pods 工程里的 Development Pods 分組看文件是否出現(xiàn)在對(duì)應(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 沒對(duì)上換成上述方式一般都能解決。6.3 用了 use_frameworks! 之后靜態(tài)庫和動(dòng)態(tài)庫的混編問題在 Podfile 里寫use_frameworks!后Pod 會(huì)編譯成動(dòng)態(tài) framework嚴(yán)格說是靜態(tài) framework 或動(dòng)態(tài) framework取決于配置這會(huì)影響#import的方式和啟動(dòng)速度。如果你的工程較多使用 OC且不想引入動(dòng)態(tài)庫的額外符號(hào)暴露可以把use_frameworks!改為use_frameworks! :linkage :static表示強(qiáng)制使用靜態(tài)鏈接。這個(gè)配置對(duì)本地 Pod 同樣生效能省掉一部分動(dòng)態(tài)庫的加載開銷也能避免部分組件因?yàn)閯?dòng)態(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 里沒有配置對(duì)應(yīng)的sourceCocoaPods 就找不到 spec。解決方法是把倉庫地址寫到 Podfile 頂部source https://github.com/CocoaPods/Specs.git source gityour-git-server:specs-repo.git注意即使是本地依賴也可以聲明多個(gè) sourceCocoaPods 會(huì)從這些倉庫里拉取其他 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ù)鏈接器不會(huì)加載包含 Category 的 object 文件運(yùn)行時(shí)就會(huì)表現(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 會(huì)自動(dòng)解析本地路徑之間的依賴。此時(shí)要特別留意版本號(hào)的一致性如果JYHomePage的 podspec 里寫了dependency JYNetwork, ~ 1.0而本地 JYNetwork 的 podspec version 還停留在0.9.0CocoaPods 會(huì)直接報(bào)版本沖突。解決辦法是在:path模式下兩個(gè) Pod 的 version 都要維護(hù)好或者將依賴版本寫成不帶太多限制的范圍比如 0.9.0。最后分享兩個(gè)我自己的習(xí)慣組件化沒有標(biāo)準(zhǔn)答案但有些坑是共通的。第一我始終建議 Pod 里不要直接訪問宿主工程的單例對(duì)象或全局宏。如果模塊需要宿主提供配置定義協(xié)議讓宿主去注入這樣模塊才不會(huì)變成下一個(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 自動(dòng)化都會(huì)順很多。