cocoaPods管理之后工程结构变化

CocoaPods是IOS项目的依赖管理工具，类似于Android的gradle，不过gradle不仅有依赖管理功能，还能负责构建。CocoaPods只负责管理项目对第三方库的依赖，下面我们主要介绍一下一个项目在使用cocoaPods管理依赖之后，项目前后的变化

文件结构变化

我们介绍一下新增的文件

podfile

依赖target或者xcode项目的依赖的文件，它的书写需要特定的语法，请参考官网

podfile.lock

记录项目依赖的库的版本，是pod install 的命令操作的文件

xxx.xcworkspace

项目的工作区，使用CocoaPod管理依赖的项目，本质上是一个文件夹，里面保存了一个名为contents.xcworkspacedata的文件，该文件记录了工作区中项目的的路径

pod目录：

Pods.xcodeproj：Pods工程,第三方库都由Pods工程构件，

AFNetworking：项目依赖的第三方库，podfile里面记录的项目的每一个依赖库都会生成一个对应的文件目录

Header：

• private：第三方库的私有头文件
• public：第三方库的公有头文件

Manifest.lock：描述当前版本的第三方库对其它库的依赖

Target Support Files：支撑target的文件，我们看一下该目录下
（1）AFNetworking目录中内容

 - AFNetworking：第三方库目录，也就是podfile里面记录的项目的每一个依赖库都会在这里生成一个对应的文件目录
 - AFNetworking-prefix.pch：pch文件，用来处理公用头文件，可以优化文件的编译速度
 - AFNetworking-dummy.m
 - debug.xcconfig和release.xcconfig：用于工程配置   -
1
2
3
4

（2）Pods-test

 - Pods-test-acknowledgements.markdown：第三方库的声明文件，类似readme文件

 - Pods-test-acknowledgements.plist：第三方库重要信息的plist形式的说明

 - Pods-test-dummy.m

 - Pods-test.debug.xcconfig

 - Pods-test.release.xcconfig
1
2
3
4
5
6
7
8
9

工程结构变化

工程上，在原有的test project基础上新增了一个名为Pods的project，该projct的工程结构如图所示。

我们先看左面工程组织形式，我们可以将工程的组织和上面的文件组织做对比，发现并不一致，xcode上面看到的文件目录并不是实际意义上的物理目录，我们将xcode里面的目录称为Gruop（一般将有关系的文件或者同一个业务组的文件放在同一个Gruop中）。下面我们分别看一下主工程的变化和新增的Pod工程结构。

主工程的变化

主工程的变化是在Configuration的设置，引入Pods之前主工程test的Configuration中Debug和Release下面没有configuration，如图所示

引入pod之后，主工程的Configuration分别在Debug和Release模式下给主工程配置了xcconfig文件。

我们简单看一下Pods-test.debug文件内容

GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
HEADER_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Headers/Public" "${PODS_ROOT}/Headers/Public/AFNetworking"
LIBRARY_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/AFNetworking"
OTHER_LDFLAGS = $(inherited) -ObjC -l"AFNetworking" -framework "CoreGraphics" -framework "MobileCoreServices" -framework "Security" -framework "SystemConfiguration"
PODS_BUILD_DIR = ${BUILD_DIR}
PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_PODFILE_DIR_PATH = ${SRCROOT}/.
PODS_ROOT = ${SRCROOT}/Pods
USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES = YES
1
2
3
4
5
6
7
8
9

该文件中设置了下面的编译选项，这些编译选项在BuildSetting中都有对应的条目

• GCC_PREPROCESSOR_DEFINITIONS
• HEADER_SEARCH_PATHS
• LIBRARY_SEARCH_PATHS
• OTHER_LDFLAGS
• 用户自定义的几项编译选项，包括PODS_BUILD_DIR、PODS_CONFIGURATION_BUILD_DIR、PODS_PODFILE_DIR_PATH、PODS_ROOT和USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES。

新增的Pod工程

我们先依次介绍一下左边的工程结构

• Podfile：表示工程里面跟目录的Podfile文件，表示使用cocoapods管理项目，并且记录的依赖库

• Frameworks：表示项目需要链接的framework，这是xcode里面虚拟的gruop，在项目里没有对应的物理文件目录

• Pods：根据Podfile安装依赖库之后，每个第三方库都会在这个Gruop中有对应的目录，对应项目目录中Pods/AFNetworking/AFNetworking目录下的内容

• Products：该Gruop存放项目及依赖的第三方库的静态库，例如本示例中

  • libAFNetworking.a ：AFNetworking target将生成的静态库
  • libPods-CardPlayer.a ：Pods-CardPlayer target将生成的静态库

• Targets Support Files：target的支持文件，对应项目目录中Pods/Target Support Files/Pods-test目录下的内容