如何輕鬆理解Xcode 專案管理

標籤：

如果是做 OSX 或 iOS 下的應用開發，我相信 Xcode開發工具http://www.maiziedu.com/course/234/是大家再熟悉不過的 IDE 了，有句話是這麼說的：工欲善其事，必先利其器。那麼，我覺得在整個項目開發的過程中，瞭解 Xcode 的專案管理思維還是非常必要的，但實際的工作過程中，我發現很多人都忽視了這塊。

所以，本篇文章以大家最熟悉的物件導向思維來分析 Xcode 的專案管理方式，希望能讓大家知其然，更能知其所以然，並能將其應用到自己的實際專案管理中。

 

抽象層級

作為一個程式員，你覺得你最擅長的應該是什嗎？邏輯？演算法？還是資料結構？反正肯定不是烹飪。我覺得即使前面所說的你都不擅長，只要你有足夠強的“抽象”能力，依然能成為一個很好的程式員。

萬物都可以應用物件導向的思維將其抽象，Xcode 自然也不例外，我們這次只是從專案管理的角度來提取它的抽象，除此之外，從 UI 層級也可以提取出一套抽象，不過這並不是本篇文章所關注的重點。下面是我們所提取出來的抽象類別圖：

這類圖相信大家一眼看上去會很熟悉，都是些我們在使用 Xcode 時經常碰到的名詞，上面只是將它們的關係理了下。既然我們將其提取成了類，那麼每個類都應該有它的職責，下面便是它們的職責劃分：

Workspace

這是最頂層的類，可以設計成單例，因為整個 Xcode 的生命週期中，只會有一個。workspace，顧名思義是工作空間，內部彙總了多個 project，用於管理 project 與 project 之間的依賴關係。

 

Project

單個項目，作為一個項目，它擁有一定的獨立性，比如兩個 app 項目可以放置在一個 workspace 中。project 主要是項目層級的抽象，劃分的臨界點是複用層級，project 和 project 一般是無法複用到源碼檔案層次的。

 

Configuration

每個 project 可以對應多個 configuration，也就是配置資訊，這些配置資訊用於編譯器的預先處理、編譯、連結等過程中使用。

 

Scheme

每個 project 也可以對應多個 scheme，與 configuration 所關注點不同，scheme 關注的是 project 在最終編譯、運行、測試、歸檔等環節的一些選項配置資訊，它可以決定在每個環節使用什麼 configuration。

 

Target

每個 project 還可以有個多個 target，並且至少有一個 target。target 代表一個項目的最終輸出，它繼承了 project 的配置資訊。target 與 target 間的聯絡比起 project 與 project 之間要更加緊密，劃分的臨界點也是複用層級，target 與 target 是可以複用到單個源碼檔案的。

在實際的操作過程中，我們常常需要明確的界定什麼時候建立 project，什麼時候建立 target，因為大部分時候，它們還是比較類似的。不過，多考慮下 target 的職責，考慮它是繼承了 project，考慮它的複用層級，應該還是可以劃分清楚的。

 

依賴管理

上面介紹了 Xcode 專案管理方面的抽象，接下來我們看看 Xcode 對它們之間依賴關係的管理。這裡我覺得有兩種依賴： 強依賴 、 弱依賴 。強依賴是指 target 與 target 之間的依賴，弱依賴是指 project 與 project 之間的依賴（ 哈哈，我又創造了兩個名詞）。在項目配置介面中，選擇一個項目中的 target，再選擇 Build Phases ，我們可以看到下面這樣的介面：

有兩個紅色的箭頭特別醒目，第一個箭頭指向的 Target Dependencies ，便是我所說的強依賴，這裡可以選定一個 target 作為當前 target 的依賴項，這可以保證所依賴的 target 一定是在當前 target 之前編譯。

那麼弱依賴是什麼呢？你猜的沒錯，就是第二個紅色箭頭所指的地方： Link Binary With Libraries ，這裡我們可以選擇到其它 project 中的靜態庫或 framework，當然這也是前提。當我們選擇了其它 project 中的 target，這就建立起了弱引用，Xcode 會保證另一個 project 中的 target 在當前 target 之前編譯。

依賴有什麼用？依賴在你將項目按照層次劃分分別維護時就會非常有用，比如資料訪問層庫、邏輯層庫、公用輔助庫、最終應用。它們之間的編譯順序可能需要非常明確的，這就需要關注依賴了。

 

Cocoa Pods 的運作原理

稍微大點的項目，或者我們想要方便的使用第三方開源庫時，可能都會選擇 cocoapods，有了上面基礎知識的鋪墊，再來看看 cocoapods 的運作原理就不那麼複雜了。

首先 cocoapods 在 workspace 中建立立了一個 project 叫 Pods ，每當我們引入一個第三方庫，這個 project 中就會多出一個 target，類型為靜態庫。這個 project 中有一個固定的 target 叫 Pods ，類型也是靜態庫，這個可以看做是 Pods 這個 project 的預設 target，它強依賴了所有其他 target，但它並不會連結其它 target，為了使這個 target 能夠正常編譯，它內部只有一個空的類實現： Pods-dummy 。

所以，如果想要編譯 Pods 這個 target，會預先編譯其它所有 target，也就是我們真正需要使用的第三方庫。

除了建立了一個項目，cocoapods，還將一系列的配置資訊，也就是 configuraion 寫入了不同的 .xcconfig 檔案中，主體項目中，每個 configuration 都會對應一個這樣的檔案。然後，我們在 Podfile 中指定的 target（ 主應用 ）會弱依賴 Pods 這個 target，也就是會連結一個叫 libPods.a 的檔案。前面說過了，這個靜態庫內部其實只有一個 Pods-dummy 的類，它只是作為一個跳板，讓我們主體項目依賴的第三方庫能在主體項目前編譯，真正使用第三方庫的地方寫在了 .xcconfig 檔案中，也就是OTHER_LDFLAGS 這個關鍵的配置資訊。

上面介紹了 cocoapods 的核心運作原理，還有些細節也都是建立在這樣的模式之下的，就不作過多詳細解釋了。所以，cocoapods 最終可以提供這樣的專案管理能力：

不同的 project 可以指定連結不同的或相同的的第三方庫

不同的 target 可以指定連結不同的或相同的第三方庫

不同的 target 可以指定不同的 configuration

不同的 configuration（ Debug，Release，Custom ）可以指定連結不同的或相同的第三方庫

從專案管理的角度來說，cocoapods 還是很不錯的將 Xcode 專案管理的靈活性都保留了下來，並且大多都是通過 .xcconfig 檔案來實現，侵入性也不大，還是非常值得使用的。

 

自己動手

本篇到這裡也就差不多了，那麼給大家留一個小實驗：

1.在一個 workspace 中建立兩個 project，一個是 app，一個是 static library。

2.app 建立一個 configuration 叫 inhouse。

3.要求 app 只在 inhouse 配置下連結並使用 static library。

提示：static library 項目中也需要建立一個 inhouse 的 configuration 哦，否則若依賴建立不起來。

那麼，無論你自己願不願意動手實驗，應該都可以愉快的使用 Xcode 設定項目玩耍了吧。

 

 

原文來自：Sun.Makee

如何輕鬆理解Xcode 專案管理