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 相关的内容所带来的改变。虽然原文不是很长，但是有些地方上下文没有说太清楚，可能不太容易理解。本文希望对这个话题以问答的形式进行一些总结，让大家能更明白将要发生的事情。

    Apple 在推出 Swift 时就将其冠以先进，安全和高效的新一代编程语言之名。前两点在 Swift 的语法和语言特性中已经表现得淋漓尽致：像是尾随闭包，枚举关联值，可选值和强制的类型安全等都是 Swift 显而易见的优点。但是对于高效一点，就没有那么明显了。在 2014 年 WWDC 大会上 Apple 宣称 Swift 具有超越 Objective-C 的性能，甚至某些情况下可以媲美和超过 C。但是在 Swift 正式发布后，很多开发者发现似乎 Swift 性能并没有像宣传的那样优秀。甚至在 Swift 经过了一年半的演进的今天，稍有不慎就容易掉进语言性能的陷阱中。

    在开始这一节的内容之前，我想先阐明两个在很多时候被混淆的概念，那就是异常 (exception) 和错误 (error)。 在 Objective-C 开发中，异常往往是由程序员的错误导致的 app 无法继续运行，比如我们向一个无法响应某个消息的 NSObject 对象发送了这个消息，会得到 NSInvalidArgumentException 的异常，并告诉我们 "unrecognized selector sent to instance"；比如我们使用一个超过数组元素数量的下标来试图访问 NSArray 的元素时，会得到 NSRangeException。类似由于这样所导致的程序无法运行的问题应该在开发阶段就被全部解决，而不应当出现在实际的产品中。相对来说，由 NSError 代表的错误更多地是指那些“合理的”，在用户使用 app 中可能遇到的情况：比如登陆时用户名密码验证不匹配，

    相对于普通的 Optional 值，在 Swift 中我们还有一种特殊的 Optional，在对它的成员或者方法进行访问时，编译器会帮助我们自动进行解包，这就是 ImplicitlyUnwrappedOptional。在声明的时候，我们可以通过在类型后加上一个感叹号 (!) 这个语法糖来告诉编译器我们需要一个可以隐式解包的 Optional 值： var maybeObject: MyClass! 首先需要明确的是，隐式解包的 Optional 本质上与普通的 Optional 值并没有任何不同，只是我们在对这类变量的成员或方法进行访问的时候，编译器会自动为我们在后面插入解包符号 !，也就是说，对于一个隐式解包的下面的两种写法是等效的。。。。

    Optional 可以说是 Swift 的一大特色，它完全解决了 “有” 和 “无” 这两个困扰了 Objective-C 许久的哲学概念，也使得代码安全性得到了很大的增加。但是一个陷阱 -- 或者说一个很容易让人迷惑的概念 -- 也随之而来，那就是多重的 Optional。

    在我动手搞这个 JSON 解析库之前，我一直在用 SwiftJSON 这个库，这个库是国人开源的最受欢迎的 Swift 项目，没有之一，也是全球最受欢迎的 Swift 库第二名，第一名是网络库 Alamofire。由于要实现 ["key"]["key1"] 这样的递归查找，我一直觉得 JSON 解析库非常复杂难搞。

    Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务，并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。

    OpenStack的源码分析在网上已经非常多了，针对各个部分的解读亦是非常详尽。这里我根据自己的理解把之前读过的Swift源码的一些要点记录一下，希望给需要的同学能带来一些帮助。