Может ли приложение быть не убито, а Activity какая-нибудь убита?

Да, приложение может остаться "живым", а отдельные Activity — "убиты"

Это абсолютно нормальная и распространённая ситуация в Android, связанная с управлением памятью и жизненным циклом компонентов. Процесс приложения и его компоненты (такие как Activity, Fragment) управляются системой Android независимо, но в определенной иерархии.

Как это работает?

Процесс приложения — это контейнер, в котором выполняется код вашего приложения. Он содержит:

• Объект Application
• Выполняющиеся потоки (Threads), включая главный поток (Main/UI Thread)
• Живые (не уничтоженные) компоненты (Activity, Service и др.)
• Выделенную память (heap)

Activity — это один из компонентов, который работает внутри этого процесса. Уничтожение Activity не обязательно влечет за собой уничтожение всего процесса.

Типичные сценарии "живого" приложения с "убитой" Activity

1. Ориентация устройства (Rotation)

    Это самый частый случай. При смене конфигурации (повороте экрана, изменении языка) система по умолчанию уничтожает текущую Activity и создает ее заново. Процесс приложения при этом обычно остается жив.

```kotlin
// Пример: Activity уничтожается при повороте. Временные данные теряются.
class MainActivity : AppCompatActivity() {
    private var userInput: String = "" // Это поле сбросится при пересоздании

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        // savedInstanceState здесь будет null после обычного поворота,
        // если мы не сохранили состояние в onSaveInstanceState()
        val restoredText = savedInstanceState?.getString("INPUT_KEY")
        // ...
    }
}
```

2. Управление памятью системой (Low Memory Situations)

    Когда системе не хватает памяти для более важных задач (например, для активного приложения на переднем плане), она может начать уничтожать **фоновые процессы** (Background Processes) или их компоненты. Activity, которая находится в стеке (Back Stack), но не видна пользователю (например, позади текущей), может быть уничтожена, чтобы освободить ресурсы. При этом процесс может остаться висеть в памяти с другими своими компонентами.

1. Явный вызов finish()

    Вы можете программно завершить Activity. Это убирает ее из стека и вызывает ее уничтожение, но не затрагивает сам процесс приложения, если в нем есть другие активные компоненты.

```kotlin
binding.exitButton.setOnClickListener {
    finish() // Уничтожает только эту Activity
}
```

Что происходит с процессом приложения?

Процесс приложения переходит в состояние "Фоновый" (Background) или "Кэшированный" (Cached). В этом состоянии:

• В нем может не остаться ни одной активной Activity.
• Он может быть оставлен в памяти для быстрого перезапуска (если пользователь вернется к приложению).
• Система может убить этот процесс позже, если потребуется больше памяти.

Важные технические следствия для разработчика

Поскольку такая ситуация — норма, архитектура приложения должна ее учитывать:

• Сохранение состояния UI (UI State): Для временного сохранения данных при уничтожении Activity (как при повороте) используется связка методов onSaveInstanceState(Bundle) и восстановление в onCreate() или onRestoreInstanceState().

  override fun onSaveInstanceState(outState: Bundle) {
      super.onSaveInstanceState(outState)
      outState.putString("INPUT_KEY", binding.editText.text.toString())
  }
  
  override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      setContentView(R.layout.activity_main)
      val restoredText = savedInstanceState?.getString("INPUT_KEY")
      restoredText?.let { binding.editText.setText(it) }
  }
  

• Сохранение постоянных данных (Persistent Data): Любые важные данные, которые должны пережить не только уничтожение Activity, но и возможное убийство всего процесса, должны сохраняться в постоянное хранилище: базу данных (Room), DataStore, SharedPreferences (для простых данных) или файловую систему.

• Разделение ответственности (Architecture): Современные подходы (MVVM, MVI) с использованием ViewModel и корутин (Kotlin Coroutines) решают эту проблему. ViewModel переживает пересоздание Activity, связанное с изменением конфигурации, потому что ее экземпляр хранится в ViewModelStore, управляемом системой. Это позволяет сохранять данные, связанные с UI.

  // ViewModel сохранит данные при повороте экрана
  class MainViewModel : ViewModel() {
      private val _uiState = MutableStateFlow("")
      val uiState: StateFlow<String> = _uiState.asStateFlow()
  
      fun updateText(newText: String) {
          _uiState.value = newText
      }
  }
  
  class MainActivity : AppCompatActivity() {
      private val viewModel: MainViewModel by viewModels()
      override fun onCreate(savedInstanceState: Bundle?) {
          super.onCreate(savedInstanceState)
          // Данные из ViewModel будут доступны даже после пересоздания Activity
          lifecycleScope.launch {
              repeatOnLifecycle(Lifecycle.State.STARTED) {
                  viewModel.uiState.collect { text ->
                      binding.textView.text = text
                  }
              }
          }
      }
  }
  

• Восстановление после убийства процесса: Если система убивает весь процесс, при следующем запуске будет создан новый процесс и новая Activity. В этом случае ViewModel (созданная через viewModels()) не спасет, так как она была привязана к старому процессу. Для восстановления сложного состояния в этом сценарии используется SavedStateHandle в ViewModel.

Итог

Да, это стандартное поведение. Activity — это "окно" вашего приложения, которое система может закрыть, чтобы сэкономить ресурсы, оставив само "здание" (процесс) стоять. Понимание этого механизма критически важно для создания стабильных, отзывчивых и энергоэффективных Android-приложений, которые корректно восстанавливают свое состояние в любых условиях, предусмотренных платформой.