Coroutine生命周期范围和ISACTIVE不起作用？

Question

我一直在与Coroutines合作，以为它们像Java线程一样工作，在长期运行的操作（例如编写大文件）中，Isalive boolean与检查IsInterrupt（）相同。

过去，Coroutine一直按照预期的方式工作，但是在当前版本1.6.1-native-Mt中似乎不再像这样了。在下面的代码中，即使我切换到1.6.1非MultithReaded库，Isalive检查中的代码似乎也不会运行。

如果这是应该工作的方式？取消作业后，应采取什么正确的清理方式？

同样，在将Coroutine附加到示波器上时，在这种情况下，当新活动开始时，是否应该自动进行自动处理？如果没有像在Onpause（）/onstop（）阶段中的Java中那样手动取消手动取消，则似乎继续运行。

Kotlin Coroutine：

import android.os.Bundle
import android.util.Log
import android.widget.Button
import androidx.appcompat.app.AppCompatActivity
import androidx.lifecycle.lifecycleScope
import kotlinx.coroutines.*

class TestActivity : AppCompatActivity() {

    private val tag = "TEST"
    lateinit var job: Job

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_test)

        val button = findViewById<Button>(R.id.stopbutton)

        job = lifecycleScope.launch(Dispatchers.IO) {

            (1..120).forEach {

                // big long operation e.g. writing a large data file
                Log.d(tag, "ticking $it")

                if ( !isActive ) {
                    // this code never happens after....
                    // 1. button is clicked to cancel job
                    // 2. app is killed
                    Log.d(tag, "ticking stopped by button")
                    // clean up the partially written file
                    return@launch
                }

                delay(1000)
            }

        }

        button.setOnClickListener {
            job.cancel()
        }

    }

}

预期输出（应与Java线程代码相同）：

ticking 1
ticking 2
ticking 3
ticking stopped

实际Coroutine输出：

ticking 1
ticking 2
ticking 3

以及用于处理线程中断的Java代码。

import androidx.appcompat.app.AppCompatActivity;

import android.os.Bundle;
import android.os.SystemClock;
import android.util.Log;
import android.view.View;
import android.widget.Button;

public class MainActivity extends AppCompatActivity {

    protected Thread t = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        t = new Thread(){

            @Override
            public void run() {

                for ( int x = 0; x < 120; x++ ) {
                    Log.d("TEST", "ticking " + x);

                    if ( interrupted() ) {
                        Log.d("TEST", "ticking stopped by button");
                        return;
                    }

                    // just for demoing
                    SystemClock.sleep(1000);

                }

            }
        };
        t.start();

        Button btn = findViewById(R.id.button);
        btn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                t.interrupt();
            }
        });
    }
}

更新1

在关注@Sergio和 @pawel的快速回复后，我删除了delay（），并将其替换为SystemClock.sleep（），就像在Java中一样，以模拟长期操作。现在，它的工作原理如预期的那样，尽管我想知道为什么这么多教程在没有突出问题的情况下使用它。

仍在尝试弄清楚如果不自动cancel（）onstop（）（如下所述）将coroutine附加到生命周期范围的意义是什么：

https://medium.com/androiddevelopers/cancellation-incellation-in-coroutines-coroutines-aa6b90163629

Answer 1

这是因为delay（）在内部还检查了取消函数，如果取消发生在其执行过程中，则通过抛出取消异常来停止Coroutine。要获得结果，您想尝试使用thread.sleep（）或类似的阻止睡眠方法而不是delay> delay或尝试包装调用delay> delay> delay> delay>进入try-catch块。

Answer 2

Coroutines中的取消确实是 ISACTIVE 是正确执行的一种方法。

但是您错过了内置的暂停功能内置的部分（在这种情况下 delay ）检查并在内部投掷cancellationException，以便在取消后不会获得其他循环执行。

如果您想对取消做出反应“ rel =“ nofollow noreferrer”> positionhandler ：

job.invokeOnCompletion {
    when(it?.message) {
        null -> Log.d("Completed normally")
        "ButtonPressed" -> Log.d("Cancelled by button press")
        else -> Log.d("Cancelled: ${it.message}")
    }
}

并更改取消代码，因此您可以识别取消消息：

job.cancel("ButtonPressed")

Answer 3

如果取消Coroutine，则delay（）或实际上任何其他暂停调用都可以扔concellationException。因此，一种方法是简单地使用try-catch-catch-catch在出口上清理，因为这些方法仍在运行。

如果您需要在清理过程中调用暂停功能，则需要使用withContext（noncancellable）{...}，以便内部的悬浮函数不会立即投掷concellationException再次。

  try {
     (1..120).forEach {
        // big long operation e.g. writing a large data file
        Log.d(tag, "ticking $it")
        delay(1000)
     }
  } catch (ex: CancellationException) {
    withContext(NonCancellable) {
       Log.d(tag, "ticking cancelled")
       // clean up interrupted file generation
    }
    throw ex
  }