发现问题
如题，在 Podfile 里将 pod 指向了某个版本，但 pod install 却无法正确的下载该版本号的代码。这个问题是最近在打包机上遇到的，Jenkins 打包提交给测试的时候偶尔会出现提交的代码未应用，或者在本地确认无误的代码在打包过程中 xcodebuild 直接编译失败。
因为场景比较特殊所以很快发现了问题。一开始我们在 Podfile 里将 PodA 指向了版本号 1.0.0，如：
Pod 'PodA', '1.0.0'
提测过程中，我们从 1.0.0 tag 处拉取了分支 branch_a，并且在该分支上提交了 commitA。然后在 Podfile 里将 PodA 从版本号 1.0.0 改向了分支 branch_a，如：
Pod 'PodA', :git => 'https://xyz.com/PodA.git', :branch => 'branch_a'
打包提交给测试之后，因为需求变更，在分支 branch_a 上的改动不需要了，所以又将 Podfile 里的 PodA 从分支改回了版本号 1.0.0，如：
Pod 'PodA', '1.0.0'
这时再打包就发现 Pods 文件夹下的 PodA 的代码依然包含了分支 branch_a 上的 commitA，并未更改为 1.0.0 tag 的代码。
通过查看 CocoaPods 源码发现，在 pod install 过程中，CocoaPods 会根据 Pods/Manifest.lock 文件比对 pod 是否需要重新下载。从版本号改向分支的时候，CocoaPods 有个 predownloaded 的判读，重新下载了 pod 代码；然而从分支改向版本号的时候，对比了 pod 版本号、名称、checksum 都没变所以代码未更新。以下是 CocoaPods 1.10.2 版本的判断代码：
def pod_changed?(pod)
spec = root_spec(pod)
return true if spec.version != sandbox_version(pod)
return true if spec.checksum != sandbox_checksum(pod)
return true if resolved_spec_names(pod) != sandbox_spec_names(pod)
return true if sandbox.predownloaded?(pod)
return true if folder_empty?(pod)
false
end
源码解读：pod install 对 pod sources 更新逻辑
现在，从头捋一遍：pod install 过程中这么判断哪些 pod 该更新，哪些 pod 不更新的呢？
首先打开 installer.rb 文件，找到 def install! 方法，便是 pod install 的入口方法了
def install!
prepare
resolve_dependencies
download_dependencies
validate_targets
if installation_options.skip_pods_project_generation?
show_skip_pods_project_generation_message
else
integrate
end
write_lockfiles
perform_post_install_actions
end
其中调用了 download_dependencies 方法：
def download_dependencies
UI.section 'Downloading dependencies' do
install_pod_sources
run_podfile_pre_install_hooks
clean_pod_sources
end
end
其中调用了 install_pod_sources 方法：
# Downloads, installs the documentation and cleans the sources of the Pods
# which need to be installed.
#
# @return [void]
#
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)
... 省略代码逻辑
UI.titled_section(title.green, title_options) do
install_source_of_pod(spec.name)
end
else
UI.section("Using #{spec}", title_options[:verbose_prefix]) do
create_pod_installer(spec.name)
end
end
end
end
发现 sandbox_state.added 和 sandbox_state.changed 应该是分别对应着 新增、变更 的 pod。全局搜索 sandbox_state 会发现方法：
# @return [SpecsState] The state of the sandbox returned by the analyzer.
#
def sandbox_state
analysis_result.sandbox_state
end
全局搜索 analysis_result，看看它是哪里来的，会发现方法：
# @!group Installation steps
# Performs the analysis.
#
# @param [Analyzer] analyzer the analyzer to use for analysis
#
# @return [void]
#
def analyze(analyzer = create_analyzer)
@analysis_result = analyzer.analyze
@aggregate_targets = @analysis_result.targets
@pod_targets = @analysis_result.pod_targets
end
analysis_result 是执行了 analyzer 的 analyze 方法得到的。搜索当前这个 analyze( 方法的调用是在方法：
# @return [Analyzer] The analyzer used to resolve dependencies
#
def resolve_dependencies
plugin_sources = run_source_provider_hooks
analyzer = create_analyzer(plugin_sources)
... 省略代码逻辑
UI.section 'Analyzing dependencies' do
analyze(analyzer)
validate_build_configurations
end
... 省略代码逻辑
analyzer
end
以上 resolve_dependencies 方法也是在 install 方法里被调用的，而且是在 download_dependencies 方法之前。根据方法名也不难看出这里的代码逻辑：首先调用 resolve_dependencies 方法进行依赖分析拿到结果，再执行 download_dependencies 方法下载依赖。
接着搜索 create_analyzer 方法：
1
2
3
def create_analyzer(plugin_sources = nil)
Analyzer.new(sandbox, podfile, lockfile, plugin_sources, has_dependencies?, update)
end
Analyzer 应该就是具体的分析类，这个类里拥有的 analyze 方法正是返回了上述提到的 @analysis_result。打开 analyzer.rb 文件搜索 analyze 试试：
# Performs the analysis.
#
# The Podfile and the Lockfile provide the information necessary to
# compute which specification should be installed. The manifest of the
# sandbox returns which specifications are installed.
#
# @param [Bool] allow_fetches
# whether external sources may be fetched
#
# @return [AnalysisResult]
#
def analyze(allow_fetches = true)
... 省略代码逻辑
sandbox_state = generate_sandbox_state(specifications)
... 省略代码逻辑
@result = AnalysisResult.new(podfile_state, specs_by_target, specs_by_source, specifications, sandbox_state,
aggregate_targets, pod_targets, @podfile_dependency_cache)
end
# Computes the state of the sandbox respect to the resolved
# specifications.
#
# @return [SpecsState] the representation of the state of the manifest
# specifications.
#
def generate_sandbox_state(specifications)
sandbox_state = nil
UI.section 'Comparing resolved specification to the sandbox manifest' do
sandbox_analyzer = SandboxAnalyzer.new(sandbox, specifications, update_mode?)
sandbox_state = sandbox_analyzer.analyze
sandbox_state.print
end
sandbox_state
end
至此，就找到了前文提到的 def sandbox_state 方法返回的 analysis_result.sandbox_state 正是以上方法里 AnalysisResult 这个类的 sandbox_state 属性，而该属性又是来自 generate_sandbox_state 方法生成的 SandboxAnalyzer 对象，执行 analyze 方法返回的。
找到 SandboxAnalyzer 类就找到我们此行的最终答案，打开 sandbox_analyzer.rb 文件：
# Performs the analysis to the detect the state of the sandbox respect
# to the resolved specifications.
#
# @return [void]
#
def analyze
state = SpecsState.new
if sandbox_manifest
all_names = (resolved_pods + sandbox_pods).uniq.sort
all_names.sort.each do |name|
state.add_name(name, pod_state(name))
end
else
state.added.merge(resolved_pods)
end
state
end
#---------------------------------------------------------------------#
private
# @!group Pod state
# Returns the state of the Pod with the given name.
#
# @param [String] pod
# the name of the Pod.
#
# @return [Symbol] The state
#
def pod_state(pod)
return :added if pod_added?(pod)
return :deleted if pod_deleted?(pod)
return :changed if pod_changed?(pod)
:unchanged
end
# Returns whether the Pod with the given name should be installed.
#
# @note A Pod whose folder doesn't exists is considered added.
#
# @param [String] pod
# the name of the Pod.
#
# @return [Bool] Whether the Pod is added.
#
def pod_added?(pod)
return true if resolved_pods.include?(pod) && !sandbox_pods.include?(pod)
return true if !folder_exist?(pod) && !sandbox.local?(pod)
false
end
# Returns whether the Pod with the given name should be removed from
# the installation.
#
# @param [String] pod
# the name of the Pod.
#
# @return [Bool] Whether the Pod is deleted.
#
def pod_deleted?(pod)
return true if !resolved_pods.include?(pod) && sandbox_pods.include?(pod)
false
end
# Returns whether the Pod with the given name should be considered
# changed and thus should be reinstalled.
#
# @note In update mode, as there is no way to know if a remote source
# hash changed the Pods from external
# sources are always marked as changed.
#
# @note A Pod whose folder is empty is considered changed.
#
# @param [String] pod
# the name of the Pod.
#
# @return [Bool] Whether the Pod is changed.
#
def pod_changed?(pod)
spec = root_spec(pod)
return true if spec.version != sandbox_version(pod)
return true if spec.checksum != sandbox_checksum(pod)
return true if resolved_spec_names(pod) != sandbox_spec_names(pod)
return true if sandbox.predownloaded?(pod)
return true if folder_empty?(pod)
false
end
这段代码就是 pod install 过程中判断得到的哪些 pod 是新增的、哪些 pod 是删除的、哪些 pod 是改变的，而新增的 和 改变的则需要下载新的代码。
关注 def pod_changed 方法，spec 相当于目标 pod 的 podspec，sandbox_ 相关的则是进行比对的 Pods/Manifest.lock 文件包含的 pod 信息。
在 Podfile 里将 pod 从分支指向改为 版本号 时，这里的判断的 version、checksum、name 等信息都是相同的，所以该 pod 并未出现在 changed 数组里，Pods 文件夹里该 pod 的代码也就并未更新。
修复问题: PR #10825
首先要搞明白在 Podfile 里将 pod 指向分支和指向版本号在 lock 记录里究竟有什么不一样，才好处理究竟要怎么判断。打开 Podfile.lock 文件（和 Pods/Manifest.lock 文件内容一致），搜索 PodA 相关的内容：
# Pod 'PodA', :git => 'https://xyz.com/PodA.git', :branch => 'branch_a'
DEPENDENCIES:
- PodA (from `https://xyz.com/PodA.git`, branch `branch_a`)
# Pod 'PodA', '1.0.0'
DEPENDENCIES:
- PodA (= 1.0.0)
由此，只要判断 Podfile 里生成的 Dependency 和 Pods/Manifest.lock 文件里记录的 Dependency 不一致则代表 pod changed，需要被更新。
通过查看 cocoapods-core 代码，Lockfile 类里已经有的 dependencies 数组，收集好了 Dependency 对象，Podfile 类里也已经提供好了 dependencies 数组。只要根据 pod name 从两个数组里分别匹配出 Dependency对象进行比对，如果不同则代表 pod changed，需要被更新。
思路大概就这样，具体改动可参考 PR 里的 files changed
private hofix
因为 PR 里 @dnkoutso 标记了 1.11.0 发布。感觉日常开发中遇到这个 bug 还挺严重的。如果 Jenkins 打包失败了还好，还能发现问题，万一不影响代码编译很有可能将错误代码提交给测试，甚至带到线上去。所以在组内发布了 private hofix 版本。基于当前的最新版本（1.10.2）cherry pick 了相关的 commit，发布了 1.10.2.9.private.hotfix 版本。作为在 1.11.0 出来之前的临时使用版本吧。
参考与佳期的个人博客：http://gonghonglou.com/2021/08/08/cocoapods-update-pod-sources/
网友评论