本文介绍如何利用 kotlin 华程的 `suspendcancellablecoroutine` 将基于回调的异步 api（如 `areallthesettingsgranted`）安全、简洁地封装为可直接 `await` 的挂起函数，从而避免阻塞线程，实现“逻辑上同步、实际非阻塞”的代码流。
在 Android 或 Kotlin 开发中，许多系统 API（例如 Google Play Services 的 SettingsClient）仍采用回调风格设计，如你提供的 areAllTheSettingsGranted { isGranted -> ... } 和内部调用的 checkLocationSettings(...).addOnSuccessListener {...}。这类 API 本质上是异步的，无法通过 Thread.sleep() 或 CountDownLatch 等方式“强制同步”——那会阻塞主线程、引发 ANR，且违背协程的设计哲学。
✅ 正确解法：使用协程将回调桥接为挂起函数。核心工具是 suspendCancellableCoroutine，它允许你在挂起函数中手动控制协程的恢复时机，并天然支持取消传播与异常处理。
以下是一个完整、生产就绪的封装示例：
import kotlinx.coroutines.suspendCancellableCoroutine
import kotlin.coroutines.resume
import kotlin.coroutines.resumeWithException
// 封装 areAllTheSettingsGranted 为挂起函数
suspend fun Settings.areAllTheSettingsGrantedSuspend(): Boolean {
return suspendCancellableCoroutine { cont ->
this.areAllTheSettingsGranted { isGranted ->
cont.resume(isGranted)
}
// 可选：监听协程取消，主动清理资源（如取消 pending 请求）
cont.invokeOnCancellation {
// 若 SDK 支持取消回调注册，此处可添加清理逻辑
}
}
}
// 同理封装 checkIfLocationServicesAreEnabled
suspend fun Settings.checkIfLocationServicesAreEnabledSuspend(): Boolean {
return suspendCancellableCoroutine { cont ->
checkIfLocationServicesAreEnabled { result ->
cont.resume(result)
}
}
}使用时，只需在协程作用域中调用即可“顺序执行”：
lifecycleScope.launch {
try {
val allGranted = settings.areAllTheSettingsGrantedSuspend()
if (allGranted) {
// ✅ 此处 result 已确定，可安全继续后续逻辑
handlePermissionsGranted()
} else {
requestPermissions()
}
} catch (e: CancellationException) {
// 协程被取消（如 Activity 销毁），无需处理
throw e
} catch (e: Exception) {
// 处理其他未预期异常（如回调未触发）
Log.e("Permission", "Failed to check settings", e)
}
}⚠️ 重要注意事项：
- 切勿在主线程中使用 runBlocking 强制同步：这会冻结 UI，严重违反 Android 最佳实践；
- 确保调用方处于协程作用域内（如 lifecycleScope、viewModelScope 或自定义 CoroutineScope）；
- suspendCancellableCoroutine 自动集成协程取消机制，若外部协程被取消，cont.invokeOnCancellation 会被触发，应在此处释放相关资源（如注销监听器、关闭流等）；
- 若原始回调可能多次调用（如某些流式 API），需额外加锁或状态检查，防止重复 resume 导致 IllegalStateException；本例中 areAllTheSettingsGranted 是单次回调，故无需防护。
总结：Kotlin 协程不是“让异步变同步”，而是“让异步代码写起来像同步”。通过 suspendCancellableCoroutine，你既保留了非阻塞、响应式的底层能力，又获得了清晰、可读、可组合的线性控制流——这才是现代 Kotlin 异步编程的正确姿势。
