在 iOS App 開發(fā)方面，幾乎所有的 App 都需要使用到第三方依賴庫。依賴庫不僅能為我們提供豐富的功能，還能避免我們從頭開發(fā)，在節(jié)省時間的同時也減少許多 Bug 。

但伴隨著軟件功能越來越豐富，依賴庫數(shù)量越來越多，由此也出現(xiàn)了“依賴地獄”，比如依賴庫循環(huán)依賴，底層依賴庫版本沖突等。為了解決此類問題，于是，依賴庫管理工具也就出現(xiàn)了。

目前流行的依賴庫管理工具主要有：Git Submodules、Carthage、 Swift Package Manager 和 CocoaPods。在這里我們選擇 CocoaPods。為什么呢？原因有三：

1. CocoaPods 非常成熟，十分穩(wěn)定，并且簡單易用，學(xué)習(xí)成本低，效果明顯；

2. CocoaPods 會自動整合 Xcode 項目，使得其他項目成員在使用第三方庫時無須任何額外的手工操作；

3. CocoaPods 已經(jīng)成為 iOS 業(yè)界標(biāo)準(zhǔn)，支持幾乎所有的開源庫和商業(yè)庫，即便是 Objective-C 的依賴庫以及二進(jìn)制文件（binary）依賴庫，CocoaPods 也提供支持。

那么，怎樣使用 CocoaPods 來管理第三方依賴庫呢？接下來我會從語義化版本管理、Pod 版本管理、Pod 版本更新三個方面展開介紹。

語義化版本管理

開發(fā)軟件，免不了要更新迭代，所以每一次更新的版本號管理變得很重要。并且，一旦版本號混亂，就會導(dǎo)致一系列問題，比如很難查找和修改線上崩潰，沒辦法支持多團(tuán)隊并行開發(fā)，等等。為了避免此類問題，我們可以使用語義化版本管理（Semantic Versioning）來統(tǒng)一版本號的定義規(guī)范。

語義化版本號是一種通用的版本號格式規(guī)范，目前絕大部分優(yōu)秀的第三方依賴庫都遵循這一規(guī)范來發(fā)布版本。

具體來說，語義化版本號的版本號一般包括四部分：MAJOR、MINOR、PATCH、BUILD。每一部分都由遞增的數(shù)值組成，例如 1.2.3.4，其中 1 是MAJOR， 2 是 MINOR。如果我們更新 MINOR 版本號，那么下一個版本就是 1.3.0.0。接下來我詳細(xì)介紹下這四部分。

• MAJOR 是指主版本號，通常在重大更新的時候才會需要更新主版本號。例如 iOS 每年都會更新一個主版本號。而對于第三方庫來說，主版本號的更新，表示該庫的 API 新增了重大功能，或者引入了不可兼容的更新 （breaking changes）。

• MINOR 是指副版本號，用于小功能的改善。例如 iOS 14 在發(fā)布主版本后，在一年內(nèi)可能發(fā)布多個副版本如 14.1、 14.2 來完善其系統(tǒng)功能。一般對于第三方庫來說，副版本的更新就是新增一些 API，但不包含不可兼容的更新。

• PATCH 是指補丁版本號，一般用于 bug fix 以及修復(fù)安全性問題等。對于第三方庫來說，補丁版本號的更新也不應(yīng)該有不可兼容的更新。雖然實際操作中這會有些困難，但我們可以通過把原有 API 標(biāo)記為 deprecated，或者為新 API 參數(shù)提供默認(rèn)值等辦法來解決。

• BUILD 是指構(gòu)建版本號，通常在內(nèi)部測試時使用。一般當(dāng)我們使用 CI 服務(wù)器進(jìn)行自動構(gòu)建時，構(gòu)建版本號會自動更新。

Pod 版本管理

要使用 CocoaPods 管理第三方依賴庫，首先要新建一個 Podfile 文件，然后執(zhí)行bundle exec pod install命令來安裝所有依賴庫。這時候 CocoaPods 會自動幫我們建立一個 Podfile.lock 文件和一個 Workspace文檔。

注意，在第一講我們說過，由于是通過 Bundler 來安裝 CocoaPods，每次執(zhí)行pod命令前，都需要加上bundle exec。不過為了簡潔，后面涉及pod命令時，我會省略bundle exec部分。

接下來，我詳細(xì)介紹下 Podfile 文件、 Podfile.lock 和 Workspace 文檔到底是什么，以及如何使用。

Podfile 文件

Podfile 文件是一個配置文件，它主要是用來描述 Xcode 項目里各個 target 的依賴庫。我們項目的 Podfile 文件可以在倉庫中找到。在這里，我主要和你介紹一下 Podfile 文件中的幾個重要配置。

source 配置

source用于指向 PodSpec（Pod 規(guī)范）文件的 Repo，從而使得 CocoaPods 能查詢到相應(yīng)的 PodSpec 文件。

具體來說，當(dāng)使用公共依賴庫的時候，source需要指向 CocoaPods Master Repo，這個主倉庫集中存放所有公共依賴庫的 PodSpec 文件。 由于 CocoaPods 經(jīng)常被開發(fā)者吐槽 Pod 下載很慢，因此 CocoaPods 使用了 CDN （Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）來緩存整個 CocoaPods Master Repo， 方便開發(fā)者快速下載。具體的配置方法就是使source指向 CND 的地址，代碼示例如下：

source 'https://cdn.cocoapods.org/'

如果使用的是私有依賴庫，我們也需要把source指向私有庫的 PodSpec Repo，以使得 CocoaPods 能找到相應(yīng)的 PodSpec 文件。 代碼示例如下：

source 'https://my-git-server.com/internal-podspecs'

注意，當(dāng)我們使用私有庫時，執(zhí)行pod install命令的機器必須能訪問到source所指向的 Repo。

project 和 workspace

project用于指定我們的主項目文檔。該項目文檔會使用到 CocoaPods 管理的所有第三方依賴庫。

workspace用于指定要生成和更新的 Workspace 文檔。和其他依賴庫管理工具不一樣，CocoaPods 會自動生成一個 Workspace 文檔，然后我們只能使用該文檔而不是 Xcode 項目文檔來進(jìn)行后續(xù)開發(fā)。

代碼示例如下：

project './Moments/Moments.xcodeproj'
workspace './Moments.xcworkspace'

這其中 Moments.xcodeproj 就是我們的主項目文檔，它一般放在和項目名字相同的下一層目錄下。

而 Moments.xcworkspace 是 CocoaPods 為我們生成的 Workspace文檔，為了統(tǒng)一，我建議名字也是和主項目相同。

platform 和 use_frameworks

先看示例，它表示什么呢？

platform :ios, '14.0'
use_frameworks!

為了保證所有依賴庫與主項目在編譯和運行時兼容，我們指定的系統(tǒng)版本號需要和主項目所支持的系統(tǒng)版本號保持一致。而platform就是用于指定操作系統(tǒng)以及所支持系統(tǒng)的最低版本號。比如，例子中的platform :ios, '14.0'就表示支持 iOS 14.0 以上的所有 iOS 版本。

另外一行的use_frameworks!這一配置會讓 CocoaPods 把所有第三方依賴庫打包生成一個動態(tài)加載庫，而不是靜態(tài)庫。因為動態(tài)庫是我們經(jīng)常用到的，它能有效地加快編譯和鏈接的速度。

組織同類型的第三方依賴庫

def dev_pods
  pod 'SwiftLint', '0.40.3', configurations: ['Debug']
  pod 'SwiftGen', '6.4.0', configurations: ['Debug']
end

其中configurations: ['Debug']用于指定該依賴庫只是使用到Debug構(gòu)建目標(biāo)（target）里面，而不在其他（如Release）構(gòu)建目標(biāo)里面，這樣做能有效減少 App Store 發(fā)布版本的體積。

def dev_pods end代碼塊是“復(fù)用同一類依賴庫方式”的意思，我們可以把同類型的依賴庫都放進(jìn)這個代碼塊里面。比如，我們的 Moments 項目中就分別有dev_pods（開發(fā)相關(guān)的庫）,core_pods（核心庫）以及thirdparty_pods(第三方庫)等代碼塊定義。

target 配置

有了這些復(fù)用庫定義以后，怎樣使用到項目的構(gòu)建目標(biāo)（target）里面呢？下面就是一個例子。

target 'Moments' do
  dev_pods
  core_pods
  # other pods...
end

我們可以把構(gòu)建目標(biāo)所使用的所有依賴庫放進(jìn)target代碼塊中間，上面中的Moments就是我們的 App 構(gòu)建目標(biāo)。該構(gòu)建目標(biāo)依賴了dev_pods和core_pods等各組依賴庫。執(zhí)行pod install的時候，CocoaPods 會把dev_pods代碼塊自動展開為SwiftLint和SwiftGen，那么Moments構(gòu)建目標(biāo)能使用SwiftLint和SwiftGen依賴庫了。

依賴庫的版本

 pod 'RxSwift', '= 5.1.1'
 pod 'RxRelay', '= 5.1.1'

在 CocoaPods 里面，每一個依賴庫稱為一個 Pod （注意這里首字母大寫，Pod 指一個庫），指定一個 Pod 的命令是pod（注意這里是小寫，表示一條命令）。在 Podfile 里面我們可以通過這樣的格式pod 'RxSwift', '= 5.1.1'來配置依賴庫的版本號。其中，RxSwift或者RxRelay是依賴庫的名字，5.1.1為版本號。這些庫的名字以及版本號都可以在 CocoaPods 官網(wǎng)上找到。

為了統(tǒng)一管理第三方依賴庫的版本，我建議統(tǒng)一使用 = 來鎖定該依賴庫的版本，這樣就能保證每次執(zhí)行pod install的時候都可以為同一個庫下載同一個版本。

除了 = 操作符以外，CocoaPods 還支持其他操作符來指定版本：

• > 0.1表示大于 0.1 的任何版本，這樣可以包含 0.2 或者 1.0；

• >= 0.1表示大于或等于 0.1 的任何版本；

• < 0.1表示少于 0.1 的任何版本；

• <= 0.1表示少于或等于 0.1 的任何版本；

• ~> 0.1.2表示大于 0.1.2 而且最高支持 0.1.* 的版本，但不包含 0.2 版本。

這幾個操作符相里面，~>（Squiggy arrow）操作符更為常用，它是以最后一個部分的版本號（例子中 0.1.2 的最后一個部分是補丁版本號 ..2）來計算可以支持的最高版本號。

例如~> 0.1.2表示 >= 0.1.2 并且 < 0.2.0，但不能等于 0.2.0， 因為 0.2.0 已經(jīng)更新了副版本號而不僅僅是補丁版本號了。另外一個例子是~> 0.1，表示 >= 0.1 并且 < 1.0，舉例來說，我們可以更新到 0.9 但不能更新到 1.0。

前面我介紹的是引用外部的第三方依賴庫，如果我們的項目有自己的內(nèi)部依賴庫，要怎樣在 CocoaPods 引用它呢？其實很簡單，我們可以執(zhí)行以下命令：

pod 'DesignKit', :path => './Frameworks/DesignKit', :inhibit_warnings => false

和其他外部依賴庫不一樣，我們需要使用:path來指定該內(nèi)部庫的路徑。

Podfile.lock 文件

Podfile.lock 文件是由 CocoaPods 自動生成和更新的，該文件會詳細(xì)列舉所有依賴庫具體的版本號。比如，

DEPENDENCIES:
  - Alamofire (= 5.2.0)
  - Firebase/Analytics (= 7.0.0)
PODFILE CHECKSUM: 400d19dbc4f5050f438797c5c6459ca0ef74a777

當(dāng)執(zhí)行pod install后，CocoaPods 會根據(jù) Podfile 文件解釋出各依賴庫的特定版本號，然后一一列舉在 DEPENDENCIES 下面。在上述的例子中，我們的 App 在構(gòu)建過程中使用了5.2.0 的 Alamofire 庫以及 7.0.0 的 Firebase Analytics 庫。

PODFILE CHECKSUM 用于記錄 Podfile 的驗證碼，任何庫的版本號的更改，都會改變該驗證碼。這樣能幫助我們在不同的機器上，快速檢測依賴庫的版本號是否一致。

我建議要把 Podfile 和 Podfile.lock 文件一同 commit 并 push 到 Git 代碼管理服務(wù)器里面。特別是在團(tuán)隊開發(fā)的環(huán)境下，這樣能幫助我們保證各個依賴庫版本號的一致性。

在實踐操作中，無論我們在哪臺機器上執(zhí)行pod install， PODFILE CHECKSUM 都不應(yīng)該發(fā)生任何改變。因為我們在 Git 保存了 Podfile.lock，一旦我們發(fā)現(xiàn)老版本 App 的 Bug ，就可以根據(jù)該文件為各個依賴庫重新安裝同一版本號，來重現(xiàn)和定位問題，從而幫助我們快速修改這些 Bug。

Workspace 文檔

Workspace 文檔是 Xcode 管理子項目的方式。通過 Workspace，我們可以把相關(guān)聯(lián)的多個 Xcode 子項目組合起來方便開發(fā)。

前面說過，當(dāng)我們執(zhí)行pod install的時候，CocoaPods 會自動創(chuàng)建或者更新一個叫作 Pods 的項目文檔（Pods.xcodeproj ）以及一個 Workspace 文檔（在我們項目中叫作 Moments.xcworkspace）。

其中，Pods 項目文檔負(fù)責(zé)統(tǒng)一管理各個依賴庫，當(dāng)我們在 Podfile 里面指定構(gòu)建成動態(tài)庫的時候，該項目會自動生成一個名叫Pods_<項目名稱>.framework的動態(tài)庫供我們項目使用。

而 Workspace 文檔則統(tǒng)一管理了我們原有的主項目 （Moments.xcodeproj）以及那個 Pods 項目。

與此同時，CocoaPods 還會修改 Xcode 項目中的 Build Phases 以此來檢測 Podfile.lock 和 Manifest.lock 文件的一致性，并把Pods_<項目名稱>.framework動態(tài)庫嵌入我們的主項目中去。

以上所有操作都是由 CocoaPods 自動幫我們完成。以后的開發(fā)，我們都可以打開 Workspace 文檔而不是原有的 Xcode 項目文檔來進(jìn)行。

Pod 版本更新

使用 CocoaPods 管理第三方依賴庫的操作非常簡單，可是一旦使用不當(dāng)，特別是在 Pod 更新的時候，很容易引起依賴庫版本不一致，從而出現(xiàn)各種問題。

比如，在編譯程序的時候，有些開發(fā)者可以順利進(jìn)行，而另外一些開發(fā)者編譯時候就會出錯；或者程序在本地編譯時運行良好，一旦在 CI 上構(gòu)建，就會出現(xiàn) App 崩潰，等等。

那么，怎么保證更新 Pod 的時候都能保證版本一致呢？

下面結(jié)合我的實踐經(jīng)驗，以第三方網(wǎng)絡(luò)庫 Alamofire 為例子和你介紹下。

第一步，CocoaPods 已經(jīng)為我們提供了pod outdated命令，我們可以用它一次查看所有 Pod 的最新版本，而無須到 GitHub 上逐一尋找。下面是執(zhí)行pod outdated命令的其中一條結(jié)果：

The following pod updates are available:
- Alamofire 5.2.0 -> 5.2.0 (latest version 5.4.0)

這表示當(dāng)前我們使用了版本為 5.2.0 的 Alamofire ，其最新版本為 5.4.0。如果我們決定更新到版本 5.4.0，那么可以繼續(xù)下一步。

第二步，在更新依賴庫版本之前，為了避免在新版本中不小心引入 Bug，我們需要了解新的版本到底提供了哪些新功能，修改了哪些 Bug，與老版本是否兼容等事項。具體我們可以到 CocoaPods 官網(wǎng)上查找需要更新的第三方依賴庫，然后在 GitHub 等平臺上找到，并仔細(xì)閱讀該庫的版本說明（release note）。

請注意，我們要閱讀當(dāng)前使用版本到要更新的版本之間的所有版本說明。 在這個例子中，我們要閱讀 5.2.1，5.2.2，5.3.0 和 5.4.0 的所有版本說明。這些版本說明會列出新增功能，更新的 API，修改的 Bug，有沒有不可兼容的更新 。

第三步，在 Podfile 文件里把要更新的 Pod 的版本號進(jìn)行修改。例如把pod 'Alamofire', '= 5.2.0'改成pod 'Alamofire', '= 5.4.0'。 然后執(zhí)行pod install來重新生成 Podfile.lock 文件。

此時特別注意的是，我們要使用pod install而不是pod update。因為執(zhí)行pod update會自動更新所有 Pod 的版本，這可能會更新了一些我們目前還不想更新的 Pod，從而會引入一些難以覺察的問題。

第四步，如果所更新的版本包含了不可兼容的更新，我們需要修改代碼來保證代碼能順利完成編譯。

第五步，很多第三方依賴庫都是一些通用的基礎(chǔ)組件，一旦發(fā)生問題會影響到整個 App 的功能，因此我們需要根據(jù)所更新的庫進(jìn)行回歸測試。例如當(dāng)更新了 Alamofire 庫的時候，我們需要把每個網(wǎng)絡(luò)請求都執(zhí)行一遍，避免所更新的版本引入新的 Bug。

第六步，為了把更新的版本共享給所有開發(fā)者和 CI 服務(wù)器，我們需要把 Podfile 和 Podfile.lock 文件一同 commit 并 push 到 Git 代碼管理服務(wù)器，并通過 Pull Request 流程并入主分支。

第七步，一旦更新的代碼并入主分支后，要通過 Slack 等內(nèi)部通信軟件告訴所有開發(fā)者 pull 或者 rebase 主分支的代碼，并執(zhí)行pod install來更新他們開發(fā)環(huán)境的所有依賴庫。

特別注意，千萬不要使用pod update，因為pod update會自動把開發(fā)者機器上所有 Pod 的版本自動更新了。這種更新往往不是我們想要的結(jié)果，我們希望統(tǒng)一更新各個 Pod 的版本，并通過 Git 進(jìn)行集中管理。

如果開發(fā)者在編譯新代碼前沒有執(zhí)行pod install命令，會出現(xiàn)以下的錯誤。

The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

這錯誤可以有效提醒所有開發(fā)者，需要再次執(zhí)行pod install來更新他們本地的依賴庫，從而保證所有開發(fā)者使用的依賴庫的版本都是一致的。

另外，如果更新了基礎(chǔ)組件的依賴庫（如網(wǎng)絡(luò)庫），在測試階段，我們還需要進(jìn)行全面的回歸測試。因為這些基礎(chǔ)組件庫的新版本如果有 Bug 很可能導(dǎo)致我們的 App 會發(fā)生大比例的崩潰，嚴(yán)重影響用戶的體驗。

有了上面的一流程，我們就可以有效地保證每個開發(fā)者使用的依賴庫版本都是一致的，同時也能保證 CI 在自動構(gòu)建 App 的時候所使用的依賴庫版本也是統(tǒng)一的。

總結(jié)

這一講我介紹了如何使用 CocoaPods 來統(tǒng)一管理依賴庫的版本。特別是根據(jù)我自己的經(jīng)驗總結(jié)了一套更新 Pod 版本的流程，希望你靈活使用這些步驟，從而少走彎路。

[圖片上傳失敗...(image-1d5139-1684744954659)]

這里我再特別強調(diào)一下，為了保證依賴庫版本都能保持一致，盡量不要執(zhí)行pod update，而是使用通過修改 Podfile 文件里的版本號并執(zhí)行pod install來更新 Pod 的版本，然后把 Podfile 和 Podfile.lock 文件一同并入 Git 主分支中進(jìn)行統(tǒng)一管理。

思考題：

CocoaPods 非常簡單易用，它可以同時管理依賴庫的依賴項，例如我們的 App 依賴 A 庫， 而 A 庫又依賴 B 庫，同時 B 庫依賴 C 庫，CocoaPods 可以幫我們自動找出所有依賴項并按順序安裝所有依賴庫。 那你知道 CocoaPods 是如何管理依賴庫的依賴呢？

下一講，我將為你介紹如何統(tǒng)一構(gòu)建配置。

源碼地址：

Podfile 文件地址：
https://github.com/lagoueduCol/iOS-linyongjian/blob/main/Podfile

[圖片上傳失敗...(image-cb33d9-1684744954659)]

《大前端高薪訓(xùn)練營》

12 個月打磨，6 個月訓(xùn)練，優(yōu)秀學(xué)員大廠內(nèi)推，點擊報名，高薪有你！

精選評論

*虎：

如何回復(fù)講師的回復(fù)？只能創(chuàng)建新的留言回復(fù)嗎？

官方客服回復(fù)：

是的，想要回復(fù)講師的答復(fù)，可以在新留言里面的開頭標(biāo)記說明就行

*虎：

"第七步，一旦更新的代碼并入主分支后，要通過 Slack 等內(nèi)部通信軟件告訴所有開發(fā)者 pull 或者 rebase 主分支的代碼，并執(zhí)行pod install來更新他們開發(fā)環(huán)境的所有依賴庫"能否把更新的依賴庫也一并 push 到遠(yuǎn)端倉庫，這樣團(tuán)隊里其他開發(fā)人員就不需要額外 pod install 了？

講師回復(fù)：

看得很仔細(xì)哦，更新和 push 到遠(yuǎn)程倉庫的是 Podfile 以及 Podfile.log 文件，團(tuán)隊其他人員還是需要執(zhí)行 pod install 安裝并更新 Pods 文件夾，這個 Pod 文件夾存放的是所有第三方庫的源碼文件，我們一般并不把該文件夾放到 Git 里面。因此每個開發(fā)環(huán)境都需要執(zhí)行 pod install 來更新。文章中提到，如果開發(fā)者不執(zhí)行 pod install 是沒有辦法編譯項目的，并且有錯誤提示。

**聰：

還不如直接看官網(wǎng)來的詳細(xì)和簡單！

講師回復(fù)：

哈哈，技術(shù)的準(zhǔn)確性都以官方文檔為準(zhǔn)哦。現(xiàn)在 iOS 開發(fā)已經(jīng)不是學(xué)習(xí)了系統(tǒng)提供的 API 就可以了，還需要學(xué)習(xí)系統(tǒng)架構(gòu)，自動化，代碼規(guī)范，單元測試。在團(tuán)隊協(xié)助的時候還需要制定代碼管理流程與規(guī)范。目前這些內(nèi)容在蘋果官網(wǎng)都沒有提供官方的方案，我們的課程是通過一個類似朋友圈 App 作為案例把開發(fā)過程中的各個方面連貫起來講述，希望能成為官方文檔的一個補充。

**華：

老師講的比較細(xì)

**不吃窩邊草：

CocoaPods 管理依賴庫的依賴，這種A依賴B，B依賴C,不是鏈表么？

講師回復(fù)：

有時候并不是單鏈條的鏈表那么簡單哦，可能是一個圖，要為圖找出依賴關(guān)系，需要使用拓?fù)渑判颉?/p>

**昆：

老師你好，關(guān)于pod update的描述，我有個疑問：如果是使用了 podName，'=version' 這時候 通過pod update 也會使用 = 號的版本號，而不會去所有都更新吧？

講師回復(fù)：

不是的哦，一旦執(zhí)行 pod update，會把版本號自動更新了。我們應(yīng)該手動更新版本后，然后執(zhí)行 pod install 來安裝。

*一：

感謝老師的講解??

講師回復(fù)：

也感謝你的支持。

*辰：

每個庫的PodSpec文件里會配置它所依賴的庫，CocoaPods 就是根據(jù)這個文件找出庫的依賴庫，依次類推。

*瀟：

老師，如果pod里面的第三方庫都指定了準(zhǔn)確的版本號，是不是用 pod update 也可以？

講師回復(fù)：

不是的，如果我們執(zhí)行了 pod update 命令，就會把執(zhí)行的機器中的第三方庫版本給更新了，這不是我們想要的效果，為了保證整個團(tuán)隊都使用統(tǒng)一的版本，我們應(yīng)該讓一個人更新版本，并在測試完畢后合并到主分支供大家使用，一個團(tuán)隊在一個時間只有一個人更新第三方庫的版本，其他人使用 pod install 來使用就可以了。

**超：

Cocopods 依賴庫沖突怎么解決？

講師回復(fù)：

請把問題描述清楚哦，這樣我好方便回答。

**龍：

可能我自己寫的不太清楚，思考題中，確實還不了解是通過什么算法來管理依賴庫的依賴呢，這方面還請賜教。上網(wǎng)查了一些，不過總覺得不對。有關(guān)于第三庫的管理和使用上，我舉個例子，比如我使用Alamofire，一般會在項目中再封裝一層，比如叫HttpUtils，而這個HttpUtils我通過Swift Package進(jìn)行本地化的組件化管理，如果這個HttpUtils寫的好，就放在公司內(nèi)網(wǎng)，大家都可以使用。不知道這樣表達(dá)是否清晰？

講師回復(fù)：

我想問的是 CocoaPods 的內(nèi)部實現(xiàn)，想讓大家不僅會用，還知道里面是怎樣實現(xiàn)的，一旦懂了原理，替換成不同的包管理工具都有一致的思路。你說到的情況（HttpUtils）其實是對的，我們在 Moments App 里面也有一個底層網(wǎng)絡(luò)通信模塊，在 APISession 里面。我們也可以把它獨立出來成為一個 DesignKit 這樣的組件。但是只要邏輯是結(jié)耦（目前已經(jīng)是了），物理上的分離只是水到渠成的事情。同理，路由模塊，數(shù)據(jù)存儲那些都可以獨立出來。

**澤：

老師，我自己新建了一個Moments工程， pod install以后，像這些Moments.xcodeproj/project.pbxprojMoments.xcodeproj/project.xcworkspace/contents.xcworkspacedataMoments.xcodeproj/xcuserdata/guoruize_account.xcuserdatad/xcschemes/xcschememanagement.plist這樣的文件需要忽略嗎， 還是讓git管理起來。

講師回復(fù)：

需要呀，請看看我們的 .gitignore 文件，在這里 https://github.com/lagoueduCol/iOS-linyongjian/blob/main/.gitignore#L122

**澤：

CocoaPods是通過.podspec文件 來管理依賴庫，在這個文件里配置依賴庫的依賴。不知道對不對。

講師回復(fù)：

你說得對，第三方自己也使用 .podspec 文件來指明依賴庫，可以一層層去找出所有依賴關(guān)系。

**龍：

在.podsepc文件中，有一個dependency參數(shù)來管理依賴庫的依賴我現(xiàn)在的思路是用cocopods來管理第三方，考慮第三方一般都需要自己再封裝一層，在現(xiàn)有項目中再創(chuàng)建SwiftPackage進(jìn)行封裝。

講師回復(fù)：

哦哦，我不是很明白你說的辦法，如果你想回答的是思考題的問題，我想問在 CocoaPods 里面到底是怎樣計算出依賴項之間的依賴順序，我的提示是它使用了一個算法，看看你能不能找出來哦。

**欽：

如果有一些自己搭建的私有pod ，合適在放在哪一步把私有的pod源引入呢？。

講師回復(fù)：

我們會在 第 08 講｜設(shè)計組件：DesignKit 組件橋接設(shè)計與開發(fā)規(guī)范 講述如何創(chuàng)建和使用私有 Pod。

**永：

每次思考的問題都沒有配答案的嗎

講師回復(fù)：

后面會有編程題，那些題目比較容易驗證，其他的思考題是想讓大家多思考并把想法發(fā)出來，大家相互啟發(fā)，共同學(xué)習(xí)與進(jìn)步。

**澤：

老師您好，在團(tuán)隊項目中，像Podfile文件更改，只需要一個人去做吧，比如A把依賴1的版本改了， 執(zhí)行了pod install命令， 在本地開發(fā)沒問題，推到了git， B把依賴2的版本改了， 也推到了git，是不是團(tuán)隊成員每個人拉下來代碼都需要先進(jìn)行一次pod install，以保證最新的。

講師回復(fù)：

是的呀，如果 Git 上的 Podfile 改動了，不執(zhí)行 pod install 是不能編譯項目的，所以你可以先編譯，發(fā)現(xiàn)有問題再執(zhí)行 pod install 來重新安裝 Pod。

**6158：

謝謝老師的回復(fù)，我的意思是pod 'DesignKit', :path = false這里，在我看來是指向了一個本地路徑？如果我的理解正確的話，那么是否所有設(shè)備都需要在相同的本地路徑里保存一份相關(guān)代碼？我目前只用過:git =，我的理解是:path =的區(qū)別只是一個在本地一個在git服務(wù)器上？

講師回復(fù)：

是的，path 指本地路徑，可以在代碼庫里面看到 DesignKit 在 Moments App 下的一個子目錄，位于 Frameworks 里面。當(dāng)我們 Git clone Moments 的 Repo 時就包含了 DesignKit 的源碼了。如果有需要可以把 DesignKit 變成一個獨立的 Repo，這個在 08 講會詳細(xì)講述。

**彬：

我提問：Required ruby-2.7.1 is not installed.To install do: 'rvm install "ruby-2.7.1"'只要我在終端cd 到項目文件夾目錄下，就會有這樣的提示，我明明有裝rbenv，有裝ruby 2.7.1，那這個問題怎么解決?#講師回復(fù)：請執(zhí)行一下 rbenv versions 看一下到底有沒有安裝成功，這個安裝過程需要一段時間哦。#回復(fù)講師：我查看了一下 rbenv -v 是能查看到版本">1.1.2 的。但是我看到了，我電腦上是安裝了 rvm 的，我現(xiàn)在卸載 rvm 看看，可能是 rvm 和 rbenv 的沖突

講師回復(fù)：

是的呀，RVM 會和 rbenv 沖突的呀，我們在文章里面也提到過。如果可以，請只使用 rbenv。

**彬：

post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET' config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64" end endend；；；Podfile中的這段代碼沒看懂是什么作用的。

講師回復(fù)：

可以看一下這個 commit，這段代碼用于解決一個構(gòu)建時候的 warning https://github.com/lagoueduCol/iOS-linyongjian/commit/d30b4048aec9d1bc76626e410c83f208758c54f3#diff-8f7d6adf31268a2d897ee34bd170592648d6e520aa237104395e4a4438af50cb

*鵬：

您好，使用cocoapods依賴自己的庫，是要將自己的庫放到本地統(tǒng)一管理起來，然后使用:path鏈接到本地的路徑嗎？

講師回復(fù)：

是的，我們會在第 08 講講述如何封裝自己的 Pod。使用的時候就正如你說的那樣 pod 'DesignKit', :path => './Frameworks/DesignKit', :inhibit_warnings => false

**6158：

請問內(nèi)部依賴庫是放在本地的嗎？如果是的話，是需要所有設(shè)備都保存一份本地文件嗎？

講師回復(fù)：

請問你說是這些依賴庫的源代碼文件嗎？我們只需要把 Podfile 和 Podfile.log 文件保存到 Git 服務(wù)器上，每次執(zhí)行 bundle exec pod install 都能重新下載統(tǒng)一版本的依賴庫到 Pods 文件夾里面。Pods 文件夾不需要放到 Git 服務(wù)器中。

*召：

團(tuán)隊成員的cocoapods的版本號也得保持一致

**彬：

Required ruby-2.7.1 is not installed.To install do: 'rvm install "ruby-2.7.1"'只要我在終端cd 到項目文件夾目錄下，就會有這樣的提示，我明明有裝rbenv，有裝ruby 2.7.1，那這個問題怎么解決

講師回復(fù)：

請執(zhí)行一下 rbenv versions 看一下到底有沒有安裝成功，這個安裝過程需要一段時間哦。

**9149：

pod outdated這個好

**6126：

把source從https://cdn.cocoapods.org/改成https://github.com/CocoaPods/Specs.git后執(zhí)行pod install提示 如下信息，根據(jù)提示修改還是無法解決Unable to add a source with url https://github.com/CocoaPods/Specs.git named cocoapods. You can try adding it manually in /Users/mengmengzhang/.cocoapods/repos or via pod repo add.

講師回復(fù)：

哈哈，我也沒有遇到個這個問題呀，但是臨時 Google 了一下，找到答案啦，比如 Github 里面的回復(fù) https://github.com/CocoaPods/CocoaPods/issues/9947#issuecomment-665182547 ，請試一下看看能不能幫到你。我也建議遇到問題先放狗 （Google），搞不好一下子就解決啦。

*東：

Pod 版本更新那個地方的幾個步驟不錯，有啟發(fā)