使用 OData 时如何加快 Android 版 Restlet 的速度？
我正在尝试使用适用于 Android 的 Restlet 来查询 OData 数据源。然而，我对它在模拟器和真实设备上的性能都没有印象。我在包装器 AsyncTask 中发出了请求，以使 UI 做出响应，但最终返回对象仍需要 1 分钟多的时间。
我在 LogCat 窗口中得到了很多这样的内容：
10-04 18:20:41.667: DEBUG/dalvikvm(278): GC freed 7872 objects / 523928 bytes in 279ms
我可以做什么来加快查询速度？
I am attempting to use Restlet for Android to query an OData data source. However, I am not impressed with its performance in both the emulator as well on a real device. I have the requests made in a wrapper AsyncTask to make the UI responsive but it still takes over 1 minute to finally return the objects.
I get plenty of these in the LogCat window:
10-04 18:20:41.667: DEBUG/dalvikvm(278): GC freed 7872 objects / 523928 bytes in 279ms
What can I do to speed up the queries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 odata4j - http://odata4j.org 这是 Java 的替代 odata 库，包括 Android 兼容的客户端 api 。
我们刚刚在 0.3 版本中发布了一个简单的 Android 客户端示例。此示例演示了解析/分页任意 odata 服务的有效方法。
除了服务驱动的分页（Alex 提到的）之外，我们还使用高效的 xml pull 解析器实现来解析 odata 负载（我们发现堆活动/GC 是 Android 上最大的性能瓶颈）。
Check out odata4j - http://odata4j.org This is an alternative odata library for java, including an android-compatible client api.
We just released a simple android client example in our 0.3 release. This example demonstrates an efficient way of parsing/paging an arbitrary odata service.
Along with service driven paging (mentioned by Alex), we use the efficient xml pull parser implementation to parse the odata payload (we found heap activity/GCs to be the biggest perf bottleneck on android).
我知道这对您提高 RESTlet 库的性能没有帮助...但是：
需要考虑的一件事是使用名为 服务驱动分页。
请注意，这与 $top 和 $skip （又名客户端驱动的分页）不同，因为即使客户端不要求，服务器也会进行分页。
当客户端对大型数据集进行未经过滤的查询时，SDP 特别有用。
这样也许您可以将 7872 数字降低到更易于管理的数字。
I know this doesn't help you with the perf of the RESTlet library... but:
One thing to consider is using something called Service Driven Paging.
Note this is distinct from $top and $skip (aka client driven paging), because the server pages even if the client doesn't ask for it.
SDP is particularly useful when a client does an unfiltered query over a large data set.
That way perhaps you can lower that 7872 number to something more manageable.