日本免费高清视频-国产福利视频导航-黄色在线播放国产-天天操天天操天天操天天操|www.shdianci.com

學無先后，達者為師

網站首頁 編程語言 正文

Suspend函數與回調的互相轉換示例詳解_Android

作者：Pika ? 更新時間： 2023-03-05 編程語言

前言

我們再來一期關于kotlin協程的故事，我們都知道在Coroutine沒有出來之前，我們對于異步結果的處理都是采用回調的方式進行，一方面回調層次過多的話，容易導致“回調地獄”，另一方法也比較難以維護。當然，我們并不是否定了回調本身，回調本身同時也是具備很多優點的，比如符合代碼閱讀邏輯，同時回調本身也是比較可控的。這一期呢，我們就是來聊一下，如何把回調的寫法變成suspend函數，同時如何把suspend函數變成回調，從而讓我們更加了解kotlin協程背后的故事

回調變成suspend函數

來一個回調

我們以一個回調函數作為例子，當我們normalCallBack在一個子線程中做一些處理，比如耗時函數，做完就會通過MyCallBack回調onCallBack，這里返回了一個Int類型，如下：

var myCallBack:MyCallBack?= null
interface MyCallBack{
    fun onCallBack(result: Int)
}
fun normalCallBack(){
    thread { 
        // 比如做一些事情
        myCallBack?.onCallBack(1)
    }
}

轉化為suspend函數

此時我們可以通過suspendCoroutine函數，內部其實是通過創建了一個SafeContinuation并放到了我們suspend函數本身（block本身）啟動了一個協程，我們之前在聊一聊Kotlin協程"低級"api 這篇文章介紹過

public suspend inline fun <T> suspendCoroutine(crossinline block: (Continuation<T>) -> Unit): T {
    contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) }
    return suspendCoroutineUninterceptedOrReturn { c: Continuation<T> ->
        val safe = SafeContinuation(c.intercepted())
        block(safe)
        safe.getOrThrow()
    }
}

這時候我們就可以直接寫為，從而將回調消除，變成了一個suspend函數。

suspend fun mySuspend() = suspendCoroutine<Int> {
    thread {
        // 比如做一些事情
        it.resume(1)
    }
}

當然，如果我們想要支持一下外部取消，比如當前頁面銷毀時，發起的網絡請求自然也就不需要再請求了，就可以通過suspendCancellableCoroutine創建，里面的Continuation對象就從SafeContinuation（見上文）變成了CancellableContinuation，變成了CancellableContinuation有一個invokeOnCancellation方便，支持在協程體被銷毀時的邏輯。

public suspend inline fun <T> suspendCancellableCoroutine(
    crossinline block: (CancellableContinuation<T>) -> Unit
): T =
    suspendCoroutineUninterceptedOrReturn { uCont ->
        val cancellable = CancellableContinuationImpl(uCont.intercepted(), resumeMode = MODE_CANCELLABLE)
        /*
         * For non-atomic cancellation we setup parent-child relationship immediately
         * in case when `block` blocks the current thread (e.g. Rx2 with trampoline scheduler), but
         * properly supports cancellation.
         */
        cancellable.initCancellability()
        block(cancellable)
        cancellable.getResult()
    }

此時我們就可以寫出以下代碼

suspend fun mySuspend2() = suspendCancellableCoroutine<Int> {
    thread {
        // 比如做一些事情
        it.resume(1)
    }
    it.invokeOnCancellation { 
        // 取消邏輯
    }
}

suspend函數變成回調

見到了回調如何變成suspend函數，那么我們反過來呢？有沒有辦法？當然有啦！當時suspend函數中有很多種區分，我們一一區分一下

//直接返回的suspend函數
suspend fun myNoSuspendFunc():Int{
    return 1
}

//調用suspendCoroutine后直接resume的suspend函數
suspend fun myNoSuspendFunc() = suspendCoroutine<Int> {
        continuation ->
    continuation.resume(1)
}

//調用suspendCoroutine后異步執行的suspend函數（這里異步可以是單線程也可以是多線程，跟線程本身無關，只要是異步就會觸發掛起）
suspend fun myRealSuspendFunc() = suspendCoroutine<Int> {
    thread {
        Thread.sleep(300)
        it.resume(2)
    }

那么我們來想一下，這里真正發起掛起的函數是哪個？通過代碼其實我們可以猜到，真正掛起的函數只有最后一個myRealSuspendFunc，其他都不是真正的掛起，這里的掛起是什么意思呢？我們從協程的狀態就可以知道，當前處于CoroutineSingletons.COROUTINE_SUSPENDED時，就是掛起狀態。我們回歸一下，一個suspend函數有哪幾種情況

這里的1，2，3就分別對應著上文demo中的例子

  • 直接返回結果，不需要進入狀態機判斷，因為本身就沒有啟動協程
  • 進入了協程，但是不需要進行SUSPEND狀態就已經有了結果，所以直接返回了結果
  • 進入了SUSPEND狀態，之后才能獲取結果

這里我們就不貼出來源碼了，感興趣可自己看Coroutine的實現，這里我們要明確一個概念，一個Suspend函數的運行機制，其實并不依靠了協程本身。

對應代碼表現就是，這個函數的返回結果可能就是直接返回結果本身，另一種就是通過回調本身通知外部（這里我們還會以例子說明）

suspend函數轉換為回調

這里有兩種情況，我們分別以kotlin代碼跟java代碼表示：

kotlin代碼

由于kotlin可以直接通過suspend的擴展函數startCoroutine啟動一個協程，

fun myRealSuspendCallBack(){
    ::myRealSuspendFunc.startCoroutine(object :Continuation<Int>{
       當前環境
        override val context: CoroutineContext
            get() = Dispatchers.IO
        結果
        override fun resumeWith(result: Result<Int>) {
            if(result.isSuccess){
                myCallBack?.onCallBack(result.getOrDefault(0))
            }
        }
    })
}

其中Result就是一個內聯類，屬于kotlin編譯器添加的裝飾類，在這里我們無論是1，2，3的情況，都可以在resumeWith 中獲取到結果，在這里通過callback回調即可

@JvmInline
public value class Result<out T> @PublishedApi internal constructor(
    @PublishedApi
    internal val value: Any?
) : Serializable {

Java代碼

這里我們更正一個誤區，就是suspend函數只能在kotlin中使用/Coroutine協程只能在kotlin中使用，這個其實是錯誤的，java代碼也能夠調起協程，只不過麻煩了一點，至少官方是沒有禁止的。 比如我們需要調用startCoroutine，可直接調用

ContinuationKt.startCoroutine();

當然，我們也能夠直接調用suspend函數

Object result = CallBack.INSTANCE.myRealSuspendFunc(new Continuation<Integer>() {
    @NonNull
    @Override
    public CoroutineContext getContext() {
        //這里啟動的環境其實協程沒有用到，讀者們可以思考一下為什么！這里就當一個謎題啦！可以在評論區說出你的想法（我會在評論區解答）
        return (CoroutineContext) Dispatchers.getIO();
        //return EmptyCoroutineContext.INSTANCE;
    }
    @Override
    public void resumeWith(@NonNull Object o) {
        情況3
        Log.e("hello","resumeWith result is "+ o +" is main "+ (Looper.myLooper() == Looper.getMainLooper()));
          // 回調處理即可
          myCallBack?.onCallBack(result)
    }
});
if(result != IntrinsicsKt.getCOROUTINE_SUSPENDED()){
    情況1，2
    Log.e("hello","func result is "+ result);
      // 回調處理即可
      myCallBack?.onCallBack(result)
}

這里我們需要注意的是，這里java代碼比kotlin多了一個判斷，同時resumeWith的參數不再是Result，而是一個Object

if(result != IntrinsicsKt.getCOROUTINE_SUSPENDED()){
}

這里脫去了kotlin給我們添加的各種外殼，其實這就是真正的對于suspend結果的處理（只不過kotlin幫我們包了一層）

我們上文說過，suspend函數對應的三種情況，這里的1，2都是直接返回結果的，因為沒有走到SUSPEND狀態（IntrinsicsKt.getCOROUTINE_SUSPENDED()）這里需要讀者好好閱讀上文，因此 result != IntrinsicsKt.getCOROUTINE_SUSPENDED()，就會直接走到這里，我們就直接拿到了結果

if(result != IntrinsicsKt.getCOROUTINE_SUSPENDED()){
}

如果屬于情況3，那么這里的result就不再是一個結果，而是當前協程的狀態標記罷了，此時當協程完成執行的時候（調用resume的時候），就會回調到resumeWith，這里的Object類型o才是經過SUSPEND狀態的結果！

總結

經過我們suspend跟回調的互相狀態，能夠明白了suspend背后的邏輯與掛起的細節，希望能幫到你

原文鏈接：https://juejin.cn/post/7175752374458253373

欄目分類
最近更新