8. ContentProvider与数据共享：跨进程数据访问、URI匹配、Cursor与Binder桥接

ContentProvider，说白了就是Android系统给咱们开的一扇窗。让一个App的数据，能被另一个App访问到。我刚开始接触Android时，总觉得这玩意儿有点多余——直接用文件或者数据库不就行了？后来做项目才明白，跨进程的数据共享，没它还真不行。

你想想看，每个App跑在自己的进程里，有自己的沙箱。你想读通讯录、看相册、获取日历事件，这些数据都在别的App手里。没有ContentProvider，你连个电话号码都拿不到。嗯，这就是它存在的意义。

8.1 跨进程数据访问的核心机制

跨进程访问，说白了就是两个进程之间要交换数据。Android的进程间通信（IPC）方案有好几种，但ContentProvider走的是Binder路线。为什么选Binder？因为它安全、高效，而且支持匿名共享内存。

我个人习惯把ContentProvider理解成一个“数据服务端”。它暴露数据，但不关心谁来访问。客户端通过ContentResolver发起请求，底层自动走Binder通道。整个过程对开发者是透明的——你调一个query()方法，背后就是一次跨进程调用。

核心流程：

  • 客户端调用ContentResolver.query()
  • Binder驱动将请求转发到Provider所在进程
  • Provider执行查询，返回Cursor
  • Cursor通过Binder桥接回客户端

这里有个坑，我踩过。Cursor本身不是跨进程对象。它只是一个接口，真正的实现类（比如CursorWindow）内部持有共享内存的指针。Binder传递的其实是Cursor的Binder代理，客户端拿到后通过它去读共享内存。嗯，这个设计很巧妙，但如果你在Cursor上做了太多操作，内存就炸了。

8.2 URI匹配：从字符串到数据表的映射

ContentProvider用URI来标识数据。一个典型的URI长这样：

content://com.example.app.provider/table1/123

拆开来看：

  • content://：协议头，固定写法
  • authority：唯一标识，通常是包名+provider名
  • path：表名或资源路径
  • ID：具体某条记录（可选）

为什么需要URI匹配？因为一个Provider可能管理多张表。你传一个URI过来，我得知道你要查哪张表。Android提供了UriMatcher来做这件事。

private static final UriMatcher sUriMatcher = new UriMatcher(UriMatcher.NO_MATCH);

static {
    sUriMatcher.addURI("com.example.app.provider", "users", USERS);
    sUriMatcher.addURI("com.example.app.provider", "users/#", USER_ID);
    sUriMatcher.addURI("com.example.app.provider", "orders", ORDERS);
}

@Override
public Cursor query(Uri uri, String[] projection, String selection,
                    String[] selectionArgs, String sortOrder) {
    switch (sUriMatcher.match(uri)) {
        case USERS:
            // 查询所有用户
            break;
        case USER_ID:
            // 查询单个用户
            break;
        case ORDERS:
            // 查询所有订单
            break;
        default:
            throw new IllegalArgumentException("Unknown URI: " + uri);
    }
}

我曾经在项目里犯过一个低级错误——忘了在UriMatcher里注册URI。结果客户端传了正确的URI过来，Provider却抛异常说“Unknown URI”。排查了半天才发现是静态代码块没执行。嗯，静态代码块在类加载时执行，如果你用反射或者动态加载，可能会踩这个坑。

8.3 Cursor与Binder桥接

Cursor是查询结果的载体。在ContentProvider里，query()方法返回的就是Cursor。但这里有个问题——Cursor是Java对象，不能直接跨进程传递。怎么办？

Android的解决方案是：用Binder传递一个Cursor的代理对象。这个代理对象内部持有共享内存的引用。客户端通过代理去读共享内存，数据就过来了。

具体来说，CursorWindow是真正的数据容器。它分配一块匿名共享内存，把数据库查询结果填进去。然后Provider把CursorWindow的Binder描述符传给客户端。客户端拿到后，通过Binder驱动映射到自己的进程空间，就能直接读了。

避坑指南：

我曾经在项目里一次性查询了上万条记录，结果CursorWindow撑爆了。默认的CursorWindow大小是2MB，超过这个量就会报错。建议分页查询，或者用ParcelFileDescriptor传文件。

还有一个细节：Cursor的close()方法。客户端用完Cursor后，一定要记得关闭。否则共享内存不会被释放，时间长了就会内存泄漏。我见过一个App，每次查询都不关Cursor，最后OOM了。嗯，这种问题很难排查，因为堆栈里看不到明显异常。

8.4 实战：自定义ContentProvider

光说不练假把式。咱们写一个简单的Provider，管理用户数据。

public class UserProvider extends ContentProvider {

    private SQLiteDatabase db;

    @Override
    public boolean onCreate() {
        // 初始化数据库
        db = new DBHelper(getContext()).getWritableDatabase();
        return true;
    }

    @Override
    public Cursor query(Uri uri, String[] projection, String selection,
                        String[] selectionArgs, String sortOrder) {
        // 根据URI匹配不同的表
        String table = getTableName(uri);
        return db.query(table, projection, selection, selectionArgs, null, null, sortOrder);
    }

    @Override
    public Uri insert(Uri uri, ContentValues values) {
        String table = getTableName(uri);
        long id = db.insert(table, null, values);
        // 通知数据变化
        getContext().getContentResolver().notifyChange(uri, null);
        return ContentUris.withAppendedId(uri, id);
    }

    @Override
    public int delete(Uri uri, String selection, String[] selectionArgs) {
        String table = getTableName(uri);
        int count = db.delete(table, selection, selectionArgs);
        if (count > 0) {
            getContext().getContentResolver().notifyChange(uri, null);
        }
        return count;
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection,
                      String[] selectionArgs) {
        String table = getTableName(uri);
        int count = db.update(table, values, selection, selectionArgs);
        if (count > 0) {
            getContext().getContentResolver().notifyChange(uri, null);
        }
        return count;
    }

    @Override
    public String getType(Uri uri) {
        // 返回MIME类型
        return "vnd.android.cursor.dir/vnd.example.user";
    }

    private String getTableName(Uri uri) {
        // 根据URI解析表名
        if (uri.getPath().contains("users")) {
            return "users";
        } else if (uri.getPath().contains("orders")) {
            return "orders";
        }
        throw new IllegalArgumentException("Unknown URI");
    }
}

这段代码看起来简单，但有几个点要注意：

  • 线程安全：ContentProvider的方法可能被多个线程同时调用。SQLite本身是线程安全的，但如果你用了其他数据源，得自己加锁。
  • 通知机制：数据变化后，记得调用notifyChange()。这样客户端注册的ContentObserver才能收到通知。
  • 权限控制：别忘了在AndroidManifest里声明权限。否则别的App访问不了。

8.5 知识体系总览

下面这张图，把ContentProvider的核心逻辑串起来了。从URI匹配到Binder桥接，再到Cursor的共享内存机制，一目了然。

ContentProvider 核心知识体系 客户端 App ContentResolver Binder 驱动 IPC 通道 服务端 App ContentProvider URI 匹配：UriMatcher → 解析 authority/path/ID → 路由到对应数据表 数据操作：query / insert / update / delete → SQLite / 文件 / 网络 Cursor 桥接：CursorWindow（共享内存）→ Binder 传递代理 → 客户端读取 核心：安全、高效、跨进程的数据共享方案

8.6 性能与安全考量

ContentProvider虽然好用，但也不是银弹。我总结了几条经验：

场景 建议 原因
大量数据查询 分页 + 限制返回列 避免CursorWindow撑爆
频繁数据变化 使用ContentObserver 避免轮询，减少Binder调用
敏感数据 加权限校验 防止未授权访问
跨进程大数据 考虑FileProvider Binder有1MB大小限制

注意：Binder的传输大小限制是1MB。如果你要传大文件，别走ContentProvider的query()方法。用FileProvider或者直接传文件路径，让客户端自己读。

嗯，ContentProvider这块内容，说深也深，说浅也浅。理解它的核心机制——URI匹配、Binder桥接、Cursor共享内存——基本上就能应付大部分场景了。我在实际项目中，用得最多的就是用它来暴露数据库给别的模块访问。只要注意线程安全和内存管理，一般不会出大问题。

最后说一句：别把ContentProvider当成万能工具。如果你的数据只在App内部用，用Room或者直接操作数据库就够了。跨进程共享才需要它。选对工具，事半功倍。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →