iOS之CocoaPods二进制化的实现方案

背景

• 随着公司业务规模的增长，iOS 客户端的代码量也越来越大，编译一次项目的时间也越来越长。那么减少编译时间成了一个不得不面对的问题；
• 随着越来越多方便的第三方组件，现在开发App基本十多个第三方依赖以上。没有build cache 或者打正式包的时候，每次基本耗时10分钟以上；
• 现有的二进制方案如 Carthage、Rome 等都是在本地生成 framework，没法实现“一次编译，处处使用”的目标；
• 主要原因是需要编译大量源文件(大概分为 App 和 Cocoapods 依赖库)，所以把可抽离代码编译好，再去引用就能减少源文件编译时间；
• 为了实现这个目标，就需要一个人或者一个 CI Job，把编译好的二进制产物上传到某个的地方，集中化地管理这些二进制形式的依赖。然后在每个人 pod install 的时候，检查该 pod 版本对应的二进制是否存在，如果有就使用，没有就继续采用源码的方式依赖；
• 这个方案隐藏了许多细节，比如到底应该如何集中管理这些 pod，如何知道对应的版本是否存在，如何在 pod install 的时候动态地把这些 pod 从源码形式的依赖换成二进制形式的依赖等；
• 整个流程涉及生产方（产生二进制）和消费方（使用二进制）。

思路流程

一、产生二进制

① 代码结构

• 产生二进制的流程在一个 CI Job 中，每隔一段时间，它会同步主仓库最新的 dev 分支，然后运行管理此环节的工具，Platypus；
• 结构如下：

• 说明：
  • config.yml 是与工程相关联的配置，其中包含了需要二进制化的名单（pod_names），project 文件相关信息，以及工程初始化的 action（prebuild_action）等等。
  • specs_repo 是私有的 podspec 仓库，需要单独创建，负责集中管理已经二进制好的 pod 信息。

② 具体流程

• (a)对于大多数项目来说是 pod install，但如果在不改变 podfile 原有写法的基础上实现此套方案，需要把使用 patch 过后的 pod install 方式。
• (b)白名单存在的意义有两点：
  • 一是有些 pod 本来就是二进制好了的；
  • 二是某些 pod 因为头文件没有用 < > 的方式引用在目前阶段没法二进制，否则就会因为找不到头文件编译失败；
• ( c )模拟器和真机的版本都需要编译，最终使用 lipo 把两份二进制合并到一个 .framework 中。如果 pod 中包含 Swift 代码，需要把模拟器和真机的编译产物中的 swiftdoc 和 swiftmodule 都合并到一个文件夹中。由于 Swift 版本的原因，由旧版 Xcode 编译生成 Swift 二进制是无法在新版 Xcode 中使用的；
• (f)通过 CocoaPods 中的 Analyzer 调用 analyzer.analyze.specifications，可以获取当前项目所有依赖 pod 的 podspecs，具体操作可以参考该文章：分析使用 CocoaPods 项目的依赖；关于如何编辑 podspec，可以使用这个 gem。编辑的内容包括删掉 source_files 字段，把 vendored_frameworks 字段指向 .framework， source 指向上传生成的 URL， resources 指向对应 .framework 中的资源等。保存后，作为二进制时依赖使用的 podspec；
• (g)这一步是为了把项目中依赖的 pod 版本与二进制化后的版本建立起联系。因为项目中依赖的引用方式五花八门，有用 CocoaPods Master Repo 中版本号的，有用 git tag 的，也有用 git commmit 的，针对不同的引用方式，都要有对应的匹配规则；

③ 示例说明

• (g) 示例说明：比如有一个使用 tag 方式引用的组件，把它的 tag 号后面加上 -yang-static 作为它在私有 Specs 仓库中的版本号，它在 podfile 中的 external_source 作为 summary 字段，同时确保唯一性。这里的映射关系只要能一一对应起来，随便怎么建立都好，如下：

	pod 'A', git: 'git@git.xxx.com:xxx/A.git', tag: '4.24.0.9'

• 所以它被改完版本号后 poddpec 会变成如下样式：

	{
	  "name": "A",
	  "version": "4.24.0.9-yang-static",
	  "summary": "{:git=>\"git@git.xxx.com:xxx/A.git\", :tag=>\"4.24.0.9\"}"
	  ...
	}

• (h) Specs 仓库目录结构如下所示，目录均为手动创建，没有使用 CocoaPods 提供的方式更新:

	├── A
	│   └── 4.22.0.8-yang-static
	│       └── A.podspec.json
	├── B
	│   ├── 0.2.21-yang-static
	│   │   └── B.podspec.json
	│   └── 0.2.9-yang-static
	│       └── B.podspec.json
	├── C
	│   └── 1.4.0-yang-static
	│       └── C.podspec
	└── D
	    └── 2.5.0-yang-static
	        └── D.podspec

二、使用二进制

• 在触发 pod install 过程之前，需要在本地把私有 Specs 仓库更新到最新，pod repo update xxx；
• 接下来就是 patch pod install 替换依赖的过程，在不更改 podfile 的情况下，只能模仿 pod install 的过程，自己创建一个脚本来替代这个操作。整个过程不复杂，可以参考下面这一段带注释的代码：

	# 参考 `CocoaPods` 的源码，模拟 `pod install` 执行的过程
	argv = CLAide::ARGV.new([])
	cmd = Pod::Command.new(argv)
	cmd.send :verify_podfile_exists!
	installer = cmd.send :installer_for_config
	installer.repo_update = false
	installer.update = false
	
	podfile = installer.podfile
	
	# 获取此次 install 的配置，是全部使用二进制还是全部使用源码
	# 全部使用二进制时，哪些 pod 依旧使用源码引入
	use_all_binary, source_pod_list = ZHPodInstallHelper.read_binary_pods_pref
	use_all_binary = false if ENV['ALL_SOURCE'] == 'true'
	unless use_all_binary
	  puts '  pod install with all source'
	  installer.install!
	  exit(0)
	end
	
	# 为 podfile 添加二进制 Specs 仓库的 source
	podfile.send(:get_hash_value, 'sources')
	hash_sources = podfile.send(:get_hash_value, 'sources') || []
	hash_sources << 'git@git.xxx.com:xxx/E.git'
	podfile.send(:set_hash_value, 'sources', hash_sources.uniq)
	
	# 遍历 podfile 中的所有 dependencies
	podfile.root_target_definitions.each do |root_target_definition|
	  children_definitions = root_target_definition.recursive_children
	  children_definitions.each do |children_definition|
	    dependencies_hash_array = children_definition.send(:get_hash_value, 'dependencies')
	    next if dependencies_hash_array.count.zero?
	    dependencies_hash_array.each do |dependencie_hash_item|
	      next if dependencie_hash_item.class.name != 'Hash'
	      dependencie_hash_item.each do |name, value|
	        next if value[0].is_a?(Hash) && value[0][:path]
	        search_name = name
	        search_name = name.split('/')[0] if name.include?('/')
	
	        # 对于想要以源码依赖的 pod，不作修改
	        next if source_pod_list.include?(search_name)
	
	        # 根据 podfile 中引用的源码版本，在私有 Specs 仓库中查找相应二进制的版本
	        version = ZHPodInstallHelper.get_binary_version(search_name, value[0].to_s)
	        # 存在对应的二进制版本，就替换掉
	        dependencie_hash_item[name] = [version] if version
	      end
	    end
	    # 替换 podfile 的 dependencies 为修改后的 dependencies
	    children_definition.send(:set_hash_value, 'dependencies', dependencies_hash_array)
	  end
	end
	
	installer.install!

局限

• 需要自定义 pod install 过程，同时修改某些 CocoaPods 中的私有属性；
• 最终的 binary size 会比使用源码的时候大一点，不建议最终上传 Store 的时候使用；
• 缺少一个验证的机制，如果已发布的二进制包不能被项目正常引用，那么会导致所有人的编译失败；
• 由于工程采用的是全部静态库依赖的形式，所以在二进制和源码切换的过程中会对 project 文件产生更改。

步骤总结

① 打包第三方源码

• git clone各种组件源码库；
• 脚本打包：
  • tag拉分支, 并切换(打包之后删除, 再回去master)；
  • 使用pod gen根据podsec创建工程；
  • xcodebuild打包framework(真机和模拟器)；
  • 合并真机和模拟器的framework；
  • 实践的时候会发现有些库是不能通用一个脚本的；
• 上传framework(用了binary-server管理)；

② 二进制的podsec上传到私有的repo

• 使用pod bin spec create创建二进制版本的podsec；
  • 有subsec的会要求提供template；
  • 某些平台要求版本会低于8, 因为是使用framework, 需要平台版本需要改为8以上；
• 上传生成的podsec；

③ 使用

• 在Podfile加上source {私有repo}，然后再加一个官方的repo(例如: source ‘https://cdn.cocoapods.org/’)。
• 官方的一定要加在后面，有相同的库会根据source的顺序获取依赖，想切回源码注释私有库那一行就好了(因为只是简单的一个私有二进制repo)。

辅助工具

• cocoapods-bin
• binary-server