在Android BindingAdapter中使用runBlocking{}的影响及假设合理性问询

• runBlocking的核心危害是阻塞调用它的线程，直到其作用域内所有协程执行完毕。在Android的BindingAdapter场景中，调用runBlocking的线程是主线程，这意味着主线程会被卡住，直到launch里的所有代码执行完成，直接引发UI卡顿、ANR等严重问题。
• 你认为launch能抵消runBlocking的负面影响，这是对协程作用域的误解：
  • launch确实会在IO线程启动新协程，但它属于当前runBlocking作用域的子协程，runBlocking会一直等待所有子协程执行完毕才会释放主线程。主线程的阻塞时长完全等于launch内代码的执行时间，根本没有抵消任何负面影响。
  • 即便你改用全局作用域启动launch（比如GlobalScope.launch），runBlocking虽然会快速结束，但依然会短暂阻塞主线程，而且全局协程不受组件生命周期管控，极易引发内存泄漏。

在BindingAdapter这类主线程调用的Android场景中，绝对不能使用runBlocking。推荐两种正确写法：

1. 借助LifecycleScope绑定生命周期（如果能获取到View的LifecycleOwner）：

@BindingAdapter("loadData")
fun View.loadData(data: String) {
    lifecycleScope.launch(Dispatchers.IO) {
        // 执行耗时挂起操作
        withContext(Dispatchers.Main) {
            // 切换回主线程更新UI
        }
    }
}

2. 手动创建协程并在View销毁时取消（无法获取LifecycleOwner时）：

@BindingAdapter("loadData")
fun View.loadData(data: String) {
    val coroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob())
    coroutineScope.launch {
        // 执行耗时挂起操作
        withContext(Dispatchers.Main) {
            // 切换回主线程更新UI
        }
    }
    // 在View脱离窗口时取消协程，避免内存泄漏
    addOnAttachStateChangeListener(object : View.OnAttachStateChangeListener {
        override fun onViewAttachedToWindow(v: View) {}
        override fun onViewDetachedFromWindow(v: View) {
            coroutineScope.cancel()
        }
    })
}

内容的提问来源于stack exchange，提问作者Eddie