我们遇到了一个 IE8 噩梦，RPC 服务返回列表（或多或少）60 个对象，每个对象有 5 个属性。尽管现代浏览器可以完成这项工作，但 IE8 的响应速度还不够。 甚至还有一个open issue 与此相关。
我们计划为需要发送大量对象列表的服务更改 RPC，但我们希望更改服务器和客户端上可能的最少代码量。
第一个问题：在这种情况下，JSON 反序列化会在 IE8 上运行得更快吗？
我们喜欢简单的 RPC 服务。我们有我们的 CustomRemoteService 实现、我们的 CustomAsyncCallback 实现、我们的 CustomRPCException 实现等等。 RF 对我们来说是一个很大的变化。
第二个问题：使用返回单个 JSON 字符串然后在客户端反序列化它的 RPC 服务是否可以完成这项工作？
或者你能推荐另一种方法吗？
谢谢！
【问题讨论】：
标签： performance json gwt rpc
第一个问题：在这种情况下，JSON 反序列化会在 IE8 上运行得更快吗？
它应该运行得更快，因为 IE8 支持原生 JSON 解析（在 IE6 和 7 中，您可以使用 eval()，它应该仍然比手动解析字符串运行得更快 /em>)
但这在很大程度上取决于您对解析的对象所做的事情：如果您对其进行处理以从中重建 POJO，您可能会失去所有 JSON 的好处；另一方面，JS 覆盖的开销为零，但需要将所有数组或列表更改为 JsArrays，并且日期不能轻松地用 JSON 编码，它们需要额外的编组/解组。
第二个问题：使用返回单个 JSON 字符串然后在客户端反序列化它的 RPC 服务是否可以完成这项工作？
如果您的 JSON 处理比 RPC 反序列化更轻量级，那么可以。在客户端解析响应是一个简单的eval()（是的，奇怪的是它在可用时不使用本机 JSON），然后在解析的对象中查找； RPC 反序列化中花费最多的是解释值以重建对象；获取字符串只是在数组中查找，因此这取决于您稍后对该字符串执行的操作。
【讨论】：
我感觉到你的 IE8 痛苦。我们遇到了同样的问题。我们的解决方案是将所有内容序列化为 JSON 客户端，然后仅发送一个 JSON 对象备份并处理繁重的服务器端。 IE8 仍然没有像我们希望的那样快速处理反序列化，但它确实加快了速度（大约三倍）。如果您的情况可能，另一种选择可能是延迟执行 RPC 调用。
问题是，如果您有大量并发 RPC 调用发生，IE8 不是理想的浏览器。我希望能尽快解决这个错误。
【讨论】：