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