作者 | 启明星小组

上一篇我们介绍了移动开发常见的内存泄漏问题，见《百度工程师移动开发避坑指南——内存泄漏篇》。本篇我们将介绍 Swift 语言部分常见问题。

对于 Swift 开发者，Swift 较于 OC 一个很大的不同就是引入了可选类型（Optional），刚接触 Swift 的开发者很容易在相关代码上踩坑。

本期我们带来与 Swift 可选类型相关的几个避坑指南：可选类型要判空；避免使用隐式解包可选类型；合理使用 Objective-C 标识符；谨慎使用强制类型转换。希望能对 Swift 开发者有所帮助。

一、可选类型（Optional）要判空

在 Objective-C 中，可以使用 nil 来表示对象为空，但是使用一个为 nil 的对象通常是不安全的，如果使用不慎会出现崩溃或者其它异常问题。在 Swift 中，开发者可以使用可选类型表示变量有值或者没有值，可以更加清晰的表达类型是否可以安全的使用。如果一个变量可能为空，那么在声明时可以使用?来表示，使用前需要进行解包。例如：

var optionalString: String?

在使用可选类型对象时，需要进行解包操作，有两种解包方式：强制解包与可选绑定。

强制解包使用 ! 修饰一个可选对象 ，相当于告诉编译器『我知道这是一个可选类型，但在这里我可以保证他不为空，编译时请忽略此处的可空校验』，例如：

let unwrappedString: String = optionalString!  // 运行时报错：Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value

这里使用 ! 进行了强制解包，如果 optionalString 为 nil，将会产生运行时错误，发生崩溃。因此，在使用 ! 进行强制解包时，必须保证变量不为 nil，要对变量进行判空处理，如下：

if optionalString != nil {    let unwrappedString = optionalString!}

相较于强制解包的不安全性，一般而言推荐另一种解包方式，即可选绑定。例如：

if let optionalString = optionalString {    // 这里optionalString不为nil，是已经解包后的类型，可以直接使用}

综上，在对可选类型进行解包时应尽量避免使用强制解包，采用可选绑定替代。如果一定要使用强制解包，那么必须在逻辑上完全保证类型不为空，并且做好注释工作，以增加后续代码的可维护性。

二、避免使用隐式解包可选类型（Implicitly Unwrapped Optionals）

由于可选类型每次使用之前都需要进行显式解包操作，有时变量在第一次赋值之后，就会一直有值，如果每次使用都显式解包，显得繁琐，Swift 引入了隐式解包可选类型，隐式解包可选类型可以使用 ! 来表示，并且使用时不需要显式解包，可以直接使用，例如：

var implicitlyUnwrappedOptionalString: String! = "implicitlyUnwrappedOptionalString"var implicitlyString: String = implicitlyUnwrappedOptionalString

上述例子的隐式解包，在编译和运行过程中都不会发生问题，但如果在两行代码中间插入一行 implicitlyUnwrappedOptionalString = nil 将会产生运行时错误，发生崩溃。

在我们实际项目中，一个模块通常由多人维护，通常很难保证变量在第一次赋值之后一直不为 nil 或者只有在第一次正确赋值之后使用，从安全角度考虑，在使用隐式解包类型之前也要进行判空操作，但这样就和使用可选类型没有区别。对于可选类型（?），不经过解包直接使用编译器会报告错误，对于隐式解包类型，则可直接使用，编译器无法帮助我们做出是否为空的检查。因此，在实际项目中，不推荐使用隐式解包可选类型，如果一个变量是非空的，则选择非空类型，如果不能保证是非空的，则选择使用可选类型。

三、合理使用 Objective-C 标识符

与 Swift 不同的是，OC 是一种动态类型语言，对于 OC 而言没有 optional 这个概念，无法在编译期间检查对象是否可空。苹果在 Xcode 6.3 中引入了一个 Objective-C 的新特性：Nullability Annotations，允许编码时使用 nonnull、nullable、null_unspecified 等标识符告诉编译器对象是否是可空或者非空的，各标识符含义如下：

nonnull，表示对象是非空的，有__nonnull 和_Nonnull 等价标识符。

nullable，表示对象可能是空的，有__nullable 和_Nullable 等价标识符。

null_unspecified，不知道对象是否为空，有__null_unspecified 等价标识符。

OC 标识符标注的对象类型和 Swift 类型对应关系如下：

除了以上标识符外，现在通过 Xcode 创建的头文件默认被 NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END 包住，即在这之间声明的对象默认标识符是 nonnull 的。

在 Swift 与 OC 混编场景，编译器会根据 OC 标识符将 OC 的对象类型转换成 Swift 类型，如果没有显式的标识，默认是 null_unspecified。例如：

@interface ExampleOCClass : NSObject// 没有指定标识符，且没有被NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END包裹，标识符默认为null_unspecified+ (ExampleOCClass *)getExampleObject; @end
@implementation ExampleOCClass+ (ExampleOCClass *)getExampleObject {    return nil; // OC代码直接返回nil}@end

class ViewController: UIViewController {    override func viewDidLoad() {        super.viewDidLoad()        let _ = ExampleOCClass.getExampleObject().description // 报错：Thread 1: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value    }}

在上面例子中，Swift 代码调用 OC 接口获取一个对象，编译器隐式的将 OC 接口返回的对象转换为隐式解包类型来处理。由于隐式解包类型可以不显式解包直接使用，使用者往往会忽略 OC 返回的是隐式解包类型，不通过判空而直接使用。但当代码执行时，由于 OC 接口返回了一个 nil，导致 Swift 代码解包失败，发生运行时错误。

在实际编码中，推荐显式指定 OC 对象为 nonnull 或者 nullable，针对上述代码进行修改后如下：

@interface ExampleOCClass : NSObject/// 获取可空的对象+ (nullable ExampleOCClass *)getOptionalExampleObject;/// 获取不可空的对象+ (nonnull ExampleOCClass *)getNonOptionalExampleObject;@end
@implementation ExampleOCClass+ (ExampleOCClass *)getOptionalExampleObject {    return nil;}+ (ExampleOCClass *)getNonOptionalExampleObject {    return [[ExampleOCClass alloc] init];}@end

class ViewController: UIViewController {    override func viewDidLoad() {        super.viewDidLoad()        // 标注nullable后，编译器调用接口时，会强制加上 ?        let _ = ExampleOCClass.getOptionalExampleObject()?.description         // 标注nonnull后，编译器将会把接口返回当做不可空来处理        let _ = ExampleOCClass.getNonOptionalExampleObject().description     }}

在 OC 对象加上 nonnull 或者 nullable 标识符后，相当于给 OC 代码增加了类似 Swift 的『静态类型语言的特性』，使得编译器可以对代码进行可空类型检测，有效的降低了混编时崩溃的风险。但这种『静态特性』并不对 OC 完全有效，例如以下代码，虽然声明返回类型是 nonnull 的，但是依然可以返回 nil:

@implementation ExampleOCClass+ (nonnull ExampleOCClass *)getNonOptionalExampleObject {    return nil; // 接口声明不可空，但实际上返回一个空对象，可以通过编译，如果Swift当作非空对象使用，则会发生崩溃}@end

class ViewController: UIViewController {    override func viewDidLoad() {        super.viewDidLoad()        ExampleOCClass.getNonOptionalExampleObject().description    }}

基于以上例子，依然会产生运行时错误。从安全性的角度上来说，似乎 Swift 最好在使用所有 OC 的接口时都进行判空处理。但实际上这将导致 Swift 的代码充斥着大量冗余的判空代码，大大降低代码的可维护性，同时也违背了『暴露问题，而非隐藏问题』的编码原则，并不推荐这么做，合理的做法是在 OC 侧做好安全校验，OC 对返回类型应做好检验，保证返回类型的正确性，以及返回值和标识符能够对应。

综合来看，OC 侧标识符最好遵循如下使用原则：

1、不推荐使用 NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END，因为默认修饰符是 nonnull 的，在实际开发中很容易忽略返回的对象是否为空。返回空则会导致 Swift 运行时错误。推荐所有涉及混编的 OC 接口都需要显式使用相应的标识符修饰。

2、OC 接口要谨慎使用 nonnull 修饰 ，必须确保返回值不可能是空的情况下使用，任何不能确定不可空的接口都需要标注为 nullable。

3、为避免 Swift 侧不必要的类型、判空等校验（违背 Swift 设计理念），在理想状态下需在 OC 侧进行类型的校验，保证返回对象和标注的标识符完全正确，这样 Swift 则可以完全信赖 OC 返回的对象类型。

4、在 Swift 调用 OC 代码时，要关注 OC 返回的类型，尤其是返回隐式解包类型时，要做好判空处理。

5、在 OC 代码支持 Swift 调用前，提前对 OC 代码做好返回类型和标识符的检查，确保返回 Swift 的对象是安全的。

四、谨慎使用强制类型转换

Swift 作为强类型语言，禁止一切默认类型转换，这要求编码者需要明确定义每一个变量的类型，在需要类型转换时必须显式的进行类型转换。Swift 可以使用 as 和 as?运算符进行类型转换。

as 运算符用于强制类型转换，在类型兼容情况下，可以将一个类型转换为另一个类型，例如：

var d = 3.0 // 默认推断为 Double 类型var f: Float = 1.0 // 显式指定为 Float 类型d = f // 编译器将报错“Cannot assign value of type 'Float' to type 'Double'”  d = f as Double // 需要将Float类型转换为Double类型，才能赋值给f

除了以上列举的基本类型外，Swift 还兼容基础类型与对应的 OC 类型的转换，比如 NSArray/Array、NSString/String、NSDictionary/Dictionary。

如果类型转换失败，将会导致运行时错误。例如：

let string: Any = "string"let array = string as Array // 运行时错误

这里 string 变量实际是一个 String 类型，尝试将 String 类型转换成 Array 类型，将导致运行时错误。

另一种类型转换的方式是使用 as?运算符，如果转换成功，返回一个转换类型的可选类型，如果转换失败，返回 nil。例如：

let string: Any = "string"let array = string as? Array // 转换失败，不会产生运行时错误

这里由于无法将 String 类型转换为 Array 类型，因此转换失败，array 变量的值为 nil，但不会产生运行时错误。

综合来看，在进行类型转换时，需要注意以下几点：

1、类型转换只能在兼容的类型之间进行，例如 Double 和 Float 可以相互转换，但 String 和 Array 之间不能相互转换。

2、如果使用 as 进行强制类型转换，需要确保转换是安全的，否则将会导致运行时错误。如果不能确保转换类型之间是兼容的，则应该使用 as?运算符，例如将网络数据解析成模型数据时，无法保证网络数据的类型，应该使用 as?。

3、在使用 as?运算符进行类型转换时，需要注意返回值可能为 nil 的情况。

----------  END  ----------

推荐阅读【技术加油站】系列：

百度工程师移动开发避坑指南——内存泄漏篇

百度程序员开发避坑指南（Go语言篇）

百度程序员开发避坑指南（3）

百度程序员开发避坑指南（移动端篇）

百度程序员开发避坑指南（前端篇）