But SupervisorJob is easy to be misunderstood. It is related to coroutine exception handling and sub-coroutines.The >Job type and domain are confusing. For specific exception handling, please refer to this Google article: Cancellation and Exceptions in Coroutines | Exception Handling Details

Three, suspend keyword

This suspend keyword, since it does not really implement suspension, what is its function?

It is actually a reminder.

The creator of the function reminds the user of the function: I am a time-consuming function, and I am put in the background by my creator in a suspended manner, so please call me in the coroutine.

The suspended operation—that is, thread cutting, depends on the actual code in the suspended function, not on this keyword.

So this keyword, is just a reminder.

3.1, CoroutineDispatcher scheduler

• Dispatchers.Default

  The default scheduler is suitable for processing background calculations and is a CPU-intensive task scheduler. If no dispatcher is specified when creating a Coroutine, this is generally used as the default value by default. The Default dispatcher uses a shared pool of background threads to run its tasks. Note that it shares the thread pool with IO, but only limits the maximum number of concurrency.

• Dispatchers.IO

  As the name implies, this is used to perform blocking IO operations, and shares a shared thread with Default Pool to perform tasks inside. Depending on the number of tasks running at the same time, additional threads will be created when needed, and unneeded threads will be released when the tasks are completed.

• Dispatchers.Unconfined

  Since Dispatchers.Unconfined does not define a thread pool, it starts the thread by default during execution. The first suspension point is encountered, after which theThe thread calling resume determines the thread that resumes the coroutine.

• Dispatchers.Main

  The specified execution thread is the main thread, which is the UI thread on Android.

Because the child Coroutine will inherit the context of the parent Coroutine, for the convenience of use, we generally set a Dispatcher on the parent Coroutine, and then all child Coroutines will automatically use this Dispatcher.

3.2, CoroutineStart coroutine startup mode

• CoroutineStart.DEFAULT

  Start scheduling immediately after the coroutine is created, if the coroutine is canceled before scheduling, it will directly enter the cancellation response Although the state is scheduled immediately, it may also be canceled before execution

• CoroutineStart.ATOMIC

  Immediately after the coroutine is created Start scheduling, and the coroutine execution will not respond to cancellation before reaching the first suspension point
  Although it is immediate scheduling, it combines the two steps of scheduling and execution into one, just like its name, it guarantees scheduling And execution is an atomic operation, so the coroutine will also be executed

• CoroutineStart.LAZY

  As long as the coroutine is needed , including actively calling the start, join or await functions of the coroutine, the scheduling will start. If it is canceled before scheduling, the coroutine will directly enter the abnormal end state

• CoroutineStart.UNDISPATCHED

  Immediately after the coroutine is created, it is executed in the current function call stack until it encounters the first real suspension point
  is executed immediately, so The coroutine will definitely execute

The design of these startup modes is mainly to deal with some special scenarios. business developmentIn practice, it is usually enough to use the two startup modes DEFAULT and LAZY

3.3, CoroutineScope – coroutine scope

Defining a coroutine must specify its CoroutineScope . CoroutineScope can track the coroutine even if the coroutine is suspended. Unlike the dispatcher (Dispatcher), CoroutineScope doesn’t run coroutines, it just makes sure you don’t lose track of them. To ensure that all coroutines are tracked, Kotlin does not allow new coroutines to be started without using CoroutineScope. CoroutineScope can be thought of as a lightweight version of ExecutorService with superpowers. CoroutineScope keeps track of all coroutines, and it can also cancel all coroutines started by it. This is very useful in Android development, for example, it can stop the execution of the coroutine when the user leaves the interface.

Coroutine is a lightweight thread, which does not mean that it does not consume system resources. When the asynchronous operation is time-consuming, or when an error occurs in the asynchronous operation, the Coroutine needs to be canceled to release system resources. In the Android environment, usually the Coroutine started by each interface (Activity, Fragment, etc.) Makes sense, if the user exits the interface while waiting for the Coroutine to execute, it may not be necessary to continue executing the Coroutine. Additionally Coroutine also needs to be executed in a proper context, otherwise errors will occur, such as accessing View in a non-UI thread. Therefore, when designing Coroutine, it is required to be executed within a scope (Scope), so that when this Scope is cancelled, all the child Coroutine is also automatically canceled. So to use Coroutine you must first create a corresponding CoroutineScope.

CoroutineScope interface

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

CoroutineScope just defines a new Coroutine execution Scope. Each coroutine builder is an extension function of CoroutineScope and automatically inherits the coroutineContext of the current Scope.

3.4, classification and rules of conduct

The official framework also provides a scope in the process of implementing composite coroutines, which is mainly used to clarify the parent-child relationship between writing, as well as the propagation behavior for cancellation or exception handling. This scope includes the following three types:

• Top-level scope
  The scope of a coroutine without a parent coroutine is the top-level scope.

• Synergy Scope
  A new coroutine is started in a coroutine, and the new coroutine is a sub-coroutine of the existing coroutine. In this case, the scope of the sub-coroutine is the collaboration scope by default. At this time, the uncaught exception thrown by the child coroutine will be passed to the parent coroutine for processing, and the parent coroutine will also be canceled at the same time.

  coroutineScope The internal exceptions will be propagated upwards, and the uncaught exceptions of the sub-coroutines will be passed up to the parent coroutines. Any abnormal exit of a sub-coroutine will lead to the overall exit

  

• Master-slave role Domain
  is consistent with the synergy scope in the parent-child relationship of the coroutine, the difference is that when the coroutine under this scope has an uncaught exception, the exception will not be passed up to the parent coroutine .

  supervisorScope belongs to the master-slave scope and will inherit the context of the parent coroutine. Its characteristic is that the exception of the child coroutine will not affect the parent coroutine

  

In addition to the behaviors mentioned in the three scopes, there are the following rules between parent and child coroutines:

• If the parent coroutine is canceled, all child coroutines will be cancelled. Since there is a parent-child coroutine relationship in both the coroutine scope and the master-detail scope, this rule applies to both.
• The parent coroutine needs to wait for the child coroutine to finish executing before finally entering the completion state, regardless of whether the coroutine body of the parent coroutine itself has been executed.
• The child coroutine will inherit the elements in the coroutine context of the parent coroutine. If it has members with the same key, it will overwrite the corresponding key, the overriding effect is only valid within its own range.

Fourth, the use and cancellation of coroutines and exceptions in Android

If an ordinary coroutine generates an unhandled exception, it will propagate the exception to its parent coroutine, and then the parent coroutine will cancel all child coroutines, cancel itself, and continue to pass the exception upwards. Let’s take an official picture to illustrate this process:

Sometimes this situation is not what we want. We hope that when a coroutine generates an exception, it will not affect the execution of other coroutines. We have also mentioned some solutions above, and we will introduce them below Practice it.

4.1, using SupervisorJob

 // Use MainScope() of the official library to obtain a coroutine scope for creating coroutines
    private val mScope = MainScope();

    fun onClickCoroutine(view: View) {

        mScope.launch(Dispatchers.Default) {
            println("I am the first coroutine")
        }

        mScope.launch(Dispatchers.Default) {
            println("I am the second coroutine")
            throw RuntimeException("RuntimeException is an exception")
        }

        mScope.launch(Dispatchers.Default) {
            println("I am the third coroutine")
        }
    }

Code execution result:

MainScope() mentioned before, its implementation is to use SupervisorJob. The execution result is that the second coroutine throws an exception, the third coroutine executes normally, But the program crashed, because we didn’t handle this exception, let’s improve the code

Exception handling:

fun onClickCoroutine(view: View) {

    mScope.launch(Dispatchers.Default) {
        println("I am the first coroutine")
    }

    mScope.launch(Dispatchers.Default + CoroutineExceptionHandler { coroutineContext, throwable ->
        println(
            "CoroutineExceptionHandler: $throwable"
        )
    }) {
        println("I am the second coroutine")
        throw RuntimeException("RuntimeException is an exception")
    }

    mScope.launch(Dispatchers.Default) {
        println("I am the third coroutine")
    }
}

Print result:

The program does not crash, and the exception handling print is also output, which achieves the effect we want. But pay attention to one thing, the parent of these sub-coroutines is SupervisorJob, but if they have sub-coroutines, the parent of their sub-coroutines is not SupervisorJob, so when they generate When it is abnormal, it is not the effect we demonstrated. We use an official diagram to explain this relationship:

As shown in the figure, when a new coroutine is created, a new Job instance will be generated to replace SupervisorJob.

4.2, using supervisorScope

This scope is also mentioned above, using supervisorScope can also achieve the effect we want, the above code:

fun onClickCoroutine(view: View) {

    val coroutineScope = CoroutineScope(Job() + Dispatchers. Default)

    coroutineScope.launch(CoroutineExceptionHandler { coroutineContext, throwable ->
        println(
            "CoroutineExceptionHandler: $throwable"
        )
    }) {
        supervisorScope {
            launch {println("I am the first coroutine")
            }
            launch {
                println("I am the second coroutine")
                throw RuntimeException("RuntimeException is an exception")
            }
            launch {
                println("I am the third coroutine")
            }
        }
    }
}

Run results

It can be seen that the effect we want has been achieved, but if we replace supervisorScope with coroutineScope, the result is not like this. In the end, I still use the official picture to show it:

This is the end of the article. This article refers to Quyunshuo. If there is any infringement, please contact to delete it.