浅谈 Swift JSON 解析_浅谈SwiftJSON解析

时间:2021年05月10日 01:24:48
主流 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: Intenum 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 = .secondsSince1970Codable 痛点

只要有一个属性解析失败则直接抛出异常导致整个解析过程失败。

以下情况均会解析失败:

类型不匹配,例如 APP 端是 Int 类型,服务器下发的是 String 类型不可选类型键不存在, 例如服务器下发的数据缺少了某个字段不可选类型值为 null,例如服务器由于某种原因导致数据为 null

后两个可以通过使用可选类型避免,第一种情况只能重写协议方法来规避,但是很难完全避免。而使用可选类型势必会有大量的可选绑定,对于 enum 和 Bool 来说使用可选类型是非常痛苦的,而且这些都会增加代码量。这时候就需要一种解决方案来解决这些痛点。

JSONDecoder 内部实现调用关系// 入口方法JSONDecoder decode(_ type: T.Type, from data: Data)// 内部私有类,实际用来解析的__JSONDecoder unbox(_ value: Any, as type: T.Type)// 遵循 Decodable 协议的类调用协议方法Decodable init(from decoder: Decoder)// 自动生成的 init 方法调用 containerDecoder 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.intValueguard NSNumber(value: int) == number else {throw DecodingError.dataCorrupted(DecodingError.Context(codingPath: self.codingPath, debugDescription: "Parsed JSON numberdoes 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 case1case case2case case3static var defaultCase: Enum {return .case1}}自定义解码策略

可以通过 valueNotFoundDecodingStrategy 在值为 null 或类型不匹配的时候自定义解码。

struct CustomAdapter: JSONAdapter {// 由于 Swift 布尔类型不是非 0 即 true,所以默认没有提供类型转换。// 如果想实现 Int 转 Bool 可以自定义解码。func adapt(_ decoder: CleanDecoder) throws -> Bool {// 值为 nullif decoder.decodeNil() {return false}if let intValue = try decoder.decodeIfPresent(Int.self) {// 类型不匹配,期望 Bool 类型,实际是 Int 类型return intValue != 0}return false}}decoder.valueNotFoundDecodingStrategy = .custom(CustomAdapter())各项对比性能image

以上是对不同数量级的数据解析对比。数据结构越复杂,性能差距会更大。

仓库地址:https://github.com/Pircate/JSONParsePerformance

代码量

JSONSerialization

image

CleanJSON

image

HandyJSON

image

ObjectMapper

image总结

可以看到 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.

参考文档Swift Json解析探索 作者:桃红宿雨Swift 标准库源码 作者:appleCodable vs. JSONSerialization Performance 作者:Mattt

UI高级

https://blog.csdn.net/u013628092/article/details/85011573

iOS

https://blog.csdn.net/weixin_43172830/article/details/...

GitHub

https://github.com/iOShuyang/Book-Learn-Swift

iOS

https://www.bbsmax.com/A/x9J2xPljd6

swift

https://download.csdn.net/download/weixin_39840387/11551891