Patrones de corutina y antipatrones en Kotlin

Decidí escribir sobre algunas cosas que, en mi opinión, son y no deben evitarse al usar la rutina de Kotlin.

Envuelva llamadas asincrónicas en coroutineScope o use SupervisorJob para manejar excepciones

Si puede ocurrir una excepción en el bloque async , no confíe en el try/catch .

 val job: Job = Job() val scope = CoroutineScope(Dispatchers.Default + job) // may throw Exception fun doWork(): Deferred<String> = scope.async { ... } // (1) fun loadData() = scope.launch { try { doWork().await() // (2) } catch (e: Exception) { ... } } 

En el ejemplo anterior, la función doWork inicia una nueva corutina (1), que puede generar una excepción no controlada. Si intenta envolver doWork con un try/catch (2), la aplicación seguirá fallando.

Esto se debe a que la falla de cualquier componente secundario del trabajo lleva a la falla inmediata de su padre.

Una forma de evitar el error es usar SupervisorJob (1).

La falla o cancelación de la ejecución del componente hijo no conducirá a la falla del padre y no afectará a otros componentes.

 val job = SupervisorJob() // (1) val scope = CoroutineScope(Dispatchers.Default + job) // may throw Exception fun doWork(): Deferred<String> = scope.async { ... } fun loadData() = scope.launch { try { doWork().await() } catch (e: Exception) { ... } } 

Nota : esto solo funcionará si inicia explícitamente su llamada de rutina asincrónica con SupervisorJob . Por lo tanto, el código a continuación seguirá bloqueando su aplicación, porque la sincronización async ejecuta como parte de la rutina principal (1).

 val job = SupervisorJob() val scope = CoroutineScope(Dispatchers.Default + job) fun loadData() = scope.launch { try { async { // (1) // may throw Exception }.await() } catch (e: Exception) { ... } } 

Otra forma de evitar un bloqueo, que es más preferible, es envolver async en coroutineScope (1). Ahora, cuando ocurre una excepción dentro de async , cancela todas las demás corutinas creadas en esta área, sin tocar el área externa. (2)

 val job = SupervisorJob() val scope = CoroutineScope(Dispatchers.Default + job) // may throw Exception fun doWork(): Deferred<String> = coroutineScope { // (1) async { ... } } fun loadData() = scope.launch { // (2) try { doWork().await() } catch (e: Exception) { ... } } 

Además, puede manejar excepciones dentro del bloque async .

Use el administrador principal para las corutinas raíz

Si necesita hacer un trabajo de fondo y actualizar la interfaz de usuario dentro de su rutina de raíz, comience usando el despachador principal.

 val scope = CoroutineScope(Dispatchers.Default) // (1) fun login() = scope.launch { withContext(Dispatcher.Main) { view.showLoading() } // (2) networkClient.login(...) withContext(Dispatcher.Main) { view.hideLoading() } // (2) } 

En el ejemplo anterior, comenzamos la rutina de la raíz utilizando el despachador CoroutineScope en CoroutineScope (1). Con este enfoque, cada vez que necesitemos actualizar la interfaz de usuario, tendremos que cambiar el contexto (2).

En la mayoría de los casos, es preferible crear CoroutineScope inmediatamente con el despachador principal, lo que conducirá a la simplificación del código y al cambio de contexto menos explícito.

 val scope = CoroutineScope(Dispatchers.Main) fun login() = scope.launch { view.showLoading() withContext(Dispatcher.IO) { networkClient.login(...) } view.hideLoading() } 

Evite usar asíncrono / espera innecesario

Si utiliza la función async e inmediatamente la llamada en await , debe dejar de hacerlo.

 launch { val data = async(Dispatchers.Default) { /* code */ }.await() } 

Si desea cambiar el contexto de la rutina y suspender inmediatamente la rutina principal, entonces withContext es la forma más preferible de withContext .

 launch { val data = withContext(Dispatchers.Default) { /* code */ } } 

En términos de rendimiento, este no es un problema tan grande (incluso teniendo en cuenta que async crea una nueva rutina para el trabajo), pero semánticamente async implica que desea ejecutar varias rutinas en segundo plano y solo esperarlas.

Evitar la cancelación del trabajo

Si necesita cancelar la rutina, no cancele el trabajo.

 class WorkManager { val job = SupervisorJob() val scope = CoroutineScope(Dispatchers.Default + job) fun doWork1() { scope.launch { /* do work */ } } fun doWork2() { scope.launch { /* do work */ } } fun cancelAllWork() { job.cancel() } } fun main() { val workManager = WorkManager() workManager.doWork1() workManager.doWork2() workManager.cancelAllWork() workManager.doWork1() // (1) } 

El problema con el código anterior es que cuando cancelamos el trabajo, lo ponemos en un estado completado . Las rutinas lanzadas como parte de un trabajo completado no se ejecutarán (1).

Si desea deshacer todas las corutinas en un área específica, puede usar la función cancelChildren . Además, es una buena práctica proporcionar la capacidad de cancelar trabajos individuales (2).

 class WorkManager { val job = SupervisorJob() val scope = CoroutineScope(Dispatchers.Default + job) fun doWork1(): Job = scope.launch { /* do work */ } // (2) fun doWork2(): Job = scope.launch { /* do work */ } // (2) fun cancelAllWork() { scope.coroutineContext.cancelChildren() // (1) } } fun main() { val workManager = WorkManager() workManager.doWork1() workManager.doWork2() workManager.cancelAllWork() workManager.doWork1() } 

Evite escribir la función de pausa usando el despachador implícito

No escriba la función de suspend , cuya ejecución dependerá del administrador de rutina particular.

 suspend fun login(): Result { view.showLoading() val result = withContext(Dispatcher.IO) { someBlockingCall() } view.hideLoading() return result } 

En el ejemplo anterior, la función de inicio de sesión es una función de suspensión y fallará si la inicia desde una rutina que el despachador principal no utilizará.

 launch(Dispatcher.Main) { // (1)    val loginResult = login() ... } launch(Dispatcher.Default) { // (2)   val loginResult = login() ... } 

CalledFromWrongThreadException: solo el hilo fuente que creó la jerarquía de los componentes de Vista puede acceder a ellos.

Cree su función de suspensión para que pueda ejecutarse desde cualquier administrador de rutina.

 suspend fun login(): Result = withContext(Dispatcher.Main) { view.showLoading() val result = withContext(Dispatcher.IO) { someBlockingCall() } view.hideLoading() return result } 

Ahora podemos llamar a nuestra función de inicio de sesión desde cualquier despachador.

 launch(Dispatcher.Main) { // (1) no crash val loginResult = login() ... } launch(Dispatcher.Default) { // (2) no crash ether val loginResult = login() ... } 

Evitar el uso de alcance global

Si usa GlobalScope en todas partes en su aplicación de Android, debe dejar de hacerlo.

 GlobalScope.launch { // code } 

El alcance global se utiliza para lanzar corutinas de nivel superior que se ejecutan durante toda la vida de la aplicación y no se cancelan con anticipación.

El código de la aplicación generalmente debe usar el CoroutineScope específico de la aplicación, por lo que se desaconseja el uso asíncrono o el lanzamiento en GlobalScope .

En Android, la rutina puede limitarse fácilmente al ciclo de vida de una actividad, fragmento, vista o modelo de vista.

 class MainActivity : AppCompatActivity(), CoroutineScope { private val job = SupervisorJob() override val coroutineContext: CoroutineContext get() = Dispatchers.Main + job override fun onDestroy() { super.onDestroy() coroutineContext.cancelChildren() } fun loadData() = launch { // code } }