1、cocoapods的下载原理
s.source = { :git => 'git@gitlab.xxx.net:ios-thirdpartservice/xxxreact.git', :tag => '1.0.0' }
当使用Cocoapods导入私有库时，Cocoapods先是根据:git => ‘git@gitlab.xxx.net:ios-thirdpartservice/xxxreact.git’找到对应的git仓库，然后根据:tag => ‘1.0.0’定位到对应tag的提交（如果没有注明Pod依赖库版本则定位到最后一次的提交），然后在这次提交中检索后缀为.podspec的文件（文件可以随便命名）。找到podspec文件后先要验证s.name是否与Podfile中的一致，如果不一致则install时会报错：[!]Unable to find a specification for ‘React’.验证成功后，就会根据Podspec中的s.source_files找到需要导入的代码文件，并通过其他的的数据找到对应的配置文件或资源文件等。最后，将其下载到本地项目中。如果是共有库，这些原理也相同。只是共有库要将podspec文件上传到cocoapods。在导入的时候通过名字React去cocoapods匹配对应的podspec，然后根据s.source去找到对应的仓库和对应的版本，然后会再去匹配新的podspec，后边的步骤就完全相同了。
2、集成原理
当所有的依赖库都下载完后，Cocoapods会将所有的依赖库都放到另一个名为Pods的项目中，然后让主项目依赖Pods项目。这样，源码管理工作都从主目录移到了Pods项目中。Pods项目最终会编译成为一个名为libPods.a的文件，主项目只要依赖这个.a文件即可。对于资源文件，Cocoapods提供了一个名为Pods-resource.sh的bash脚本，该脚本在每次项目编译的时候都会执行，将Pods依赖库的各种资源文件复制到目标目录中。Cocoapods还通过一个名为Pods.xcconfig的文件来在编译时设置所有的依赖和参数。
libPods.a
Pods-resources.sh
Pods.xcconfig
3、版本控制原理
当执行完pod install之后，cocoapods会生成一个podfile.lock的文件。podfile.lock文件最大的用处在于多人开发。如果你没有在podfile中指定pods版本pod ‘React’，那么默认为获取当前React依赖库的最新版本。当团队中的某个人执行完pod install命令后，生产的podfile.lock文件就记录下了当时最新pods依赖库的版本，这时团队中的其他人check下来这份包含podfile.lock文件的工程以后，再去执行pod install命令时，获取下来的pods依赖库的版本和最开始用户获取到的版本一致。如果没有podfile.lock文件，后续所有用户执行pod install命令都会获取最新版本的React,这就可能造成一个团队使用的依赖库版本不一致，这对团队协作来说绝对是个灾难。在这种情况下，如果团队想使用当前最新版本的React依赖库，有两种方案：1、更改podfile，使其指向最新版本的React依赖库 2、执行pod update命令；鉴于podfile.lock文件对团队协作如此重要，所以应该加入到版本控制里面。
