快手海外Swift/ObjC混编与二进制化工程实践

背景介绍

在苹果的全力推动下，Swift逐渐成为MacOS和iOS生态的主力语言，以替换老旧的ObjectiveC语言(以下简称OC)。自Swift诞生以来，苹果不断完善语言的表达能力和生态环境，使其从饱受诟病到日趋完善。

Swift语言具有语法简洁、多范式、健壮性强、性能高等诸多优点，如今越来越多的开发者投入到了Swift的怀抱，快手海外客户端团队在Kwai-Pro、MV Master、Zynn等项目中也积累了不少Swift和OC混编的经验。为了有效提高编译效率，团队又进一步展开了对Swift/OC二进制化混编的探索，解决了实践中碰到的诸多问题。本文将和大家分享这些经验。

单Target混编

单一Target比较简单，在Build setting中设置bridging header，使Swift可以访问OC，Swift也会编译出-Swift.h来给OC调用，这样就可以实现Swift和OC的混编开发。

需要注意的是，如果使用bridging header的方式就无法开启Swift版本兼容功能。所以，我们更推荐使用的方式是OTHER_SWIFT_FLAGS标记-import-underlying-module，配合HEADER_SEARCH_PATHS来使用Swift访问OC的接口。在下文中的多Target混编部分会对此有详细的讨论。

多Target混编

快手海外已经启动组件化的改造工作，组件化以后，每个Pod组件都使用独立的Target编译，这就要求我们必须解决多Target下的Swift/OC混编问题。这个过程里我们碰到了不少问题，总结下来，有以下几道坎需要迈过。

第一道坎：OC组件Clang module化

Swift组件若依赖其它含OC代码的Pod组件，那些组件必须使用Clang module来组织，这个在戴铭老师的《A站的 Swift 实践——上篇》一文中也提到过。Clang module（以下简称Module)定义了一种新的OC模块向外暴露公开接口的方式，Clang编译器在v13版本添加了新的编译参数来支持这种方式。这里不对Module的细节做进一步展开，有兴趣的读者可以去查阅Modules-Clang 13 Document[1]。

从代码实践上说，Module带来了两个好处：

第一，避免了宏对代码上下文的污染。

第二，提高了编译的效率。在每次编译过程中，每个Module只会被加载一次，并且编译器会将编译好的部分缓存起来，避免了多次引入加载相同头文件带来的耗时问题，所以使用module的编译效率会更高，被复用越多的组件，module化后的收益越明显。

那么在实践中，如何对Cocoapods组件进行Module化改造呢？

打开Module的方法很简单，在Podfile中把pod参数设置为: modular_header => true，pod install执行之后便会自动生成modulemap与umbrella.h。但是Module和非Module的传统OC组件混合编译时，会存在很多问题：

其一，module具有传递性，如果一个module组件A所暴露的头文件中导入了组件B的头文件，那么组件B也必须是module。

其二，引用module组件的头文件时，必须采用#import <Framework/FrameworkHeader.h>和@import Framework.FrameworkHeader 的方式，而不像传统header search path那样可以直接使用双引号、尖括号头文件的方式。

如果module中含有Swift代码并且构建产物不是Framework，建议在 build phase 中添加 script，处理编译后需要做两件事：一是将编译生成的 -Swift.h 拷贝到 public header 路径以供其他组件使用；二是将编译生成的swiftinterface追加到modulemap目录下以供其他组件使用。