在 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)
}
我们看到:
- 可划分为 stringValue 和 intValue 两对,分别代表以 String 为键和以 Int 为键的两种情况。
- 在每一种对方法中,定义对 String / Int 的双向转换。
- 初始化函数是 failable 的。
- 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)
这里有两处实现细节要注意一下:
- SimpleCodingKey 的初始化方法不是 failable 的,但根据实现的要求,非 failable 的初始化方法被认定为实现了接口中的 failable 初始化方法
- extension 中使用了语法糖,添加的 convertToPascalCase 实际上是个 static var,但可以用类似于 enum 实例的语法来使用。
以上解决了编码部分,其实解码部分也是类似的,区别在于代码中的 uppercased 换成 lowercased。CodingKeys 的转换过程可以被描述为:_JSONKey 的对象需要转换成首字母小写的 SimpleCodingKey ,然后 SimpleCodingKey 再被拿去匹配 Person.CodingKeys,这个函数大家可以尝试自己实现一下。
3. 设计亮点
在了解了新特性的基础和高级用法之后,这里想简单提一下 Codable 的设计亮点,从设计者的角度学习和了解下。
- 基于接口的面向对象设计:从微观来看 CodingKey 接口的稳定设计抽象,使得 Swift 4.1 中加入 .custom CodingKey 的转换成为可能。从宏观来看 Encoder 和 Decoder,乃至 Codable 都是基于接口的面向对象设计,这使得整套设计是独立于具体格式的,标准库中内置了 JSON 和 PropertyList 两种编解码器,而你可以通过实现自己的 Encoder 和 Decoder,支持新的格式。
- 关联值枚举作为配置属性:KeyEncodingStrategy 和 KeyDecodingStrategy 中的
.custom(([CodingKey]) -> CodingKey>)
,让策略以一种优雅的方式得以动态配置。类似的设计我们还可以从 dateEncodingStrategy 等地方看到。 - 泛型设计和元类型编程:我们在解码JSON的时候是这么写的:
try? decoder.decode(Person.self, from: data)
这里传入Person.self
其实就涉及到了元类型编程了。这个函数是原型是:func decode
,如果要展开说,就是另一个话题了。我们可以在了解元类型设计的时候,想到这个范本。(_ type: T.Type, from data: Data) throws -> T where T : Decodable
小结
Codable在 Swift 4.0 的引入以及在 Swift 4.1 中的加强给 Swift 强类型持久化方案提供了新的技术选型,而且是第一梯队的。除了上述所提到的设计亮点,它还有亲儿子独有的编译器合成特性,以及存在于标准库的待遇,而后者的意义对于许多框架和库的作者来说,足以使之成为首选方案。
在本文中,我们讨论了:
- 使用新的配置属性弥合下划线命名和驼峰命名
- CodingKey 设计和自定义 CodingKey 转换
- 简单描述了 Codable 的设计亮点
- 我们应该将 Codable 纳入 Swift 持久化方案的优先技术选型
![](http://img.e-com-net.com/image/info10/27ed2c0e74ba4a02a08b3db4ef967dc4.jpg)
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的改进