cocoapods-binary工作原理及改进

·  阅读 3481

「这是我参与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,对比PodfilePodfile.lock,得到已更改的pod_name
  • 7,使用预编译安装器pod_name的源代码下载到预编译沙箱中,并生成新的Pods.xcodeproj文件。开始编译需要更新的framework
  • 8,回到主工程,继续执行 pod install的后续流程,在这一步修该需要二进制文件的podspec文件。

解析自定义参数

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

Podfile.png 创建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

lockfile.png 在这里 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!

pre_install.png 在这一阶段,主要是在预编译沙箱中拉取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_frameworkssource_filesresource_bundlesresources属性,来引用已经编译好的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文件,读取已编译的frameworkplist文件,比较两个版本号是否一致,不一致则重新编译。

cocoapods-binary-bel

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

安装

sudo gem install cocoapods-binary-bel
复制代码

流程图

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

cocoapods-binary-bel.png

一键转源码

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

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

去除了依赖分析

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

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下,在主工程编译时,由主工程处理即可。

如果觉得有收获请按如下方式给个 爱心三连:👍:点个赞鼓励一下。🌟:收藏文章,方便回看哦!。💬:评论交流,互相进步!

分类:
iOS
标签:
分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改