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

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

这表明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左右时，就会出现滑动很卡的现象，特别是由下向上滑动时，特别的卡，会狂打出：

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