基于CocoaPods的组件化原理及私有库实践

智人能在残酷的进化大战中存活下来，原因之一就是智人懂得将知识沉淀成外物，辅助彼此之间的合作，从而使得整个群体产生了规模效应，即1+1>2的效果。 从一个角度上说，石器时代是基于石器的组件化的时代，因为老张家的石矛（或其它石头利器）借给了老王，一样可以拿去狩猎。要想实现这个目的，一定要保证：

1. 石矛足够锋利。不然冒然拿着石矛去找野兽就变成了给野兽送夜宵。
2. 石矛容易使用。如果是石矛非常重或者难以抓起，也很难让人使用。

一种观点认为，信息时代是基于软件构建起来的，由工程师不断贡献智力和体力，从而产生价值的时代。产品需求就好像前文说到的猎物，完成需求类似于成功捕杀猎物，而产品逾期就好比被猎物吃掉。因此在这个时代，也需要一些可以好用且容易使用的功能代码段，方便 程序员 拿来快速实现需求，就好比远古时代的可以复用的石矛。制作这种功能代码段的过程叫做组件化，这种方法带来的产出叫做组件，俗称轮子。

上古时代的轮子

从本质上说，组件是通过库的方式来进行封装从而提供给开发者使用。而库，就是一种组织一个或多个文件的方式。在 iOS 8 之前，iOS 只支持以静态库的方式来使用第三方的代码。

静态库

静态库，在iOS中会被打包成.a文件，配合.h头文件一起可以完成功能的调用。但是在在概念上，静态库是一种All In One的设计思路，因为依赖静态库的代码会把静态库完全链接到App的可执行文件中。也就是说，静态库是在编译器被链接到App中的，因此如果多个App都引用了同一个静态库，则每个App都会把这个静态库链接一份，这其实浪费了内存。 当然，静态库的缺点不止于此。在使用静态库时，必须手动一个个链接它依赖的外部库，例如早期微信支付SDK的静态库接入方法中，必须要手动链接上:

SystemConfiguration.framework, 
libz.dylib, 
libsqlite3.0.dylib, 
libc++.dylib,
Security.framework, 
CoreTelephony.framework,
CFNetwork.framework
复制代码

有没有一种需要轮流背诵 蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭、烧雏鸡、烧子鹅、卤猪。。。 的既视感。 而且，静态库的特点导致了App每次启动时都要重新加载静态库的内存，无法控制加载时机，而且每次启动都需要重新加载静态库，导致二次加载时间无法被优化。 大部分时候，还需要在Other Linker Flags里填入 Objc -all_load 来确保静态库正常工作。 好吧，听起来静态库很难用。 我们都知道，后期iOS支持了动态库。那动态库是不是就能完美解决问题了呢？

动态库

动态库，大部分会被打包成.tbd文件或者.dylib文件。不同于静态库在编译期链接到App，动态库是在运行时链接到App的，因此它有了三个好处：

• 按需加载，什么时候需要运行什么时候加载，提高了启动app的效率
• 因为存在多个app使用同一个动态库的情况，因此一旦某个动态库被加载到内存中，下一个app使用时无需再次耗费内存加载此动态库，大家公用一个动态库。
• 因为动态库不需要参与编译过程，因此不会产生链接时符号冲突的问题。

不过，苹果对动态库的完全支持仅停留在系统的动态库上，例如UI.framework，对于第三方的动态库，还是需要embed到系统中。早期的一些热更新框架，例如JSPatch钻了漏子通过dlopen来进行热更新，不过很快被禁掉了。 不过，如果是企业证书，还是可以在自己的app里灵活的加载第三方动态库的。

Framework

在解释静态库和动态库的过程中，我并没有提framework的字眼。有些开发者觉得framework文件就是动态库，其实并不准确。 我们提到的framework，指的是.framework文件，这既不一定是静态库，也不一定是动态库。实际上这是一种打包方式，将Header（头文件）、Binary（二进制代码文件）和bundle（资源文件）一起打包，方便开发者进行接入和调用。 因此framework到底是静态库还是动态库，取决于Binary文件（Mach-O文件）到底是静态库还是动态库。

痛点

“老一辈”的iOS开发都会记得手动引入静态库时，那无止境的编译错误。我简单总结一下，如果手动引入静态库，需要：

• 将静态库和头文件引入工程
• 添加各依赖库（不同版本下可能略有不同）
• 修改Other_linker_flags，例如设置-ObjC，-fno-objc-arc等参数
• 祈祷
• 编译，如果出问题，从第一步进行检查
• 如果没有问题，未来要手动管理更新

程序员的创造力很多时候来源于“懒”，终于，CocoaPods横空出世，从此开启了一行命令行完成模块集成的时代！

CocoaPods

简介

CocoaPods是iOS平台当前最流行的包管理工具，可以将它理解为一个可以自动部署到项目的组件池，而对应的podfile文件就相当于请求组件的Request。当组件下载到工程后，cocoaPods会自动完成组件集成到现有项目的工作，并完成修改.xcodeproj文件和创建.xcworkspace文件。最终将所有组件统一打包成Pods.framework静态库，供项目使用。

在CocoaPods中，会存在以下几种文件：

• podspec Pod的描述文件，一般来说表征你的项目地址，项目使用的平台和版本等信息
• podfile 用户编写的对于期望加载的pod以及对应Target信息
• podfile.lock 记录了之前pod加载时的一些信息，包括版本、依赖、CocoaPods版本等
• mainfest.lock 记录了本地pod的基本信息，实际上是podfile.lock的拷贝 大部分开发者最熟悉的cocoaPods指令就是 pod install ，那具体在执行 pod install 时发生了什么呢？

pod install 运行原理分析

当我们运行 pod install 时，会发生：

• 分析Dependency。 对比本地pod的version和podfile.lock中的pod version，如果不一致会提示存在风险
• 对比podfile是否发生了变化。 如果存在问题，会生成两个列表，一个是需要Add的Pod(s)，一个是需要Remove的Pod(s)。
• (如果存在remove的)删除需要Remove的Pods
• 添加需要的Pod(s)。 此时，如果是常规的CocoaPods库（如果基于Git），会先去：
  • Spec下查找对应的Pod文件夹
  • 找到对应的tag
  • 定位其Podspec文件
  • git clone下来对应的文件（根据具体协议的不同，这里还可能存在以下几种方式的download：Bazaar、Mercurial、HTTP、SCP、SVN）
  • copy到Pod文件夹中
  • 运行pre-Install hook
• 生成Pod Project
  • 将该Pod中对应文件添加到工程中
  • 添加对应的framework、.a库、bundle等
  • 链接头文件（link headers），生成Target
  • 运行 post-install hook
• 生成podfile.lock，之后生成此文件的副本，将其放到Pod文件夹内，命名为manifest.lock （如果出现 The sandbox is not sync with the podfile.lock 这种错误，则表示manifest.lock和podfile.lock文件不一致），此时一般需要重新运行 pod install 命令。
• 配置原有的project文件（add build phase）

  Embed Pods Frameworks
  Copy Pod Resources
  

其中，pre-install hook和post-install hook可以理解成回调函数，是在podfile里对于install之前或者之后（生成工程但是还没写入磁盘）可以执行的逻辑，逻辑为：

pre_install do |installer| 
    # 做一些安装之前的hook
end

post_install do |installer| 
    # 做一些安装之后的hook
end
复制代码

CocoaPods第三方库下载逻辑

• 首先，CocoaPods会根据Podfile中的描述进行依赖分析，最终得出一个扁平的依赖表。 这里，CocoaPods使用了一个叫做  Milinillo  的依赖关系解决算法。简单说就是使用了回溯法来整理出所有第三方库的一个依赖列表出来，据说是CoocaPods的开发工程师原创的算法，在解决问题上应该是够用，但是貌似如果第三方库复杂的时候会有性能问题。这里美团技术团队对此有专门的优化，详情请见 美团外卖iOS多端复用的推动、支撑与思考 。
• 针对列表中的每一项，回去Spec的Repo中查看其podSpec文件，找到其地址
• 通过downloader进行对应库的下载。如果地址为git+tag，则此步骤为 git clone xxxx.git 注意，此时必须要保证需要下载的pod版本号和git仓库的tag标签号一致。

所有依赖库下载之后，便进入了和Xcode工程的融合步骤。

Xcode工程有什么变化

在cocoaPods和Xcode工程进行集成的过程中，会有有以下流程

• creat workspace 创建xcworkspace文件。其实xcworkspace文件本质上只是xcodeproject的集合，数据结构如下：

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:Demo/Demo.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
</Workspace>
复制代码

• create group 在工程中创建group文件夹，逻辑上隔离一些文件

• create pod project & add pod library 创建pod.xcodeproject工程，并且将在podfile中定义的第三方库引入到这个工程之中。

• add embed frameworks script phase 添加了[CP] Embed Pods Frameworks，相应的，多了pods_xxx的group，下列xxx.framework.sh，来完成将内部第三方库打包成.a静态库文件（在Podfile中如果选择了!use_frameworks，则此步骤会打包成.framework）

  

• remove embed frameworks script phase 如果本次podfile删除了部分第三方库，则此步骤会删除掉不需要的第三方库，将其的引用关系从Pod.xcodeproject工程中拿走。

• add copy resource script phase 如果第三方库存在资源bundle，则此步骤会将资源文件进行复制到集中的目录中，方便统一进行打包和封装。相应的，会添加[CP] Copy Pods Resources脚本。

  

• add check manifest.lock script phase 前文提到过，manifest.lock其实是podfile.lock的副本。此步骤会进行diff，如果存在不一致，则会提示著名的那句 The sandbox is not sync with the podfile.lock 错误。

• add user script phase 此步骤是对原有project工程文件进行改造。在运行过 pod install 后，再次打开原有工程会发现无法编译通过，因为已经做了改动。

  • 首先，添加了对Pod工程的依赖，具体为引用中多了libPods_xxx.a文件。此步骤的.a文件（或者.framework文件）为上述步骤中xxx.framework.sh打包出来的文件，也就是说， cocoaPods会把所有第三方的组件封装为一个.a文件（或者.framework文件）！

    

  • 建立了Pods的group，内含pods-xxx-debug.xconfig和pods-xxx.release.xconfig文件。这两个文件是对应工程的build phase的配置。相应的，主工程的Iinfo->Configurations的debug和release配置会对应上述两个配置文件。

    

  • 上述两个配置都做了什么？包括： Header_search_path，指向了Pod/Headers/public/xxx，添加了Pods文件编译后的头文件地址 Other_LDFLAGS，添加了-ObjC等等 一些Pods变了，例如Pods_BUILD_DIR等

至此，原有xcode工程和新建的Pod工程完成了集成和融合。

好了，cocoaPods的好处和原理已经介绍的差不多了。大部分时间，我们通过引用github上的组件就够用了。但是有时候处于业务需要，我们需要来实现私有Pod库。所以接下来我们来介绍下如何在公司内网来实现一个私有库，实现一个私有组件。

利用CocoaPods实现私有组件

准备工作

• 安装好XCode
• 配置好CocoaPods，并且可以pod update 以及 pod install 成功
• 已经获得CocoaPods的Repo的地址，以及对应pod的Git地址（这里以git.xxx.com上申请的repo为例）
• 涉及到的所有操作，请尽量在Terminal中进行，包括CocoaPods的相关操作（不要在CocoaPods官方客户端操作）
• 本文涉及到的Demo，可以去 git.xxx.com/XXX_SPA_XXX… 去围观

私有Spec Repo

所谓Spec Repo，就是Pods的索引。一旦在podfile中设置source为某个私有repo的git地址，在进行pod update的时候就会去这个repo中进行检索，如果检索到对应的pod，会读取该Pod的podspec从而进行安装。 一个Spec Repo的目录结构如下：

之后我们去git.xxx.com上新建一个相应的Repo地址，之后添加repo到本地，该repo地址是为了后面提交podspec使用。

# pod repo add [Private Repo Name] [GitHub HTTPS clone URL]
pod repo add XXXCocoaPodsRepo git@git.xxx.com:XXX_SPA_XXX/iOS_CocoaPods_Repo.git
复制代码

成功后可以进入 ~/.cocoapods/repos 目录下查看 XXXCocoaPodsRepo 这个目录了。

创建并Clone目标Pod地址

这里，我们以HelloXXXPod为例。 去git.xxx.com上去新建项目，之后获取地址，为：

git@git.xxx.com:XXX_SPA_XXX/HelloXXXPod.git
复制代码

此时clone到本地，命令为：

git clone git@git.xxx.com:XXX_SPA_XXX/HelloXXXPod.git
复制代码

创建Pod项目工程文件（源码方式）

这里建议通过CocoPods的官方命令来进行Pod项目的创建，以测试项目HelloXXXPod为例，命令如下：

pod lib create HelloXXXPod
复制代码

不出意外地话，会提问你六个问题（cocoaPods v1.5.3版本）：

1.What platform do you want to use? [ iOS / macOS ]

2.What language do you want to use? [ Swift / ObjC ]

3.Would you like to include a demo application with your library? [ Yes / No ]

4.Which testing frameworks will you use? [ Specta / Kiwi / None ]

5.Would you like to do view based testing? [ Yes / No ]

6.What is your class prefix?
复制代码

分别解释一下

• What platform do you want to use?? [ iOS / macOS ] 问组件化应用在哪个平台上，一般我们选iOS

• What language do you want to use? [ Swift / ObjC ] 使用何种语言，可以根据项目是OC还是Swift自行选择

• Would you like to include a demo application with your library? [ Yes / No ] 问是否需要一个Demo工程，方便调试Pod。如果是第一次做组件化，建议选Yes，方便pod的调试

• Which testing frameworks will you use? [ Specta / Kiwi / None ] 问是否需要UT测试框架，可选择Specta和Kiwi，或者选择不要。

• Specta是OC的一个轻量级TDD/BDD框架，参考 github/specta

• Kiwi是一个iOS的一个BDD框架，可以简单地部署和使用。 github/kiwi UT测试框架如果要选择的话，建议选择Kiwi，可以参考我之前写的调研kiwi上手体验 本次的Demo，暂时选None

• Would you like to do view based testing? [ Yes / No ] 如果上一步选择了Specta ，这步会生成一部分有利于做自动化测试的逻辑和代码

• What is your class prefix? 这里可以指定你的项目前缀，这样在new一个类时会自动加上前缀

之后我们运行 pod install ,生成的文件目录树结构如下：

$ tree HelloXXXPod -L 2

HelloXXXPod
├── Example
│   ├── Build
│   ├── Podfile
│   ├── Podfile.lock
│   ├── Pods
│   ├── Tests
│   ├── helloXXXPod
│   ├── helloXXXPod.xcodeproj
│   └── helloXXXPod.xcworkspace
├── LICENSE
├── README.md
├── _Pods.xcodeproj -> Example/Pods/Pods.xcodeproj
├── helloXXXPod
│   ├── Assets
│   └── Classes
└── helloXXXPod.podspec
复制代码

开发

这时候可以在刚才生成的Example工程内做开发，这时候记得把新建的代码放到Classes目录下。如果有图片资源，建议放到Assets下。

开发、调试完成之后，就可以去编辑podspec文件了。按以下方式来修改，不明白的字段请参考官方文档：

这里给出本次Demo的podspec供各位参考：

Pod::Spec.new do |s|
  s.name             = 'helloXXXPod'
  s.version          = '0.1.0'
  s.summary          = 'A short description of helloXXXPod.'
  s.description      = <<-DESC
TODO: Add long description of the pod here.
                       DESC

  s.homepage         = 'https://git.xxx.com/XXX_SPA_XXX/HelloXXXPod'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { 'nimomeng' => 'nimomeng@tencent.com' }
  s.source           = { :git => 'git@git.xxx.com:XXX_SPA_XXX/HelloXXXPod.git', :tag => s.version.to_s }

  s.ios.deployment_target = '8.0'
  s.source_files = 'helloXXXPod/Classes/**/*'
end

复制代码

其中，注意修改这几个字段：

• s.name
• s.homepage
• s.source (非常重要)
• s.source_files (如果不放在Classes下，记得在这里指定文件目录)

本地调试

如果是通过 pod lib create 命令创建的Pod，会在Example中自动配置好该pod的本地调试脚本，如下：

use_frameworks!

platform :ios, '8.0'

target 'helloXXXPod_Example' do
  pod 'helloXXXPod' :path => '../'

  target 'helloXXXPod_Tests' do
    inherit! :search_paths

    
  end
end
复制代码

其中， pod 'helloXXXPod' :path => '../' 的含义是说，在上层目录来下载 helloXXXPod 这个pod。这是本地调试Pod的一种。 同样的，可以实现类似方式调试的方法，还有通过 :podspec 命令来指定，指定pod所在的podspec文件位置即可

其中，path语法精确到目录即可；podspec语法必须要精确到文件。

设置好podfile之后，在Example文件下执行 pod install ，则可以发现新的文件已经出现在项目工程的pods文件夹之下了。

注意，通过 path 语法进行更新后，Pod中代码并不在Pod文件夹中，而是在一个叫 Development Pods 中。

开发完成，需要本地验证podspec，确保其有效：

pod lib lint helloXXXPod.podspec
复制代码

同步到Git上

之后要做的就是把库同步到Git上去了。这时候需要去git.xxx.com上建立一个对应的仓库，例如：

http://git.xxx.com/XXX_SPA_XXX/HelloXXXPod.git （替换为自己的实际git地址）
复制代码

然后将代码同步到此Git上。

git add .

git commit -m "Init"

git remote add origin http://git.xxx.com/XXX_SPA_XXX/HelloXXXPod.git（替换为自己的实际git地址）

git push --set-upstream origin master

复制代码

podSpec文件需要版本控制信息，所以我们要打一个Tag.

git tag -m "first demo" 0.1.0

git push --tags
复制代码

向Spec Repo提交podspec

在执行本歩之前，确保最新代码已经提交到了Git上，且已经打好了tag.

向Spec Repo提交podspec的命令：

pod repo push XXXCocoaPodsRepo HelloXXXPod.podspec --allow-warnings
复制代码

在经过三轮的用户校验之后，提交成功！这时候我们去 ~/.cocoapods/repos/XXXCocoaPodsRepo 中查看，我们的的podspec已经在里面了！

此时通过 pod search HelloXXXPod 已经可以查到了！

最后，为了保证本地的repo已经被更新，运行 pod update 来更新repo

如何在外部项目中使用

我们可以在想要使用的项目中的Podfile里加入如下代码：

pod 'helloXXXPod'
复制代码

即可。 当然，由于我们的是私有CocoaPods库，因此最好告诉系统这个库的source在哪里，因此在Podfile文件上部也请加上Spec Repo的git地址。同时，为了确保公共的cocoaPod可以被正常下载，请添加外部CocoaPod的库：

# For inner pods
source 'git@git.xxx.com:XXX_SPA_XXX/iOS_CocoaPods_Repo.git'

# For public pods
source 'https://github.com/CocoaPods/Specs.git'

复制代码

整个的Podfile文件看起来是这样的：

use_frameworks!

platform :ios, '8.0'

# source 'git@git.xxx.com:XXX_SPA_XXX/iOS_CocoaPods_Repo.git'

# For public pods
source 'https://github.com/CocoaPods/Specs.git'

target 'helloXXXPod_Example' do
  pod 'helloXXXPod'

  target 'helloXXXPod_Tests' do
    inherit! :search_paths
	
  end
end

复制代码

之后运行 pod install 即可安装对应的Pods

验证

我们可以复用Example项目，只不过这次不再通过 :path 命令或者 :podspec 命令来做本地调用，而是完全使用安装外部pod的方式，即：

pod 'helloXXXPod'
复制代码

注意：虽然pod已经推送到线上，但是本地一定要先更新pod的repo，不然还是无法找到最新的pod。确保先做 pod update 操作。

Example项目中，我们调用在Pod中写好的方法，查看是否输入对应的log即可验证：

至此，Pod创建完成。