使用 GWT-RPC 与 RequestFactory 来传递大型数组
我正在构建一个应用程序，它检索数据并将其解析为二维数组对象，然后再将其发送回客户端。然后，应用程序使用这些数据在 HTML5 画布上创建图像。该数组包含数千个条目，当我使用 GWT-RPC 构建应用程序时，它工作正常，但将数组传输到客户端花费的时间太长（几分钟）。
我在搜索解决方案时发现了此问题：http:// code.google.com/p/google-web-toolkit/issues/detail?id=860
最后的回复是几个月前的，但似乎没有关于最佳方法的决定性答案将大型数组从服务器传递到 客户。由于 deRPC 已被弃用（我还没有实际尝试使用它），使用 requestfactory 是唯一的选择吗？看起来 requestFactory 应该是用于访问数据库，而不是用于执行计算和返回大结果，而且我还没有找到发出计算请求并将结果传回的示例。我应该在当前的实现中创建一个 JSON 对象而不是数组并保留 RPC，还是在 requestFactory 方面我遗漏了一些东西？
I am building an application which retrieves data and parses it into a two-dimensional array object before sending it back to the client. The application then uses the data to create an image on HTML5 canvas. The array contains several thousand entries, and when I built the application using GWT-RPC, it worked properly, but it took too long to transfer the array to the client (several minutes).
I found this issue when searching for solutions: http://code.google.com/p/google-web-toolkit/issues/detail?id=860
The last response was from a couple months ago, but there doesn't seem to be a conclusive answer to the best way to go about passing large arrays from server to client. Since deRPC is being deprecated (I have yet to actually try using it), is using requestfactory the only choice? It seems like requestFactory is supposed to be for accessing a database, and not for performing calculations and returning large results, and I haven't found an example where a request is made for a calculation and a result is passed back. Should I create a JSON object instead of an array in my current implementation and keep RPC or am I missing something when it comes to requestFactory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您链接到的问题是关于客户端反序列化速度慢，而不是数据传输速度。您应该首先使用 Firebug 或类似工具测量传输速度，然后从 RPC 调用的总时间中减去该时间，以找出反序列化期间花费了多少时间。大致来说，分手的过程是这样的：
你应该首先找出哪个部分是真正的瓶颈，如果结果是数据传输速度，你可能需要重新考虑你的设计。请参阅我的回答问题。
编辑：
IMO，在计算出上述时间间隔之前，您应该先搁置 JSON 或其他方法是否适合您的问题
The issue you linked to is about slow speed of de-serialization on the client and not the data transfer speed. You should first measure the transfer speed using Firebug or similar tool and then subtract this time from total time of RPC call to find out how much time is spent during de-serialization. Roughly speaking, the breakup goes like this:
You should first find out which part is the real bottleneck, if it turns out to be the data transfer speed, you'll probably need to re-think your design. See my answer to a related question.
EDIT:
IMO, until you have calculated the above time breakup, you should put aside the question that whether JSON or another approach is right for you