iOS 开发中总会用到各种 JSON 模型转换库,这篇文章将会对常见的几个开源库进行一下评测。评测的内容主要集中在性能、功能、容错性这几个方面。
Manually
手动进行 JSON/Model 转换,不用任何开源库,可以进行高效、自由的转换,但手写代码非常繁琐,而且容易出错。
YYModel
我造的一个新轮子,比较轻量(算上 .h 只有 5 个文件),支持自动的 JSON/Model 转换,支持定义映射过程。API 简洁,功能也比较简单。
FastEasyMapping
Yalantis 开发的一个 JSON 模型转换库,可以自定义详细的 Model 映射过程,支持 CoreData。使用者较少。
JSONModel
一个 JSON 模型转换库,有着比较简洁的接口。Model 需要继承自 JSONModel。
Mantle
Github 官方团队开发的 JSON 模型转换库,Model 需要继承自 MTLModel。功能丰富,文档完善,使用广泛。
MJExtension
国内开发者"小码哥"开发的 JSON 模型库,号称性能超过 JSONModel 和 Mantle,使用简单无侵入。国内有大量使用者。
所有开源库代码更新至 2015-09-18,以 Release 方式编译,运行在 iPhone 6 上,代码见https://github.com/ibireme/YYModel/tree/master/Benchmark。
用例1:GithubUser
从 https://api.github.com/users/facebook 获取的一条 User 数据,去除 NSDate 属性。
该 JSON 有 30 行,大部分属性是 string,少量是 number。这个用例主要是测试最基础的 Model 相关操作。
每次测试执行 10000 次,统计耗时毫秒数。
用例2: WeiboStatus
从官方微博 App 抓取一条内容完整的微博数据,JSON 总共有 580 行(是的,一条微博需要这么大数据量),包含大量嵌套对象、容器对象、类型转换、日期解析等。这个用例主要是测试在复杂的情况下不同库的性能。
每次测试执行 1000 次,统计耗时毫秒数。
测试结果如下:
Mantle 在各个测试中,性能都是最差的
JSONModel 和 MJExtension 性能相差不多,但都比 Mantle 性能高。
FastEasyMapping 相对来说性能确实比较快。
YYModel 性能高出其他几个库一个数量级,接近手写代码的效率。
FastEasyMapping 不支持 NSCoding 协议,所以不能进行 Archive 的性能测试。
MJExtension 在处理复杂对象转为 JSON 时,存在错误。
(此处我也测试了一些 Swift 的项目,例如 ObjectMapper、JSONHelper、ModelRocket,性能比 Mantle 还差很多,这里就不进行对比了。)
容错性主要是测试在默认情况下,当 JSON 格式错误时,Model 框架是否会产生错误结果或造成 Crash。
用例 | YYModel | FastEasyMapping | JSONModel | Mantle | MJExtension |
---|---|---|---|---|---|
JSON 属性是 number Model 属性是 NSString |
✅ NSString | NSNumber | ✅ NSString | ⚠️ model nil | ✅ NSString |
JSON 属性是 string "100" Model 属性是 int |
✅ 100 | Crash | Crash | ⚠️ model nil | ✅ 100 |
JSON 属性是 string "2009-04-02T03:35:22Z" Model 属性是 NSDate |
✅ NSDate | NSString | ✅ NSDate | ⚠️ model nil | NSString |
JSON 属性是 string Model 属性是 NSValue |
✅ nil | NSString | crash | ⚠️ model nil | NSString |
YYModel 和 Mantle 都会进行对象类型检查,避免将错误的对象类型赋值到属性,以避免潜在的 Crash 问题。不同的是 YYModel 会尝试自动转换,转换失败时留空;而 Mantle 遇到类型不匹配时,直接把错误向上返回,从而终止了整个转换过程,但这么做更方便调试。
MJExtension 会对部分对象进行自动转换(比如 NSString 和 NSNumber 之间的转换),但当自动转换不能完成时,它会直接把 JSON 对象赋值给类型不匹配的 Model 属性。这样的结果会导致稍后 Model 在使用时,造成潜在的 Crash 风险。
JSONModel 并没有对错误类型的检测,并且没有对 App 的保护,当出现异常时,会导致整个 App Crash,非常危险。
FastEasyMapping 表现则是最差的,它没有自动转换的机制,当遇到类型不匹配时,会导致错误的类型赋值,甚至直接 Crash。
功能 | YYModel | FastEasyMapping | JSONModel | Mantle | MJExtension |
---|---|---|---|---|---|
相同属性名自动映射 | ✅ | ✅ | ✅ | ✅ | |
自定义属性转换方式 | ✅ | ✅ | |||
NSCoding | ✅ | ✅ | ✅ | ✅ | |
hash/equal | ✅ | ✅ | ✅ | ||
CoreData | ✅ | ✅ | ✅ |
就功能来说,Mantle 的可定制性最高,功能相对比较丰富。
YYModel、JSONModel、MJExtension 使用比较简单,但功能相对 Mantle 稍弱。
FastEasyMapping 功能最少,使用也不算方便。
Mantle 和 JSONModel 都需要 Model 继承自某个基类,灵活性稍差,但功能丰富。
YYModel、MJExtension 都是采用 Category 方式来实现功能,比较灵活,无侵入。
但注意 MJExtension 为 NSObject/NSString 添加了一些没有前缀的方法,且方法命名比较通用,可能会和一个工程内的其他类有冲突。
FastEasyMapping 采用工具类来实现 Model 转换的功能,最为灵活,但使用很不方便。
如果需要一个稳定、功能强大的 Model 框架,Mantle 是最佳选择,它唯一的缺点就是性能比较差。
如果对功能要求并不多,但对性能有更高要求时,可以试试我的 YYModel。
Swift 相关的几个库性能都比较差,非 Swift 项目不推荐使用。
1. 缓存
Model JSON 转换过程中需要很多类的元数据,如果数据足够小,则全部缓存到内存中。
2. 查表
当遇到多项选择的条件时,要尽量使用查表法实现,比如 switch/case,C Array,如果查表条件是对象,则可以用 NSDictionary 来实现。
3. 避免 KVC
Key-Value Coding 使用起来非常方便,但性能上要差于直接调用 Getter/Setter,所以如果能避免 KVC 而用 Getter/Setter 代替,性能会有较大提升。
4. 避免 Getter/Setter 调用
如果能直接访问 ivar,则尽量使用 ivar 而不要使用 Getter/Setter 这样也能节省一部分开销。
5. 避免多余的内存管理方法
在 ARC 条件下,默认声明的对象是 __strong 类型的,赋值时有可能会产生 retain/release 调用,如果一个变量在其生命周期内不会被释放,则使用 __unsafe_unretained 会节省很大的开销。
访问具有 __weak 属性的变量时,实际上会调用 objc_loadWeak() 和 objc_storeWeak() 来完成,这也会带来很大的开销,所以要避免使用 __weak 属性。
创建和使用对象时,要尽量避免对象进入 autoreleasepool,以避免额外的资源开销。
6. 遍历容器类时,选择更高效的方法
相对于 Foundation 的方法来说,CoreFoundation 的方法有更高的性能,用 CFArrayApplyFunction() 和 CFDictionaryApplyFunction() 方法来遍历容器类能带来不少性能提升,但代码写起来会非常麻烦。
7. 尽量用纯 C 函数、内联函数
使用纯 C 函数可以避免 ObjC 的消息发送带来的开销。如果 C 函数比较小,使用 inline 可以避免一部分压栈弹栈等函数调用的开销。
8. 减少遍历的循环次数
在 JSON 和 Model 转换前,Model 的属性个数和 JSON 的属性个数都是已知的,这时选择数量较少的那一方进行遍历,会节省很多时间。