Callback 기반의 비동기작업에 사용되는 CompletableDeferred, suspendCancellableCoroutine

 

안드로이드 오픈채팅방에서 보게 되어 찾아본 주제다.

CompletableDeferred

콜백 기반의 비동기 작업을 수행할 때 유용하게 사용할 수 있는 클래스다.

Deferred 클래스 기반이라 반환 값을 활용할 수 있는데, 인터페이스를 먼저보자.

public interface CompletableDeferred<T> : Deferred<T> {
    public fun complete(value: T): Boolean
    public fun completeExceptionally(exception: Throwable): Boolean
}

이 때 사용되는 complete는 자식 코루틴 까지 전파되기 때문에 여러개의 코루틴으로 중첩되어있으면 모든 작업이 끝나야 complete가 true를 반환한다. 작업이 끝나지 않은 경우는 작업이 끝날 때 까지 기다린다. complete안의 value값으로 완료를 결정한다. completeExceptionally는 이름에서 알 수 있듯이 예외가 트리거다.

suspend fun fetchDataFromServer(): Data {
    val deferred = CompletableDeferred<Data>()
    
    someAsyncOperation { data ->
    // ... 작업들
        deferred.complete(data)
    }
    
    return deferred.await()
}

CompletableDeferred클래스로 객체를 하나 만들고, 비동기 작업 블록안에 이 변수를 넣어주면 제어할 수 있게된다. 해당 블록의 작업이 모두 끝나면 complete가 불리고, 그 안에 담긴 값을 deffered.await()로 꺼내 쓸 수 있다.

 

이전에 그냥 사용하던 suspendable coroutine(async(얘도 반환값이 Deferred라서 await가 가능하다), delay같은) 것 과 차이점이 바로 보인다면 코루틴 마스터라고 할 수 있겠다. 일반적으로 사용하던 async 같은건 바깥에 있던 변수로 내부 코루틴을 제어하는 것이 불가능했다. 그런데 이 코드를 보면, 비동기 작업을 할 코루틴 스코프 바깥에 객체를 선언해서 값을 감시하며 결과값도 가져온다는 차이점을 볼 수 있다.

 

그럼 의문점이 하나 생긴다. async빌더를 쓰면 더 간단한데 왜 굳이 CompletableDeferred를 써야하나? async 계속 써도 된다. 사용법 간단하고 await로 값 받아올 수 있다. 그런데 CompletableDeferred를 사용하면 수동으로 결과를 설정해서 가져오기 때문에 좀 더 정교하게 값을 다룰 수 있고, 작업이 취소될 때 수행할 내용을 더욱 자세하게 지정할 수 있게된다.

 

좀 더 예시를 들어보겠다. 여러개의 api 결과값을 조합해서 사용해야된다고 가정해보자.

suspend fun fetchDataFromServer(): String {
    val deferred1 = CompletableDeferred<String>()
    val deferred2 = CompletableDeferred<String>()

    viewModelScope.launch {
        val result1 = fetchData1()
        deferred1.complete(result1)
    }

    viewModelScope.launch {
        val result2 = fetchData2()
        deferred2.complete(result2)
    }

    // 두 작업이 모두 완료될 때까지 기다림
    val data1 = deferred1.await()
    val data2 = deferred2.await()

    return "$data1 and $data2"
}

 

data1을 받아올 때는 deferred1이 끝나야 값을 가져오고, data2역시 deferred2가 끝나야 값을 가져온다. 완료가 되는 시점에 어떤 값을 가져올지 명시하는 게 가능하기 때문에 가독성이 좋아지고, 객체이름을 작업이름으로 바꿔준다면 더 읽기 좋게 바꿀 수 있게된다.

val deferred1 = viewModelScope.async { fetchData1() }
val deferred2 = viewModelScope.async { fetchData2() }

deferred부분만 async로 바꾼 코드다. fetchData가 수행되고나서 어떤 값이 반환될 지 알 수 없다. 단순히 이렇게만 놓고 봐도 장점이 보이는데, api를 더욱 많이 사용하게 되면 이 장점이 더 부각될 것이라고 생각한다.

suspendCancellableCoroutine

앞서 얘기한 ComletableDeferred와 거의 동일한 개념이다. 차이점으로는 suspendCancellableCoroutine이 코루틴 빌더라는 것이다.

suspend fun <T> suspendCancellableCoroutine(
    block: (CancellableContinuation<T>) -> Unit
): T

코루틴 본문을 CancellableContinuation으로 받기 때문에 이 스코프 안에서 작업을 수행할 때 취소에 대한 행동을 정의할 수 있다. 작업이 완료되었다면 resume, 작업중 예외가 발생했다면 resumeWithException으로 제어가능하다. 값을 반환하기 때문에 이것 역시 콜백기반의 비동기작업에 적합하다.

suspend fun fetchData(): String {
    return suspendCancellableCoroutine { continuation ->
        val job = CoroutineScope(Dispatchers.IO).launch {
        	try {
            	continuation.resume("User data")
            } catch (e: Exception) {
                continuation.resumeWithException(e)
            }
        }

        continuation.invokeOnCancellation {
            job.cancel()
        }
    }
}

job으로 지정한 작업이 완료되면, continuation의 resume에 값을 전달해서 fetchData의 반환값으로 사용하고, 작업중에 예외가 발생했다면 resumeWithException을 사용해 작업중이던 코루틴 외부로 전파시킬 수 있다. 그리고  invokeOnCancellaion 블록에는 취소가 발생할 때 수행할 작업을 정의할 수 있다. 

resumeWithException은 예외를 전파시키기 때문에 예시코드 기준으로 fetchData를 호출하는 쪽에서 예외처리를 해줘야하고, invokeOnCancellation은 외부에서 suspendCancellableCoroutine에 대한 취소가 발생했을 때 이전 입력된 값을 날린다던가 하는 초기화 로직을 넣어두면 될 것 같다. 

 

이때 Cancellable의 의미가 중요하다. 이름에 들어있는 Cancellable은 이 코루틴 스코프를 외부에서 취소시킬 수 있는 지에 대한 여부를 의미한다. 즉 외부에서 예외를 받고 -> 취소를 호출하면 invokeOnCancellation 내부에 작성해둔 코드가 실행된다.

 

try-catch 대신 runCatching을 사용해 좀 더 코틀린스럽게 바꿔보면 

suspend fun fetchData(): String {
    return suspendCancellableCoroutine { continuation ->
        val job = CoroutineScope(Dispatchers.IO).launch {
            val result = runCatching {
                "User data"
            }

            result.onSuccess { data ->
                continuation.resume(data)
            }

            result.onFailure { e -> // Throwable이 들어온다.
                continuation.resumeWithException(e)
            }
        }

        continuation.invokeOnCancellation {
            job.cancel()
        }
    }
}

이렇게 가독성 좋게 바꿀 수 있다.

onSuccess를 쓰지않고 그냥 리시버로 api를 호출하는 방법도 있는데, 그렇게 하면 성공했을 때 데이터를 this로만 접근할 수 있다. 나는 받아올 객체 데이터에다가 이름을 지정하는 게 가독성이 좋다고 생각해서 onSuccess를 사용하는 걸 선호한다. 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!