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去掉,即可以解决滑动变卡。