先前用美柚的 cocoapods-imy-bin 插件简单实现了部分 Pods 的二进制化，虽然功能不完善，但是起码还是先用上了。接入、回归测试期间发现些小的问题，整理一下后面再继续造轮子解决这些问题。
生成 bin 的方式，需要编写一个项目 spec，然后查看 Podfile.lock 中具体的版本，通过编写 spec.dependency 指定版本，然后插件打包上传，然后 pod install 生成对 bin 的依赖。
这里面的操作成本比较高：
1. 需要手工编写 spec；
2. 需要手工确认 Podfile.lock 中锁定的版本；
3. 某些源码打出来的包没有头文件、bundle；
4. 某些源码打出来的包可能是因为 macro 的问题有异常；
关于第一二点，理想状况只要在 Podfile mark 一下就应该自动搞定。
关于第三点，WCDB 用 cocoapods-packager 是有 header 的，WCDB.podspec 看了下也是没问题的，所以目前这种 packing 方式不满足我们的需求。
第四点提及的 macro 的问题则更多些，有点让人想放弃填坑的冲动，比如：
SDSWebImage 的 webp support，单独编译时就想不到要在 preprocess definition 上增加 SD_WEBP=1；
还有些与 Debug/Release/ARC Support 这些 macro 相关的条件编译，这意味着如果要 packing 一个 binary，这个 binary 大概率只能用在这个项目的某种编译环境中。
综上使用 source + tag/version/commit 的方式就不能用来作为这个 binary 的唯一标识。因为你不知道哪天引入的第三方库里面有多少条件编译代码，所以不得不时刻提防。
最终的形态应该是某个 binary 仅用在特定项目中，具体引用的 binary 要和编译参数内容相关。
由于目前插件采用的是源码白名单，那么白名单之外的 Pod 就自动使用了二进制，这种无感知会带来潜在的异常，比如：
有两个项目，A 使用 master-107-YYText，B 使用 private-107-YYText，两个项目同时开启二进制依赖。A 上传了 master-107-YYText-bin，而 B 不知情，插件导致错误地使用了 master-107-YYText-bin 。
在业务代码没有组件化的情况下，搞 Pods 的二进制化必要性一般，特别是有了 M1 的 Mac mini 之后，得益于 M1 超高的 IPC 和高性能 SSD，打包速度有了几倍的提升。
技术原理上没有特别复杂的东西，倒是工程化落地需要考量的细节比较多。
— May 19, 2021