Может ли вызваться onDestroy без onStop?

Краткий ответ

Да, в определенных сценариях onDestroy() может быть вызван без предварительного вызова onStop(). Это исключительная ситуация, нарушающая стандартный жизненный цикл Activity, и происходит она при принудительном уничтожении активности системой или самим приложением.

Стандартный жизненный цикл и исключение

В нормальных условиях жизненный цикл Activity следует строгой последовательности: onCreate() → onStart() → onResume() → onPause() → onStop() → onDestroy().

Однако, документация Android прямо указывает, что в двух случаях onDestroy() может быть вызван напрямую, минуя onStop() (и иногда даже onPause()):

1. Когда система убивает процесс приложения из-за нехватки ресурсов (памяти) до того, как она успеет вызвать onStop(). Это аварийное завершение.
2. При вызове Activity.finish() из метода onCreate() или onStart(). В этом случае система немедленно начинает завершение активности, пропуская промежуточные состояния.

Пример кода, демонстрирующий исключение

Рассмотрим сценарий, когда разработчик сам провоцирует это поведение:

class MyActivity : AppCompatActivity() {

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

        // Ситуация 1: Вызов finish() в onCreate()
        // onStop() вызван не будет
        if (someCriticalCondition) {
            finish()
        }
    }

    override fun onStart() {
        super.onStart()

        // Ситуация 2: Вызов finish() в onStart()
        // onStop() также, скорее всего, не будет вызван
        if (someOtherCondition) {
            finish()
        }
    }

    override fun onPause() {
        super.onPause()
        Log.d("Lifecycle", "onPause called")
    }

    override fun onStop() {
        super.onStop()
        Log.d("Lifecycle", "onStop called") // Этот лог может не появиться!
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d("Lifecycle", "onDestroy called")
    }
}

Что происходит в этом коде:

• Если finish() вызывается внутри onCreate(), система сразу начинает завершать Activity. Она вызовет onDestroy() напрямую или, возможно, вызовет onStart() и затем onDestroy(), но onStop() (и onPause()) будут пропущены.
• Поведение при вызове finish() в onStart() может немного варьироваться в зависимости от версии Android, но часто приводит к пропуску onStop().

Почему это важно и какие есть последствия?

Понимание этого нюанса критично для написания надежного кода:

• Неполная очистка ресурсов: Метод onStop() традиционно считается местом для остановки тяжелых операций, анимаций или потребления ресурсов (например, отписка от сервисов точного местоположения). Если рассчитывать только на него, ресурсы могут быть не освобождены.
• Рекомендация по проектированию: Логику очистки, критически важную для освобождения ресурсов (открытые файлы, сетевые соединения, регистрация широковещательных приёмников), следует размещать в паре методов: onPause() и onDestroy(). onPause() вызывается почти всегда (кроме редкого убийства процесса из onCreate()), а onDestroy() — финальный гарант.
• Сохранение состояния: Для сохранения UI-состояния (например, введенного текста) всегда используйте onSaveInstanceState(). Этот метод вызывается перед onStop() в нормальных условиях, но система также может вызвать его перед onDestroy() при убийстве процесса, что делает его более надежным, чем опора на onStop().

Практическое правило (Best Practice)

override fun onPause() {
    super.onPause()
    // Остановить операции, которые должны быть приостановлены,
    // когда активность не на переднем плане (например, камера).
    releaseCamera()
}

override fun onDestroy() {
    // Выполнить окончательную очистку ВСЕГДА.
    cleanupResources()
    super.onDestroy() // Вызов super в конце - хороший тон
}

Вывод

Таким образом, хотя последовательность onStop() → onDestroy() является нормой, архитектура Android допускает и исключения. Ответственный разработчик должен проектировать свои Activity, учитывая возможность пропуска onStop(). Критическая логика завершения работы должна быть дублирована или размещена в методах, вызов которых более гарантирован (onPause(), onDestroy()), а для сохранения состояния полагаться на механизм onSaveInstanceState(Bundle).