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 идеално място за „тежки“ операции по актуализиране, които не са необходими при частична загуба на фокус.

Според спецификацията на жизнения цикъл на Android Activity, времевият интервал между 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).