Android Kotlin协程：回调转挂起函数方案及自定义函数咨询

Nice work on building your own resolvable function to bridge callbacks and coroutines! It's a clever approach, but Kotlin's coroutine library actually has built-in tools that can make this cleaner and more robust. Let's break this down:

The Kotlin coroutine library provides a dedicated tool for converting callback-based APIs to suspend functions: suspendCancellableCoroutine. It’s far more efficient than rolling your own solution with semaphores, and it natively handles coroutine cancellation scenarios (like when an Activity is destroyed).

Here’s how you’d rewrite your prompt example using it:

class MainActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Use lifecycleScope to tie coroutines to the Activity's lifecycle (Android-specific)
        lifecycleScope.launch {
            val value = promptUserInput()
            println("Value: $value")
        }
    }

    private suspend fun promptUserInput(): String? = suspendCancellableCoroutine { continuation ->
        val inputField = EditText(this)
        val dialog = AlertDialog.Builder(this)
            .setTitle("Please insert a value")
            .setView(inputField)
            .setPositiveButton("Ok") { _, _ ->
                continuation.resume(inputField.text.toString())
            }
            .setNegativeButton("Cancel") { _, _ ->
                continuation.resume(null) // Return null when user cancels
            }
            .create()

        // Clean up if the coroutine is cancelled (e.g., Activity is destroyed)
        continuation.invokeOnCancellation {
            dialog.dismiss()
        }

        dialog.show()
    }
}

If you want to refine your custom implementation, here are key areas to improve:

• Replace semaphores with coroutine-native suspension: Manual Semaphore usage introduces unnecessary thread blocking. Coroutines are designed to suspend without blocking threads, so using suspendCoroutine or suspendCancellableCoroutine eliminates this overhead.
• Simplify error handling: Instead of tracking exceptions with a nullable variable, use continuation.resumeWithException() to propagate errors directly—this aligns with standard coroutine error handling patterns.
• Remove redundant launch: Your block parameter is already a suspend function, so you don’t need to wrap it in an extra launch call. This reduces unnecessary coroutine creation overhead.
• Ensure thread safety: Your result and exception variables aren’t thread-safe. While the semaphore provides some synchronization, using continuation.resume() is inherently thread-safe and more reliable.

There are a few critical edge cases your resolvable function doesn’t handle well:

• Unmanaged coroutine cancellation: If the parent coroutine (the one calling resolvable) is cancelled (e.g., the Activity is closed), your code cancels the internal job but doesn’t clean up the UI (like dismissing the dialog). This can lead to memory leaks.
• Semaphore deadlocks: If the callback in block never calls success or error (e.g., the user never taps a dialog button), semaphore.acquire() will block indefinitely, leaving the coroutine hanging.
• Unnecessary performance overhead: Creating a Semaphore and extra coroutine adds avoidable runtime costs compared to using the library’s built-in suspension mechanisms.

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