前言
学如逆水行舟，不进则退。共勉！！！
今天给大家分享一篇A站的Swift实践。学习资料|领取地址
经过不断迭代，Swift如今已成iOS乃至苹果全平台首选开发语言，A站也已经完全投入到Swift浪潮中，享受到Swift语言带来的舒适和高效开发体验。《A站的Swift实践——上篇》介绍了Swift的技术背景、Swift的架构演进过程以及对最新框架SwiftUI和Combine等技术的选型。
如何混编
昨天刚刚结束的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] 、 拉仓库代码和资源的Co**coapods-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文件，内容如下：
__#import <UIKit/UIKit.h>
#else
#ifndef FOUNDATION_EXPORT
#if defined(__cplusplus)
#define FOUNDATION_EXPORT extern "C"
#else
#define FOUNDATION_EXPORT extern
#endif
#endif
#endif
#import "FMDatabase.h"
#import "FMDatabaseAdditions.h"
#import "FMDatabasePool.h"
#import "FMDatabaseQueue.h"
#import "FMDB.h"
#import "FMResultSet.h"
FOUNDATION_EXPORT double FMDBVersionNumber;FOUNDATION_EXPORT const unsigned char FMDBVersionString[];
上面代码中可以看到FMDatabase.h已经包含在文件中，因此Clang会将FMDB作为Module导入。Umbrella框架是对框架的一个封装，目的是隐藏各个框架之间的复杂依赖关系。构建完的Module会被存放到 ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/ 这个目录下面。
Clang编译单个OC文件是通过导入头文件方式进行的，而Swift没有头文件，所以Swift编译器Swiftc就需要先查找声明，再来生成接口。除此之外，Swiftc还会在Module Map文件和Umbrella Header文件中暴露的声明里查找OC声明。
如果工程要构建二进制库，需要支持Swift 5.1加的Module Stability和Library Evolution。
Name Mangling
找到OC声明后，Swiftc就需要进行Name Mangling。Name Mangling的作用在一方面是会像C++那样防止命名冲突，另外一方面是会对OC接口命名进行Swift风格化重命名。如果对Name Mangling命名的效果不满意，还可以回到OC源码中用NS_SWIFT_NAME重新定义想要在Swift使用的名字。
Swiftc的Name Mangling相比较于C和C++的Name Mangling会生成更多信息，比如下面的代码：
public func int2string(number: Int) -> String {
return "(number)"
}
Swiftc编译后，使用nm -g查看生成如下的信息：
0000000000003de0 T _$s8demotest10int2string6numberSSSi_tF
如上所示，信息中的$s表示全局，8demotest的demotest是Module名，8是Module名的长度。int2string是函数名，前面的10是类名长度，6number是参数名。SS表示参数类型是Int。Si表示的是String类型，_tF表示前面的Si是返回类型。
接下来对比一下Clang和Swiftc的编译过程，首先是Clang的编译过程，如下图
其次是Swift的编译过程，如下图：
从两者的对比中可以看出，Swift编译过程缺少了头文件，因为它通过分组编译模糊了文件的概念，减少了很多重复查找声明的工作，这样不仅仅可以简化代码的编写，还可以给编译器更多的发挥空间。
至于OC怎样调用Swift接口，Swiftc会生成一个头文件，代码中有Public的声明会先按文件生成Swiftmodule，文件链接完会合并Swiftmodule，最后整体生成到一个头文件里。过程如下图所示：
为什么可以调OC接口？
Swift代码之所以可以调OC接口，是因为OC的接口会被编译器自动生成为Swift语法接口文件。在Xcode中，在OC头文件中点击左上角的 Related Items，选择Generated Interface，就可以选择查看生成的Swift版本接口文件。自动转换成的Swift接口文件可以直接供Swift调用，在转换过程中，编译器会将NSString这种OC的基础库转换成Swift里对应的String、Date等Swift库。OC的初始化方法也会被转换成Swift的构造器方法。错误处理也会被转换成Swift风格。下面是OC和Swift转换对应的类型：
但是，仅仅只依赖于编译器的转换肯定是不够的，为了能让Swift调用得更加舒服，还需要对OC接口做些修改适配，比如将函数改成使用OC泛型，NSArray paths转成Swift是open var paths:[Any]；如果使用了泛型，将其改成 NSArray paths，那对应的Swift就是open var paths:[KSPath]，这种接口Swift使用起来会更方便有效。
苹果公司也提供了一些宏来帮助生成好用的Swift接口。
众所周知，OC之前一直缺少是非空的类型信息，可以通过 NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END包起来，这样就不用逐个去指定是非空了。NS_DESIGNATED_INITIALIZER宏可以将初始化设置为Designated，不加这个宏为Convenience。NS_SWIFT_NAME用来重命名Swift中使用的名称，NS_REFINED_FOR_SWIFT可以解决数据不一致的问题。
在iOS开发的过程中不可避免地需要访问 Core Foundation 类型，Core Fundation框架一旦导入到Swift混编环境中，它的类型就会被自动转为Swift类，Swift也会自动管理Annotated Core Foundation对象的内存，而不用像在OC中那样手动调用CFRetain、CFRelease或者CFAutorelease函数。Unannotated的对象会被包装在一个Unmanaged结构里，比如下面的代码：
CFStringRef showTwoString(CFStringRef s1, CFStringRef s2)
转成Swift就是：
func showTwoString(_: CFString!, _: CFString!) -> Unmanaged<CFString>! {
// ...
}
如上面代码所示，Core Fundation 类型的名字转换后会去掉后缀Ref，这是因为在Swift中所有类都是引用类型，Ref后缀比较多余。上面的Unmanaged结构有两个方法，一个是takeUnretainedValue()，另一个是takeRetainedValue()，这两个方法都是用来返回对象的原始未封装类型。如果对象之前没有Retain就用takeUnretainedValue()，已经Retain了，就用takeRetainedValue()。
在Swift里用getVaList(::😃 或withVaList(:😃 函数调用C的Variadic函数，比如 vasprintf(::😃。
调用指针参数的C函数，和Swift映射如下图：
Swift也有无法调用的C接口，比如复杂的宏、C风格的Variadic参数，复杂的Array成员等。简单赋值的宏会被转换成Swift里的常量赋值，对于复杂的宏定义，编译器无法自动转换，如果还是想享受宏带来的好处，比如可以避免重复输入大量模板代码和避免类型检查约束，可以通过函数和泛型替换获取同样的好处。\
Swift写出来的Module也可以给OC来调用。但是这样的调用会有很多限制，因为Swift中有很多类型是没法给OC用的，比如在Swift里定义的枚举、Swift定义的结构体、顶层定义的函数、全局变量、Typealiases、Nested类型，但是如果绕过这些类型，Swift也变得不那么Swift了。\
即使是实现了混编，开发者们还需要面对许多难题。因为在OC时代的很多问题，例如Hook，无痕埋点等可以在OC运行时很方便地实现，而Swift却缺少天然的支持。下面介绍一下Swift的动态性，在官方完善前，我们应该怎么使用它。
动态性
Swift在处理纯粹的Swift语言时是有自己的运行时的，但是对于“这个运行时是不提供访问的接口”的问题，Swift核心团队不是不做动态特性，而是因为如果想要支持动态特性就需要处理虚函数表（Virtual Method Table）的动态调用对SIL函数优化的影响，比如类没有被Override就会自动优化到静态调用，而这需要大量的时间。现阶段还有优先级更高的事情要做，比如并发模型、系统编程、静态分析支持类型状态等。因此，有人选择自己去实现一套Swift运行时，使得Swift代码具有动态特性。Jordan Rose[7] 实现了一个精简版的Swift [8] 运行时，更加严谨的运行时实现可以参考Echo[9] 和Runtime[10] 。
有人可能会问，SwiftUI的Preview不就是典型的在运行时替换方法的吗？他是怎么做到的呢？其实他使用的是@_dynamicReplacement属性，这是一个可以直接拿着用来进行方法替换的内部使用属性。
@_dynamicReplacement(for: runSomething())
static func _replaceRunSomething() -> String {
"replaced"
}
如果想要把上面的代码放到一个库中，并且在运行时加载这个库进行运行时方法替换可以通过这样的方式：
runSomething()
let file = URL(fileURLWithPath: "/path/of/replaceLib.dylib")
guard let handle = dlopen(file.path, RTLD_NOW) else {
fatalError("oops dlopen failed")
}
runSomething()
除了这个方法以外，还有其他办法可以进行运行时的方法替换吗？
值类型的方法替换
通过 AnyClass和class_getSuperclass方法可以查看Swift对象的继承链，没有继承NSObject的Swift类，会有一个隐含的Super Class，这个类会带有一个生成的带前缀的SwiftObject，比如_TtCs12_SwiftObject。Swift是实现了NSObject的一个objc运行时的类型，这个类型不能和OC交互。但是如果继承了NSObject就可以和OC交互。
如果方法或属性声明了 @objc dynamic，那么就可以在运行时通过动态派发在Swift对象上去调用，方法是：使用AnyObject的Perform方法去执行NSSelectorFromString里传入的方法或属性名。
对于Swift里的值类型，比如Struct、Enum、Array等，可以遵循_ObjectiveCBridgeable协议，经过Type Casting（显示或隐式）转成对应的OC对象类型。举个例子，如果想要查看Array的类继承关系，代码如下：
func classes(of cls: AnyClass) -> [AnyClass] {``
var clses:[AnyClass] = [] ``
var cls: AnyClass? = cls ``
while let _cls = cls { ``
clses.append(_cls) ``
cls = class_getSuperclass(_cls) ``
}
`` return clses
``}``
let arrays = ["jone", "rose", "park"]``
print(classes(of: object_getClass(arrays)!))``
// [Swift.__SwiftDeferredNSArray, Swift.__SwiftNativeNSArrayWithContiguousStorage, Swift.__SwiftNativeNSArray, __SwiftNativeNSArrayBase, NSArray, NSObject]`
如上面代码所示，Swift的Array最终都是继承自NSObject，其它值类型也类似。可以看出，所有Swift类型都是可兼容objc运行时的。因此可以给这些值类型添加objc运行时方法，代码如下：
// MARK: 为Swift类型提供动态派发的能力struct structWithDynamic {
public var str: String
public func show(_ str: String) -> String {
print("Say (str)")
return str
}
internal func showDynamic(_ obj: AnyObject, str: String) -> String {
return show(str)
}
}
let structValue = structWithDynamic(str: "Hi!")
// 为 structValue 添加Objc运行时方法
let block: @convention(block)(AnyObject, String) -> String = structValue.showDynamic
let imp = imp_implementationWithBlock(unsafeBitCast(block, to: AnyObject.self))
let dycls: AnyClass = object_getClass(structValue)!
class_addMethod(dycls, NSSelectorFromString("objcShow:"), imp, "@24@0:8@16")
// 使用Objc动态派发
_ = (structValue as AnyObject).perform(NSSelectorFromString("objcShow:"), with: String("Bye!"))!
如上面代码所示，取出函数闭包可以通过 @convertion(block)转换成C函数Call Convention来调用，C函数也可以直接去执行这个指针。使用 Memory Dump 工具可以查看Swift函数内存结构，以及解析出符号信息DL_Info。Memory Dump工具有Mikeash的memorydumper2[11] ，源码解读可以参考Swift Memory Dumping[12] 。逆向查看内存布局可以参考 《初探Swift Runtime：使用Frida实现针对Alamofire的抓包工具》[13]
类的方法替换
在运行时进行类方法的替换时，先将方法的Block以AnyObject类型传入imp_implementationWithBlock方法，返回一个imp，然后使用 class_getInstanceMethod 来获取实例的原方法，再通过 class_replaceMethod 进行方法替换，完整代码可以参看InterposeKit[14] ，另外还有一个使用libffi的方法替换库，参见SwiftHook[15] 。
另外，通过获取函数地址来改变函数指向位置的方法在Swift里实现比较困难，这是因为NSInvocation不可用了，因此需要通过C的函数来Hook Swift。在Swift的AnyClass中有类似OC的布局，记录了指向类和类成员函数的数据，这样就可以使用汇编来做函数指针替换的事情。思路是：保存寄存器，调用新函数，然后恢复寄存器，还原函数。具体可以参考项目SwiftTrace[16] 。
插桩
使用编译插桩的方式也可以实现运行中的方法替换，关键步骤在于编译时，需要使用DYLD_INSERT_LIBRARIES进行拦截，CommandLine.arguments可以得到Swiftc的执行参数，以查找待编译的Swift文件。通过苹果公司的SwiftSyntax[17] 源代码解析、生成和转换的工具可以查出所有方法，并插入特定的方法替换逻辑代码。修改完通过-output-file-map来获取mach-o的地址去覆盖先前产物。使用self.originalImplementation(…)调用原始的实现作为闭包传入execute(arguments:originalImpl:)方法。
ClassContextDescriptorBuilder
Swift运行时给每个类型保留了Metadata信息。Metadata是由编译器静态生成的，有了Metadata的调试才能够发现类型的信息。Metadata偏移-1是Witness table 指针，Witness Table 提供分配、复制和销毁类型的值，Witness Table 还记录了类型大小、对齐、Stride等其它属性。Metadata偏移量0的地方是Kind字段，其描述了Metadata所描述的类型的种类，例如Class、Struct、Enum、Optional、Opaque、Tuple、Function、Protocol等类型。这些类型的Metadata具体详述可见Type Metadata 的官方文档[18] ，代码描述可以在include/swift/ABI/MetadataValues.h[19] 里看到。比如在Metadata里类的方法数量会比实际代码里写的方法数量要多，那是因为编译器会自动生成一些方法，这些方法的种类在MethodDescriptorFlags类中Kind里描述了，代码如下：
enum class Kind {
Method,
Init,
Getter,
Setter,
ModifyCoroutine,
ReadCoroutine,
};`
可以看到，Getter、Setter以及线程相关读写的ModifyCoroutine、ReadCoroutine类型都是自动生成的。
Class的内存结构生成方法可以在 /lib/IRGen/GenMeta.cpp [20] 里找到：
- ClassContextDescriptorBuilder这个类是用来生成Class内存结构的，它继承于TypeContextDescriptorBuilderBase。
- Enum、Struct等类型的内存结构Builder基类都是继承于ContextDescriptorBuilderBase的TypeContextDescriptorBuilderBase。
- ContextDescriptorBuilderBase 是最基础的基类，Module、Extension、Anonymous、Protocol、Opaque Type、Generic都是继承于它。
- Struct的Metadata和Enum的Metadata共享内存布局，- -Struct会多个指向Type Context Descriptor的指针。
内存布局指的是使用一个Struct或者Tuple，根据每个字段的大小和对齐方式决定怎样来安排内存中的字段，在这个过程中，不仅需要描述清楚每个字段的偏移量，还有Struct或Tuple整体的大小和对齐方式。下面就是GenMeta里和Class类型相关的内存方法代码：
// 最底层基类 ContextDescriptorBuilderBase的布局方法
void layout() {
asImpl().addFlags();
asImpl().addParent();
}
// TypeContextDescriptorBuilderBase的布局方法
void layout() {
asImpl().computeIdentity();
super::layout();
asImpl().addName();
asImpl().addAccessFunction();
asImpl().addReflectionFieldDescriptor();
asImpl().addLayoutInfo();
asImpl().addGenericSignature();
asImpl().maybeAddResilientSuperclass();
asImpl().maybeAddMetadataInitialization();
}
// ClassContextDescriptorBuilder的布局方法
void layout() {
super::layout();
addVTable();
addOverrideTable();
addObjCResilientClassStubInfo();
maybeAddCanonicalMetadataPrespecializations();
}
根据GenMeta可以看到Swift的Class类型内存布局是根据ContextDescriptorBuilderBase、TypeContextDescriptorBuilderBase再到ClassContextDescriptorBuilder继承层层叠加的，因此对应Class类型的Nominal Type Descriptor就可以用如下C结构来描述：
struct SwiftClassInfo {
uint32_t flag;
uint32_t parent;
int32_t name;
int32_t accessFunction;
int32_t reflectionFieldDescriptor;
...
uint32_t vtable;
uint32_t overrideTable;
...
};
代码中可见，add的前缀就是增加的偏移记录，addFlags后面的addParent就是下一个偏移的记录。FieldDescriptor换成ReflectionFieldDescriptor是苹果公司在5.0版本对Metadata做的改变，官方Mirror反射目前还不完善，有些信息还没法提供，因此在Metadata里增加了一些反射相关信息。
OC动态调用方法会把_cmd作为第一个参数，第二个参数是Self，后面是可变参数列表，动态调度可以在运行时添加类、变量和方法。而在Swift中动态调用方法是基于VTable的，运行时没法对方法进行动态搜索，地址在编译时静态写在了VTable里，运行时不能改，可以用静态地址调用，或dlsym来搜索名称。
VTable的地址在TypeContextDescriptor之后，OverrideTable存储位置在VTable之后，有三个字段来描述，第一个是记录哪个类被重写，第二个是被重写的函数，第三个是用来重写的函数相对的地址。因此通过OverrideTable就可以找到重写前和重写后函数指针，这样就有机会在VTable里找到对应函数进行函数指针的替换，达到Hook的效果。要注意，在Swift编译器设置优化时VTable的函数地址可能会清空或使用直接地址调用，这两种情况发生的话就没法通过VTable进行方法替换。
那么还有其它思路吗？这里先提供一波资料包。
iOS学习资料包|领取地址
Mach_override
使用Wolf Rentzsch[21] 写的M ach_override[22] 也是一种方法，可以在原始函数的汇编里加个jmp，跳到自定义函数，然后再跳回原始函数。Mach_override_ptr的三个参数分别是，一，要覆盖函数的指针；二，去覆盖函数的指针；三，参数可以设置为原函数的指针地址，待Mach_override_ptr返回成功，就可以调原函数。Mach_override会分配一个虚拟内存页，使其可写可执行。需要注意的是，Mach_override_ptr初始函数和重入函数指针相同，调用后，重入函数将调用替换函数而不是原始函数。在Swift中如何使用Mach_override可参考SwiftOverride[22] 。
总结
通过上下篇的介绍，想必你已经了解到A站为拥抱Swift都做了哪些事情。基于A站以及快手主站的一些架构师对于Swift的热爱，以及为之付于的实践，A站的开发体验才得以蜕变。
为了让OC开发同学能够掌握Swift，以更“Swift”的方式进行开发，A站组织了十多次Swift组内的培训和分享，并规范了Swift代码风格和静态检查流程。针对开发体验上的痛点，A站在2020年上半年就开始了混编工程的优化、组件化以及二进制化的建设。完成了分层设计，渐进式地将模块解耦下沉到对应的分层，进而可以借助LLVM Module来抹平模块API在语言上的差异，从而代替Swift和Objective-C在主工程的桥接，为10+ A站和中台的基础库进行了Module化问题修复，并基于主站的二进制化方案 （GUNDAM）完善了对Swift以及混编的支持。从Swift ABI Stability进化为Module Stability的XCFramework，WWDC的Session[23] 很好的说明XCFramework的原理，同时表示XCFramework格式对Objective-C/C/C++也有很好的支持。目前组件的二进制化率约为80%，约有50%的组件已经完成了LLVM Module化，构建时间提升了60%以上。随着Swift优势的逐渐体现以及团队Swift能力建设的推进，A站更多的工程师开始倾向于使用Swift进行业务开发，而Swift带来的“加速度”，也让技术团队切实地感受到了强烈的“推背感“。
当然，A站也曾遇到一些Swift的Bug，比如打包RxSwift5后遇到模块名和类名一样所产生的Bug和Issue[24] ，RxSwift6通过避免使用Typealias的类型曲线形地解决了这个问题，目前此问题已被官方标记为“解决”，后面的版本可以正常使用。另外还有两个未解决的问题，一个是在Module的接口中出现Ambiguous Type Name Error问题，参考Issue[25] ； 另一个是Import后产生.swiftinterface出现的错误，参见网站Issue[26] 。
最后想说的是，Swift开发并不容易，不要被Swift简洁的语法所迷惑，各种大小括号组合会让开发者们感到困惑，还有一些特性会让直观理解变得很困难，比如下面的代码：
`let str:String! = "Hi"
let strCopy = str
根据Swift类型推导的特性，按道理str类型加上感叹符号后，strCopy就会被自动推导为非可选String类型。但实际情况是，按照官方文档[27] 的说法，strCopy没有直接指明类型，即隐式可选值时，str类型是String后加上感叹号，这种是属于隐含解包可选值String无法推导出非可选String类型，因此Swift会先将strCopy作为一个普通可选值来用，这样和直观的感觉非常不一样。
本以为5.0的ABI在稳定后，Swift学起来会更容易，但是其实新的SwiftUI和Combine这样重量级的框架需要开发者继续钻研，真是“Write Swift, Learn Every Year”。Swift不断从其它语言中吸取精髓，接下来的async/await，你准备好了吗？要用上，先得看咱家APP系统最低版本是不是能够支持这些新特性。
虽说不容易，但为了稳定和效率，终究跟上了时代的步伐。
推荐阅读：iOS自动编译