前言

在使用CocoaPods時，難免會混淆?pod install 和 pod update?的用法，于是在官網找到了相應的說明文章，并決定翻譯過來，供大家學習。

以下內容來自:pod install vs. pod update翻譯。

介紹

很多人使用CocoaPods時往往認為pod install只是在首次配置項目的時候使用的，而pod update是稍后更新庫的時候使用的。但是事實并非如此。

這篇文章的目的是闡述清楚什么時候使用pod install命令，什么時候使用pod update命令。

綜述：

• 使用 pod install 在你的項目中安裝新的庫，即使你已經有了 Podfile 文件并且運行過 pod install 命令，或者你已經有添加、刪除過庫。
• 使用 pod update [PODNAME] 僅僅是在你想更新庫版本的時候。

命令的詳細細節：

pod install:

• 該命令是你第一次在項目中獲取庫的時候使用，并且在每次對 Podfile 文件編輯的時候（添加、更新、刪除）使用。
• 每一次運行 pod install 命令后，都會去下載安裝新的庫，并且會修改 Podfile.lock文件中記錄的庫的版本。Podfile.lock文件只是用來追蹤和鎖定這些庫的版本。
• 運行 pod install 后，它僅僅只能解決 Podfile.lock中沒有列出來的依賴關系。
• 在 Podfile.lock中列出的那些庫，也僅僅只是去下載 Podfile.lock中指定的版本，并不會去檢查最新的版本。
• 沒有在 Podfile.lock中列出的那些庫，會去檢索 Podfile 中指定的版本，比如 pod 'myPod', '~>1.2'。

pod outdated:

• 當你使用 pod outdated 時，CocoaPods 會羅列出所有在 Podfile.lock中記錄的有新版本的庫，意思是，如果你進行了 pod update PODNAME 操作，只要這些庫符合 Podfile.lock中的版本限制（如 pod MyPod, '~>x.y'），那么它就會更新。

pod update

• 當你運行了 pod update PODNAME 命令，CocoaPods 將不會考慮 Podfile.lock中列出的版本，而直接去查找該庫的新版本。它將更新到這個庫盡可能新的版本，只要符合 Podfile 中的版本限制要求。
• 如果使用 pod update 命令不帶庫名參數，CocoaPods 將會去更新 Podfile 中每一個庫的盡可能新的版本。

正確的用法：

使用 pod update PODNAME 可以去更新一個庫的 指定版本（檢查相應的庫是否存在更新的版本，并且更新），相對應的，使用 pod install 將不會更新那些已經下載安裝了的庫。

當你在 Podfile 中添加一個新的庫時，你應該使用 pod install 命令， 而不是 pod update ，這樣安裝了新增的庫，也不會重復安裝已經存在的庫。

使用 pod update 僅僅只是去更新指定庫的版本（或者全部庫）。

提交你的Podfile.lock文件:

提醒一下，即使你一向不 commit 你的庫文件到你的共享倉庫，你也應該總是 commit & push 到你的 Podfile.lock文件中。
否則，就會破壞掉 pod install 的整個設計邏輯，造成 Podfile.lock文件無法鎖定你已經安裝的庫。

場景應用：

例1：用戶1創建了一個項目

用戶1創建了一個工程，并且想使用A、B、C這三個庫，所以他就創建了一個含有這個三個庫的Podfile文件，并且運行pod intall命令。

這樣就會安裝了A、B、C三個庫到這個工程里面，假設我們的版本都為1.0.0。

因此Podfile.lock將會跟蹤并記錄A、B、C這三個庫以及它們的版本號1.0.0。

順便說一下：因為第一次運行pod install，并且Pods.xcodeproj工程文件還不存在，所以這個命令會同時創建Pods.xcodeproj以及.xcworkspace工程文件，這只是這個命令的一個副作用，但不是主要目的。

例2：用戶1添加了一個新庫

其后，用戶1添加了一個庫D到Podfile文件中。

然后他就運行pod install命令了。因此即使庫B的開發者發布了B的一個新版本1.1.0。但只要是在第一次執行pod install之后發布的新的版本，那么B的版本使用的仍然是1.0.0。因為用戶1只是希望添加一個新庫D，不希望更新庫B。

這就是很多人容易出錯的地方，因為他們在這里使用了pod update，而不是pod install，可能是想著“我要更新一下我工程中的庫”。

例3：用戶2加入到工程中

用戶2是一個之前沒有參與到這個工程的人，稍后加入到項目中。他使用pod install命令克隆了代碼倉庫。

如果Podfile.lock被提交到git倉庫中，那么Podfile.lock的內容就會確保用戶1和用戶2會得到完全一樣的庫。

即使庫C已經有了到了1.2.0版本，用戶2使用的庫C仍然是1.0.0版本，因為庫C已經在Podfile.lock里面注冊過了，庫C的1.0.0版本已經在Podfile.lock中被鎖住了。

例4：檢查某個庫的新版本

之后，用戶1想檢查pods里面是否有可更新的庫時，他執行了 pod outdated，這個命令將會羅列出來：庫B有了新版本1.1.0，庫C有了新版本1.2.0。

用戶1決定更新庫B，但不更新庫C，所以執行pod update B，這樣就把庫B從1.0.0更新到1.1.0（同時更新Podfile.lock中相應的庫B的版本記錄），此時，庫C仍然是1.0.0版本，不會被更新到1.2.0。

在Podfile中使用明確的版本還不夠

有些人可能認為在Podfile中指定某個庫的版本已經足以保證所有項目團隊中的人都會使用完全一樣的版本，比如：pod 'A', '1.0.0' 。

然后，他們可能認為此時如果添加一個新庫的時候，我使用pod update并不會去更新其它的庫，因為其它的庫已經被限定了固定的版本號。

但事實上，在以上場景中，這不足以保證用戶1和用戶2用到的庫版本完全一樣。

一個典型的例子是，如果庫A對A2有一個依賴（比如聲明在A.podspec中：dependency 'A2', '~> 3.0'），這樣的話，在你的Podfile中使用 pod 'A', '1.0.0'將會讓用戶1和用戶2都使用同樣版本的庫A（1.0.0）。

• 但是，用戶1最后可能使用的是版本為3.4的庫A2（因為3.4是當時用戶1使用的最新版本）。

• 用戶2稍后加入到項目中，使用pod install 安裝庫，得到的庫A2版本可能是3.5（假設A2的開發者剛剛發布了A2的新版本3.5）。

這就是為什么使用Podfile.lock這一個方式來保證參與項目的每個開發者的電腦中都使用相同版本的庫，并且合理的使用pod install和 pod update。

總結

以上是生活随笔為你收集整理的iOS进阶 - pod install 与 pod update 读这一篇就够了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。