Таймер увеличивается на единицу всякий раз, когда пользователь пытается сбросить его до нуля в Android

Я решил эту проблему, проверив переменную isTimerRunning внутри цикла while функции startTimer перед увеличением значения времени. Насколько я понимаю, область сопрограммы не может проверить, является ли isTimerRunning ложным, если он запускает метод задержки в цикле while, поэтому нам нужно проверить его и внутри.

// Start Timer Function
fun startTimer() {
    isTimerRunning = true
    CoroutineScope(Dispatchers.IO).launch {
        while (isTimerRunning) {
            delay(1000)
            if (isTimerRunning) time += 1
        }
    }
}

Спасибо за отчет Левиафан.

resetTimer останавливает таймер, установив isTimerRunning = false. Таймер в основном просто ждет delay(1000), поэтому, когда вы установите isTimerRunning = false, он, вероятно, будет делать именно это в данный момент. После завершения сделки timer увеличивается на единицу (нежелательное поведение, которое вы наблюдали), и только затем в цикле while проверяется, истинно ли isTimerRunning. Это не так, поэтому цикл завершается и сопрограмма завершается, но таймер уже равен 1, а не 0.

Вы можете исправить это, изменив свою сопрограмму на это:

delay(1000)
while (isTimerRunning) {
    time += 1
    delay(1000)
}

Теперь следующее, что происходит, когда delay выполнено, — это проверка истинности isTimerRunning, а не увеличение таймера.

Хотя в большинстве случаев это будет работать, на самом деле это состояние гонки, поскольку у вас задействованы два отдельных потока, которые обращаются к одному и тому же изменяемому состоянию: может случиться так, что сопрограмма уже проверила, что isTimerRunning истинно, тогда resetTimer устанавливает isTimerRunning = false и time на 0, а затем сопрограмма устанавливает time += 1, в результате чего таймер сброса снова становится 1.

Хуже того, последнее утверждение на самом деле представляет собой два разных утверждения:

time = time + 1

Первый читает time и увеличивает его на 1, второй устанавливает результат этого вычисления в time. Теперь представьте, что между этими двумя потоками другой работающий поток resetTimer сбрасывает time в 0. Предположим, что время было 10 раньше, и пусть два задействованных потока называются Main и IO, тогда происходит следующее:

1. Поток ввода-вывода считывает time и увеличивает его на единицу, создавая 11. Это всего лишь результат расчета, который еще не записан обратно в переменную time.
2. Основная ветка устанавливает от time до 0
3. Поток ввода-вывода записывает результат вычисления обратно в time, который сейчас равен 11.

Таймер сейчас остановлен, но вместо сброса на 0 будет 11.

Это распространенная проблема в многопоточной среде при доступе к Общему изменяемому состоянию. В вашем конкретном случае это можно легко исправить, разрешив сопрограмме запускаться и в потоке пользовательского интерфейса, просто не используйте Dispatchers.IO. Это гарантирует, что одновременно может быть запущен только один блок кода, и ничто не сможет помешать, пока ваша сопрограмма в данный момент не ожидает delay.

На самом деле, вам вообще не следует использовать CoroutineScope, потому что это создает неуправляемую, висящую область действия сопрограммы, которую невозможно отменить. Если в компонуемом коде вы можете получить область видимости, вызвав rememberCoroutineScope(), то в модели представления вам следует использовать viewModelScope.

Одна из проблем при использовании метода активного увеличения счетчика time заключается в том, что ваши часы будут медленно отклоняться от прошедшего реального времени, потому что вы не просто увеличиваете счетчик ровно каждые 1000 миллисекунд, он всегда будет немного больше. См. первые два пункта, которые я сделал в https://stackoverflow.com/a/78742092/6216216 для подробного объяснения, почему это так.

Если вам не нужно, чтобы ваш секундомер был точным, это не будет проблемой, в противном случае вам нужно будет изменить свой подход, сохраняя только время, когда секундомер был запущен, как также объяснено (и подробно описано) в связанном ответ выше.