主流 JSON 解析框架
SwiftyJSON Github 上 Star 最多的 Swift JSON 解析框架
ObjectMapper 面向协议的 Swift JSON 解析框架
HandyJSON 阿里推出的一个用于 Swift 语言中的 JSON 序列化/反序列化库。
JSONDecoder Apple 官方推出的基于
Codable的 JSON 解析类
个人分析
SwiftyJSON 采用下标方式获取数据，使用起来比较麻烦，还容易发生拼写错误、维护困难等问题。
ObjectMapper 使用上类似 Codable，但是需要额外写 map 方法，重复劳动过多。
HandyJSON 使用上类似于 YYModel，采用的是 Swift 反射 + 内存赋值的方式来构造 Model 实例。但是有内存泄露，兼容性差等问题。
Codable 是 Apple 官方提供的，更可靠，对原生类型支持更好。
Codable 简介
Codable 是 Swift 4.0 以后推出的一个编解码协议，可以配合 JSONDecoder 和 JSONEncoder 用来进行 JSON 解码和编码。
Codable 使用方法
struct Foo: Codable {
let bar: Int
enum CodingKeys: String, CodingKey {
// key 映射
case bar = "rab"
}
init(from decoder: Decoder) throws {
// 自定义解码
let container = try decoder.container(keyedBy: CodingKeys.self)
if let intValue = try container.decodeIfPresent(String.self, forKey: .bar) {
self.bar = intValue
} else {
self.bar = try container.decode(Int.self, forKey: .bar)
}
}
let decoder = JSONDecoder()
try decoder.decode(Foo.self, from: data)
// 蛇形命名转驼峰
decoder.keyDecodingStrategy = .convertFromSnakeCase
// 日期解析使用 UNIX 时间戳
decoder.dateDecodingStrategy = .secondsSince1970
Codable 痛点
只要有一个属性解析失败则直接抛出异常导致整个解析过程失败。
以下情况均会解析失败:
- 类型不匹配，例如 APP 端是 Int 类型，服务器下发的是 String 类型
- 不可选类型键不存在, 例如服务器下发的数据缺少了某个字段
- 不可选类型值为 null，例如服务器由于某种原因导致数据为 null
后两个可以通过使用可选类型避免，第一种情况只能重写协议方法来规避，但是很难完全避免。而使用可选类型势必会有大量的可选绑定，对于 enum 和 Bool 来说使用可选类型是非常痛苦的，而且这些都会增加代码量。这时候就需要一种解决方案来解决这些痛点。
JSONDecoder 内部实现
调用关系
// 入口方法
JSONDecoder decode<T : Decodable>(_ type: T.Type, from data: Data)
// 内部私有类，实际用来解析的
__JSONDecoder unbox<T : Decodable>(_ value: Any, as type: T.Type)
// 遵循 Decodable 协议的类调用协议方法
Decodable init(from decoder: Decoder)
// 自动生成的 init 方法调用 container
Decoder container(keyedBy: CodingKeys)
// 解析的容器
KeyedDecodingContainer decodeIfPresent(type: Type) or decode(type: Type)
// 内部私有类，循环调用 unbox
__JSONDecoder unbox(value:Any type:Type)
...循环，直到基本类型
JSONDecoder 内部实际上是使用 __JSONDecoder 这个私有类来进行解码的，最终都是调用 unbox 方法。
解码机制
以下代码摘自 Swift 标准库源码，分别是解码 Bool 和 Int 类型，可以看到一旦解析失败直接抛出异常，没有容错机制。
fileprivate func unbox(_ value: Any, as type: Bool.Type) throws -> Bool? {
guard !(value is NSNull) else { return nil }
if let number = value as? NSNumber {
// TODO: Add a flag to coerce non-boolean numbers into Bools?
if number === kCFBooleanTrue as NSNumber {
return true
} else if number === kCFBooleanFalse as NSNumber {
return false
}
/* FIXME: If swift-corelibs-foundation doesn't change to use NSNumber, this code path will need to be included and tested:
} else if let bool = value as? Bool {
return bool
*/
}
throw DecodingError._typeMismatch(at: self.codingPath, expectation: type, reality: value)
}
fileprivate func unbox(_ value: Any, as type: Int.Type) throws -> Int? {
guard !(value is NSNull) else { return nil }
guard let number = value as? NSNumber, number !== kCFBooleanTrue, number !== kCFBooleanFalse else {
throw DecodingError._typeMismatch(at: self.codingPath, expectation: type, reality: value)
}
let int = number.intValue
guard NSNumber(value: int) == number else {
throw DecodingError.dataCorrupted(DecodingError.Context(codingPath: self.codingPath, debugDescription: "Parsed JSON number <\(number)> does not fit in \(type)."))
}
return int
}
解决方案
由于 __JSONDecoder 是内部私有类，而 Decoder 协议暴露的接口太少，鉴于 Swift protocol extension 优先使用当前模块的协议方法，所以可以从 KeyedDecodingContainer 协议下手。
因此 第一版解决方案 诞生了。通过扩展 KeyedDecodingContainer 协议，重写 decodeIfPresent 和 decode 方法，捕获异常并处理。如果是可选类型则将异常抛出改为返回 nil，如果是不可选类型则返回默认值。
缺点:
- 只能在当前模块使用，不支持跨模块。
- 不支持不可选枚举的解析。
- 对于数组如果有一个出错只能解析为空数组，除非通过反射处理。
最终解决方案 CleanJSON
继承自 JSONDecoder，在标准库源码基础上做了改动，以解决 JSONDecoder 各种解析失败的问题，如键值不存在，值为 null，类型不一致。
实现原理
从标准库复制一份源码
在最底层的
unbox方法里面将异常抛出改为返回nil在
SingleValueDecodingContainer和KeyedDecodingContainerProtocol协议方法中通过KeyNotFoundDecodingStrategy和ValueNotFoundDecodingStrategy两种策略处理异常，并通过JSONAdapter协议提供自定义适配方法。对于枚举这种无法确定默认值的类型，提供一个
CaseDefaultable协议，然后重写init(from decoder: Decoder)方法来处理异常。
解决了什么
- 类型不匹配的时候不会抛出异常而是根据是否可选返回
nil或者默认值 - 提供了在异常时自定义解码的策略
- 减少了大量的重复劳动和可选绑定
- 提高容错率，可以放心的使用不可选类型而不用担心解析失败
用法
将 JSONDecoder 替换成 CleanJSONDecoder 即可。
let decoder = CleanJSONDecoder()
try decoder.decode(Foo.self, from: data)
对于不可选的枚举类型请遵循 CaseDefaultable 协议，如果解析失败会返回默认 case
NOTE：枚举使用强类型解析，关联类型和数据类型不一致不会进行类型转换，会解析为默认 case
enum Enum: Int, Codable, CaseDefaultable {
case case1
case case2
case case3
static var defaultCase: Enum {
return .case1
}
}
自定义解码策略
可以通过 valueNotFoundDecodingStrategy 在值为 null 或类型不匹配的时候自定义解码。
struct CustomAdapter: JSONAdapter {
// 由于 Swift 布尔类型不是非 0 即 true，所以默认没有提供类型转换。
// 如果想实现 Int 转 Bool 可以自定义解码。
func adapt(_ decoder: CleanDecoder) throws -> Bool {
// 值为 null
if decoder.decodeNil() {
return false
}
if let intValue = try decoder.decodeIfPresent(Int.self) {
// 类型不匹配，期望 Bool 类型，实际是 Int 类型
return intValue != 0
}
return false
}
}
decoder.valueNotFoundDecodingStrategy = .custom(CustomAdapter())
各项对比
性能
以上是对不同数量级的数据解析对比。数据结构越复杂，性能差距会更大。
仓库地址：https://github.com/Pircate/JSONParsePerformance
代码量
JSONSerialization
CleanJSON
HandyJSON
ObjectMapper
总结
可以看到 JSONSerialization 速度是最快的，但同时也是代码量最多的，容错处理最差的。CleanJSON 和 ObjectMapper 速度不相上下，但 ObjectMapper 代码量较多，且对不可选类型的解析和 JSONDecoder 一样解析失败直接抛出异常。HandyJSON 性能较差。
引用 Mattt 大神的分析:
On average, Codable with JSONDecoder is about half as fast as the equivalent implementation with JSONSerialization.
But does this mean that we shouldn’t use Codable? Probably not.
A 2x speedup factor may seem significant, but measured in absolute time difference, the savings are unlikely to be appreciable under most circumstances — and besides, performance is only one consideration in making a successful app.
