这篇主要是从我个人的开发经验角度，把 Swift 和 Objective-C 进行比较，介绍 Swift 的优缺点，基本上不涉及 Swift 的语法。

Swift 属于入手难度低，学习 Swift 语法最好的方式是阅读 英文版的官方教程，如果想看中文版，可以参考国内的 SwiftGG 组织翻译的 中文版教程。

Swift 的优点

代码更安全

这里的安全包括两层含义：

• 程序不崩溃。
• 程序的运行结果符合预期。

Uber 在 2015 年使用 Swift 重写了他们的整个 APP，他们的架构 leader 说，

开发阶段的前五个月，APP 从来没有崩溃过……

全新的 APP 上线后……崩溃率接近万分之一。我从没见过一个新 APP 第一次上线就几乎没有 崩溃这种事情。

在 objc.io 出版的《Advanced Swift》中，作者指出，

除非你有意为之，否则 Swift 在实践中总是安全的。

在 Swift 中只要按正常模式开发，基本上不会崩溃；在 Objective-C 中非常小心，也会踩到坑。

常量和变量隔离

多用常量是一个好的编程习惯，可以避免变量的值被误修改，可以提供运行效率等等。但是由于各种原因，大家在 Objective-C 开发中并没有大规模地使用常量：

• 我们都很懒：定义常量需要多写一个 const。
• 常量无法实现：无法将类的 property 定义为常量。
• 常量不管用：即便将一个类的实例定义为常量，依然可以修改它的 property 值。

而 Swift 常量基本上解决了上面的痛点。

首先，在 Swift 中定义一个变量时必须声明它是否可变，

• let：不可变变量（即常量）。
• var：可变变量。

因此定义常量不会增加我们的工作量，而且这种定义方式的另一个好处在于，强迫我们在定义变量之初就思考这个变量是否可变，有助于提升代码质量。

// 定义了一个常量
let π = 3.14159

// 定义了一个可变量
var num = 1

π = 3.14    // ❌，不能修改常量
num = 2     // ✅

其次，我们可以按定义一般变量的形式，将 Swift 类/结构体的 property 声明为常量，编译器会保证这个属性仅能被初始化一次。

struct Person {
    // 定义一个常量属性
    let gender: String

    // 定义一个可变属性
    var age: Int
}

var person = Person(gender: "M", age: 18)
person.gender = "F"     // ❌，不能修改常量
person.age = 19         // ✅

最后，在 Swift 中将类的实例定义为常量后，它的 property 也是可以被修改的，这个是没办法的事情。但是 Swift 标准库中绝大部分类型都是值类型（结构体和枚举），将它们的实例定义为常量后，对应的属性是无法修改的。这算是间接地解决了我们的痛点。

Nil 与非 Nil 隔离

Objective-C 中 nil 可能导致程序崩溃

这是 Objective-C 中很常见的一种崩溃了：

• 比较明显的是将 nil 插入 NSArray 和 NSDictionary 的崩溃
• 比较隐晦的是某些 API 文档并未要求实参为非 nil，但传 nil 就会崩溃的，比如[NSAttributedString stringWithString:]。

Objective-C 中 nil 可能导致逻辑错误

Objective-C 允许我们向 nil 发送消息，程序不会崩溃，不过逻辑就不一定正确了。让我们来看看下面这个例子:

NSString *someString = ...;
if ([someString rangeOfString:@"Swift"].location != NSNotFound) {
    NSLog(@"Someone mentioned Swift!"); 
}

这里例子在 someString 为 nil 时也会执行输出语句，从而出现逻辑错误。

在 Objective-C 中要避免 Nil 的坑，只能靠我们的经验。而在 Swift 中，我们可以依靠编译器。

Swift 中 nil 和 非 nil 隔离

在 Swift 中 nil 和 非 nil 变量是完全隔离的。当我们定义一个变量时必须声明它是否可以为 nil。可以为 nil 的变量被称为“可选值”（Optional）。Swift 在编译阶段就会确保我们不会误用 nil。看下面这个例子，

// 定义一个可选值 optStr
var optStr: String? = ...
// 定义一个非可选值 str
var str: String = ...

if optStr?.contains("Swift") == true {
    // optStr == nil 时不会执行该语句
    print("Someone mentioned Swift!")
}

// ❌。编译错误，参数必须为 `String`，不能为 `String?`
let attributedStr = NSAttributedString(string: optStr)    

// ❌。编译错误，不能将 `String` 赋值为 nil
str = nil

最近购物车出现了两次价格展示异常的问题。原因在于虽然我们跟后端约定了那些字符串肯定不为 nil，但后端可能直接不传那些字段，导致我们解析时将它们处理为 nil。若是我们使用 Swift，绝对不会出现这样的问题。

有效避免命名冲突

Objective-C 很大的一个坑就是命名冲突，包括

• 类名冲突
• 方法名冲突
• 变量名冲突

最经典的命名冲突就是 category/subclass 中的同名函数覆盖原有函数的问题了。

正是为了避免命名冲突，所以 Objective-C 语言的最佳实践中建议每个 class 都带三个字母的前缀，所以我们内部做组件化时还精心设计了一套命名规范。

不过若使用的第三方库之间出现了命名冲突，尤其是没有源码的情况下，我们就一点办法都没有，只能等对方去改代码了。

Swift 引入了 Module 的概念，为名字增加了一层作用域。每个 APP、每个 framework 都是一个独立的 Module，它们内部定义的 class、方法、变量不会与外部的混淆在一起，因此基本上不会存在命名冲突的问题。

所以，Swift 在 class 命名时也不推荐使用前缀，比如 Alamofire —— Swift 版的 AFNetworking —— 中，它的 class 就直接命名为 Session、Request 等。

不能使用未初始化的变量

我们可以在 Objective-C 中使用一个未初始化的变量，编译器不会报错，但风险未知。

在 Swift 中，无论是局部变量还是 class 的成员变量，都必须先初始化，再使用，否则编译报错。它从语言层面上保证了代码的安全性。

语法更简洁

Objective-C 这个名字本身就很长😫

Swift 语言很重要的一个设计思想就是为程序员减负。只要是编译器能通过上下文推断出来的，就没必要人工输入。

下面是 Swift 官方教程 中一个字符串数组排序的例子，显示了如何从常规写法，一步步变为 Swift 经典写法的过程，很能体现 Swift 简洁语法的特色。

// 常规写法
reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in
    // 返回值为 true 时 s1 在前，否则 s2 在前
    return s1 > s2
})

// >> 自动推断参数类型
reversedNames = names.sorted(by: { s1, s2 in return s1 > s2 } )

// >> 自动推断单行表达式 Closures 的返回值
reversedNames = names.sorted(by: { s1, s2 in s1 > s2 } )

// >> 使用简洁版的参数名
reversedNames = names.sorted(by: { $0 > $1 } )

// >> 使用方法名作为参数
reversedNames = names.sorted(by: >)

在日常开发中，我们常用用到下面这些福利：

• 定义变量时不必输入类型，比如下面两个定义的效果一样。

let a1: Int = 10

// 编译器自动推断 a2 的类型为 Int
let a2 = 10

• 函数名更短，实参不用写全

// .zero 这里等同于 CGRect.zero
let button = UIButton(frame: .zero)

// .normal 这里等同于 UIControl.State.normal
button.setTitle("标题", for: .normal)

• if 表达式不必带 ()，语句末尾不必带 ;
• 使用同一个 Module 中其他文件的代码时，不必写 import 语句
• ……

不过，Swift 这种简洁语法的代价是编译时间变长！因此对于复杂表达式，我们最好还是显式地声明类型，减少编译器的推断时间。

基于值类型的编程

Swift 中结构体 (struct) 和枚举 (enum) 都是值类型（value type）。当你把一个结构体变量赋值给另一个，那么这两个变量将会包含同样的值。当一个变量修改它的值时，不会影响另一个变量的值。

相对的，类（class）是引用类型（reference type）。当你把一个类对象赋值给另一个时，这两个变量是指向同一个值。当一个变量修改了它的值时，会影响另一个变量的值。

优点

• 值类型只有一个持有者，所以：
  • 不需要使用引用计数，管理更简单，执行更高效。
  • 没有循环引用问题。
• 值具有不可变的特性，线程更安全，因为不可变的东西可以在线程间安全的共享。

缺点

• 没有 dealloc 方法。
  • 这也不太算缺点，因为值类型本身就是用来处理没有生命周期的数据。
• 不能继承。

Swift 对值类型做了很大的增强，使它们基本上具备了类的所有功能：

• 可以定义方法
• 可以遵从协议

Swift 标准库中，绝大多数的公开类型都是值类型（主要是结构体，小部分是枚举），而类只占很小一部分。比如除了常规的 Int、Bool 和 Double 等类型为结构体以外，下列类型在 Swift 中都是结构体，而不是类！

• String
• Array
• Data
• URL
• ……

Swift 的枚举很强大

Swift 的枚举很强大，除了可以添加方法外，还可以定义 string、characters、浮点数等形式的 case。

// 数字型枚举
enum Planet: Int {
    case mercury = 1, venus, earth, mars, jupiter, saturn, uranus, neptune
}

// 字符串型枚举
enum CompassPoint: String {
    case north, south, east, west
}

let earthsOrder = Planet.earth.rawValue
// earthsOrder is 3

let sunsetDirection = CompassPoint.west.rawValue
// sunsetDirection is "west"

面向协议的编程

Swift 标准库还大规模地使用了面向协议的编程的思想。比如 Array 就遵守了如下的诸多协议：

• CKRecordValueProtocol
• CustomDebugStringConvertible
• CustomReflectable
• CustomStringConvertible
• CVarArg
• Decodable
• Encodable
• Equatable
• ExpressibleByArrayLiteral
• Hashable
• MLDataValueConvertible
• MutableCollection
• RandomAccessCollection
• RangeReplaceableCollection

克服继承的毛病

OOC（Object Oriented Programming）的核心就是封装和继承。POP（Protocol Oriented Programming）也支持封装，但 POP 克服了 OOC 继承中存在以下痛点：

• 不支持多继承
• 子类会全盘接受父类的 property，即便用不到。
• 这还意味着子类必须正确的初始化父类的全部 property
• 当子类 override 父类的 method 时，必须阅读文档才能知道：
  • 能否 override（胡乱 override 可能有严重的 bug）、
  • override 时是否需要调用父类 method
  • 何时调用（方法的最上方还是最下方等）

我们也可以在 Objective-C 中使用 POP 的编程思想，但 Swift 的 POP 之所以更强大，是因为

• 它支持值类型
• 它支持在 Protocol 中直接添加方法的实现

在 Swift Protocol 中直接添加方法的实现

我们可以在 Extension 中为 Swift Protocol 添加两种方法的实现：

• 已声明方法的默认实现。
  • 这样做的好处在于，遵守该协议的所有类型都可以不必再提供实现代码，可以大大减少重复代码。
  • 遵守该协议的类型若选择提供实现体，将执行它们的实现体。
• 没有声明方法的实现。

我们看下面这个具体的例子，

// 定义一个 Protocol
protocol NibLoadableView {

    // Protocol 中声明了一个属性要求
    static var nibName: String { get }

}

// 为 Protocol 添加实现体
extension NibLoadableView {

    // NibLoadableView 协议中**声明了**这个方法，可以在 extension 中提供它的默认实现
    static var nibName: String {
        let fullClassName = self.fullClassName
        return fullClassName.components(separatedBy: ".").last ?? fullClassName
    }

    // NibLoadableView 协议中**没有声明**这个方法，但依然可以在 extension 中提供它的实现体
    static var fullClassName: String {
        return String(describing: self)
    }

}

// 由于我们已经为 NibLoadableView 提供了默认实现，因此 UIView 遵守该协议后，可以不必再提供实现体
extension UIView: NibLoadableView { }

Swift 的 Protocol 不必依赖具体类型就可以提供方法的实现体，这使它成为与 class、struct、enum 平起平坐的一个类型。

函数式编程

泛型

运行速度更快

• let 确保变量不会再变，可以做更多优化
• 值编程减少引用计数和线程保护的逻辑
• 函数分派更高效

语言持续演进中，会添加更多特性，但 Objective-C 绝对不会了

比如处理 JSON 数据是开发中很常见的一个需求，在 Objective-C 中只能自己开发或者使用第三方的 SDK，性能、安全等因素全靠自己。Swift 则在 4.0 中提供了 Codable，从语言层面给出了解决方案。

Swift 的坑

编译速度慢

动态性不足，不方便骚操作

API 更新

不过最近已经很少发生 API 的剧烈更新了，尤其在 ABI 稳固的情况下，我们也不必担心 API 更新导致的兼容问题。