一、ABl是什么  

每个操作系统都会为运行在该系统下的应用程序提供应用程序二进制接口（Application Binary Interface，即ABI）, 描述了应用程序和操作系统之间，一个应用和它的库之间的接口。与API不同的是：ABI允许编译好的目标代码在使用兼容ABI的系统中无需改动就能运行，而API则是定义 源代码 和 库 之间的接口，同样的代码可以在支持这个API的任何系统中编译。

ABI包含了应用程序在这个系统下运行时必须遵守的编程约定。ABI总是包含一系列的系统调用和使用这些系统调用的方法，以及关于程序可以使用的内存地址和使用机器寄存器的规定。从一个应用程序的角度看，ABI既是系统架构的一部分也是硬件体系结构的重点，因此只要违反二者之一的条件约束就会导致程序出现严重错误。在很多情况下，链接器为了遵守ABI的约定需要做一些重要的工作。例如，ABI要求每个应用程序包含一个程序中各例程使用的静态数据的所有地址表，链接器通过收集所有链接到程序中的模块的地址信息来创建地址表。

在 iOS 和 macOS 平台，Swift编写的二进制程序在运行时通过ABI与其他程序库或组件进行交互。程序的编译会产生一个或者多个二进制实体，这些二进制实体必须在一些很底层的细节上达成一致，才能被链接在一起执行。可以说ABI就是一个规范，一种协议。它会规定如何调用函数，如何在内存中表示数据，甚至是如何存储和访问metadata。ABI底层包装的是具体平台硬件相关的程序代码了。

ABI涵盖了各种细节，如：

• 数据类型的大小、布局和对齐；

• 调用约定（控制着函数的参数如何传送以及如何接受返回值），例如，是所有的参数都通过栈传递，还是部分参数通过寄存器传递；哪个寄存器用于哪个函数参数；通过栈传递的第一个函数参数是最先push到栈上还是最后；

• 系统调用的编码和一个应用如何向操作系统进行系统调用；

• 以及在一个完整的操作系统ABI中，目标文件的二进制格式、程序库等等。

ABI稳不稳定与Swift版本是无关的，取决于swift的编译器版本。Xcode10.2集成了swift5.0编译器，只要使用这个版本以上的编译器，编译出来的二进制就是ABI稳定的。Swift5.0编译器提供了Swift4的语法兼容，也就是说即使你的项目代码仍然是swift4，编译出来的二进制也是ABI稳定的。

二、ABI稳定的意义

ABI稳定是指把ABI锁定在某种形式，以至于未来的编译器都可以生成遵从这种形式的二进制实体（可以是程序库，也可以是应用程序）。ABI稳定之后，OS发行商就可以把Swift标准库和运行时作为操作系统的一部分嵌入。也就是说Apple 会把Swift runtime 放到 iOS 和 macOS 系统里，我们的swift App包里就不需要包含应用使用的标准库 和Swift runtime 拷贝了。同时在运行的时候，只要是用 Swift 5 (或以上) 的编译器编译出来的 binary，就可以跑在任意的 Swift 5 (或以上) 的 runtime 上。

ABI稳定带来了以下好处：

• 大量减小app体积
  针对已经嵌入swift runtime的系统(macOS 10.14.4, iOS 12.2, tvOS12.2, watchOS5.2)，

• 所有app使用同一个运行时， app启动不需要额外加载Swift runtime，在新系统上会更快更节省内存

• Apple工程师可以在系统框架中使用Swift了
  系统中统一使用了稳定的ABI之后，受益最大的应该就是Apple本身了。他们可以编写纯Swift系统框架了，不需要包一遍OC，代码运行效率会更高，维护成本也更低。

当然ABI稳定也有其弊端，集成到OS的Swift runtime只能伴随iOS系统更新才会更新，不像稳定之前我们自己打包的会随着App更新而更新。语言新特性的使用会开始受限于系统，后续的开发过程中新特性的使用就需要添加版本判断这种胶水代码，类似我们熟悉的远程推送的注册这种版本判断。

通常，如果一门编程语言在表现力和性能上均表现良好，并且还提供了二进制接口，它就很容易表现出二进制接口很脆弱的问题。对于用这种语言编写的程序库或组件来说，要让用户在不重新编译源码的条件下使用新版本的程序库是很难的。当前，Swift主要的前进方向是标准库的进化，自然就要给开发者在维护二进制兼容性这个问题上更多进退的空间。很多实现上的考量的确会对ABI的设计有所影响。

对ABI做的每一个决定都会对编程语言产生长远的影响，甚至会制约一门编程语言在未来可以发展和进化的空间。Swift未来的版本可能会在更多垂直领域为ABI添加特性，但只要声明了某个平台的ABI已稳定，那么任何在效率以及灵活性上曾经不妥的设计都将永远伴着这个平台存在。

一旦ABI稳定了，就意味着它会伴着这个平台的一生一世，直至日益增长的依赖关系让它走向灭亡。

swift已经经历了五大版本，才声明ABI稳定的一个主要目的，就是为程序库的进化保留足够的灵活性，而不希望开发者由于ABI的稳定性而限制设计空间。

ABI与API的区别

应用程序接口（Application Programming Interface，API），又称为应用编程接口，就是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大，常常需要把复杂的系统划分成小的组成部分，编程接口的设计十分重要。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的维护性和扩展性。

ABI不同于API ，API定义了源代码和库之间的接口，因此同样的代码可以在支持这个API的任何系统中编译 ，然而ABI允许编译好的目标代码在使用兼容ABI的系统中无需改动就能运行。 ABI掩盖了各种细节，例如:调用约定控制着函数的参数如何传送以及如何接受返回值；系统调用的编码和一个应用如何向操作系统进行系统调用；以及在一个完整的操作系统ABI中，对象文件的二进制格式、程序库等等。一个完整的ABI，像 Intel二进制兼容标准 (iBCS) ，允许支持它的操作系统上的程序不经修改在其他支持此ABI的操作系统上运行。其他的 ABI 标准化细节包括C++ name decoration和同一个平台上的编译器之间的调用约定，但是不包括跨平台的兼容性。在Unix的操作系统中，存在很多运行在同一件平台上互相相关但是不兼容的操作系统（尤其是80386兼容系统）。有一些努力尝试标准化A I，以减少销售商将程序移植到其他系统时所需的工作。然而，还没有很成功的例子，虽然LSB正在为Linux做这方面的努力。

它描述了应用程序与OS之间的底层接口。ABI涉及了程序的各个方面，比如：目标文件格式、数据类型、数据对齐、函数调用约定以及函数如何传递参数、如何返回值、系统调用号、如何实现系统调用等。

一套完整的ABI（比如：Intel Binary Compatibility Standard (iBCS)），可以让程序在所有支持该ABI的系统上运行，而无需对程序进行修改。

  Swift 社区最近最重大的新闻应该就是 ABI 稳定了。这个话题虽然已经讨论了有一阵子了，但随着 Xcode 10.2 beta 的迭代和 Swift 5 的 release 被提上日程，最终 Swift ABI 稳定能做到什么程度，我们开发者能做些什么，需要做些什么，就变成了一个重要的话题。Apple 在这个月接连发布了 ABI Stability and More 和 Evolving Swift On Apple Platforms After ABI Stability 两篇文章来阐述 Swift 5 发布以后 ABI 相关的内容所带来的改变。虽然原文不是很长，但是有些地方上下文没有说太清楚，可能不太容易理解。本文希望对这个话题以问答的形式进行一些总结，让大家能更明白将要发生的事情。

我是一个 app 开发者，Swift 5 发布以后会怎么样？

  简单说，安装 Xcode 10.2，然后正常迁移就可以了，和以往 Swift 3 到 Swift 4 需要做的事情差不多。单论 Swift 5 这个版本，不会对你的开发造成什么影响，直到下一个版本 (比如 Swift 5.1) 之前，你几乎不需要关心 ABI 稳定这件事。关于下个 Swift 版本，我们稍后会提到这件事情。

我还是想知道什么是 ABI 稳定？

  就是 binary 接口稳定，也就是在运行的时候只要是用 Swift 5 (或以上) 的编译器编译出来的 binary，就可以跑在任意的 Swift 5 (或以上) 的 runtime 上。这样，我们就不需要像以往那样在 app 里放一个 Swift runtime 了，Apple 会把它弄到 iOS 和 macOS 系统里。

所以说 app 尺寸会变小？

  是的，但是这是 Apple 通过 App Thinning 帮我们完成的，不需要你操心。在提交 app 时，Apple 将会按照 iOS 系统创建不同的下载包。对于 iOS 12.2 的系统，因为它们预装了 Swift 5 的 runtime，所以不再需要 Swift 的库，它们会被从 app bundle 中删掉。对于 iOS 12.2 以下的系统，外甥打灯笼，照旧。

  一个新创建的空 app，针对 iOS 12.2 打包出来压缩后的下载大小是 26KB，而对 iOS 12.0 则是 2.4MB。如果你使用了很多标准库里的东西，那这个差距会更大 (因为没有用到的标准库的符号会被 strip 掉)，对于一个比较有规模的 app 来说，一般可以减小 10M 左右的体积。

还有什么其他好处么？

  因为系统集成了 Swift，所以大家都用同一个 Swift 了，app 启动的时候也就不需要额外加载 Swift，所以在新系统上会更快更省内存。当然啦，只是针对新系统。

  另外，对于 Apple 的工程师来说，他们终于能在系统的框架里使用 Swift 了。这样一来，很多东西就不必通过 Objective-C wrap 一遍，这会让代码运行效率提高很多。虽然在 iOS 12.2 中应该还没有 Swift 编写的框架，但是我们也许能在不久的将来看到 Swift 被 Apple 自己所使用。等今年 WWDC 的消息吧。

我还想用一段时间的 Xcode 10.1，不太想这么快升级

  Xcode 10.1 里的是 Swift 4.2 的编译器，出来的 binary 不是 ABI 稳定的，而且必定打包了 Swift runtime。新的系统发现 app 包中有 Swift runtime 后，就会选择不去使用系统本身的 Swift runtime。这种情况下一切保持和现在不变。旧版本的 Xcode 只有旧版本的 iOS SDK，所以自然你也没有办法用到新系统的 Swift 写的框架，系统肯定不需要在同一个进程中跑两个 Swift runtime。

  简单说，你还可以一直使用 Xcode 10.1 直到 Apple 不再接受它打包的 app。不过这样的话，你不能使用新版本 Swift 的任何特性，也不能从 ABI 稳定中获得任何好处。

我升级了 Xcode 10.2，但是还想用 Swift 4 的兼容模式，会怎么样？

首先你需要弄清楚 Swift 的编译器版本和语言兼容版本的区别：

  同一个 Xcode 版本默认使用的编译器版本只有一个 (在你不更换 toolchain 的前提下)，当我们在说到“使用 Xcode10.2 的 Swift 4 兼容模式”时，我们其实指的是，使用 Xcode 10.2 搭载的 Swift 5.0 版本的编译器，它提供了 4.2 的语法兼容，可以让我们不加修改地编译 Swift 4.2 的代码。即使你在 Xcode 10.2 中选择语言为 Swift 4，你所得到的二进制依然是 ABI 稳定的。ABI 和你的语言是 Swift 4 还是 Swift 5 无关，只和你的编译器版本，或者说 Xcode 版本有关。

多提一句，即使你选择了 Swift 4 的语言兼容，只要编译器版本 (当然，以及对应的标准库版本) 是 5.0 以上，你依然可以使用 Swift 5 的语法特性 (比如新增加的类型等)。

看起来 ABI 稳定很美好，那么代价呢？

  Good question! 我们在第一个问题里就提到过，一切都会很美好，直到下一个版本。因为 Swift runtime 现在被放到 iOS 系统里了，所以想要升级就没那么容易了。

  在 ABI 稳定之前，Swift runtime 是作为开发工具的一部分，被作为库打包到 app 中的。这样一来，在开发时，我们可以随意使用新版本 Swift 的类型或特性，因为它们的版本是开发者自己决定的。不过，当 ABI 稳定后，Swift runtime 变为了用户系统的一部分，它从开发工具，变为了运行的环境，不再由我们开发者唯一决定。比如说，对应 iOS 13 的 Swift 6 的标准库中添加了某个类型 A，但是在 iOS 12.2 这个只搭载了 Swift 5 的系统中，并没有这个类型。这意味着我们需要在使用 Swift 的时候考虑设备兼容的问题：如果你需要兼容那些搭载了旧版本 Swift 的系统，那你将无法在代码里使用新版本的 Swift runtime 特性。

  这和我们一直以来适配新系统的 API 时候的情况差不多，在 Swift 5 以后，我们需要等到 deploy target 升级到对应的版本，才能开始使用对应的 Swift 特性。这意味着，我们可能会需要写一些这样的兼容代码：

// 假如 Swift 6.0 是 iOS 13.0 的 Swift 版本
if #available(iOS 13.0, *) {// Swift 6.0 标准库中存在 Alet a = A()
} else {// 不存在 A 时的处理
}

  对于“新添加的某个类型”这种程度的兼容，我们可以用上面的方式处理。但是对于更靠近语言层面的一些东西 (比如现在已有的 Codable 这样的特性)，恐怕适配起来就没有那么简单了。在未来，Deployment target 可能会和 Swift 语言版本挂钩，新的语言特性出现后，我们可能需要等待一段时间才能实际用上。而除了那些纯编译期间的内容外，任何与 Swift runtime 有关的特性，都会要遵守这个规则。

可以像现在一样打包新版本的 Swift runtime 到 app 里，然后指定用打包的 Swift 版本么

  不能，对于包含有 Swift runtime 的系统，如果运行的 binary 是 ABI 稳定的，那么就必须使用系统提供的 Swift。这里的主要原因是，Apple 想要保留使用 Swift 来实现系统框架的可能性：

1. 如果允许两个 Swift runtime (系统自带，以及 app 打包的)，那么这两个运行时将无法互相访问，app 也无法与系统的 Swift 框架或者第三方的 ABI 稳定的框架进行交互。
2. 如果允许完全替换 Swift runtime，系统的 Swift 框架将执行用户提供的 Swift 标准库中的代码，这将造成重大的安全隐患。

有任何可能性让我能无视系统版本，去使用 Swift 的新特性么

  有，但是相对麻烦，很大程度上也依赖 Apple 是否愿意支持。如果你还记得 iOS 5.0 引入 ARC 时，Apple 为了让 iOS 4.3 和之前的系统也能使用 ARC 的代码，在 deployment target 选到 iOS 4.3 或之前时，会用 static link 的方式打包一个叫做 libarclite 的库，其中包含了 ARC 所需要的一些 runtime 方法。对于 ABI 稳定后的 Swift，也许可以采用类似做法，来提供兼容。

这种做法在感觉上和 Android 的 Support Library Packages 的方式类似，但是 Apple 似乎不是很倾向于提供这样的官方支持。所以之后要看有没有机会依靠社区力量来提供 Swift 的兼容支持了。

  不能第一时间用上新的语言特性，必然会打击大家进行适配和使用新特性的积极性，也势必会影响到语言的发展和快速迭代，可以说这一限制是相当不利的。

  所以，对于一般的 app 开发者来说，ABI 稳定其实就是一场博弈：你现在有更小的 app 尺寸，但是却被限制了无法使用最新的语言特性，除非你提升 app 的 depolyment target。

我是框架开发者，ABI 稳定后我可以用 binary 形式来发布了么？

  还不能。ABI 稳定是使用 binary 发布框架的必要非充分条件。框架的 binary 在不同的 runtime 是兼容了，但是作为框架，现在是依靠一个 .swiftmodule 的二进制文件来描述 API Interface 的，这个二进制文件中包含了序列化后的 AST (更准确说，是 interface 的 SIL)，以及编译这个 module 时的平台环境 (Swift 编译器版本等)。

  ABI 稳定并不意味着编译工具链的稳定，对于框架来说，想要用 binary 的方式提供框架，除了 binary 本身稳定以外，还需要描述 binary 的方式 (也就是现在的 swiftmodule) 也稳定，而这正在开发中。将来，Swift 将为 module 提供文本形式的 .swiftinterface 作为框架 API 描述，然后让未来的编译器根据这个描述去“编译”出对应的 .swiftmodule作为缓存并使用。

  这一目标被称为 module stability，当达到 module stability 后，你就可以使用 binary 来发布框架了 (当然，这种 binary 框架只支持带有 ABI 稳定的 Swift runtime 的平台，也就是 iOS 12.2 及以上)。

能总结一下 ABI 稳定，或者展望一下未来么？

  ABI 稳定最大的受益者应该是 Apple，这让 Apple 在自己的生态系统中，特别是系统框架中，可以使用 Swift 来进行实现。在我看来，Swift ABI 稳定为 Apple 开发平台的一场革命奠定了基础。在接下来的几年里，如果你还想要关注 Apple 平台，可能下面几件事情会特别重要：

1. Apple 什么时候发布第一个 Swift 写的系统框架
2. Apple 什么时候开始提供第一个 Swift only 的 API
3. Apple 什么时候开始“锁定” Objective-C 的 SDK，不再为它增加新的 API
4. Apple 什么时候开始用 Swift 特性更新现有的 Objective-C SDK

  这些事情也许会在未来几年陆续发生。面对微软从 Win32 API 向 .Net 一路迁移，到今天的 UWP (Universal Windows Platform)，Google 来势汹汹的 Fuchsia 和 Dart，Swift 是 Apple 唯一能与它们抗衡的答案。相比于微软提供的泛型和并行编程模型，Google 的 Flutter 的跨平台的先天优势，Apple 平台基于 Objective-C 的 API 的易用性已然被抛开很远。虽然 Apple 在 2014 年承诺过依然维护 Objective-C，但是经过 Swift 这五年的发展，随着 Swift ABI 的稳定，什么时候如果 Objective-C 成为了继续发展的阻碍，相信 Apple 已经有足够的理由将它抛弃。

作为 Apple 平台的从业者，我们也许正处在另一个时代变革的开端。

原文地址：Swift ABI 稳定对我们到底意味着什么