Cocoapods核心组件：CocoaPods-Core

Cocoapods

介绍

CocoaPods-Core 用于CocoaPods中配置文件的解析，包括Podfile、Podspec以及解析后的依赖锁存文件，如Podfile.lock等。

CocoaPods-Core 的文件构成

我们先通过入口文件 lib/cocoapods-core.rb 来一窥 Core 项目的主要文件：

module Pod
  require 'cocoapods-core/gem_version'
  class PlainInformative < StandardError; end
  class Informative < PlainInformative; end
  require 'pathname'
  require 'cocoapods-core/vendor'
  # 用于存储 PodSpec 中的版本号
  autoload :Version,        'cocoapods-core/version'
  # pod 的版本限制
  autoload :Requirement,    'cocoapods-core/requirement'
  # 配置 Podfile 或 PodSpec 中的 pod 依赖
  autoload :Dependency,     'cocoapods-core/dependency'
  # 获取 Github 仓库信息
  autoload :GitHub,         'cocoapods-core/github'
  # 处理 HTTP 请求
  autoload :HTTP,           'cocoapods-core/http'
  # 记录最终 pod 的依赖信息
  autoload :Lockfile,       'cocoapods-core/lockfile'
  # 记录 SDK 的名称和 target 版本
  autoload :Platform,       'cocoapods-core/platform'
  # 对应 Podfile 文件的 class
  autoload :Podfile,        'cocoapods-core/podfile'
  # 管理 PodSpec 的集合
  autoload :Source,         'cocoapods-core/source'
  # 管理基于 CDN 来源的 PodSpec 集合
  autoload :CDNSource,      'cocoapods-core/cdn_source'
  # 管理基于 Trunk 来源的 PodSpec 集合
  autoload :TrunkSource,    'cocoapods-core/trunk_source'
  # 对应 PodSpec 文件的 class
  autoload :Specification,  'cocoapods-core/specification'
  # 将 pod 信息转为 .yml 文件，用于 lockfile 的序列化
  autoload :YAMLHelper,     'cocoapods-core/yaml_helper'
  # 记录 pod 依赖类型，是静态库/动态库
  autoload :BuildType,      'cocoapods-core/build_type'
  ...
  Spec = Specification
end

将这些 Model 类按照对应的依赖关系进行划分，层级如下：

主要数据结构

TargetDefinition（target_definition.rb）

TargetDefinition 是一个多叉树结构，每个节点记录着 Podfile 中定义的 Pod 的 Source 来源、Build Setting、Pod 子依赖等。该树的根节点指向 Podfile，而 Podfile 中的 root_target_definitions 则记录着所有的 TargetDefinition 的根节点，正常情况下该 list 中只有一个 root 即 Pods.project。

为了便于阅读，简化了大量的 DSL 配置相关的方法和属性并对代码顺序做了调整，大致结构如下：

module Pod
  class Podfile
    class TargetDefinition
      # 父节点: TargetDefinition 或者 Podfile
      attr_reader :parent
      # 子节点: TargetDefinition
      attr_reader :children
      # 记录 tareget 的配置信息
      attr_accessor :internal_hash
      def root?
        parent.is_a?(Podfile) || parent.nil?
      end
      def root
        if root?
          self
        else
          parent.root
        end
      end
      def podfile
        root.parent
      end
      # ...
  end
end

在初始化Podfile对象时就会初始化根TargetDefinition：

# podfile.rb
def initialize(defined_in_file = nil, internal_hash = {}, &block)
  self.defined_in_file = defined_in_file
  @internal_hash = internal_hash
  if block
    # TargetDefinition名为Pods，parent父节点为podfile
    default_target_def = TargetDefinition.new('Pods', self)
    default_target_def.abstract = true
    @root_target_definitions = [default_target_def]
    @current_target_definition = default_target_def
    instance_eval(&block)
  else
    @root_target_definitions = []
  end
end

然后在Podfile文件里的每一个target声明都会调用dsl.rb里对应的target函数，初始化对应的子TargetDefinition：

Specification（specification.rb）

Specification即存储PodSpec的内容，是用于描述一个Pod库的源代码和资源将如何被打包编译成链接库或framework。

Podspec 支持的文件格式为 .podspec 和 .json 两种，而 .podspec 本质是 Ruby 文件。

在数据结构上Specification与TargetDefinition是类似的，同为多叉树结构。这里的parent是为 subspec保留的，用于指向其父节点的Spec。简化后的Spec的类如下：

require 'active_support/core_ext/string/strip.rb'
# 记录对应 platform 上 Spec 的其他 pod 依赖
require 'cocoapods-core/specification/consumer'
# 解析 DSL
require 'cocoapods-core/specification/dsl'
# 校验 Spec 的正确性，并抛出对应的错误和警告
require 'cocoapods-core/specification/linter'
# 用于解析 DSL 内容包含的配置信息
require 'cocoapods-core/specification/root_attribute_accessors'
# 记录一个 Pod 所有依赖的 Spec 来源信息
require 'cocoapods-core/specification/set'
# json 格式数据解析
require 'cocoapods-core/specification/json'
module Pod
  class Specification
    include Pod::Specification::DSL
    include Pod::Specification::DSL::Deprecations
    include Pod::Specification::RootAttributesAccessors
    include Pod::Specification::JSONSupport
    # `subspec` 的父节点
    attr_reader :parent
    # `Spec` 的唯一 id，由 name + version 的 hash 构成
    attr_reader :hash_value
    # 记录 `Spec` 的配置信息 
    attr_accessor :attributes_hash
    # `Spec` 包含的 `subspec`
    attr_accessor :subspecs
    # 递归调用获取 Specification 的根节点
    def root
      parent ? parent.root : self
    end
     def hash
    if @hash_value.nil?
        @hash_value = (name.hash * 53) ^ version.hash
        end
      @hash_value
    end
    # ...
  end
end

Specification 同样用 map attributes_hash 来记录配置信息。

Podfile（podfile.rb）

Podfile 是用于描述一个或多个 Xcode Project 中各个 Targets 之间的依赖关系。

这些 Targets 的依赖关系对应的就是 TargetDefinition 树中的各子节点的层级关系。如前面所说，有了 Podfile 这个根节点的指向，仅需对依赖树进行遍历，就能轻松获取完整的依赖关系。

有了这层依赖树，对于某个 Pod 库的更新即是对树节点的更新，便可轻松的分析出此次更新涉及的影响。

简化调整后的 Podfile 代码如下：

require 'cocoapods-core/podfile/dsl'
require 'cocoapods-core/podfile/target_definition'
module Pod
  class Podfile
    include Pod::Podfile::DSL
    # podfile 路径
    attr_accessor :defined_in_file
    # 所有的 TargetDefinition 的根节点, 正常只有一个，即 Pods.project target
    attr_accessor :root_target_definitions
    # 记录 Pods.project 项目的配置信息
    attr_accessor :internal_hash
    # 当前 DSL 解析使用的 TargetDefinition
    attr_accessor :current_target_definition
    # ...
  end
end

直接看 dsl.rb，该文件内部定义了 Podfile DSL 支持的所有方法。通过 include 的使用将 Pod::Podfile::DSL 模块 Mix-in 后插入到 Podfile 类中。

Lockfile（lockfile.rb）

Lockfile，顾名思义是用于记录最后一次 CocoaPods所安装的Pod依赖库版本的信息快照。也就是生成的 Podfile.lock。

在 pod install 过程，Podfile 会结合它来确认最终所安装的 Pod 版本，固定 Pod 依赖库版本防止其自动更新。Lockfile 也作为 Pods 状态清单(mainfest)，用于记录安装过程的中哪些 Pod 需要被删除或安装或更新等。

Lockfile可获取的信息：

• PODS：记录所有 Pod 库的具体安装版本号
• DEPENDENCIES：记录各 Pod 库之间的相互依赖关系
• EXTERNAL SOURCES：记录部分通过外部源的 Pod 库（Git 引入、Path 引入）
• SPEC CHECKSUMS：记录当前各 Pod 库的 Podspec 文件 Hash 值，其实就是文件的 md5
• PODFILE CHECKSUM：记录 Podfile 文件的 Hash 值，同样是 md5，确认是否有变更
• COCOAPODS：记录上次所使用的 CocoaPods 版本

Podfile 内容加载

podfile文件读取

pod install 命令执行后的 verify_podfile_exists!中读取podfile：

def verify_podfile_exists!
  unless config.podfile
    raise Informative, "No `Podfile' found in the project directory."
  end
end

Podfile文件的读取就是config.podfile里触发的，代码在 CocoaPods 的 config.rb 文件中：

def podfile_path_in_dir(dir)
    PODFILE_NAMES.each do |filename|
        candidate = dir + filename
        if candidate.file?
        return candidate
        end
    end
    nil
end
def podfile_path
    @podfile_path ||= podfile_path_in_dir(installation_root)
end
def podfile
    @podfile ||= Podfile.from_file(podfile_path) if podfile_path
end

最后 Core 里的podfile.rb的from_file函数将依据目录下的 Podfile 文件类型选择调用 from_yaml 或者 from_ruby：

def self.from_file(path)
  path = Pathname.new(path)
  unless path.exist?
    raise Informative, "No Podfile exists at path `#{path}`."
  end
  case path.extname
  when '', '.podfile', '.rb'
    Podfile.from_ruby(path)
  when '.yaml'
    Podfile.from_yaml(path)
  else
    raise Informative, "Unsupported Podfile format `#{path}`."
  end
end

Podfile From Ruby 解析

读取到文件之后我们需要对Podfile内容进行解析，这里主要看Core下面的podfile.rb文件下的from_ruby函数：

# podfile.rb
def self.from_ruby(path, contents = nil)
  contents ||= File.open(path, 'r:utf-8', &:read)
  ...
  # 初始化生成Podfile对象，eval执行自己定义的dsl语句
  podfile = Podfile.new(path) do
    # rubocop:disable Lint/RescueException
    begin
      # rubocop:disable Security/Eval
      eval(contents, nil, path.to_s)
      # rubocop:enable Security/Eval
    rescue Exception => e
      message = "Invalid `#{path.basename}` file: #{e.message}"
      raise DSLError.new(message, path, e, contents)
    end
    # rubocop:enable Lint/RescueException
  end
  podfile
end

其中核心的一段代码是eval(contents, nil, path.to_s)，它将Podfile中的文本内容转化为方法执行，也就是说里面的参数是一段Ruby 的代码字符串，通过eval方法可以直接执行。

Podfile From YAML 解析

YAML 格式的 Podfile 加载需要借助 YAMLHelper 类来完成，YAMLHelper 则是基于 yaml 的简单封装。

# podfile.rb
def self.from_yaml(path)
    string = File.open(path, 'r:utf-8', &:read)
    # 为了解决 Rubinius incomplete encoding in 1.9 mode
    # https://github.com/rubinius/rubinius/issues/1539
    if string.respond_to?(:encoding) && string.encoding.name != 'UTF-8'
        string.encode!('UTF-8')
    end
    hash = YAMLHelper.load_string(string)
    from_hash(hash, path)
end
def self.from_hash(hash, path = nil)
    internal_hash = hash.dup
    target_definitions = internal_hash.delete('target_definitions') || []
    podfile = Podfile.new(path, internal_hash)
    target_definitions.each do |definition_hash|
        definition = TargetDefinition.from_hash(definition_hash, podfile)
        podfile.root_target_definitions << definition
    end
    podfile
end

通过from_yaml将文件内容转成Ruby hash后转入from_hash方法。

区别于from_ruby，这里调用的initialize将读取的hash直接存入internal_hash，然后利用TargetDefinition.from_hash 来完成的hash内容到targets的转换，因此，这里无需传入block进行DSL解析和方法转换。

初始化Podfile对象

Podfile的initialize方法：

def initialize(defined_in_file = nil, internal_hash = {}, &block)
    self.defined_in_file = defined_in_file
    @internal_hash = internal_hash
    if block
        default_target_def = TargetDefinition.new('Pods', self)
        default_target_def.abstract = true
        @root_target_definitions = [default_target_def]
        @current_target_definition = default_target_def
        instance_eval(&block)
    else
        @root_target_definitions = []
    end
end

它定义了三个参数：

• defined_in_file：Podfile 文件路径
• internal_hash：通过 yaml 序列化得到的 Podfile 配置信息，保存在internal_hash中（Podfile From YAML使用）
• block：用于映射 Podfile 的 DSL 配置（Podfile From Ruby使用）

当 block 存在，会初始化名为Pods的TargetDefinition对象，用于保存Pods project的相关信息和 Pod 依赖。然后调用instance_eval执行传入的block，将 Podfile 的 DSL 内容转换成对应的方法和参数，最终将参数存入 internal_hash 和对应的 target_definitions 中。

Podfile 内容解析

Podfile 的内容最终保存在 internal_hash 和 target_definitions 中，本质上都是使用了 hash 来保存数据。由于 YAML 文件格式的 Podfile 加载后就是 hash 对象，无需过多加工。唯一需要处理的是递归调用 TargetDefinition 的 from_hash 方法来解析 target 子节点的数据。

因此，接下来的内容解析主要针对 Ruby 文件格式的 DSL 解析，我们以 pod 方法为例：

target 'Example' do
    pod 'Alamofire'
end

当解析到 pod 'Alamofire' 时，会先通过 eval(contents, nil, path.to_s) 将其转换为 dsl.rb 中的方法：

def pod(name = nil, *requirements)
    unless name
        raise StandardError, 'A dependency requires a name.'
    end
    current_target_definition.store_pod(name, *requirements)
end

name 为 Alamofire，由于我们没有指定对应的 Alamofire 版本，默认会使用最新版本。requirements 是控制 该 pod 来源获取或者 pod target 的编译选项等，例如：

pod 'Alamofire', '0.9'
pod 'Alamofire', :modular_headers => true
pod 'Alamofire', :configurations => ['Debug', 'Beta']
pod 'Alamofire', :source => 'https://github.com/CocoaPods/Specs.git'
pod 'Alamofire', :subspecs => ['Attribute', 'QuerySet']
pod 'Alamofire', :testspecs => ['UnitTests', 'SomeOtherTests']
pod 'Alamofire', :path => '~/Documents/AFNetworking'
pod 'Alamofire', :podspec => 'https://example.com/Alamofire.podspec'
pod 'Alamofire', :git => 'https://github.com/looseyi/Alamofire.git', :tag => '0.7.0'

对 name 进行校验后，直接转入 current_target_definition 毕竟 Pod 库都是存在 Pods.project 之下：

# target_definition.rb
def store_pod(name, *requirements)
  return if parse_subspecs(name, requirements) # This parse method must be called first
  parse_inhibit_warnings(name, requirements)
  parse_modular_headers(name, requirements)
  parse_configuration_whitelist(name, requirements)
  parse_project_name(name, requirements)
  if requirements && !requirements.empty?
    pod = { name => requirements }
  else
    pod = name
  end
  get_hash_value('dependencies', []) << pod
  nil
end
def get_hash_value(key, base_value = nil)
  unless HASH_KEYS.include?(key)
    raise StandardError, "Unsupported hash key `#{key}`"
  end
  internal_hash[key] = base_value if internal_hash[key].nil?
  internal_hash[key]
end
def set_hash_value(key, value)
  unless HASH_KEYS.include?(key)
    raise StandardError, "Unsupported hash key `#{key}`"
  end
  internal_hash[key] = value
end

经过一系列检查之后，调用 get_hash_value 获取 internal_hash 的 dependencies，并将 name 和 requirements 选项存入。

我们能看到当前的current_target_definition的internal_hash['dependencies']存的就是pod podname声明的所有依赖，是一个数组，数组里面的值如果有requirements则是Hash，没有则是pod名的字符串：

整个映射过程如下：

Podspec内容加载

Podspec文件读取

# source.rb
def specification(name, version)
  Specification.from_file(specification_path(name, version))
end
# 根据name和version读取到podspec的路径
def specification_path(name, version)
  raise ArgumentError, 'No name' unless name
  raise ArgumentError, 'No version' unless version
  path = pod_path(name) + version.to_s
  specification_path = path + "#{name}.podspec.json"
  unless specification_path.exist?
    specification_path = path + "#{name}.podspec"
  end
  unless specification_path.exist?
    raise StandardError, "Unable to find the specification #{name} " \
      "(#{version}) in the #{self.name} source."
  end
  specification_path
end

Podspec内容读取

def self.from_file(path, subspec_name = nil)
  path = Pathname.new(path)
  unless path.exist?
    raise Informative, "No podspec exists at path `#{path}`."
  end
  string = File.open(path, 'r:utf-8', &:read)
  # Work around for Rubinius incomplete encoding in 1.9 mode
  if string.respond_to?(:encoding) && string.encoding.name != 'UTF-8'
    string.encode!('UTF-8')
  end
  from_string(string, path, subspec_name)
end
def self.from_string(spec_contents, path, subspec_name = nil)
  path = Pathname.new(path).expand_path
  spec = nil
  case path.extname
  when '.podspec'
    Dir.chdir(path.parent.directory? ? path.parent : Dir.pwd) do
      # 直接通过eval执行podspec里的ruby语句，返回Specifiction对象
      spec = ::Pod._eval_podspec(spec_contents, path)
      unless spec.is_a?(Specification)
        raise Informative, "Invalid podspec file at path `#{path}`."
      end
    end
  when '.json'
    spec = Specification.from_json(spec_contents)
  else
    raise Informative, "Unsupported specification format `#{path.extname}` for spec at `#{path}`."
  end
  spec.defined_in_file = path
  spec.subspec_by_name(subspec_name, true)
end

以AFNetworking为例，.podspec文件就是简单直接地声明了一个Specifiction对象，然后通过 block 块定制来完成配置：

Pod::Spec.new do |s|
  s.name     = 'AFNetworking'
  s.version  = '2.7.2'
  s.license  = 'MIT'
  s.summary  = 'A delightful iOS and OS X networking framework.'
  s.homepage = 'https://github.com/AFNetworking/AFNetworking'
  .
  .
  .

Podspec内容解析

类似于podfile的内容保存在internal_hash的hash里，像podspec的内容name、source_files 这些配置参数最终都会转换为方法调用并将值存入attributes_hash的hash中。

这些方法调用的实现方式分两种：

• 大部分配置是通过方法包装器 attribute 和 root_attribute 来动态添加的 setter 方法；
• 对于复杂逻辑的配置则直接方法声明，如 subspec 、dependency 方法等

方法包装器（attribute wrappter）

# lib/cocoapods-core/specification/dsl.rb
module Pod
  class Specification
    module DSL
      extend Pod::Specification::DSL::AttributeSupport
      # Deprecations must be required after include AttributeSupport
      require 'cocoapods-core/specification/dsl/deprecations'
      attribute :name,
                :required => true,
                :inherited => false,
                :multi_platform => false
      root_attribute :version,
                      :required => true
      # ...
    end
  end
end

可以看出 name和 version 的方法声明与普通的不太一样，其实 attribute 和 root_attribute 是通过 Ruby 的方法包装器来实现的，这些装饰器所声明的方法会在其模块被加载时动态生成，来看其实现：

# lib/cocoapods-core/specification/attribute_support.rb
module Pod
  class Specification
    module DSL
      class << self
        attr_reader :attributes
      end
      module AttributeSupport
        def root_attribute(name, options = {})
          options[:root_only] = true
          options[:multi_platform] = false
          store_attribute(name, options)
        end
        def attribute(name, options = {})
          store_attribute(name, options)
        end
        def store_attribute(name, options)
          attr = Attribute.new(name, options)
          @attributes ||= {}
          @attributes[name] = attr
        end
      end
    end
  end
end

attribute 和 root_attribute 最终都走到了 store_attribute 保存在创建的 Attribute 对象内，并以配置的 Symbol名称作为 KEY 存入 @attributes，用于生成最终的 attributes setter 方法。

最关键的一步，让我们回到 specification 文件：

# /lib/coocapods-core/specification
module Pod
  class Specification
    # ...
    def store_attribute(name, value, platform_name = nil)
      name = name.to_s
      value = Specification.convert_keys_to_string(value) if value.is_a?(Hash)
      value = value.strip_heredoc.strip if value.respond_to?(:strip_heredoc)
      if platform_name
        platform_name = platform_name.to_s
        attributes_hash[platform_name] ||= {}
        attributes_hash[platform_name][name] = value
      else
        attributes_hash[name] = value
      end
    end
    DSL.attributes.values.each do |a|
      define_method(a.writer_name) do |value|
        store_attribute(a.name, value)
      end
      if a.writer_singular_form
        alias_method(a.writer_singular_form, a.writer_name)
      end
    end
  end
end

Specification 类被加载时，会先遍历 DSL module 加载后所保存的 attributes，再通过 define_method 动态生成对应的配置方法。最终数据还是保存在 attributes_hash 中。

• root_attribute：仅用于修饰 Spec 根节点，比如版本号 version 只能由 Spec 根节点来设置，另外还有 source、static_framework、module_name 等；
• attribute：不限是否为 Spec 根结点，比如source_files

方法声明

除了 attribute 装饰器声明的 setter 方法，还有几个自定义的方法是直接通过 eval 调用的：

# lib/cocoapods-core/specification/dsl.rb
# 三种不同类型的 Subspec 经 eval 转换为对应的 Specification 对象，注意这里初始化后都将 parent 节点指向 self 同时存入 @subspecs 数组中，完成 SubSpec 依赖链的构造。
def subspec(name, &block)
  subspec = Specification.new(self, name, &block)
  @subspecs << subspec
  subspec
end
def test_spec(name = 'Tests', &block)
  subspec = Specification.new(self, name, true, &block)
  @subspecs << subspec
  subspec
end
def app_spec(name = 'App', &block)
  appspec = Specification.new(self, name, :app_specification => true, &block)
  @subspecs << appspec
  appspec
end
# 对于其他 pod 依赖的添加我们通过 dependency 方法来实现
def dependency(*args)
  name, *version_requirements = args
  # dependency args 有效性校验 ...
  attributes_hash['dependencies'] ||= {}
  attributes_hash['dependencies'][name] = version_requirements
  unless whitelisted_configurations.nil?
    # configuration 白名单过滤和校验 ...
    attributes_hash['configuration_pod_whitelist'] ||= {}
    attributes_hash['configuration_pod_whitelist'][name] = whitelisted_configurations
  end
end

参考

文件几乎完全一样摘抄自Podfile 的解析逻辑，这篇文章条理已经很清晰，本人只是为了个人查阅方便记录一下。