iOS

cocoapods-binary工作原理及改进

「这是我参与11月更文挑战的第4天，活动详情查看：2021最后一次更文挑战」

在iOS开发中，如果能够对一些稳定的组件能够二进制化，那么将大大的缩减我们在开发过程中的编译时间。在基于Cocaopods工程，快速实现Swift组件二进制一文中，我们讲述了，借助Pods工程和Shell脚本，一步实现二进制打包，但需要我们手动更改podspec文件，采用这种方式，如果作为依赖项加入到其他工程中，还会出现二进制和源码共存的情况，今天介绍一个cocoapods插件 cocoapods-binary，可以实现组件预编译，该工程已经两年多没维护了，随着pods更新，有了一些小bug。基于源码，我对该插件做了几点更改，又可以开心的玩耍了.在了解该插件之前，我们先大概了解下，输入pod install之后发生了什么？

Pod install

如果你想调试cocoapods工程，可以查看之前的文章Ruby和Cocoapods文章合集。

一图胜千言，当输入Pod install后

Pod install.png

1，首先校验是否有Podfile文件，并解析为Podfile对象
2，准备阶段，安装插件，调用pre_install阶段的插件
3，解析依赖，通过当前的Podfile文件和上一次的Pofile.Lock,Manifest.Lock文件进行比对，确认哪些文件需要更新。
4，下载依赖，更新需要更改的文件，并执行Podfile里面定义的pre_installhook函数。
5，集成阶段，生成新的Pods.xcodeproj工程文件，并执行Podfile里面的post_installhook函数。
6，写入新的Lockfile信息。
7，执行 post_install阶段的插件，并输出安装信息。

cocoapods-binary是以插件的形式，在Pod工程的pre_install阶段进行预编译的，

cocoapods-binary工作流

pre_install 插件

在 cocoapods-binary中的，通过HookManager来注册插件的执行时机

Pod::HooksManager.register('cocoapods-binary', :pre_install) do |installer_context|


end

主流程

主要流程如下图所示

截屏2021-11-28 下午7.20.16.png

1，必须使用framework的形式，也就是use_frameworks。
2，在Pods文件夹下，创建一个名为_Prebuild的文件夹，作为预编译沙箱。
3，在当前环境下，读取Podfile文件，并创建Podfile对象。
4，读取Podflie.lock文件，创建 Lockfile对象。
5，创建预编译安装器，沙箱地址为 预编译沙箱。
6，对比Podfile和 Podfile.lock，得到已更改的pod_name。
7，使用预编译安装器将 pod_name的源代码下载到预编译沙箱中，并生成新的Pods.xcodeproj文件。开始编译需要更新的framework。
8，回到主工程，继续执行 pod install的后续流程，在这一步修该需要二进制文件的podspec文件。

解析自定义参数

在插件中，有两个自定义的参数 :binary和all_binary!，是通过自定义DSL来实现的，有对这一块不熟悉的，可以参考我的这篇文章Cocoapods之 Podfile文件。

创建Podfile对象时，通过 method swizzling来hook:parse_inhibit_warnings方法，拿到我们在Podfile文件中写入的配置选项。将需要预编译的pod，保存到数组中。

old_method = instance_method(:parse_inhibit_warnings)

define_method(:parse_inhibit_warnings) do |name, requirements|

    variables = requirements

    parse_prebuild_framework(name, requirements)

    old_method.bind(self).(name, variables)

end

复制代码

在Ruby中，Method Swizzling主要分为三步：

1，获取parse_inhibit_warnings实例方法。
2，定义一个相同名字的方法。
3，调用原来的方法。

对比Lockfile

在这里 Podfle.lock和预编译沙箱中Manifest.lock是一样的，通过对比可以一个Hash对象

<Pod::Installer::Analyzer::SpecsState:0x00007f83370c61a8 @added=#<Set: {}>, @deleted=#<Set: {}>, @changed=#<Set: {}>, @unchanged=#<Set: {"Alamofire", "SnapKit"}>>

可以很清楚的知道哪些pod库发生了更改。如果有改动，则就在预编译沙箱进行install。

binary_installer.install!

在这一阶段，主要是在预编译沙箱中拉取framework源码和修改Pods.xcodeproj文件，在 Manifest.lock成功写入预编译沙箱，通过hook run_plugins_post_install_hooks函数，在预编译沙箱中，使用 xcodebuild命令，编译每一个需要更新的pod_target，并将编译好的framework放至GeneratedFrameworks目录下。

回到主工程执行pod install

截屏2021-11-28 下午8.22.44.png

编译完成后，就回到了主工程里面的 Pod install流程中。对:resolve_dependencies方法进行Method Swizzling，对需要更改的pod_target进行修改。通过修改内存中的Pod::Specification对象的vendored_frameworks、source_files、resource_bundles和resources属性，来引用已经编译好的framework。

工作流总结

通过对每一个阶段的了解，我们了解了作者的思路是这样的：
1，先将源码和Pods.project安装到预编译沙箱中。
2，借助于Pods.project工程，使用xcodebuild编译需要预编译的scheme。
3，巧妙的利用Method Swizzling，在分析依赖阶段，修改Pod::Specification对象，完成二进制的引用等工作。

现有问题

1，:binary => true 无效

在 ruby 2.6.8p205 (2021-07-07 revision 67951) [universal.x86_64-darwin21]版本中，使用:binary => true无效，无法编译为framework。在D ebug模式下生效，在发布后就失效了。

def set_prebuild_for_pod(pod_name, should_prebuild)

    Pod::UI.puts("pod_name: #{pod_name} prebuild:#{should_prebuild}")

    if should_prebuild == true

        @prebuild_framework_pod_names ||= []

        @prebuild_framework_pod_names.push pod_name

    else 

        @should_not_prebuild_framework_pod_names ||= []

        @should_not_prebuild_framework_pod_names.push pod_name

    end

end

在ruby 2.6.8中,release模式下，执行了两次，参数还不一致，导致 @prebuild_framework_pod_names和@should_not_prebuild_framework_pod_names相等，最终需要预编译的数组为[]

pod_name: SnapKit, should_prebuild:true

pod_name: SnapKit, should_prebuild:

2，pod update没有及时更新最新的framework

在frameworkA依赖frameworkB，在 Podfile中，只引入了 frameworkA

target xxx do 

    pod "frameworkA", :binary => true

end

当 frameworkB有新版本时，没有更新最新的frameworkB，对于我们自己的组件，我们期望有新版本发布时，能及时更新。

解决办法：
在检测更新的方法中，读取最新的Manifest.lock文件，读取已编译的framework的plist文件，比较两个版本号是否一致，不一致则重新编译。

cocoapods-binary-bel

为了能充分利用该插件，我根据实际产生的问题，对源码进行了一些修改，增加了 plist版本校验。使用方式和cocoapods-binary一致。
源码github链接cocoapods-binary-bel

安装

sudo gem install cocoapods-binary-bel

流程图

在 cocoapods-binary的基础上增加了版本校验工程，总的流程图如下所示：

一键转源码

1，:binary => false，指定某一个framework为源码

2，新增 --hsource选项，输入 pod install --hsource，可以将所有的framework转为源码。

去除了依赖分析

在实际运用的工程中，如果 A 依赖 B 和C, B又依赖D,如果 A需要预编译，那么 B、C 和 D都需要重新编译，实际上此时B、C、D已经有了已经编译好的版本，无需重新编译。在Podfile指明 B、C、D即可。

pod "A"

pod "B"

pod "C"

pod "D"

增加静态库的resource处理

在 cocoapods中，如果使用 resource_bundle 处理资源文件，会生成一个相对应的target来处理资源文件，如果是动态库，会在动态库的Target，添加资源工程依赖，使用 xcodebuild命令制作二进制会将bundle文件编译至xxx.framework目录下，使用 resources同样也会将资源文件编译至xxx.framework目录下。

对于静态库而言，如果是使用resource_bundle，也同样生成一个会生成一个相对应的target来处理资源文件，但对资源文件的拷贝，是由主工程做的，无需静态库工程处理，如果使用 resources，则需要将资源文件从源码中，拷贝到 xxx.framework下，在主工程编译时，由主工程处理即可。

作者：Bel李玉
链接：https://juejin.cn/post/7035628418972516360

0

2021-12-15

0 个评论

要回复文章请先登录或注册