Activity и Fragment: ключевые различия для Android-разработчика

Введение: почему этот вопрос так любят на собеседованиях

«В чем разница между Activity и Fragment?» — если вы готовитесь к Android-собеседованию, этот вопрос вы услышите с вероятностью 90%. И это не случайность.

Этот вопрос — идеальный индикатор уровня разработчика. С первого взгляда он кажется простым, но за ним скрывается целый пласт знаний: архитектура приложения, жизненные циклы, управление состоянием и понимание того, как Android-система взаимодействует с вашим кодом.

Многие кандидаты отвечают шаблонно: «Activity — это экран, а Fragment — это часть экрана». Формально это правда, но такой ответ показывает, что человек не копал глубже. Интервьюер же хочет услышать, как вы понимаете ответственность каждого компонента, как они связаны и где находятся границы их полномочий.

В этой статье мы разберём не только базовое отличие, но и нюансы, о которых часто забывают. Например, как Fragment влияет на производительность и почему попытка управлять его жизненным циклом как независимым компонентом — классическая ошибка кандидатов на собеседовании.

Итак, начнём с фундамента: разберём, что такое Activity на самом деле, а затем перейдём к Fragment и их взаимодействию. К концу статьи у вас будет чёткая ментальная модель, которая поможет уверенно ответить на этот вопрос на любом собеседовании.

Activity: полноценный компонент экрана

«В чем разница между Activity и Fragment?» — с этого вопроса часто начинается разговор про архитектуру Android-приложений. И первый шаг к уверенному ответу — четко понимать, что такое Activity и какую роль она играет в системе.

Activity — это самостоятельный компонент приложения, который представляет собой один экран или часть пользовательского интерфейса. Когда вы открываете приложение, система создает Activity, и именно она становится точкой входа для пользователя. Это не просто «окно» — это полноценный элемент, который напрямую взаимодействует с операционной системой.

Ключевая особенность Activity в том, что ее жизненный цикл контролируется Android Framework и операционной системой. Разработчик не решает, когда Activity будет создана или уничтожена — система делает это сама, руководствуясь действиями пользователя, состоянием памяти и конфигурацией устройства. Нам остается только правильно реагировать на эти события.

MainActivity.kt
class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        // Инициализация UI и первичных данных
    }

    override fun onStart() {
        super.onStart()
        // Activity становится видимой для пользователя
    }

    override fun onResume() {
        super.onResume()
        // Activity готова к взаимодействию, фокус на экране
    }

    override fun onDestroy() {
        super.onDestroy()
        // Освобождение ресурсов перед уничтожением
    }
}

Жизненный цикл Activity включает ключевые методы: onCreate, onStart, onResume, а также onPause, onStop и onDestroy. Каждый из них — это точка, где вы можете управлять состоянием экрана: инициализировать данные, подписываться на события или, наоборот, освобождать ресурсы.

Еще один важный момент: Activity — это самостоятельный элемент, который может быть запущен напрямую. Например, через Intent из другого приложения или как часть более крупной структуры. Именно Activity регистрируется в манифесте, и именно к ней система обращается, когда нужно показать новый экран.

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

• Что важно запомнить про Activity:
• Activity — самостоятельный компонент, управляемый операционной системой
• Жизненный цикл — ключевые методы onCreate, onStart, onResume, onDestroy
• Activity — контейнер для всего экрана и точка взаимодействия с системой
• Может быть запущена напрямую через Intent или как часть структуры приложения
• Именно Activity обрабатывает системные события: поворот экрана, нехватку памяти, входящие вызовы

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

Fragment: модуль внутри Activity

Если Activity — это сцена, то Fragment — актёр, который выходит на неё по команде режиссёра. Разберём метафору дальше: у актёра нет собственной жизни вне театра — его выходы и уходы определяет постановка. Точно так же Fragment не существует сам по себе, он всегда привязан к конкретной Activity.

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

Теперь про жизненный цикл — здесь кандидаты чаще всего путаются. У Fragment нет собственного жизненного цикла в том смысле, что у Activity. Его жизненный цикл тесно связан с жизненным циклом хостинг-Activity:

• Activity создала onCreate → Fragment проходит свои onAttach, onCreate, onCreateView
• Activity в onStart → Fragment получает onStart
• Activity в onResume → Fragment получает onResume
• Activity уничтожается → Fragment проходит onDestroyView, onDestroy, onDetach

Fragment управляется через методы, которые вызывает Activity для контроля его видимости. Вы не можете «запустить» Fragment как самостоятельный компонент — только через FragmentManager внутри конкретной Activity.

// Так Fragment добавляется внутрь Activity
supportFragmentManager.beginTransaction()
    .replace(R.id.fragment_container, ProfileFragment())
    .addToBackStack("profile")
    .commit()

// А так Activity управляет видимостью Fragment
val fragment = supportFragmentManager.findFragmentById(R.id.fragment_container)
fragment?.let { manager ->
    manager.beginTransaction()
        .hide(it)
        .commit()
}

Ещё один нюанс, который часто спрашивают, — производительность. Создание и уничтожение Fragment может вызывать накладные расходы, связанные с их инициализацией. Каждый раз, когда вы делаете replace, система создаёт новый экземпляр, раздувает layout, проходит весь цикл. На простых экранах это незаметно, но в тяжёлых интерфейсах лучше использовать show/hide вместо постоянных replace.

Отдельно стоит разобрать onSaveInstanceState. Activity использует эту механику для сохранения состояния при повороте экрана, и Fragment использует ту же механику — но с одним важным отличием: Fragment сохраняет состояние через свой SavedStateRegistry, который привязан к хостинг-Activity. Если Activity будет уничтожена, Fragment потеряет своё состояние вместе с ней.

Ключевые различия: контейнер vs модуль

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

Это главное, что нужно держать в голове: Activity — контейнер, Fragment — модуль. Activity отвечает за весь экран целиком: за то, чтобы приложение появилось в списке запущенных, за обработку поворота экрана, за взаимодействие с системой через onCreate, onStart, onResume и onDestroy. Fragment же отвечает только за свою часть UI — он живёт внутри Activity и подчиняется её правилам.

Fragment не имеет собственного жизненного цикла в том смысле, в каком его имеет Activity. Его жизненный цикл — это проекция жизненного цикла хостинг-Activity. Когда Activity переходит в состояние onPause, все её фрагменты тоже получают onPause. Когда Activity уничтожается — фрагменты уничтожаются вместе с ней. Попытка управлять жизненным циклом Fragment как независимой сущностью — верный путь к утечкам памяти и «вылетам».

class MainActivity : AppCompatActivity() {

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

        // Fragment добавляется в контейнер, который определён в layout Activity
        if (savedInstanceState == null) {
            supportFragmentManager.beginTransaction()
                .add(R.id.fragment_container, ProfileFragment())
                .commit()
        }
    }
}

Обратите внимание: R.id.fragment_container — это просто FrameLayout или FragmentContainerView в XML-разметке Activity. Activity выделяет место, Fragment заполняет его. Это и есть отношение «контейнер — модуль».

Когда вы говорите о Fragment как о временном или модальном элементе, вы тоже попадаете в точку. Activity всегда занимает весь экран (или почти весь — вспомните мультиоконный режим, но это отдельная история). Fragment же может быть скрыт, заменён, добавлен поверх другого фрагмента или показан как диалог — DialogFragment использует ту же механику. Activity так не умеет: вы не можете показать «половину Activity» поверх другой Activity без дополнительных ухищрений с темами и анимациями.

• Как отвечать на вопрос «В чём разница?» — план ответа:
• Activity — самостоятельный компонент, точка входа в приложение, управляется ОС
• Fragment — модуль внутри Activity, не может существовать без хостинга
• Жизненный цикл — у Activity он собственный и полный; у Fragment он привязан к Activity и дополнен своими фазами (onAttach, onCreateView, onDestroyView)
• Назначение — Activity отвечает за экран и системные взаимодействия; Fragment — за переиспользуемую часть UI
• Гибкость — Fragment можно динамически добавлять, удалять, заменять; Activity — статичная единица в стеке навигации

Ещё один важный нюанс из практики: создание и уничтожение Fragment — операция не бесплатная. Каждый раз, когда вы заменяете один фрагмент другим, происходят инициализация, создание view, привязка к контейнеру и последующее уничтожение. На слабых устройствах это заметно, поэтому злоупотреблять динамической заменой фрагментов не стоит. И обязательно следите за тем, чтобы Fragment корректно обрабатывал потерю фокуса и уничтожение — иначе получите утечку контекста, которую потом будете долго искать в профилировщике.

Нюансы производительности и жизненного цикла

Когда речь заходит о Fragments, даже опытные кандидаты часто сыпятся на двух вещах: производительность и жизненный цикл. Давайте разберем, что здесь важно, а что — просто страшилки для джуниоров.

Начнем с производительности. Создание и уничтожение Fragment — это не бесплатная операция. Каждый раз, когда вы добавляете Fragment через FragmentTransaction, система выполняет целый ряд шагов: создает экземпляр, привязывает к контейнеру, запускает lifecycle-методы, делает commit транзакции. Все это — накладные расходы на инициализацию.

// Типичный пример, который может стоить вам производительности
supportFragmentManager
    .beginTransaction()
    .replace(R.id.container, MyFragment.newInstance())
    .commit()

Кажется безобидным, правда? Но если вы делаете это в onResume при каждом повороте экрана или в списке при скролле — привет, лаги. Поэтому на собеседовании стоит упомянуть, что для часто пересоздаваемых UI-блоков иногда выгоднее использовать View или Compose, а Fragment оставить для действительно независимых модулей.

Теперь о жизненном цикле. Это та тема, где проваливается большинство. Fragment не имеет собственного жизненного цикла в том смысле, в котором его имеет Activity. Его lifecycle полностью подчинен хостинг-Activity. Когда Activity уничтожается — Fragment уничтожается вместе с ним. Когда Activity в onStop — Fragment тоже в onStop. Вы не можете «пережить» свою Activity.

Критически важно правильно обрабатывать события потери фокуса и уничтожения. Например, если вы подписались на поток данных в onStart — отпишитесь в onStop. Если начали анимацию в onResume — остановите в onPause. Это банально, но именно на таких вещах строятся каверзные вопросы.

• Проверьте себя перед собеседованием:
• [ ] Понимаете ли вы, в каком порядке вызываются lifecycle-методы Fragment относительно Activity?
• [ ] Знаете ли вы, что onViewCreated вызывается после onCreateView, и чем они отличаются?
• [ ] Можете ли вы объяснить, почему нельзя делать commit() после onSaveInstanceState()?

Самая распространенная ошибка — пытаться управлять жизненным циклом Fragment как независимым от Activity. Это недопустимо. Всегда смотрите на хостинг: если Activity в процессе уничтожения, ваши попытки «спасти» Fragment через retainInstance или хитрые манипуляции с транзакциями приведут к крашам или утечкам.

Помните: Fragment — это модуль внутри контейнера. Его судьба привязана к судьбе контейнера, и пытаться сделать иначе — значит бороться с платформой, а не использовать её.

Отдельно стоит упомянуть SaveInstanceState. Многие путают, как эта механика работает для Activity и Fragment. Activity сохраняет состояние через onSaveInstanceState, и вы восстанавливаете его в onCreate. Fragment делает то же самое, но в onSaveInstanceState и onViewCreated или onActivityCreated. Разница в точках входа и в том, что Fragment может пережить изменение конфигурации, если Activity пересоздается, но сам Fragment при этом тоже пересоздается — просто с сохраненным состоянием.

Сохранение состояния: Activity vs Fragment

Когда на собеседовании заходит речь о жизненных циклах, рано или поздно всплывает вопрос про onSaveInstanceState. И тут многие кандидаты теряются: механизм вроде одинаковый, а нюансов — вагон. Давайте разберём, чем отличается сохранение состояния у Activity и Fragment, и почему это частый источник ошибок.

Вопрос с собеседования: «В чём разница между сохранением состояния в Activity и Fragment при повороте экрана?»

Начнём с базы. onSaveInstanceState в Activity — это колбэк, который вызывается перед тем, как система может уничтожить ваше Activity. Вы кладёте в Bundle простые данные (строки, числа, Parcelable-объекты) и восстанавливаете их в onCreate или onRestoreInstanceState. Работает это одинаково уже много лет, и здесь сюрпризов нет.

Теперь про Fragment. У него тоже есть onSaveInstanceState, но вызывается он внутри механизма сохранения состояния Activity. Ключевое отличие: FragmentManager сам сохраняет состояние каждого добавленного Fragment в Bundle Activity. Это значит, что при повороте экрана система автоматически восстановит список фрагментов, их View (если вы не забыли про setRetainInstance или ViewModel) и переданные в arguments данные.

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Восстанавливаем состояние Activity
        val savedText = savedInstanceState?.getString("key_text")
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("key_text", textInput.text.toString())
    }
}

А вот как это выглядит для Fragment:

class ProfileFragment : Fragment() {

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        // Восстанавливаем состояние самого фрагмента
        val userName = savedInstanceState?.getString("user_name")
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("user_name", userNameTextView.text.toString())
    }
}

Выглядит похоже, но есть критическая разница: savedInstanceState у Fragment содержит не только ваши данные, но и внутреннее состояние FragmentManager — например, какой фрагмент сейчас в BackStack. Activity про это ничего не знает, оно просто хранит Bundle, который формирует FragmentManager.

Отдельно стоит упомянуть про arguments. Это тот механизм, который многие путают с сохранением состояния. arguments — это неизменяемый набор данных, который передаётся при создании Fragment. Он переживает поворот экрана автоматически, потому что FragmentManager сохраняет его в Bundle. Но это не замена onSaveInstanceState: в arguments нельзя складывать то, что меняется в процессе жизни фрагмента.

• onSaveInstanceState в Activity — это «внешний» механизм, который контролирует сама система.
• Fragment сохраняет состояние через свой собственный колбэк, но весь Bundle уходит в onSaveInstanceState хостинг-Activity.
• При изменении конфигурации FragmentManager восстанавливает фрагменты автоматически — вам нужно только корректно обработать свои данные.
• Не пытайтесь «пересоздавать» Fragment вручную при повороте экрана — это сделает за вас система, а вы только сломаете BackStack.

И ещё один момент, который любят проверять на собеседованиях: порядок вызовов. При повороте экрана сначала вызывается onSaveInstanceState у Activity, затем — у каждого Fragment. При восстановлении всё наоборот: сначала FragmentManager восстанавливает фрагменты, и только потом Activity получает свой savedInstanceState в onCreate. Если вы не учитываете этот порядок, можно случайно обратиться к ещё не созданному фрагменту.

Итоги

Давайте зафиксируем главное, чтобы на собеседовании вы отвечали чётко и без запинки. Вопрос про Activity и Fragment — один из самых частых, и от того, насколько структурирован ваш ответ, зависит первое впечатление.

Вот три тезиса, которые стоит держать в голове:

• Activity — контейнер, Fragment — модуль. Activity отвечает за весь экран и его взаимодействие с системой, а Fragment — за часть UI внутри этого экрана. Fragment не может существовать сам по себе, он всегда привязан к хостинг-Activity.
• Жизненный цикл Fragment зависит от Activity. Это не самостоятельный жизненный цикл, а отражение состояния родителя. Пытаться управлять Fragment так, будто он независим, — главная ошибка, которую допускают кандидаты.
• Помните про производительность и состояние. Создание и уничтожение Fragment — это накладные расходы. А сохранение состояния через onSaveInstanceState работает в связке с Activity, и это важно показать в ответе.

Если чувствуете, что тема lifecycle всплывёт в следующих вопросах, держите в голове простую схему: Activity создаёт Fragment через FragmentManager, и дальше все колбэки Fragment — onStart, onResume, onDestroy — лишь следуют за состоянием Activity. Можно даже набросать пример на доске:

class HostActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Fragment привязан к lifecycle Activity
        supportFragmentManager.beginTransaction()
            .add(R.id.container, DetailFragment())
            .commit()
    }
}

• Что важно упомянуть в ответе:
• Fragment — это модуль внутри Activity, а не самостоятельный экран.
• Жизненный цикл Fragment повторяет жизненный цикл Activity с небольшой задержкой.
• onSaveInstanceState работает в обоих случаях, но для Fragment состояние сохраняется в связке с хостингом.
• Создание Fragment — затратная операция, не злоупотребляйте этим.