iOS 静态库及动态库开发

开发者技术前线

发布于 2020-11-23 11:32:53

7530

发布于 2020-11-23 11:32:53

文章被收录于专栏：开发者技术前线

快讯

12月15日，滴滴正式宣布推出小巴业务，该产品通过搭建算法模型和大数据计算能力，优化站点和路线规划，专注解决用户3公里以内的短途出行问题。此外，12月13日，滴滴出行宣布滴滴公交与行业龙头天津市公交集团展开深度战略合作。

心得

昨天参加上海GDG大会，技术交流的同时也认识了很多朋友，提出了两个问题，情商和技术在职业生涯中哪个尤为重要？怎么权衡工作和生活！可能不同的人在不同阶段有不同的规划！老话说：100个人有100个哈雷波特！

阅读文章需要几分钟，伴随早晨的第一缕阳光！开启新的一周，无论你在北京，上海，广州，深圳, 还是其他城市。或许你像我一样在这些城市的地铁，公交，或者它的每个角落！就让我的文章陪着拼搏的你一直前行！依旧来首经典的歌曲！GO！

开始

本文总结在好房移动架构团队做 Framework 开发中的一些经验。之前负责好房 APP 开发时，需要支持 iOS 7+，所以五月份设计统计 SDK 时只好采用静态库的方式。随着 iOS 10 的推出，iOS 7 的支持默认被移除，结合 APP 的用户设备分布，目前 APP 已改为支持 iOS 8+，所以上个月设计的 React Native 增量 Patch 更新 SDK 可采用动态库的方案。

至于 iOS 中静态库与动态库的差别，网上有很多文章介绍，本文不再赘述，而将重点放在这两种库的具体开发实现过程。

静态库

Google 的工程师已经写了一篇非常赞的文章(https://github.com/jverkoey/iOS-Framework)，好房统计 SDK 就是按照此方案一步步配置的。经验证，效果非常好。其提供的脚本也很精致，无冗余。

当然 Raywenderlich 的网站也有一篇文章(https://www.raywenderlich.com/65964/create-a-framework-for-ios)，方案类似，相比于 Google 程序员写的指南，多个实例。初次接触静态库开发的开发者可以读一读。

故此处也不再重复介绍。

动态库

Xcode自带的 framework 模板，创建的动态库（包含资源）可以在iOS 7上跑（真机测试过），但官方要求iOS 8+，可能提交 app store 验证不过。

更大的问题就是提交 app store 时会提示包含 x86_64, i386 ...

该问题在 Xcode 6.3.2 之前及 7.1 上都有开发者遇到，PSPDFKit 这个库的开发者是在分发动态库时在 framework 里嵌入一个 shell 脚本，供使用方在 Xcode 里运行。我最终没有采用该方式。

关于动态库的更多讨论，有一篇文章(http://stackoverflow.com/questions/30963294/creating-ios-osx-frameworks-is-it-necessary-to-codesign-them-before-distributin)值得一看。

有上述背景知识，我们的动态库的具体做法：

针对 Dynamic Library

工程中Dynamic Library,仿照 jverkoey 文章中的 Aggregate 脚本，很 Easy ！

SDK_NAME"exit 1

fi if [[ "SF_SDK_PLATFORM" = "iphoneos" ]]
then

SF_OTHER_PLATFORM=iphonesimulator
else

SF_OTHER_PLATFORM=iphoneos
fi if [[ " ]]
thenSF_OTHER_BUILT_PRODUCTS_DIR="BULT_PRODUCTS_DIR"

exit 1 fi 

rm -r "{CONFIGURATION}"

 -sdk {BUILD_ROOT}" 
 SYMROOT="

业务工程脚本增加

https://github.com/realm/realm-cocoa/blob/f07d1af226b67c0aefb150d12da3fd34c5d64087/scripts/strip-frameworks.sh

该脚本从动态库里移除不必要的处理器架构。因为改动了 ipa 中动态库的可执行文件，所以该 strip 脚本还需要重新对动态库中可执行文件签名。正因为会重新签名，Embed Framework 处不必勾选 Code Sign on Copy。

第三方依赖

我的做法是尽量不引入第三方代码到我的 Framework 中。但如果有些算法类的库，比如 ZipArchive 等，很多时候还是需要在 Framework 中用的。直接把第三方代码拉进来，可能会和业务方引入的代码冲突。怎么办？

@Kamil Burczyk在他的文章(http://blog.sigmapoint.pl/avoiding-dependency-collisions-in-ios-static-library-managed-by-cocoapods/)中给出了一种通过脚本改类名的方案。

我们的方案是在 Framework 的工程里，只引入第三方的头文件。要求APP业务方使用时确保引入第三方库。