A站 的 Swift 实践 —— 下篇

如何混编

昨天刚刚结束的Google I/O让人想起了Kotlin在三年前曾经上过一次热搜，Google I/O官宣Kotlin替代Java，正式成为Android开发的首选语言。正所谓演进的力量，这一切都要归功于苹果公司在2014年推出的Swift替代了Objective-C，成为iOS乃至苹果全平台首选的开发语言，从而提高了iOS开发者的热情。上篇介绍了Swift的技术背景以及如何选择开发框架。下篇的内容会介绍大多数以OC为主体的工程如何与Swift共舞，以及如何利用Swift动态性解决工程难题。

如果你的工程是OC开发的，要用上Swift就需要进行OC和Swift的混编开发。

然而，混编开发应该怎么开始呢？有没有什么前置条件？

前置条件

混编本质上就是把OC语法的声明通过编译工具生成Swift语法的声明，这样Swift就可以通过生成的声明直接调用OC接口。反之，OC调用Swift接口也可以通过相同的方法，把Swift语法的声明生成OC语法的头文件。这些转换生成的编译工具都集成在开发工具Xcode里。

Xcode其实就是执行多命令行的工具，比如Clang、ld等等。Xcode、Project文件里包含了这些命令的参数和它们执行的顺序，也有所有待编译文件和它们的依赖关系。llbuild[1]是低等级构建系统，根据Xcode Project里的配置按顺序执行命令。命令行工具的参数配置是在Xcode的Build Settings里进行设置的。如果是在同一个Project里混编，首先需要将Build Settings里Always Embed Swift Standard Libraries设置为YES，然后在桥接文件，也就是ProductName-Bridging-Header.h里导入需要暴露给Swift的OC类。如果Swift要调用的OC在不同Project里，则需要将OC的Project设置为Module，将Defines Module设为YES，再把Module里的头文件导入到OC Modulemap文件里的Umbrella Header里。

如何设置CocoaPods

Swift Pod的Podspec需要写明对OC Pod的依赖。在工程Podfile中，OC Pod后面要写 :modular_headers => true。开启Modular Header就是把Pod转换为Module。那CocoaPods究竟做了什么？执行  Pod Install -- Verbose就可以看到，在生成Pod Targets时，CocoaPods会生成Module Map File和Umbrella Header。

每个工程设置的情况千奇百怪，而CocoaPods主要是通过自己的dsl配置来完成这些编译参数的设置，所以就需要先了解些混编设置的编译参数和概念：

• 前面提到的Defines Module，需要设置为YES。

• Module Map File表示 Module Map的路径。

• Header Search Paths代表Module Map定义的OC头文件路径。

• Product Module Name的默认设置和Target Name一样。

• Framework Search Paths是设置依赖Framework的搜索路径。

• Other C Flags可以用来配置依赖其它Module文件路径。

• Other Swift Flags可以配置其Module Map文件路径。

CocoaPods的主要组件有解析命令的CLAide[2]、用来解析Pod描述文件，比如Podfile、Podfile.lock和PodSpec文件的Cocoapods-core[3]、拉仓库代码和资源的Cocoapods-downloader[4]、分析依赖的Molinillo[5]、以及创建和编辑Xcode的.xcodeproj和.xcworkspace文件的Xcodeproj[6]。在执行了Pod Install以后，组件调用流程以及配置Module所处流程位置，如下图所示：

按照上图的逻辑，Integrates这一步主要是用来配置Module的。先检查Targets，主要是对于包括Swift版本和Module依赖等问题的检查，然后再使用Xcodeproj组件做Module的工程配置。

完成以上工作后，如果我们想要在Swift里使用OC开发的库FMDB，就可以直接使用Import来导入，代码如下：

import UIKit
import FMDB

class SwiftTestClass: NSObject {
    var db:FMDB.FMDatabase?

    override init() {
        super.init()
        self.db = FMDB.FMDatabase(path: "dbname")
        print("init ok")

    }
}

可以看到，Import FMDB将FMDB的Module倒入进来后，接口依然能够直接使用Swift语法调用。

这里需要注意的是，Module依赖的Pod也需要是Module。因此改造时需要从底向上地改造成Module。另外，开启Module后，如果某个头文件在Umbrella Header里，那么其它包含这个头文件的Pod也需要打开Module。

为什么要用Module？

在Module被使用之前，开发者们需要对要导入的C语言编译器处理方式类头文件进行预处理，查找头文件里还导入了哪些头文件，递归直到找到全部头文件。但是，预处理的方式会遇到许多问题。其一，编译的复杂度高且耗时长，这是因为每个可编译的文件都会单独编译进行预处理，所以在预处理过程中递归查找导入头文件的工作会重复很多次，尤其是当包含关系很深的头文件被很多.m所导入的时候；其二，会出现宏定义冲突时需要重新排序以及和解依赖的问题等。

Module相对来说更加简易，它的头文件只需要解析一次，所以编译的复杂度会指数级降低，且编译器对Module的处理方式和C语言的预处理方式是完全不同的。编译器会将要编译的文件导入的头文件生成二进制格式，存储在Module Cache中，编译时如果碰到需要导入模块时，会先检查Module Cache，有对应的二进制文件就直接加载，没有才会解析，以此来保证Module解析只有一次。重新解析编译Module只会发生在头文件包含的任何头文件有变动，或者依赖另外一个模块有更新的时候。比如下面的代码：

#import <FMDB/FMDatabase.h>

Clang会先从FMDB.framework的Headers目录里查找FMDatabase.h，再去FMDB.framework的Modules目录里查找module.modulemap文件，分析module.modulemap来判断FMDatabase.h是否是模块的一部分。Module Map用来定义Module和头文件之间的关系。FMDB.framework的module.modulemap的内容如下：

framework module FMDB {
  umbrella header "FMDB-umbrella.h"

  export *
  module * { export * }
}

想要确定FMDatabase.h是否是Module的一部分就要看module.modulemap里的Umbrella Header文件，即FMDB-umbrella.h目录里是否包含了FMDatabase.h。在Headers目录里查看FMDB-umbrella.h文件，内容如下：

#ifdef __OBJC__
#import <