Android开发笔记之:深入理解Cursor相关的性能问题

当数据库中存有大量数据的时候，用cursor查询时要注意，有可能引发性能问题。数据库查询出来的cursor都会由一个cursorwindow来进行数据管理，包括内存空间的申请和数据的填充。cursorwindow对cursor中的内容大小有限制，限制为1024*1024也就是1m，换句话说cursor中数据的大小不能超过1m，如果超过1m会引发如下的错误：

08-23 05:48:31.838: debug/cursor(1805): skip_rows row 149
08-23 05:48:31.844: error/cursorwindow(1805): need to grow: msize = 1048576, size = 11499, freespace() = 7397, numrows = 80
08-23 05:48:31.844: error/cursorwindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: error/cursor(1805): failed allocating 11499 bytes for blob at 228,7
08-23 05:48:31.849: debug/cursor(1805): finish_program_and_get_row_count row 12
08-23 05:48:31.851: debug/browser/browserbookmarkfoldersadapter(1805): getview()-position:149
08-23 05:48:32.019: debug/cursor(1805): skip_rows row 148

这表明cursorwindow中的空闲空间已经不足，已经在申请新的空间，但似乎申请失败。这个错误有时候会导致查询得到的cursor为null，有时候不会引发太严重的问题。但是它会引起性能上的问题，不停的申请空间会占用大量的cpu时间，从而导致整个手机变卡。特别是在listview或gridview中绑定的cursor，会导致无法滑动，或者滑动变的十分的卡。用android2.3的原生browser，打开其中的历史记录，当有超过200条历史记录时，不停的滑动，特别是由下向上滑时会变的十分的卡，而对于其书签，如果条目超过100，且每个都有缩略图时，滑动会变得特别的卡，甚至都打不开，就是这个原因。
这个问题没有根本的解法，这是android系统的限制，唯一可行的就是想办法避免，也就是尽可能让cursor的大小 小于1m，以下是可行的方法：
1. 只查询需要的字段
这个特别重要，根据ui显示的需要，或者实际的需要查询需要的字段。就是一定要给contentresolver.query(uri, projection)第二个参数projection，如果这个参数为null，那么就会查询表中所有的字段，那么当条数一增加cursor的大小 会增长很快。browser中历史记录的原因就是它在query的时候查询了所有的字段，其数所库中保存了favicon和thumbnail二进制文件，因此当包含了这二个字段时，cursor的容量很容易就达到了限制。
2. 二进制文件不要存在数据库中
数据库仅适用于保存一些较短文字，整数，布尔，浮点数等一些，易于查询和操作的轻量级的数据，目的也是在于快速搜索和查询。对于像图片，较长的文字（如文章）等大数据，最好直接以文件形式存储在硬盘中，然后在数据库保存它们的访问路径。对于像favicon这样的小图片也可以考虑存在数据库中，但是像对于thumbnail的图片就不明智，除非整个应用在数量上有限制（比如只有几十或百级）否则很容易在查询的时候达到1m的限制。
3. 对于特别大量的数据超过5000级或万级或十万级或百万级的要分段查询
无论表中的一条记录数据量如何的小，当条数达到5000级或者万级或者更多的时候，还是会达到1m的限制，这时就需要分段查询，比如每次查询500个，或者1000个。另外，如果是要做展示用，这么多数据一下子出来，用户也不方便查看。
【实例】android2.3书签，历史记录和最多访问三个页面当数据量达到300左右时，就会出现滑动很卡的现象，特别是由下向上滑动时，特别的卡，会狂打出：

08-23 05:48:31.844: error/cursorwindow(1805): need to grow: msize = 1048576, size = 11499, freespace() = 7397, numrows = 80
08-23 05:48:31.844: error/cursorwindow(1805): not growing since there are already 80 row(s), max size 1048576
08-23 05:48:31.844: error/cursor(1805): failed allocating 11499 bytes for blob at 228,7

这样的log。而书签似乎都没有办法打开和滑动，其特别的卡。
究其原因就是它们在查询的时候都用了同一个字段集browser.history_projection这个是把bookmarks表中的所有字段都 查询出来。书签，历史记录和最多访问虽是三个不同的展示页，但它们的数据是相同的都是来自bookmarks表。bookmarks表中存有_id,title,url,bookmark,favicon,touch_icon,thumbnail等字段，其中favicon和thumbnail是二进制图片数据(byte[])。browser.history_projection里面包含了所有的字段，当然也包含了favicon和thumbnail，所以当条目一旦达到200多时，cursor就会达到其1m的限制，因此会导致性能下降，滑动变卡。

事实上对于历史记录和最多访问二个页面来讲thumbnail和touch_icon根本就没有用到，它只需要_id,title,url,bookmark和favicon；对于书签页，也仅是在grid时才用到thumbnail。所以，只需要把查询时的字段集browser.history_projection中的thumbnail去掉，即可以解决滑动变卡。