CocoaPods到底做了什么

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/fly1183989782/article/details/80720467

CocoaPods到底做了什么

    CocoaPods 到底做了什么,还是需要了解一下,否则构建出了问题,根本无从下手解决。查了一些文档,创建了 Demo ,用 Git 看 CocoaPods 到底新增、修改了哪些文件,总结一下。

    首先 CocoaPods 设计出来是要解决两个问题,一是 library 的管理问题,二是 library 的发现问题。作为依赖管理工具,可以让我们更快更方便的用轮子。在黑盒里面,CocoaPods 做的事情也不复杂,利用脚本自动化的创建了依赖关系、构建参数。用的依赖机制、构建框架都是 Xcode 已有的能力,CocoaPods 利用了这些机制并进行了相应的配置,来完成自己的目的。一个很重要的机制是 Target,所以先来聊聊 Target。

    Target 是用于构建某个产物的一套配置和流程。产物可以是测试版本的应用,可以是 Framework,可以是很多东西。构建配置包括需要编译的源码(这也是源码都有 Target MemberShip)、编译链接参数(arc、c++等)等。所以一个 Project 可以 Build 出不同的产物。Target 还可以依赖 Target,来生成更复杂的产物。

    至于CocoaPods 做了什么,举个例子,工程 A 使用 CocoaPods 实现对 B、C 两个库的依赖调用。在初次 Pod install 执行的时候,CocoaPods 会

1.创建一个 Pods Project
2.为 B 、 C 分别创建各自的 Target, Target 会根据 B 、C 的 podspec 来自动生成,包括编译链接参数,产物是 B、C 的 Library 或 Framework
3.创建一个 Pods-A 的 Target,这个 Target 是用来包 B 、 C 的,它会依赖 B、C Target(Target Dependency),产出 Pods-A 的 Libary 或 Framework,里面包含了 B 、 C 的 Library 或 Framework。
4.修改 A 工程的工程文件,Link Binary With Pods-A.a 或者 Pods-A.framework,然后就可以使用 B、C 库当中的能力

    Target Dependency、Link Binary With Library 都能添加依赖。Target Dependency 在主 Target Build 的时候一定会 Build,Linked Library 不一定会,受 Find Implicit Dependencies 设置的影响,可以不勾选来提升构建速度。(选项在 Product Edit Scheme - Build)。

参考:

猜你喜欢

转载自blog.csdn.net/fly1183989782/article/details/80720467