在 Swift 4.0 的标准库中，引入了 Codable 接口，它实际上是 Encodable & Decodable 两个接口的复合接口。感谢编译器的加持，可以很方便地合成 init(from:Decoder) 以及 encode(to:Encoder) 这两个函数。Swift 4.1 为 JSONEncoder 和 JSONDecoder 分别引入了两个新的属性: keyEncodingStrategy 以及 keyDecodingStrategy，来详细了解一下用途。

1. 弥合下划线命名和驼峰命名

在日常使用过程中，我们经常会碰到强类型对象和 JSON 不同命名风格转换的问题，来看下面的例子。

let jsonStr = """
{
"age": 18,
"first_name": "Leon"
}
"""

struct Person : Codable {
  var age: Int
  var firstName: String
}

在这个例子中，JSON 字符串无法解码成 Person，同时 Person 的实例也无法编码成这个 JSON 字符串。原因就在于第二个属性的命名风格是不同的，前者使用了下划线命名法 (Snake Case)，后者使用了驼峰命名法 (Camel Case)。为了解决这个问题，在Swift 4.0 中，我们需要在 Person 内部自定义一个 CodingKeys，如下：

enum CodingKeys : String, CodingKey {
    case age
    case firstName = "first_name"
}

这个内部枚举 CodingKeys 的 rawType 是 String，并且声明实现 CodingKey 接口。这时，编译器会使用它的信息合成 Codable 相关函数，包括 Person.CodingKeys 的完整实现，问题解决。而在Swift 4.1 中，解决这个问题有了个更方便的方法：不指定 CodingKeys，而是在编码的时候，把 JSONEncoder 的属性 keyEncodingStrategy 设置为 .convertToSnakeCase；在解码的时候，把 JSONDecoder 的属性 keyDecodingStrategy 设置成 .convertFromSnakeCase。代码如下：

// 编码
let leon = Person(age: 18, firstName: "Leon")
let encoder = JSONEncoder()
encoder.keyEncodingStrategy = .convertToSnakeCase
let resultData = try? encoder.encode(leon)

// 解码
let data = jsonStr.data(using: .utf8)!
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let person = try? decoder.decode(Person.self, from: data)

2. 自定义键策略

大家一定想到了，上面这个例子只解决了最典型的一种 Key 风格不匹配的情况。有很多其它情况需要覆盖，比如：首字母大写的帕斯卡命名法了解一下？

let jsonStr = """
{
"Age": 18,
"FirstName": "Leon"
}
"""

实际上，我们需要更通用的方法，来解决 JSON 解码和编码的键策略问题。它就是 keyEncodingStrategy 和 keyDecodingStrategy 的另一个枚举项 .custom(([CodingKey]) -> CodingKey>)，我们看到它接受一个 CodingKey 数组到 CodingKey 的函数作为关联值。

那么 CodingKey 到底是什么呢？官方这样定义：一种被当做键 (Key) 用于编码和解码的类型。它是个 protocol，定义了以下四个方法，简写如下：

protocol CodingKey {
  var stringValue: String { get }
  init?(stringValue: String)

  var intValue: Int? { get }
  init?(intValue: Int)
}

我们看到：

1. 可划分为 stringValue 和 intValue 两对，分别代表以 String 为键和以 Int 为键的两种情况。
2. 在每一种对方法中，定义对 String / Int 的双向转换。
3. 初始化函数是 failable 的。
4. stringValue 不是 Optional 的，intValue 是 Optional 的。

回到需要解决的问题，我们需要传入的这个 ([CodingKey]) -> CodingKey> 函数，正是利用了 CodingKey 可以双向转换的特性，将一个 CodingKey 转换成另一种 CodingKey，所以实质上提供的是一个 map 函数。 看到这里，可能你有些疑惑，输入参数可是个数组，这里解释一下：之所以是数组是为了提供给你到当前编解码位置的完整路径，在大多数情况下，我们只需要取数组最后一个 CodingKey 即可。

结合之前的例子解决方案如下：默认情况在编码成 JSON 的时候，Encoder 会使用 Person.CodingKeys 进行编码，调用它的 stringValue，最终给出在实际 JSON 中当做键的字符串（驼峰命名风格的）。当使用 .custom 键编码策略的时候，就在上述过程中插入了一步：将 Person.CodingKeys 转变成了另一个 CodingKey（下面实现中的 SimpleCodingKey ），在负责转换的 map 函数中，将 stringValue 从 Person.CodingKeys 对象中取出，首字母变成大写，再用来构造 SimpleCodingKey，这时候实际用以 JSON 编码的 CodingKey 被替换成 SimpleCodingKey了（帕斯卡命名风格）。实现代码如下：

struct SimpleCodingKey : CodingKey {
    var stringValue: String
    var intValue: Int?
    
    init(stringValue: String) {
        self.stringValue = stringValue
    }
    
    init(intValue: Int) {
        self.stringValue = "\(intValue)"
        self.intValue = intValue
    }
}

extension JSONEncoder.KeyEncodingStrategy {
    static var convertToPascalCase: JSONEncoder.KeyEncodingStrategy {
        return .custom { codingKeys in
            var str = codingKeys.last!.stringValue
            guard let firstChar = str.first else {
                return SimpleCodingKey(stringValue: str)
            }
            let startIdx = str.startIndex
            str.replaceSubrange(startIdx...startIdx,
                                with: String(firstChar).uppercased())
            return SimpleCodingKey(stringValue: str)
        }
    }
}

let leon = Person(age: 18, firstName: "Leon")
let encoder = JSONEncoder()
encoder.keyEncodingStrategy = .convertToPascalCase
let resultData = try? encoder.encode(leon)

这里有两处实现细节要注意一下：

1. SimpleCodingKey 的初始化方法不是 failable 的，但根据实现的要求，非 failable 的初始化方法被认定为实现了接口中的 failable 初始化方法
2. extension 中使用了语法糖，添加的 convertToPascalCase 实际上是个 static var，但可以用类似于 enum 实例的语法来使用。

以上解决了编码部分，其实解码部分也是类似的，区别在于代码中的 uppercased 换成 lowercased。CodingKeys 的转换过程可以被描述为：_JSONKey 的对象需要转换成首字母小写的 SimpleCodingKey ，然后 SimpleCodingKey 再被拿去匹配 Person.CodingKeys，这个函数大家可以尝试自己实现一下。

3. 设计亮点

在了解了新特性的基础和高级用法之后，这里想简单提一下 Codable 的设计亮点，从设计者的角度学习和了解下。

1. 基于接口的面向对象设计：从微观来看 CodingKey 接口的稳定设计抽象，使得 Swift 4.1 中加入 .custom CodingKey 的转换成为可能。从宏观来看 Encoder 和 Decoder，乃至 Codable 都是基于接口的面向对象设计，这使得整套设计是独立于具体格式的，标准库中内置了 JSON 和 PropertyList 两种编解码器，而你可以通过实现自己的 Encoder 和 Decoder，支持新的格式。
2. 关联值枚举作为配置属性：KeyEncodingStrategy 和 KeyDecodingStrategy 中的.custom(([CodingKey]) -> CodingKey>)，让策略以一种优雅的方式得以动态配置。类似的设计我们还可以从 dateEncodingStrategy 等地方看到。
3. 泛型设计和元类型编程：我们在解码JSON的时候是这么写的：try? decoder.decode(Person.self, from: data)这里传入 Person.self 其实就涉及到了元类型编程了。这个函数是原型是：func decode<T>(_ type: T.Type, from data: Data) throws -> T where T : Decodable，如果要展开说，就是另一个话题了。我们可以在了解元类型设计的时候，想到这个范本。

小结

Codable在 Swift 4.0 的引入以及在 Swift 4.1 中的加强给 Swift 强类型持久化方案提供了新的技术选型，而且是第一梯队的。除了上述所提到的设计亮点，它还有亲儿子独有的编译器合成特性，以及存在于标准库的待遇，而后者的意义对于许多框架和库的作者来说，足以使之成为首选方案。

在本文中，我们讨论了：

• 使用新的配置属性弥合下划线命名和驼峰命名
• CodingKey 设计和自定义 CodingKey 转换
• 简单描述了 Codable 的设计亮点
• 我们应该将 Codable 纳入 Swift 持久化方案的优先技术选型

欢迎关注公众号

Swift 4.1 新特性系列文章

Swift 4.1 新特性 (1) Conditional Conformance
Swift 4.1 新特性 (2) Sequence.compactMap
Swift 4.1 新特性 (3) 合成 Equatable 和 Hashable
Swift 4.1 新特性 (4) Codable的改进