kotlinコラボレーションベースの共有

参考記事:kotlin公式中国語ドキュメントKotlin Primer・第七章・協程庫(前編)
協程は何ですか.

コモン

ユーザー・ステータス・スレッドは、プロセスに制御権を渡し、プロセスを自分でスケジューリングするので、本質的には、コラボレーションはスレッドです.

ユーザ状態スレッド

プロセスでスレッドの論理スケジューリングを手書きコードで管理します.これがユーザー状態スレッドです.
なぜ協程を使うのか
Androidの典型的な例は、ネットワークリクエストです.

メインスレッドは、ネットワーク要求タスクを開始する.

サブスレッド要求サービス側対応;

は、ネットワーク転送要求を待つ.

サーバがデータを処理して返すのを待つ.

サブスレッドは、サーバがデータを返し、フォーマットを変換することを取得する.

プライマリ・スレッドはコールバックを実行します.

2−4のプロセスでは,スレッドはブロック状態にあり,そのスレッドにネットワーク処理に関係のない論理がいくつかあると仮定すると,このときのスレッド利用率はそれほど高くなく,このときにコヒーレンスの概念を導入することができ,このスレッドのコヒーレンスが停止すると,スレッドは依然として仕事を続けることができるため,コヒーレンスを導入し,スレッドを極めて多重化することができる.
協程の使い方

kotlinのコンシステントはコアライブラリに含まれていないため、コンシステントを使用するには、

に導入する必要があります.

implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.0.1'
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.0.1'

最初のコヒーレントプログラムから

を直接話します.

 GlobalScope.launch { //               
        delay(1000L) //        1   （         ）
        println("World!") //         
    }
    println("Hello,") //               
    Thread.sleep(2000L) //       2       JVM   ，          

GlobalScopeはCoroutineScopeコンテキストのサブクラスであり、launchは私たちが今接触している最初のコプロセッサ、GlobalScopeです.Launch{}は、アプリケーション全体のライフサイクルによってのみ制限される新しいコラボレーションを開始したことを示します.

最初のプログラムで小さな変更をしました

GlobalScope.launch { //               
        delay(1000L)
        println("World!")
    }
    println("Hello,") //             
    runBlocking {     //              
        delay(2000L)  // ……     2      JVM    
    } 

スレッドのThreadをブロックします.sleep(2000 L)をrunBlockingのコモンコードに変更すると、2番目のコモンコンストラクタrunBlockingに接触し、メインスレッド呼び出しrunBlockingはrunBlocking内部のコモン実行が完了するまでブロックされます.

3は、プライマリ・スレッドで2つのコヒーレンスを開始することを示しています.では、最適化を行います.

runBlocking { //        
    GlobalScope.launch { //               
        delay(1000L)
        println("World!")
    }
    println("Hello,") //            
    delay(2000L)      //    2      JVM   
}

プライマリ・スレッドはprintlnを実行しないし、2つのコモンを起動するのではなく、最上位のプライマリ・コモン内で新しいコモンを起動し、印刷とdelay操作を実行します.

対2の拡張

役割ドメインビルダー

前述のrunBlockingに加えて、coroutineScopeを使用して役割ドメインを宣言することもできます.runBlockingとcoroutineScopeの主な違いは、後者がすべてのサブコラボレーションの実行を待っている間に現在のスレッドをブロックしていないことです.

runBlocking { // this: CoroutineScope
    launch { 
        delay(200L)
        println("Task from runBlocking")
    }
    
    coroutineScope { //            
        launch {
            delay(500L) 
            println("Task from nested launch")
        }
    
        delay(100L)
        println("Task from coroutine scope") //               
    }
    
    println("Coroutine scope is over") //                
}

launchの戻り値は、start、join、cancelの3つの方法で一般的に使用されているJobオブジェクトです.それぞれ、コヒーレンスの起動、現在のコヒーレンスへの切り替え、キャンセルに対応します.

val job = GlobalScope.launch { //                   
    delay(1000L)
    println("World!")
}
println("Hello,")
job.join() //            

この結果はまだハロー、World!もし私が

val job = GlobalScope.launch { //                   
    delay(1000L)
    println("World!")
}
job.join() //            
println("Hello,")

プリントアウトの結果がWorld!ハロー、これでjoinの使い方がもっと理解できます.
問題
runBlockingにcoroutineScopeがネストされている場合、coroutineScopeはすべてのサブコモンの実行が完了するのを待機し、現在のスレッドの実行をブロックすることはありません(換言すれば、runBlockingはcoroutineScopeコモンブロックのコードの実行が完了するのを待機します).