我正在评估使用GWT-RPC和HTTP Call进行的调用之间是否存在性能差异。
我的appln服务作为Java servlet托管，我目前正在使用HTTPProxy连接从中获取数据。我希望将它们转换为GWT-RPC调用，如果这会带来性能提升。
我想知道每个人的利弊......
还有关于衡量异步调用性能的工具的任何建议......
[A good article on various Server communication strategies可与GWT一起使用。]
答案 0 :(得分：13)
当后端也用Java编写时，GWT-RPC通常是首选，因为它意味着不必在每端对对象进行编码和解码 - 您只需将常规Java对象传输到客户端，然后在那里使用它。
JSON（使用RequestBuilder）通常在后端用其他语言编写时使用，并要求服务器对响应对象进行JSON编码，并将客户端JSON解码为{{1}用于GWT代码。
如果我不得不猜测我会说GWT-RPC也导致较小的传输对象，因为GWT团队针对这种情况进行了优化，但两者都可以工作，而JSON仍然可以很小。在大多数情况下，这只取决于开发人员的便利性。
对于衡量请求时间的工具，您可以使用Chrome / Webkit的开发人员工具或Firefox的Firebug扩展程序，也可以测量应用中的请求时间，并在延迟的收集和分析请求中将指标数据发送回服务器
答案 1 :(得分：5)
我写了问题中提到的那篇文章（感谢链接！）。
与往常一样，答案是'它取决于'。我已经使用了GWT-RPC和JSON。
如上所述，GWT-RPC允许通过线路运送java对象（有一些限制）的一些严重的生产力。可以共享一些逻辑，GWT负责编组/解组对象。
JSON允许其他非GWT客户端进行跨域访问和使用。您可以使用覆盖类型，但不能共享任何行为（如验证）。与GWT-RPC（我上次看）相比，JSON也可以轻松压缩和缓存。
由于我们不知道有效载荷是什么，因此很难给出性能建议。我建议（再次，就像上面有人一样）测试自己。
答案 2 :(得分：4)
只是对其他答案的补充，有一点需要考虑哪些可能影响您对JSON的决定，即使您在后端使用Java：
也许将来某个时候，您希望允许非GWT客户端与您的服务器通信。许多现代网站提供某种API访问，如果您使用的是JSON，那么您基本上已经拥有了相对开放的API。
答案 3 :(得分：1)
总的来说，我同意Jason的观点 - 如果您的服务器端使用Java，请使用GWT-RPC。您将能够重用POJO，验证逻辑等.RPC也倾向于使用MVP和代码分割“更好地”发挥作用。
但是，如果你的服务器端使用其他任何东西都使用JSON - 但不要担心，JavaScript Overlay Types使用JSON是轻而易举的事。但是，您无法在服务器上重用客户端的代码（YMMV）。
从性能的角度来看 - 我会说JSON在这里有优势。现代浏览器有一些非常好的方法可以快速编码/解码JSON。我不确定GWT-RPC是什么“幕后”，但我怀疑它在速度方面可以击败JSON。至于有效负载 - 这取决于开发人员（JSON中对象的名称等），但我会说，一般来说JSON也（可轻微地）更小。在服务器上启用压缩（例如，mod_deflate on Apache HTTP）以进一步挤压位数;）