CocoaPods 都做了什么？
chizongmin
8年前
<p>稍有 iOS 开发经验的人应该都是用过 CocoaPods，而对于 CI、CD 有了解的同学也都知道 Fastlane。而这两个在 iOS 开发中非常便捷的第三方库都是使用 Ruby 来编写的，这是为什么？</p> <p>先抛开这个话题不谈，我们来看一下 CocoaPods 和 Fastlane 是如何使用的，首先是 CocoaPods，在每一个工程使用 CocoaPods 的工程中都有一个 Podfile：</p> <pre> <code class="language-objectivec">source 'https://github.com/CocoaPods/Specs.git' target 'Demo' do pod 'Mantle', '~> 1.5.1' pod 'SDWebImage', '~> 3.7.1' pod 'BlocksKit', '~> 2.2.5' pod 'SSKeychain', '~> 1.2.3' pod 'UMengAnalytics', '~> 3.1.8' pod 'UMengFeedback', '~> 1.4.2' pod 'Masonry', '~> 0.5.3' pod 'AFNetworking', '~> 2.4.1' pod 'Aspects', '~> 1.4.1' end</code></pre> <p>这是一个使用 Podfile 定义依赖的一个例子，不过 Podfile 对约束的描述其实是这样的：</p> <pre> <code class="language-objectivec">source('https://github.com/CocoaPods/Specs.git') target('Demo') do pod('Mantle', '~> 1.5.1') ... end</code></pre> <p>Ruby 代码在调用方法时可以省略括号。</p> <p>Podfile 中对于约束的描述，其实都可以看作是对代码简写，上面的代码在解析时可以当做 Ruby 代码来执行。</p> <p>Fastlane 中的代码 Fastfile 也是类似的：</p> <pre> <code class="language-objectivec">lane :beta do increment_build_number cocoapods match testflight sh "./customScript.sh" slack end</code></pre> <p>使用描述性的”代码“编写脚本，如果没有接触或者使用过 Ruby 的人很难相信上面的这些文本是代码的。</p> <h2><strong>Ruby 概述</strong></h2> <p>在介绍 CocoaPods 的实现之前，我们需要对 Ruby 的一些特性有一个简单的了解，在向身边的朋友“传教”的时候，我往往都会用优雅这个词来形容这门语言</p> <p>除了优雅之外，Ruby 的语法具有强大的表现力，并且其使用非常灵活，能快速实现我们的需求，这里简单介绍一下 Ruby 中的一些特性。</p> <h3><strong>一切皆对象</strong></h3> <p>在许多语言，比如 Java 中，数字与其他的基本类型都不是对象，而在 Ruby 中所有的元素，包括基本类型都是对象，同时也不存在运算符的概念，所谓的 1 + 1 ，其实只是 1.+(1) 的语法糖而已。</p> <p>得益于一切皆对象的概念，在 Ruby 中，你可以向任意的对象发送 methods 消息，在运行时自省，所以笔者在每次忘记方法时，都会直接用 methods 来“查文档”：</p> <pre> <code class="language-objectivec">2.3.1 :003 > 1.methods => [:%, :&, :*, :+, :-, :/, :<, :>, :^, :|, :~, :-@, :**, :<=>, :<<, :>>, :<=, :>=, :==, :===, :[], :inspect, :size, :succ, :to_s, :to_f, :div, :divmod, :fdiv, :modulo, :abs, :magnitude, :zero?, :odd?, :even?, :bit_length, :to_int, :to_i, :next, :upto, :chr, :ord, :integer?, :floor, :ceil, :round, :truncate, :downto, :times, :pred, :to_r, :numerator, :denominator, :rationalize, :gcd, :lcm, :gcdlcm, :+@, :eql?, :singleton_method_added, :coerce, :i, :remainder, :real?, :nonzero?, :step, :positive?, :negative?, :quo, :arg, :rectangular, :rect, :polar, :real, :imaginary, :imag, :abs2, :angle, :phase, :conjugate, :conj, :to_c, :between?, :instance_of?, :public_send, :instance_variable_get, :instance_variable_set, :instance_variable_defined?, :remove_instance_variable, :private_methods, :kind_of?, :instance_variables, :tap, :is_a?, :extend, :define_singleton_method, :to_enum, :enum_for, :=~, :!~, :respond_to?, :freeze, :display, :send, :object_id, :method, :public_method, :singleton_method, :nil?, :hash, :class, :singleton_class, :clone, :dup, :itself, :taint, :tainted?, :untaint, :untrust, :trust, :untrusted?, :methods, :protected_methods, :frozen?, :public_methods, :singleton_methods, :!, :!=, :__send__, :equal?, :instance_eval, :instance_exec, :__id__]</code></pre> <p>比如在这里向对象 1 调用 methods 就会返回它能响应的所有方法。</p> <p>一切皆对象不仅减少了语言中类型的不一致，消灭了基本数据类型与对象之间的边界；这一概念同时也简化了语言中的组成元素，这样 Ruby 中只有对象和方法，这两个概念，这也降低了我们理解这门语言的复杂度：</p> <ul> <li> <p>使用对象存储状态</p> </li> <li> <p>对象之间通过方法通信</p> </li> </ul> <h3><strong>block</strong></h3> <p>Ruby 对函数式编程范式的支持是通过 block，这里的 block 和 Objective-C 中的 block 有些不同。</p> <p>首先 Ruby 中的 block 也是一种对象，所有的 Block 都是 Proc 类的实例，也就是所有的 block 都是 first-class 的，可以作为参数传递，返回。</p> <pre> <code class="language-objectivec">def twice(&proc) 2.times { proc.call() } if proc end def twice 2.times { yield } if block_given? end</code></pre> <p>yield 会调用外部传入的 block， block_given? 用于判断当前方法是否传入了 block 。</p> <p>在这个方法调用时，是这样的：</p> <pre> <code class="language-objectivec">twice do puts "Hello" end</code></pre> <h3>eval</h3> <p>最后一个需要介绍的特性就是 eval 了，早在几十年前的 Lisp 语言就有了 eval 这个方法，这个方法会将字符串当做代码来执行，也就是说 eval 模糊了代码与数据之间的边界。</p> <pre> <code class="language-objectivec">> eval "1 + 2 * 3" => 7</code></pre> <p>有了 eval 方法，我们就获得了更加强大的动态能力，在运行时，使用字符串来改变控制流程，控制程序的输入、输出；而不需要去手动去解析输入、生成语法树等过程。</p> <h3><strong>手动解析 Podfile</strong></h3> <p>在我们对 Ruby 这门语言有了一个简单的了解之后，就可以开始写一个简易的解析 Podfile 的脚本了。</p> <p>在这里，我们以一个非常简单的 Podfile 为例，使用 Ruby 脚本解析 Podfile 中指定的依赖：</p> <pre> <code class="language-objectivec">source 'http://source.git' platform :ios, '8.0' target 'Demo' do pod 'AFNetworking' pod 'SDWebImage' pod 'Masonry' pod "Typeset" pod 'BlocksKit' pod 'Mantle' pod 'IQKeyboardManager' pod 'IQDropDownTextField' end</code></pre> <p>因为这里的 source 、 platform 、 target 以及 pod 都是方法，所以在这里我们需要构建一个包含上述方法的上下文：</p> <pre> <code class="language-objectivec"># eval_pod.rb $hash_value = {} def source(url) end def target(target) end def platform(platform, version) end def pod(pod) end</code></pre> <p>使用一个全局变量 hash_value 存储 Podfile 中指定的依赖，并且构建了一个 Podfile 解析脚本的骨架；我们先不去完善这些方法的实现细节，先尝试一下读取 Podfile 中的内容并执行会不会有什么问题。</p> <p>在 eval_pod.rb 文件的最下面加入这几行代码：</p> <pre> <code class="language-objectivec">content = File.read './Podfile' eval content p $hash_value</code></pre> <p>这里读取了 Podfile 文件中的内容，并把其中的内容当做字符串执行，最后打印 hash_value 的值。</p> <pre> <code class="language-objectivec">$ ruby eval_pod.rb</code></pre> <p>运行这段 Ruby 代码虽然并没有什么输出，但是并没有报出任何的错误，接下来我们就可以完善这些方法了：</p> <pre> <code class="language-objectivec">def source(url) $hash_value['source'] = url end def target(target) targets = $hash_value['targets'] targets = [] if targets == nil targets << target $hash_value['targets'] = targets yield if block_given? end def platform(platform, version) end def pod(pod) pods = $hash_value['pods'] pods = [] if pods == nil pods << pod $hash_value['pods'] = pods end</code></pre> <p>在添加了这些方法的实现之后，再次运行脚本就会得到 Podfile 中的依赖信息了，不过这里的实现非常简单的，很多情况都没有处理：</p> <pre> <code class="language-objectivec">$ ruby eval_pod.rb {"source"=>"http://source.git", "targets"=>["Demo"], "pods"=>["AFNetworking", "SDWebImage", "Masonry", "Typeset", "BlocksKit", "Mantle", "IQKeyboardManager", "IQDropDownTextField"]}</code></pre> <p>CocoaPods 中对于 Podfile 的解析与这里的实现其实差不多，接下来就进入了 CocoaPods 的实现部分了。</p> <h2><strong>CocoaPods 的实现</strong></h2> <p>在上面简单介绍了 Ruby 的一些语法以及如何解析 Podfile 之后，我们开始深入了解一下 CocoaPods 是如何管理 iOS 项目的依赖，也就是 pod install 到底做了些什么。</p> <h3><strong>Pod install 的过程</strong></h3> <p>pod install 这个命令到底做了什么？首先，在 CocoaPods 中，所有的命令都会由 Command 类派发到将对应的类，而真正执行 pod install 的类就是 Install ：</p> <pre> <code class="language-objectivec">module Pod class Command class Install < Command def run verify_podfile_exists! installer = installer_for_config installer.repo_update = repo_update?(:default => false) installer.update = false installer.install! end end end end</code></pre> <p>这里面会从配置类的实例 config 中获取一个 Installer 的实例，然后执行 install! 方法，这里的 installer 有一个 update 属性，而这也就是 pod install 和 update 之间最大的区别， 其中后者会无视已有的 Podfile.lock 文件，重新对依赖进行分析 ：</p> <pre> <code class="language-objectivec">module Pod class Command class Update < Command def run ... installer = installer_for_config installer.repo_update = repo_update?(:default => true) installer.update = true installer.install! end end end end</code></pre> <h3><strong>Podfile 的解析</strong></h3> <p>Podfile 中依赖的解析其实是与我们在手动解析 Podfile 章节所介绍的差不多，整个过程主要都是由 <strong>CocoaPods-Core</strong> 这个模块来完成的，而这个过程早在 installer_for_config 中就已经开始了：</p> <pre> <code class="language-objectivec">def installer_for_config Installer.new(config.sandbox, config.podfile, config.lockfile) end</code></pre> <p>这个方法会从 config.podfile 中取出一个 Podfile 类的实例：</p> <pre> <code class="language-objectivec">def podfile @podfile ||= Podfile.from_file(podfile_path) if podfile_path end</code></pre> <p>类方法 Podfile.from_file 就定义在 CocoaPods-Core 这个库中，用于分析 Podfile 中定义的依赖，这个方法会根据 Podfile 不同的类型选择不同的调用路径：</p> <pre> <code class="language-objectivec">Podfile.from_file `-- Podfile.from_ruby |-- File.open `-- eval</code></pre> <p>from_ruby 类方法就会像我们在前面做的解析 Podfile 的方法一样，从文件中读取数据，然后使用 eval 直接将文件中的内容当做 Ruby 代码来执行。</p> <pre> <code class="language-objectivec">def self.from_ruby(path, contents = nil) contents ||= File.open(path, 'r:utf-8', &:read) podfile = Podfile.new(path) do begin eval(contents, nil, path.to_s) rescue Exception => e message = "Invalid `#{path.basename}` file: #{e.message}" raise DSLError.new(message, path, e, contents) end end podfile end</code></pre> <p>在 Podfile 这个类的顶部，我们使用 Ruby 的 Mixin 的语法来混入 Podfile 中代码执行所需要的上下文：</p> <pre> <code class="language-objectivec">include Pod::Podfile::DSL</code></pre> <p>Podfile 中的所有你见到的方法都是定义在 DSL 这个模块下面的：</p> <pre> <code class="language-objectivec">module Pod class Podfile module DSL def pod(name = nil, *requirements) end def target(name, options = nil) end def platform(name, target = nil) end def inhibit_all_warnings! end def use_frameworks!(flag = true) end def source(source) end ... end end end</code></pre> <p>这里定义了很多 Podfile 中使用的方法，当使用 eval 执行文件中的代码时，就会执行这个模块里的方法，在这里简单看一下其中几个方法的实现，比如说 source 方法：</p> <pre> <code class="language-objectivec">def source(source) hash_sources = get_hash_value('sources') || [] hash_sources << source set_hash_value('sources', hash_sources.uniq) end</code></pre> <p>该方法会将新的 source 加入已有的源数组中，然后更新原有的 sources 对应的值。</p> <p>稍微复杂一些的是 target 方法：</p> <pre> <code class="language-objectivec">def target(name, options = nil) if options raise Informative, "Unsupported options `#{options}` for " \ "target `#{name}`." end parent = current_target_definition definition = TargetDefinition.new(name, parent) self.current_target_definition = definition yield if block_given? ensure self.current_target_definition = parent end</code></pre> <p>这个方法会创建一个 TargetDefinition 类的实例，然后将当前环境系的 target_definition 设置成这个刚刚创建的实例。这样，之后使用 pod 定义的依赖都会填充到当前的 TargetDefinition 中：</p> <pre> <code class="language-objectivec">def pod(name = nil, *requirements) unless name raise StandardError, 'A dependency requires a name.' end current_target_definition.store_pod(name, *requirements) end</code></pre> <p>当 pod 方法被调用时，会执行 store_pod 将依赖存储到当前 target 中的 dependencies 数组中：</p> <pre> <code class="language-objectivec">def store_pod(name, *requirements) return if parse_subspecs(name, requirements) parse_inhibit_warnings(name, requirements) parse_configuration_whitelist(name, requirements) if requirements && !requirements.empty? pod = { name => requirements } else pod = name end get_hash_value('dependencies', []) << pod nil end</code></pre> <p>总结一下，CocoaPods 对 Podfile 的解析与我们在前面做的手动解析 Podfile 的原理差不多，构建一个包含一些方法的上下文，然后直接执行 eval 方法将文件的内容当做代码来执行，这样只要 Podfile 中的数据是符合规范的，那么解析 Podfile 就是非常简单容易的。</p> <h3><strong>安装依赖的过程</strong></h3> <p>Podfile 被解析后的内容会被转化成一个 Podfile 类的实例，而 Installer 的实例方法 install! 就会使用这些信息安装当前工程的依赖，而整个安装依赖的过程大约有四个部分：</p> <ul> <li> <p>解析 Podfile 中的依赖</p> </li> <li> <p>下载依赖</p> </li> <li> <p>创建 Pods.xcodeproj 工程</p> </li> <li> <p>集成 workspace</p> </li> </ul> <pre> <code class="language-objectivec">def install! resolve_dependencies download_dependencies generate_pods_project integrate_user_project end</code></pre> <p>在上面的 install 方法调用的 resolve_dependencies 会创建一个 Analyzer 类的实例，在这个方法中，你会看到一些非常熟悉的字符串：</p> <pre> <code class="language-objectivec">def resolve_dependencies analyzer = create_analyzer plugin_sources = run_source_provider_hooks analyzer.sources.insert(0, *plugin_sources) UI.section 'Updating local specs repositories' do analyzer.update_repositories end if repo_update? UI.section 'Analyzing dependencies' do analyze(analyzer) validate_build_configurations clean_sandbox end end</code></pre> <p>在使用 CocoaPods 中经常出现的 Updating local specs repositories 以及 Analyzing dependencies 就是从这里输出到终端的，该方法不仅负责对本地所有 PodSpec 文件的更新，还会对当前 Podfile 中的依赖进行分析：</p> <pre> <code class="language-objectivec">def analyze(analyzer = create_analyzer) analyzer.update = update @analysis_result = analyzer.analyze @aggregate_targets = analyzer.result.targets end</code></pre> <p>analyzer.analyze 方法最终会调用 Resolver 的实例方法 resolve ：</p> <pre> <code class="language-objectivec">def resolve dependencies = podfile.target_definition_list.flat_map do |target| target.dependencies.each do |dep| @platforms_by_dependency[dep].push(target.platform).uniq! if target.platform end end @activated = Molinillo::Resolver.new(self, self).resolve(dependencies, locked_dependencies) specs_by_target rescue Molinillo::ResolverError => e handle_resolver_error(e) end</code></pre> <p>这里的 Molinillo::Resolver 就是用于解决依赖关系的类。</p> <p>解决依赖关系（Resolve Dependencies）</p> <p>CocoaPods 为了解决 Podfile 中声明的依赖关系，使用了一个叫做 <a href="/misc/goto?guid=4959717424425101949" rel="nofollow,noindex">Milinillo</a> 的依赖关系解决算法；但是，笔者在 Google 上并没有找到与这个算法相关的其他信息，推测是 CocoaPods 为了解决 iOS 中的依赖关系创造的算法。</p> <p>Milinillo 算法的核心是 <a href="/misc/goto?guid=4959717424516495206" rel="nofollow,noindex">回溯（Backtracking）</a> 以及 <a href="/misc/goto?guid=4959717424600905938" rel="nofollow,noindex">向前检查（forward check）</a> ，整个过程会追踪栈中的两个状态（依赖和可能性）。</p> <p>在这里并不想陷入对这个算法执行过程的分析之中，如果有兴趣可以看一下仓库中的 <a href="/misc/goto?guid=4959717424425101949" rel="nofollow,noindex">ARCHITECTURE.md</a> 文件，其中比较详细的解释了 Milinillo 算法的工作原理，并对其功能执行过程有一个比较详细的介绍。</p> <p>Molinillo::Resolver 方法会返回一个依赖图，其内容大概是这样的：</p> <pre> <code class="language-objectivec">Molinillo::DependencyGraph:[ Molinillo::DependencyGraph::Vertex:AFNetworking(#<Pod::Specification name="AFNetworking">), Molinillo::DependencyGraph::Vertex:SDWebImage(#<Pod::Specification name="SDWebImage">), Molinillo::DependencyGraph::Vertex:Masonry(#<Pod::Specification name="Masonry">), Molinillo::DependencyGraph::Vertex:Typeset(#<Pod::Specification name="Typeset">), Molinillo::DependencyGraph::Vertex:CCTabBarController(#<Pod::Specification name="CCTabBarController">), Molinillo::DependencyGraph::Vertex:BlocksKit(#<Pod::Specification name="BlocksKit">), Molinillo::DependencyGraph::Vertex:Mantle(#<Pod::Specification name="Mantle">), ... ]</code></pre> <p>这个依赖图是由一个结点数组组成的，在 CocoaPods 拿到了这个依赖图之后，会在 specs_by_target 中按照 Target 将所有的 Specification 分组：</p> <pre> <code class="language-objectivec">{ #<Pod::Podfile::TargetDefinition label=Pods>=>[], #<Pod::Podfile::TargetDefinition label=Pods-Demo>=>[ #<Pod::Specification name="AFNetworking">, #<Pod::Specification name="AFNetworking/NSURLSession">, #<Pod::Specification name="AFNetworking/Reachability">, #<Pod::Specification name="AFNetworking/Security">, #<Pod::Specification name="AFNetworking/Serialization">, #<Pod::Specification name="AFNetworking/UIKit">, #<Pod::Specification name="BlocksKit/Core">, #<Pod::Specification name="BlocksKit/DynamicDelegate">, #<Pod::Specification name="BlocksKit/MessageUI">, #<Pod::Specification name="BlocksKit/UIKit">, #<Pod::Specification name="CCTabBarController">, #<Pod::Specification name="CategoryCluster">, ... ] }</code></pre> <p>而这些 Specification 就包含了当前工程依赖的所有第三方框架，其中包含了名字、版本、源等信息，用于依赖的下载。</p> <p>下载依赖</p> <p>在依赖关系解决返回了一系列 Specification 对象之后，就到了 Pod install 的第二部分，下载依赖：</p> <pre> <code class="language-objectivec">def install_pod_sources @installed_specs = [] pods_to_install = sandbox_state.added | sandbox_state.changed title_options = { :verbose_prefix => '-> '.green } root_specs.sort_by(&:name).each do |spec| if pods_to_install.include?(spec.name) if sandbox_state.changed.include?(spec.name) && sandbox.manifest previous = sandbox.manifest.version(spec.name) title = "Installing #{spec.name} #{spec.version} (was #{previous})" else title = "Installing #{spec}" end UI.titled_section(title.green, title_options) do install_source_of_pod(spec.name) end else UI.titled_section("Using #{spec}", title_options) do create_pod_installer(spec.name) end end end end</code></pre> <p>在这个方法中你会看到更多熟悉的提示，CocoaPods 会使用沙盒（sandbox）存储已有依赖的数据，在更新现有的依赖时，会根据依赖的不同状态显示出不同的提示信息：</p> <pre> <code class="language-objectivec">-> Using AFNetworking (3.1.0) -> Using AKPickerView (0.2.7) -> Using BlocksKit (2.2.5) was (2.2.4) -> Installing MBProgressHUD (1.0.0) ...</code></pre> <p>虽然这里的提示会有三种，但是 CocoaPods 只会根据不同的状态分别调用两种方法：</p> <ul> <li> <p>install_source_of_pod</p> </li> <li> <p>create_pod_installer</p> </li> </ul> <p>create_pod_installer 方法只会创建一个 PodSourceInstaller 的实例，然后加入 pod_installers 数组中，因为依赖的版本没有改变，所以不需要重新下载，而另一个方法的 install_source_of_pod 的调用栈非常庞大：</p> <pre> <code class="language-objectivec">installer.install_source_of_pod |-- create_pod_installer | `-- PodSourceInstaller.new `-- podSourceInstaller.install! `-- download_source `-- Downloader.download `-- Downloader.download_request `-- Downloader.download_source |-- Downloader.for_target | |-- Downloader.class_for_options | `-- Git/HTTP/Mercurial/Subversion.new |-- Git/HTTP/Mercurial/Subversion.download `-- Git/HTTP/Mercurial/Subversion.download! `-- Git.clone</code></pre> <p>在调用栈的末端 Downloader.download_source 中执行了另一个 CocoaPods 组件 <strong>CocoaPods-Download</strong> 中的方法：</p> <pre> <code class="language-objectivec">def self.download_source(target, params) FileUtils.rm_rf(target) downloader = Downloader.for_target(target, params) downloader.download target.mkpath if downloader.options_specific? params else downloader.checkout_options end end</code></pre> <p>方法中调用的 for_target 根据不同的源会创建一个下载器，因为依赖可能通过不同的协议或者方式进行下载，比如说 Git/HTTP/SVN 等等，组件 CocoaPods-Downloader 就会根据 Podfile 中依赖的参数选项使用不同的方法下载依赖。</p> <p>大部分的依赖都会被下载到 ~/Library/Caches/CocoaPods/Pods/Release/ 这个文件夹中，然后从这个这里复制到项目工程目录下的 ./Pods 中，这也就完成了整个 CocoaPods 的下载流程。</p> <p>生成 Pods.xcodeproj</p> <p>CocoaPods 通过组件 CocoaPods-Downloader 已经成功将所有的依赖下载到了当前工程中，这里会将所有的依赖打包到 Pods.xcodeproj 中：</p> <pre> <code class="language-objectivec">def generate_pods_project(generator = create_generator) UI.section 'Generating Pods project' do generator.generate! @pods_project = generator.project run_podfile_post_install_hooks generator.write generator.share_development_pod_schemes write_lockfiles end end</code></pre> <p>generate_pods_project 中会执行 PodsProjectGenerator 的实例方法 generate! ：</p> <pre> <code class="language-objectivec">def generate! prepare install_file_references install_libraries set_target_dependencies end</code></pre> <p>这个方法做了几件小事：</p> <ul> <li>生成 Pods.xcodeproj 工程</li> <li>将依赖中的文件加入工程</li> <li>将依赖中的 Library 加入工程</li> <li>设置目标依赖（Target Dependencies）</li> </ul> <p>这几件事情都离不开 CocoaPods 的另外一个组件 Xcodeproj，这是一个可以操作一个 Xcode 工程中的 Group 以及文件的组件，我们都知道对 Xcode 工程的修改大多数情况下都是对一个名叫 project.pbxproj 的文件进行修改，而 Xcodeproj 这个组件就是 CocoaPods 团队开发的用于操作这个文件的第三方库。</p> <p>生成 workspace</p> <p>最后的这一部分与生成 Pods.xcodeproj 的过程有一些相似，这里使用的类是 UserProjectIntegrator ，调用方法 integrate! 时，就会开始集成工程所需要的 Target：</p> <pre> <code class="language-objectivec">def integrate! create_workspace integrate_user_targets warn_about_xcconfig_overrides save_projects end</code></pre> <p>对于这一部分的代码，也不是很想展开来细谈，简单介绍一下这里的代码都做了什么，首先会通过 Xcodeproj::Workspace 创建一个 workspace，之后会获取所有要集成的 Target 实例，调用它们的 integrate! 方法：</p> <pre> <code class="language-objectivec">def integrate! UI.section(integration_message) do XCConfigIntegrator.integrate(target, native_targets) add_pods_library add_embed_frameworks_script_phase remove_embed_frameworks_script_phase_from_embedded_targets add_copy_resources_script_phase add_check_manifest_lock_script_phase end end</code></pre> <p>方法将每一个 Target 加入到了工程，使用 Xcodeproj 修改 Copy Resource Script Phrase 等设置，保存 project.pbxproj ，整个 Pod install 的过程就结束了。</p> <h2><strong>总结</strong></h2> <p>最后想说的是 pod install 和 pod update 区别还是比较大的，每次在执行 pod install 或者 update 时最后都会生成或者修改 Podfile.lock 文件，其中前者并不会修改 Podfile.lock 中 <strong>显示指定</strong> 的版本，而后者会会无视该文件的内容，尝试将所有的 pod 更新到最新版。</p> <p>CocoaPods 工程的代码虽然非常多，不过代码的逻辑非常清晰，整个管理并下载依赖的过程非常符合直觉以及逻辑。</p> <p> </p> <p> </p> <p> </p> <p>来自：http://draveness.me/cocoapods/</p> <p> </p>