De hecho, están estrechamente relacionados. Se podría decir que CoroutineScope formaliza la forma en que se hereda CoroutineContext .

CoroutineScope no tiene datos por sí solo, solo contiene un CoroutineContext . Su función clave es como receptor implícito del bloque que pasa para launch , async , etc.

Mira este ejemplo:

 runBlocking { val scope0 = this // scope0 is the top-level coroutine scope. scope0.launch { val scope1 = this // scope1 inherits its context from scope0. It replaces the Job field // with its own job, which is a child of the job in scope0. // It retains the Dispatcher field so the launched coroutine uses // the dispatcher created by runBlocking. scope1.launch { val scope2 = this // scope2 inherits from scope1 } } }

Puede ver cómo CoroutineScope media la herencia de los contextos de corrutina. Si cancela el trabajo en el scope1 , esto se propagará al scope2 y también cancelará el launch iniciado.

Tenga en cuenta la característica sintáctica clave: escribí explícitamente scope0.launch , pero si hubiera escrito solo launch , implícitamente significaría exactamente lo mismo. Así es como CoroutineScope ayuda a propagar "automáticamente" el alcance.

Sí, en principio tienes razón, aquí más detalles.

Alcance

• una rutina debe ejecutarse en un ámbito
• es una forma de realizar un seguimiento de todas las rutinas que se ejecutan en él
• todas las corrutinas ( cooperativas ) se pueden cancelar a través de su alcance
• los ámbitos obtienen excepciones no detectadas
• son una forma de vincular rutinas a un ciclo de vida específico de la aplicación (por ejemplo viewModelScope en Android) para evitar fugas

Contexto

El contexto determina en qué subproceso se ejecutarán las rutinas. Hay cuatro opciones:

• Dispatchers.Default - para trabajo intensivo de CPU (por ejemplo, ordenar una lista grande)
• Dispatchers.Main : lo que será depende de lo que haya agregado a las dependencias de tiempo de ejecución de sus programas (por ejemplo kotlinx-coroutines-android , para el subproceso de interfaz de usuario en Android)
• Dispatchers.Unconfined : ejecuta rutinas no limitadas en ningún hilo específico
• Dispatchers.IO : para trabajos pesados de E/S (p. ej., consultas de base de datos de ejecución prolongada)

El siguiente ejemplo reúne tanto el alcance como el contexto. Crea un nuevo ámbito en el que las corrutinas se ejecutarán (si no se modifican) en un subproceso designado para el trabajo de IO y las cancela a través de su ámbito.

 val scope = CoroutineScope(context = Dispatchers.IO) val job = scope.launch { val result = suspendFunc1() suspendFunc2(result) } // ... scope.cancel() // suspendFunc1() and suspendFunc2() will be cancelled

CoroutineScope tiene un CoroutineContext .

Por ejemplo si tienes:

 runBlocking { // defines coroutineScope launch(Dispatchers.Default) { //inherits coroutineScope but changes context } }

runBlocking define un CoroutineScope (obtén más información aquí ) que hereda el launch . El contexto se anula al especificar explícitamente un despachador aquí. Si observa la definición de launch , puede ver que toma un CoroutineContext opcional:

 public fun CoroutineScope.launch( context: CoroutineContext = EmptyCoroutineContext, ... )

Otra parte del contexto sería el nombre de la rutina:

 launch(CoroutineName("launchMe") + Dispatchers.Default) { println("") }