背景
随着公司业务规模的增长,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)。
辅助工具