onRestart — відновлення Activity у життєвому циклі

onRestart — суть методу в життєвому циклі Android

onRestart — метод-колбек, який Android викликає строго до onStart, коли Activity повертається з невидимого стану Stopped назад у видимий. Цей метод унікальний тим, що він викликається тільки при повторному показі Activity — при першому створенні екземпляра послідовність починається з onCreate, минаючи onRestart. Повний цикл: onCreate → onStart → onResume (перший запуск) або onRestart → onStart → onResume (повторний показ).

З точки зору системи Android, onRestart — це оптимізація, що дозволяє Activity підготуватися до повернення: оновити дані з репозиторію, синхронізувати стан UI, перевірити підключення до мережі. На відміну від onResume, який викликається щоразу при отриманні фокусу (у тому числі при поверненні з діалогу або системного меню), onRestart спрацьовує тільки при повному циклі приховування-повернення. Це робить onRestart ідеальним місцем для «важких» операцій оновлення, які не потрібні при частковій втраті фокусу.

Згідно зі специфікацією життєвого циклу Activity Android, часовий проміжок між onStop та onRestart може становити від кількох секунд (користувач швидко перемкнувся) до кількох годин (додаток був у фоні і користувач повернувся). За цей час дані у віддаленому джерелі (API, БД) могли змінитися, тому onRestart — природна точка для перевірки актуальності.

Коли викликається onRestart: умови та послідовність

onRestart викликається тільки при поверненні Activity зі стану Stopped, у який Activity перейшла після виклику onStop. Нижче перераховані всі сценарії, що ведуть до onRestart.

Сценарії виклику onRestart:

• Повернення з іншої Activity — користувач відкрив нову Activity (наприклад, натиснув на сповіщення), а потім повернувся назад (натиснув «Назад»). Стек: MainActivity.onPause → MainActivity.onStop → SecondActivity створюється → користувач натискає «Назад» → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Повернення зі згортання — користувач згорнув додаток (Home) і через деякий час повернувся. CurrentActivity.onPause → CurrentActivity.onStop → (додаток у фоні) → користувач повертається → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Повернення з екрана блокування — екран блокування перекриває Activity; після розблокування Activity отримує onRestart, якщо минув значний час (більше 5 секунд).
• Повернення з додатка, запущеного через Intent — камера, галерея, браузер — будь-який сторонній додаток, запущений через startActivityForResult() або ActivityResultLauncher.

Коли onRestart НЕ викликається: при повороті екрана (Activity знищується та створюється заново через onCreate), при поверненні з діалогового вікна (Activity не йде в onStop, тільки onPause → onResume), при process death (Activity створюється заново).

Відмінність onRestart від onCreate: що вибрати

onRestart та onCreate — два різних підходи до відновлення Activity. Вибір між ними залежить від того, чи була Activity повністю знищена або просто прихована.

Правило вибору: ініціалізацію View та підписку на LiveData/StateFlow робіть у onCreate (або onViewCreated для Fragment). Оновлення даних, перезавантаження списків та перевірку стану — у onRestart. Якщо дані завантажуються через ViewModel, onRestart може просто викликати метод refresh() на ViewModel, а View підпишеться на оновлені дані через реактивний потік.

Google рекомендує: не дублюйте логіку onCreate в onRestart. Виділіть у ViewModel методи refresh(), які завантажують актуальні дані, та викликайте їх у onRestart. Це зберігає чистоту архітектури MVVM та виключає дублювання коду.

Сценарії використання onRestart: оновлення даних та UI

onRestart — ідеальне місце для операцій, які повинні виконуватися при кожному поверненні на екран, але не потрібні при першому відкритті. Ось типові сценарії:

• Оновлення списку з БД або API — користувач пішов в іншу Activity, там змінив дані, повернувся — список повинен бути актуальним. Викличте viewModel.refreshItems() в onRestart.
• Перевірка авторизації — якщо Activity була прихована тривалий час, токен доступу міг прострочитися. onRestart — точка для перевірки дійсності токена та перенаправлення на екран логіна.
• Синхронізація стану UI — перемикання тем, зміна мови, оновлення налаштувань — зміни повинні застосуватися при поверненні на екран.
• Перезавантаження медіа — якщо Activity показує контент, який міг змінитися (стрічка новин, курс валют, погода), оновіть дані в onRestart.
• Перевірка мережевого підключення — при поверненні з офлайн-режиму Activity повинна перевірити доступність мережі та перемкнути UI.
• Відновлення анімацій — анімації, звільнені в onStop, перезапустіть у onRestart перед onStart.

Чого не робити в onRestart: не ініціалізуйте View заново — вони живі, оскільки Activity не знищена. Не підписуйтеся на LiveData повторно — підписка в onCreate жива. Не створюйте нові фрагменти — вони вже у FragmentManager.

onRestart та process death: важливий виняток

Найважливіший виняток: onRestart не викликається, якщо процес додатка був убитий системою. Це ключовий момент, який розробники часто упускають, покладаючись на onRestart для відновлення стану.

При process death:

• Додаток був у фоні, Android убив процес для звільнення пам'яті.
• Користувач повертається — система запускає новий процес.
• Activity створюється заново: onCreate(Bundle) → onStart → onResume.
• onRestart НЕ викликається — для системи це новий екземпляр Activity.

Як захиститися від цього: завжди зберігайте критичний стан у onSaveInstanceState(Bundle) (викликається до onStop) або використовуйте SavedStateHandle у ViewModel. У onCreate перевіряйте savedInstanceState: якщо він не null, відновлюйте стан з Bundle, якщо null — завантажуйте свіжі дані.

Згідно з Google Android Vitals, близько 7% повернень на Activity після тривалого перебування у фоні відбуваються після process death. Це означає, що кожна 15-та Activity, яка мала викликати onRestart, насправді проходить через onCreate. Ігнорування цього сценарію — одна з головних причин багів «порожній екран після повернення».

Приклади коду з onRestart на Kotlin

Приклад 1: onRestart з оновленням списку через ViewModel

Activity викликає viewModel.refreshTasks() в onRestart для оновлення списку завдань після повернення з екрана редагування.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "Отримано ${tasks.size} завдань")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: оновлення списку завдань")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() завантажує актуальні дані з репозиторію. LiveData автоматично сповіщає Activity про зміну даних — UI оновлюється без додаткового коду. onRestart не створює нову підписку — вона вже встановлена в onCreate.

Приклад 2: onRestart з перевіркою авторизації

Activity перевіряє дійсність токена при поверненні та перенаправляє на логін при необхідності.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Повернулися з екрана логіна") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Токен прострочений — перенаправлення на логін")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Якщо користувач згорнув додаток на тривалий час і повернувся після закінчення терміну дії токена, onRestart перенаправить його на екран логіна. Це запобігає помилкам API при спробі виконати запит із простроченим токеном. Зверніть увагу: перевірка в onRestart, а не в onResume, щоб уникнути зайвої перевірки при поверненні з діалогу.

Приклад 3: onRestart у Fragment з ViewLifecycleOwner

Fragment використовує onRestart через LifecycleObserver для оновлення даних.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart через LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Замість перевизначення onRestart у Fragment використовується LifecycleObserver — більш гнучкий підхід, що дозволяє додавати логіку на події життєвого циклу без успадкування. ViewLifecycleOwner гарантує, що observer живе в скоупі View (не переживає onDestroyView).