Android语言基础教程（208）AndroidContentProvider实现数据共享经典范例之查询联系人姓名和电话：别让APP当“数据孤岛”！Android ContentProvider带你

一、 开场白：当一个APP想“偷看”别人的通讯录

想象一下这个场景：你的APP是个刚出社会的“社交小能手”，它想帮用户快速找到通讯录好友。但问题是，通讯录数据牢牢掌握在系统“大佬”（Contacts App）手里。你总不能直接闯进人家的数据库里乱翻吧？那不成黑客了？Android系统这个“大管家”第一个不答应，分分钟给你报个 SecurityException，让你的APP当场“社会性死亡”。

那怎么办呢？难道就此放弃，让我们的APP成为一个“数据孤岛”吗？

当然不！这时候，就需要请出我们今天的超级英雄——ContentProvider（内容提供器）。它就像是系统为每个重要数据仓库安排的“官方新闻发言人”兼“前台接待”。

二、 ContentProvider：数据界的“社交达人”

1. 它到底是个啥？

说人话，ContentProvider就是一个专门帮其他APP“跑腿”拿数据的组件。它把自己应用的数据封装起来，只通过一套标准、统一的接口对外提供服务。其他APP不用关心数据到底是存在SQLite里、文件里，还是云端，只要按照规矩“下单”，ContentProvider就会把数据“打包”好送过来。

它的核心优势就是：

安全可控： “大管家”Android系统可以设置权限（Permission），只有被授权的APP才能向ContentProvider“下单”。标准统一： 不管底层数据多复杂，对外都是一套以 Uri为核心的访问API，学一次，到处用。

2. 它的工作流程，像极了点外卖

我们把查询联系人这个事儿，代入一个超好懂的外卖流程：

你（Client App）： 想吃...不对，想查询联系人。美团/饿了么（ContentResolver）： 你是通过一个叫 ContentResolver的对象来“下单”的。它是系统提供的，专门用于和所有ContentProvider打交道的“统一外卖APP”。餐厅地址（Uri）： 你得告诉“外卖APP”你要去哪家店点餐。在Android里，这个地址就是 Uri（统一资源标识符）。比如，联系人的Uri长得像： content://com.android.contacts/data/phones。 content://是协议， com.android.contacts是“餐厅名”（Authority）， data/phones是“菜单路径”（Path）。餐厅后厨（ContentProvider）： 系统通讯录应用里的ContentProvider就是“餐厅后厨”。它接收到“外卖APP”送来的订单（带着Uri和查询条件），然后在自己内部的SQLite数据库里一顿操作，把准备好的“美食”（数据）打包成一个 Cursor对象。外卖小哥： 这个 Cursor对象就像外卖小哥，他把数据“餐盒”安全地送到你手上。权限（Permission）： 最关键的一步！在你“下单”前，系统“大管家”会检查你有没有相应的“配送资格”，比如 READ_CONTACTS权限。没有？订单直接拒接！

看，整个过程清晰、安全、合规，完美避免了“破门而入”的违法行为。

三、 实战！手把手教你“盘”出联系人来

光说不练假把式，现在我们就撸起袖子，写代码！

第一步：申请“通行证”（权限）

在 AndroidManifest.xml文件里，郑重声明：“我要读联系人！”

<uses-permission android:name="android.permission.READ_CONTACTS" />

但这只是告诉系统“我有这个意图”。在Android 6.0（API 23）以后，你还需要在运行时像这样“苦苦哀求”用户：

// 在Activity或Fragment中
private fun checkPermissions() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.READ_CONTACTS
        ) == PackageManager.PERMISSION_GRANTED -> {
            // 已经有权限了，开搞！
            loadContacts()
        }
        else -> {
            // 没权限，弹窗申请
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.READ_CONTACTS),
                PERMISSION_REQUEST_CODE
            )
        }
    }
}
 
// 处理用户的授权结果
override fun onRequestPermissionsResult(
    requestCode: Int,
    permissions: Array<out String>,
    grantResults: IntArray
) {
    super.onRequestPermissionsResult(requestCode, permissions, grantResults)
    if (requestCode == PERMISSION_REQUEST_CODE) {
        if (grantResults.isNotEmpty() && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
            // 用户同意了，开搞！
            loadContacts()
        } else {
            // 用户残忍地拒绝了，给个提示吧
            Toast.makeText(this, "不给权限没法玩呀~", Toast.LENGTH_SHORT).show()
        }
    }
}

第二步：编写“核心业务逻辑”（查询数据）

权限到手，天下我有！现在可以真正查询了。

import android.content.ContentResolver
import android.provider.ContactsContract
 
private fun loadContacts() {
    // 获取“统一外卖APP”
    val contentResolver: ContentResolver = applicationContext.contentResolver
 
    // 定义要查询的“列”（只关心姓名和电话）
    val projection = arrayOf(
        ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, // 姓名
        ContactsContract.CommonDataKinds.Phone.NUMBER        // 电话
    )
 
    // 构建“餐厅地址”（Uri）。这个是查询系统通讯录电话信息的标准Uri。
    val uri = ContactsContract.CommonDataKinds.Phone.CONTENT_URI
 
    // 可选的查询条件，比如排序
    val sortOrder = "${ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME} ASC"
 
    // 开始“下单”！查询会返回一个Cursor对象。
    val cursor = contentResolver.query(
        uri,
        projection,
        null, // 没有筛选条件，查询所有
        null,
        sortOrder
    )
 
    // 处理“外卖小哥”送来的数据
    cursor?.use { c ->
        // 获取列索引，方便后面取数据
        val nameIndex = c.getColumnIndex(ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME)
        val numberIndex = c.getColumnIndex(ContactsContract.CommonDataKinds.Phone.NUMBER)
 
        // 遍历Cursor，一条条处理
        while (c.moveToNext()) {
            val name = c.getString(nameIndex)
            val number = c.getString(numberIndex)
            // 这里你就可以为所欲为了！比如添加到List，显示在RecyclerView里...
            Log.d("Contacts", "姓名：$name, 电话：$number")
            // 例如：contactsList.add(Contact(name, number))
        }
        // 注意：Cursor用完后必须关闭！这里用了`.use{}`扩展函数，会自动关闭，非常推荐。
    }
    // 通知UI更新，比如 adapter.notifyDataSetChanged()
}

第三步：在UI上展示（简单示例）

假设你有一个 RecyclerView和对应的Adapter，在 loadContacts函数中，你将查询到的数据添加到一个列表 contactsList中，然后通知Adapter刷新界面即可。

四、 深度思考与安全避坑指南

1. 为什么不用直接读数据库？
兄弟，不是不想，是做不到啊！系统通讯录的数据库是受保护的，其他APP根本无权访问。ContentProvider提供了一层完美的抽象和安全的沙箱机制。这才是“优雅”的编程。

2. 性能优化很重要！

Cursor必须关闭： 上面代码用了 .use{}，如果你用 try-finally，一定要在 finally块中调用 cursor.close()，否则会引起内存泄漏。移到后台线程： 数据库查询是IO操作，可能会耗时。务必在子线程（如 Coroutine、 RxJava）中执行 contentResolver.query操作，然后在主线程更新UI。只查询需要的列： 就像我们的 projection一样，别用 null查询所有列，省时省力。

3. 兼容性是爸爸
联系人相关的Uri在不同Android版本上可能有细微差别。我们示例中用的 ContactsContract.CommonDataKinds.Phone.CONTENT_URI是官方推荐的标准方式，兼容性最好。尽量不要自己去拼写那些魔法字符串Uri。

五、 总结

恭喜你！看到这里，你已经从一个想“硬闯”数据仓库的“小白”，蜕变成一个懂得通过ContentProvider“合规办事”的“高级工程师”了。

我们来快速回顾一下重点：

思想： ContentProvider是Android解决跨APP数据共享的安全桥梁。核心： Uri是地址， ContentResolver是工具， Cursor是结果。流程： 申明权限 -> 运行时请求 -> 构建查询 -> 执行并处理Cursor。美德： 记得关Cursor、做异步处理、精确查询。

现在，你已经掌握了这门“合法串门”的神技。不仅可以查联系人，举一反三，去访问系统的媒体库、短信（需要更高权限，且不推荐）、或者为你自己的APP设计一个供其他APP使用的ContentProvider，都不再是难事！

快去动手试试吧，让你的APP告别“孤岛”，成功“社交”起来！