Json.NET 项目刚刚发布了.NET JSON 框架 4.5 版本。新版本包含了许多新特性,并带来了显著的速度提升。InfoQ 最近采访了 Json.NET 的创建者 James Newton-King,采访过程谈及了新版本以及整个项目。
InfoQ: 在最后两个主要发布的版本(Json.NET 4.0 和 4.5)中,你最满意的特性有哪些?
James Newton-King:对于 Json.NET 4.0,我比较的满意的是借助.NET 4.0 而加入的动态支持。我最喜欢添加那些能够让我能边做边学的特性。例如,在 JObject/JArray/JValue 上实现 IDynamicMetaObjectProvider 对我来说无疑是一个学习的过程,而我也希望当前版本能够从中受益。在实现的同时,我还需要将其分离以便将它从 Json.NET 支持的旧版本中排除。
将 ISO 8601 日期格式作为默认的序列化格式是 Json.NET 4.5 中我最喜爱的特性。JSON 中的日期对于我来说一直是个头疼的问题,虽然 Json.NET 一开始就使用了微软的日期格式,但我从来都不喜欢。JSON 库的互操作性对于非微软平台显然是个问题,不过更主要的原因是,使用微软格式的日期易读性很差。开发人员调试代码时,ISO 格式“2009-02-15T00:00:00Z”要比微软的旧日期格式“\/Date(1198908717056)\/”易读得多。令人惊讶的是,对于该破坏性改动,我还没有收到任何人的抱怨,我想它的推出肯定让.NET 开发人员很开心。
InfoQ:在未来版本中,你最想要看到哪些关键特性被添加?(你在 Codeplex 上的特性列表提到了添加 JSON 递归上限支持,还有其他的吗?)
J.N.K.:添加 JSON 递归上限支持主要出于两个原因。第一个原因是因为微软的 JSON 序列化器支持它,而我想要支持微软提供的所有特性。我觉得添加一个上限很有用,特别是如果你想公开暴露端点并希望进行锁定的话。另外一个原因是 ASP.NET MVC 团队会把 JSON 与 Web API 一同使用。目前他们自己实现了该功能,不过由于添加这个特性很容易,所以我想让 Web API 与 Json.NET 的工作方式变得与 JSON 的工作方式尽可能地相似。
我从来不为 Json.NET 添加新特性而筹备什么计划。我倾向于看看 Json.NET 开发人员在一些网站如 StackOverflow 上的提问,看看他们报告给我的 bug,然后想出一些主意来帮助改善这种情况。有的时候新特性与文档之间存在一个空档期,以至于开发人员不知道新特性已经有了。
InfoQ:你曾经提到“一个完美的 bug 修复意味着当前性能测试能够跑得 70,000% 快”,能否给大家解释一下?
J.N.K.:一位微软开发人员在对 Json.NET 进行压力测试后发现,将 100,000 个嵌套数组反序列化为 LINQ to JSON 对象花费的时间比想象中的要长得多。性能差的原因是因为 LINQ to JSON 对象会检查递归循环,也就是说,如果一个数组不是它自己的父容器,那么每次当新的嵌套数组反序列化时,都会检查它所有的父容器,例如,数组 90,001 会检查它的 90,000 个父容器,数组 90,002 会检查它的 90,001 个父容器等等。显然这种情况不是很理想。
解决方案很简单:检查被添加的条目是否拥有任何子元素。如果一个数组没有任何子元素的话,那么因为它不可能作为它自身父容器,因此可以跳过递归父容器检查。这一行的代码改动立刻带来了由 43 秒到 63 毫秒的速度提升。
InfoQ:4.0-6 发布版本着重强调了比.NET framework 方案更好的性能。你认为 Json.NET 的性能比起它的整个性能集合有重要性如何?
J.N.K.:除了那些需要极限性能的人员之外,几乎每一位开发人员都会从提高生产效率的特性中获益,因此平衡两者变得很重要。我要做的是确保 Json.NET 比.NET framework 序列化器更快,并同时提供更多功能。
InfoQ:好的,再次感谢 ****James Newton-King 的到来。如果你想要关于所有新特性的完整信息,可以查看这篇宣布;而如果想了解所有项目特性的概述,可以访问它的 Codeplex 站点。
评论