JSON：Jackson 流解析器——真的值得吗？ [关闭]

Posted 2023-04-19

【中文标题】JSON：Jackson 流解析器——真的值得吗？ [关闭]

【英文标题】：JSON: Jackson stream parser - is it really worth it? [closed]

【发布时间】：2011-01-28 20:53:35

【问题描述】：

我正在编写的应用程序中大量使用 JSON 解析。我所做的大部分工作已经使用 android 内置的 JSONObject 库（是 json-lib 吗？）实现。

JSONObject 似乎创建了 JSON 字符串中绝对所有内容的实例......即使我最终没有使用所有这些实例。

我的应用目前运行良好，即使在 G1 上也是如此。

我的问题是：使用像 Jackson 这样的流解析器所带来的速度和内存优势值得所有麻烦吗？

麻烦，我的意思是：据我所知，使用 Jackson 而不是内置库有三个缺点：

依赖于外部库。这最终使您的 .apk 更大。没什么大不了的。 您的应用程序更加脆弱。由于解析不是自动完成的，它更容易受到正在解析的 JSON 文本的更改的影响（也许我错了）。 编写代码以通过流解析器解析 JSON 既丑陋又乏味。

【问题讨论】：

我不同意#2。如果 JSON 结构以意想不到的方式发生变化，那么无论如何你真的很不走运。

在某些情况下不正确。例如，将一个对象作为值添加到另一个对象中。除非您在拉解析器中计划它，否则它会丢弃它，而使用 JSONObject，它会正常工作。例如：将 "first_name": "Adam", "last_name": "Olsen" 更改为 "first_name": "Adam, "last_name: "Olsen", "phone_numbers": "home": "555-867 -5309", "work": "888-555-5555" 会让你的拉式解析器在一个循环中关闭，比如：while(parser.nextToken() != JsonToken.END_OBJECT) - 你最终会提前打到 END_OBJECT , JSONObject 可以很好地解析它。

可以编写一个流解析器来处理它。我相信这就是 shipChildren (jackson.codehaus.org/1.5.0/javadoc/org/codehaus/jackson/…) 的用途。

酷，我去看看。谢谢

除非您遇到性能问题，否则 API 在后台执行的操作并不重要。

【参考方案1】：

在大多数情况下，我也在使用内置 JSON 解析器，但最近遇到了一个不适合的场景：对于一些 Web 服务请求，我收到超过 1 MB 的 JSON 文档。使用内置 JSON 解析器加载这些需要大量的主内存，并导致 OutOfMemoryException 多次。对于这些场景，流式解析器是更好的选择（尽管使用起来更不方便），并且内置的 JSON 解析器不提供流式传输，仅提供类似 DOM 的样式。

对于正在寻找适用于 Android 的流式 JSON 解析器的任何人，我强烈建议您使用 Google's GSON。我一开始尝试过 Jackson JSON，它运行良好，直到我尝试构建我的应用程序的发布版本：ProGuard 报告了几个问题，并且正在运行的应用程序在 Jackson 的 ObjectMapper 的构造函数中以神秘的 NullPointerException 崩溃（尽管一切正常在调试版本中很好）。即使经过几个小时的尝试，我也无法解决这个问题。然后我切换到 GSON，一切都像魅力一样。

顺便说一句：仅 GSON 流式处理的 jar 的大小只有 14kB —— 所以没什么好担心的。

【讨论】：

原来有办法制作ProGuard内容；我的同事想通了。我希望能说服他写关于细节的博客，因为不幸的是它不是单行的。从根本上说，ProGuard 的弱点在于它依赖于静态分析，这会遇到反射问题。需要注意的一件事是，如果仅使用来自核心 jar 的 Jackson 的流式传输内容（JsonParser、JsonGenerator），则应该没有问题。它是映射器部分，大量使用反射。

如果我们必须使用映射器，您是否介意将那些遇到 NullPointerException 问题的用户指向解决方案的总体方向？

正如我的帖子中提到的，我还没有找到NullPointerException 的解决方案。这就是我改用 GSON 的原因。

StaxMan 提到他的同事想出了办法，尽管这似乎不是一个简单的解决方案。

抱歉，没有正确读取 cmets...

【参考方案2】：

猜你已经回答了你自己的问题。 :) 我自己使用内置的 JSON 解析器，从未寻找过替代方案。

编辑：现在我正在使用来自DroidParts 的基于注释的瘦包装器。

【参考方案3】：

我认为问题是内置的是否足够好。如果是的话，当然，最小化依赖关系通常是一个好策略。足够好可以指效率和易用性。

不管怎样，Jackson 也有一个不错的树模型以及完整的数据绑定。 树模型比默认解析器快得多（解析在 J2SE 上快 3 到 5 倍，在 Android 等其他平台上可能类似，树模型本身也可能更有效）。 或者：如果您不希望依赖于第二个 jar（树模型和数据绑定需要映射器），那么编写自己的树来覆盖您的用例也很简单。要么使用基本的 HashMap/ArrayList/wrappers，或者如果你愿意，也可以拥有自己的类。 Builder 可能是 40 行代码。