📚 课程目录第3章监听权限状态的场景分析

监听权限状态的场景分析：相机、位置、麦克风权限的典型监听需求

在 Android 应用开发中，运行时权限机制早已不是“一次性申请”的简单模型。自 Android 6.0（API 23）起，用户可以在应用运行期间随时通过系统设置撤销已授予的权限；从 Android 11 开始，系统还会在多次拒绝后自动将权限状态置为“不再询问”。这意味着传统的一次性 checkSelfPermission 快照检查存在严重的状态不同步风险。本章针对相机、位置、麦克风三大高频敏感权限，剖析其真实的监听场景与架构化解决方案。

1. 核心场景差异分析

不同的物理权限在撤销时对业务的影响不同，监听侧重点也随之变化。下表从典型用途、监听核心诉求、UI处理要点与错误边界四个维度进行对比：

权限类型	典型用途	监听核心需求	状态变更时 UI 与业务处理要点
相机	扫码、拍照、视频通话	权限撤销后立即释放 Camera 实例，防止预览黑屏或 App 崩溃	隐藏扫码框/拍照按钮，提示用户前往设置开启；必要时销毁当前预览界面
位置	地图导航、后台跟踪、地理围栏	监控前后台权限降级（精确→粗略）或撤销，保障定位数据合法性	停止定位服务并清除现有定位结果；展示权限变更提示条；更新定位精度标识
麦克风	录音、语音识别、通话	权限撤销时自动保存已录制文件并停止录音，避免音频数据丢失	禁用录音按钮；展示麦克风权限提示；自动保存录音草稿并关闭 AudioRecord

实践要点：所有监听逻辑建议在 onStart() 中开始收集，在 onStop() 中取消收集。这样既能保证权限状态变更时 UI 及时响应，又能在界面不可见时释放资源，避免无意义的后台监听。

2. 技术实现架构与数据流

要实现对权限状态的持续监听，不能依赖轮询或零散的回调注册。推荐采用 Repository → Flow → ViewModel → UI 的标准化数据管道架构。下层利用 onOpChangedListener 或 registerOnAppOpsChangeListener 将回调转化为结构化的 Flow，上层通过 StateFlow 保持状态一致性与生命周期安全。

  架构优势：通过 Flow 解耦权限监听的具体实现与 UI 消费逻辑。开发者可以在 Repository 层集中处理多权限的聚合监听，ViewModel 只需关注业务状态转换，UI 层仅做响应式渲染。

3. API 机制与核心代码实现

实现持续监听需要将传统的一次性 API 与回调注册相结合。以下表格对比了核心 API 的差异：

API / 机制	返回类型	是否持续监听	适用场景
`ContextCompat.checkSelfPermission()`	`Int` (GRANTED / DENIED)	否	页面初始化时的一次性快照检查
`shouldShowRequestPermissionRationale()`	`Boolean`	否	监听前判断是否需要弹出解释对话框
`registerOnOpChangeListener` / `callbackFlow`	`Flow<Status>`	是	需要实时感知权限撤销/授予的长期场景

以下是一个基于 callbackFlow 监听位置权限状态的典型仓库层实现。该方案将底层回调适配为响应式数据流，并自动处理初始化状态发射与资源清理：

class LocationPermissionObserver(
    private val context: Context
) {
    private val appOpsManager =
        context.getSystemService(Context.APP_OPS_SERVICE) as AppOpsManager

    @RequiresPermission(Manifest.permission.ACCESS_FINE_LOCATION)
    fun observeLocationPermission(): Flow<Boolean> = callbackFlow {
        val permission = Manifest.permission.ACCESS_FINE_LOCATION
        val opCode = AppOpsManager.permissionToOpCode(permission)
        val listener = AppOpsManager.OnOpChangedListener { op, packageName ->
            if (op == opCode && packageName == context.packageName) {
                val status =
                    ContextCompat.checkSelfPermission(context, permission)
                trySend(status == PackageManager.PERMISSION_GRANTED)
            }
        }
        appOpsManager.startWatchingMode(
            opCode, context.packageName, listener
        )
        // 发送初始状态
        trySend(
            ContextCompat.checkSelfPermission(context, permission)
                == PackageManager.PERMISSION_GRANTED
        )

        awaitClose {
            appOpsManager.stopWatchingMode(listener)
        }
    }.distinctUntilChanged()
}

4. 性能优化与常见错误

状态去重：务必在 Flow 末端使用 .distinctUntilChanged()，避免连续发射相同的权限状态导致 UI 产生冗余刷新或界面闪烁。
生命周期绑定：在 ViewModel 中使用 .stateIn() 将冷流转为 StateFlow，配合 repeatOnLifecycle 收集，确保 Activity 重建后仍保留最新的权限状态。
资源泄漏防护：在 callbackFlow 的 awaitClose 中务必注销监听器。如果忘记调用 awaitClose 或其中的清理逻辑不完整，会导致协程泄漏和回调重复注册。

高频踩坑点：在 callbackFlow 内部使用 trySend 而非 send，避免因背压或挂起导致协程意外取消。同时确保在 awaitClose 之前发射初始状态，否则 UI 层可能因缺少初始值而一直停留在旧状态。

5. 调试与验证方案

开发阶段可以通过 ADB 模拟用户撤销权限的操作，验证监听机制是否按预期触发状态变化：

# 授予权限
adb shell pm grant com.example.app android.permission.ACCESS_FINE_LOCATION

# 撤销权限（模拟用户在设置中关闭）
adb shell pm revoke com.example.app android.permission.ACCESS_FINE_LOCATION

# 模拟权限置空（对后台进程强制重置，适用于测试 Empty 场景）
adb shell appops set com.example.app android:access_fine_location default

在生产部署前，还需额外测试权限置空场景下 Flow 是否仍然正常发射 false，确保相机预览关闭、录音自动保存等降级逻辑能够得到充分验证。