浅谈 Swift JSON 解析

主流 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 以后推出的一个编解码协议,可以配合 JSONDecoderJSONEncoder 用来进行 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

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

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 标准库源码,分别是解码 BoolInt 类型,可以看到一旦解析失败直接抛出异常,没有容错机制。

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 协议,重写 decodeIfPresentdecode 方法,捕获异常并处理。如果是可选类型则将异常抛出改为返回 nil,如果是不可选类型则返回默认值。

缺点:

  1. 只能在当前模块使用,不支持跨模块。
  2. 不支持不可选枚举的解析。
  3. 对于数组如果有一个出错只能解析为空数组,除非通过反射处理。

最终解决方案 CleanJSON

继承自 JSONDecoder,在标准库源码基础上做了改动,以解决 JSONDecoder 各种解析失败的问题,如键值不存在,值为 null,类型不一致。

实现原理

  • 从标准库复制一份源码

  • 在最底层的 unbox 方法里面将异常抛出改为返回 nil

  • SingleValueDecodingContainerKeyedDecodingContainerProtocol 协议方法中通过 KeyNotFoundDecodingStrategyValueNotFoundDecodingStrategy 两种策略处理异常,并通过 JSONAdapter 协议提供自定义适配方法。

  • 对于枚举这种无法确定默认值的类型,提供一个 CaseDefaultable 协议,然后重写 init(from decoder: Decoder) 方法来处理异常。

解决了什么

  1. 类型不匹配的时候不会抛出异常而是根据是否可选返回 nil 或者默认值
  2. 提供了在异常时自定义解码的策略
  3. 减少了大量的重复劳动和可选绑定
  4. 提高容错率,可以放心的使用不可选类型而不用担心解析失败

用法

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())
复制代码

各项对比

性能

image.png

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

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

代码量

JSONSerialization

image

CleanJSON

image

HandyJSON

image

ObjectMapper

image

总结

可以看到 JSONSerialization 速度是最快的,但同时也是代码量最多的,容错处理最差的。CleanJSONObjectMapper 速度不相上下,但 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.

作者:Pircate
链接:https://www.jianshu.com/p/1f194f09599a
来源:简书
小编这呢,给大家推荐一个优秀的iOS交流平台,平台里的伙伴们都是非常优秀的iOS开发人员,我们专注于技术的分享与技巧的交流,大家可以在平台上讨论技术,交流学习。欢迎大家的加入(想要进入的可加小编微信)。 18173184032

全部评论

相关推荐

上周组里招人,我面了六个候选人,回来跟同事吃饭的时候聊起一个让我挺感慨的现象。前三个候选人,算法题写得都不错。第一道二分查找,五分钟之内给出解法,边界条件也处理得干净。第二道动态规划,状态转移方程写对了,空间复杂度也优化了一版。我翻他们的简历,力扣刷题量都在300以上。后三个呢,就有点参差不齐了。有的边界条件没处理好,有的直接说这道题没刷过能不能换个思路讲讲。其中有一个女生,我印象特别深——她拿到题之后没有马上写,而是先问我:“面试官,我能先跟你确认一下我对题目的理解吗?”然后她把自己的思路讲了一遍,虽然最后代码写得不是最优解,但整个沟通过程非常顺畅。这个女生的代码不是最优的,但当我问她“如果这里是线上环境,你会怎么设计’的时候,她给我讲了一套完整的方案——异常怎么处理、日志怎么打、怎么平滑发布。她对这是之前在实习的时候踩过的坑。”我在想LeetCode到底在筛选什么?我自己的经历可能有点代表性。我当年校招的时候,也是刷了三百多道题才敢去面试。那时候大家都刷,你不刷就过不了笔试关。后来工作了,前三年基本没再打开过力扣。真正干活的时候,没人让你写反转链表,也没人让你手撕红黑树。更多的是:这个接口为什么慢了、那个服务为什么OOM了、线上数据对不上了得排查一下。所以后来我当面试官,慢慢调整了自己的评判标准。算法题我还会出,但目的变了。我出算法题,不是想看你能不能背出最优解。而是想看你拿到一个陌生问题的时候,是怎么思考的。你会先理清题意吗?你会主动问边界条件吗?你想不出来的时候会怎么办?你写出来的代码,变量命名乱不乱、结构清不清楚?这些才是工作中真正用得到的能力。LeetCode是一个工具,不是目的。它帮你熟悉数据结构和常见算法思路,这没问题。但如果你刷了三百道题,却说不清楚自己的项目解决了什么问题、遇到了什么困难、你是怎么解决的,那这三百道题可能真的白刷了。所以还要不要刷LeetCode?要刷,但别只刷题。刷题的时候,多问自己几个为什么:为什么用这个数据结构?为什么这个解法比那个好?如果换个条件,解法还成立吗?把刷题当成锻炼思维的方式,而不是背答案的任务。毕竟面试官想看到的,从来不是一台背题机器,而是一个能解决问题的人。
牛客51274894...:意思是光刷力扣还不够卷
AI时代还有必要刷lee...
点赞 评论 收藏
分享
机智的豹子有点心碎:UU我还在找工作还没找到,一直在搜简历怎么改,总结了这些: 1.SEO:简历根据每一个岗位定制化:使用这个岗位中所描述的工作的词,它要求什么技能就把自己的技能描述成什么样子,把SEO用在自己身上(把我的简历和个人特质,当成一个热门产品来做 “搜索引擎优化”),让HR能用最低的门槛看到我 2."顺序:把岗位要求的技能跟经历放在简历的最开头、最显眼的位置" 3.包装:简历是一个最终交付说明书,只要最终学习成长做得到就可以,在合适的范围内自我吹捧(我这个人怎么能够在HR的角度被迅速的看懂和看到,减轻HR的工作压力) 4.每点加小标题​:用6~10字概括该段内容,便于面试官快速抓取信息。 5.避免空泛描述​:拒绝“培养了组织能力”等泛泛而谈,替换为具体行动和成果。 6."使用“三段式结构”​​:每段经历按“为什么做-做了什么-结果如何”展开: ​a) 为什么做​:痛点或目标(例如“品牌声量不足”) ​b) 做​了什么:方法论(例如“趋势洞察+竞品对标+人群细分”) ​c) 结果如何​:量化成果或影响(例如“推动客户投放20万预算”)" 7.量化成果​:用数字体现工作成效(如“整理500+份资料”“撰写2万字报告”)。 这些有的是我想去的岗的,如果对你有用的话按需修改就好~加油,早日上岸!
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务