android中SimpleCursorAdapter的性能问题
我试图显示一个充满 SimpleCursorAdapter 的 ListView。 SimpleCursorAdapter 接收一个 Cursor，其中充满了 rawQuery 的执行，例如：
SELECT DISTINCT s.cod AS _id, s.name AS name FROM supplier s
INNER JOIN product p ON p.supplier = s.cod
INNER JOIN productprice pp ON pp.product = p.cod
WHERE
pp.category = 'w'
ORDER BY s.name
当我直接在库中执行此查询时，它会在不到 0.1 秒的时间内返回 40 行（正常）。存储库中 rawQuery 的执行速度也非常快。问题是当我执行 myListView.setAdapter(simpleCursorAdapter); 时。需要2分多钟！因此，我将查询更改为 SELECT cod AS _id, name FROM seller ORDER BY name 并且 setAdapter 的执行速度非常快（“正常快速”hshs）。
我的问题： 我可以在 rawQuery 中执行的 JOIN 来填充 listView 是否存在限制？我做错了什么吗？我应该在存储库中使用 query() 而不是 rawQuery() 吗？
抱歉英语不好，提前致谢。
I'm trying to show a ListView filled with a SimpleCursorAdapter. The SimpleCursorAdapter receives a Cursor filled with the execution of a rawQuery like:
SELECT DISTINCT s.cod AS _id, s.name AS name FROM supplier s
INNER JOIN product p ON p.supplier = s.cod
INNER JOIN productprice pp ON pp.product = p.cod
WHERE
pp.category = 'w'
ORDER BY s.name
When I execute this query directly in the base, it returns 40 rows in less than 0.1 sec (normal). The execution of the rawQuery in the repository is very fast too. The problem is when I do the myListView.setAdapter(simpleCursorAdapter);. It takes more than 2 minutes! So i've changed the query to SELECT cod AS _id, name FROM supplier ORDER BY name and the execution of the setAdapter was pretty fast ("normal fast" hshs).
My questions:
Exist a limit of JOIN's that I can do in a rawQuery to fill a listView? Am I doing something wrong? Should I use query() in the repository instead of rawQuery()?
Sorry about the english and thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您提供给 SimpleCursorAdapter 的 Cursor 是数据库查询的结果集。如果数据库查询很快，那么问题就出在CursorAdapter上。我经历过 CursorAdapter 性能较差（使用 SimpleCursorAdapter 和扩展 CursorAdapter 或 ResourceAdapter 的自定义适配器）。我最终从 Cursor 中提取数据，放入数组中，并扩展 ArrayAdapter，这给了我更好的性能。
The Cursor you provide to the SimpleCursorAdapter is a resultset from the database query. If the database query is fast, then the problem is located in the CursorAdapter. I have experienced that CursorAdapters have poor performance (both using SimpleCursorAdapter and custom adapters extending CursorAdapter or ResourceAdapter). I ended up pulling the data from the Cursor, put in in an array, and extend the ArrayAdapter, which gave me much better performance.