Android：在 ContentProvider 中处理非常大的数据集以避免内存限制

Question

我正在使用ContentProvider 查询数据库并返回Cursor 用于CursorLoader：

ItemsActivity：

public class ItemsActivity extends SherlockActivity implements LoaderCallbacks<Cursor> {

    @Override
    public void onCreate(Bundle savedInstance) {
        ....
        getSupportLoaderManager().initLoader(LOADER_ID, null, this);
        ...
    }

    @Override
    public Loader<Cursor> onCreateLoader(int loaderId, Bundle bundle) {
        return new CursorLoader(getApplicationContext(), itemsListUri, ...); 
    }

    ...
}

ItemsContentProvider：

public Cursor query(Uri uri, String[] projection, String selection, ...) {
    SqliteQueryBuilder builder = new SqliteQueryBuilder();
    builder.setTables(ItemsTable.NAME);
    return builder.query(db, projection, selection, ...);
}

活动有一个ListView，我使用CursorAdapter（通过LoaderCallbacks更新）来表示游标内的数据。

这工作正常，直到我需要在大型数据集中查找项目（例如，超过 30,000 行）。观察日志，我发现查找超出了内存限制，并且从结果游标中删除了一些行。

我的问题：当使用这样的游标时，处理非常大的数据集的最佳方法是什么？

我当前的解决方案是将ContentProvider 中的SQLite 查询分解为具有偏移和限制的查询序列，然后使用MergeCursor 类组合这些查询：

private static final int LIMIT = 5000;

// Ignoring projection, selection, etc for simplicity here
public Cursor query(Uri uri, String projection, String selection, ...) {
  List<Cursor> cursors = newList();
  int offset = 0;
  Cursor c = db.rawQuery("select * from items limit " + LIMIT + " offset " + offset, null);
  while (c.getCount() > 0) {
    cursors.add(c);
    offset += c.getCount();
    c = db.rawQuery("select * from items limit " + LIMIT + " offset " + offset, null);
  }
  return createMergedCursor(cursors);
}

private Cursor createMergedCursors(List<Cursor> cursors) {
    if (cursors.size() == 1) {
        return cursors.get(0);
    }
    return new MergeCursor(toCursorsArray(cursors));
}

这将加载所有数据，但在第一次进行查找时会有很长的延迟。执行多个查询时，列表视图大约 5 秒为空。

请注意，当我尝试单次查找（而不是批量查找）时，加载几乎是瞬时的，尽管在达到内存限制时滚动列表时会有轻微的暂停。

所以：

使用单个查询：快速更新列表视图，但达到滚动暂停和内存限制。

使用批处理查询：列表视图更新缓慢，但滚动流畅且未达到内存限制。

我想知道是否有更好的解决方案可以快速更新列表视图，但在滚动列表时也会根据需要获取更多数据。

Android 4.2.1、Nexus 7

Answer 1

移动设备不是为处理这些数据量而设计的。

但是，如果您真的想给可怜的用户施加如此大的滚动列表，您可以将其设计为仅按需加载条目的虚拟列表；见Android Endless List。

注意：使用OFFSET 子句效率低下；详情请见Scrolling Cursor。

Answer 2

我同意 CL 的观点，即您不应该这样做。这在移动设备上不是一个好主意，在台式机上也不是。谁想滚动 30000 个元素？做什么的？很可能用户只在寻找一个结果，不是吗？所以提供一种简单的方法来过滤结果集。

直到结果集小到可以实际使用（这与列表滚动良好不同 - 它的结果数量可能要少得多），您只需显示当前查询的命中总数，也许一些元素作为样本提供给用户。用户必须过滤列表以获得实际可用的大小。