如果是做 OSX 或 iOS 下的应用开发，我相信 Xcode 是大家再熟悉不过的 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文件来实现，侵入性也不大，还是非常值得使用的。
自己动手
本篇到这里也就差不多了，那么给大家留一个小实验：
- 在一个 workspace 中建立两个 project，一个是 app，一个是 static library。
- app 新建一个 configuration 叫 inhouse。
- 要求 app 只在 inhouse 配置下链接并使用 static library。
提示：static library 项目中也需要建立一个 inhouse 的 configuration 哦，否则若依赖建立不起来。
那么，无论你自己愿不愿意动手实验，应该都可以愉快的使用 Xcode 配置项目玩耍了吧。