Four startup modes of kotlin collaboration

Default ： Start scheduling immediately after the collaboration is created . If the collaboration is cancelled before scheduling . Put it directly into the corresponding cancellation state .

ATOMIC： After the collaboration is created . Start scheduling immediately . The collaboration process will not be canceled until the first starting point .

LAZY: Only when collaboration is needed , Including active coordination process start、join perhaps await Wait for the function , Will start scheduling , If it is cancelled before scheduling . Then the collaboration will directly enter the abnormal state .

UNDISPATCHED： The coroutine is executed in the current function call stack immediately after it is created , Until you meet the first real hang point .

CoroutineStart.DEFAULT

Code case

      binding.btClick7.setOnClickListener {
            runBlocking {
                val job = launch(start = CoroutineStart.DEFAULT) {
                    delay(10000)
                    Log.e(TAG, "onCreate: Job finished.")
                }
                delay(1000)
                job.cancel()
                Log.e(TAG, "onCreate: Job cancel.")
            }
        }

The coordination process will not execute

Because it was cancelled during the execution .

ATOMIC

        binding.btClick7.setOnClickListener {
            runBlocking {
                val job = launch(start = CoroutineStart.ATOMIC) {
                    // Here code 
                    
                    // These tasks must be performed 
                    // Here's the code 
                    // Here is a starting point 
                    delay(10000)
                    Log.e(TAG, "onCreate: Job finished.")
                }
                delay(1000)
                job.cancel()
                Log.e(TAG, "onCreate: Job cancel.")
            }
        }

The code before the function is suspended will not be cancelled . Cancellation can only be carried out after the starting point is reached

LAZY

        runBlocking {
                val job = async(start = CoroutineStart.LAZY) {
                    29
                }
                // Perform calculations 
                // Start the coroutines 


                Log.e(TAG, "Completed job.start in ${job.start()} ms")
                // Or use await
                job.cancel()

                job.await()
                job.join()
            }

job.cancel() Will enter an abnormal state . If not await、join、 Or is it start operation Will not be activated .

By default

   val job = async(context = Dispatchers.IO, start = CoroutineStart.DEFAULT) {
                    Log.e(TAG, "thread:" + Thread.currentThread().name)
                }

Will be executed in the child thread

If you use

UNDISPATCHED Pattern

      binding.btClick7.setOnClickListener {
            runBlocking {
                val job = async(context = Dispatchers.IO, start = CoroutineStart.UNDISPATCHED) {
                    Log.e(TAG, "thread:" + Thread.currentThread().name)
                }

            }
        }

Will print out the main thread

The printing at the bottom corresponds to the above default mode

Why does it print out the main thread

The coroutine is executed in the current function call stack immediately after it is created , Because it is executed in the main thread . So it will execute in the main thread .

UNDISPATCHED It means no forwarding .