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 站点。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论