从面向对象来理解 Xcode 的项目管理

如果是做 OSX 或 iOS 下的应用开发,我相信 Xcode 是大家再熟悉不过的 IDE 了,有句话是这么说的:工欲善其事,必先利其器。那么,我觉得在整个项目开发的过程中,了解 Xcode 的项目管理思维还是非常必要的,但实际的工作过程中,我发现很多人都忽视了这块。

所以,本篇文章以大家最熟悉的面向对象思维来分析 Xcode 的项目管理方式,希望能让大家知其然,更能知其所以然,并能将其应用到自己的实际项目管理中。

抽象层级

作为一个程序员,你觉得你最擅长的应该是什么?逻辑?算法?还是数据结构?反正肯定不是烹饪。我觉得即使前面所说的你都不擅长,只要你有足够强的“抽象”能力,依然能成为一个很好的程序员。

万物都可以应用面向对象的思维将其抽象,Xcode 自然也不例外,我们这次只是从项目管理的角度来提取它的抽象,除此之外,从 UI 层级也可以提取出一套抽象,不过这并不是本篇文章所关注的重点。下面是我们所提取出来的抽象类图:

Xcode 项目管理类图

这类图相信大家一眼看上去会很熟悉,都是些我们在使用 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 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 最终可以提供这样的项目管理能力:

  1. 不同的 project 可以指定链接不同的或相同的的第三方库
  2. 不同的 target 可以指定链接不同的或相同的第三方库
  3. 不同的 target 可以指定不同的 configuration
  4. 不同的 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 配置项目玩耍了吧。

你可能感兴趣的:(从面向对象来理解 Xcode 的项目管理)