Подготовка к собеседованию — Android-разработчик

Короткий ответ: Корутина — легковесная единица конкурентности поверх потоков. Приостановка (suspend) «паркует» корутину и освобождает поток под другую работу; блокировка держит поток занятым. Поэтому тысячи корутин спокойно живут на одном потоке.

Подробно:

// Блокировка: поток занят и бесполезен
fun blocking() {
    Thread.sleep(1000)   // поток спит — недоступен никому
}

// Приостановка: корутина паркуется, поток свободен
suspend fun suspending() {
    delay(1000)          // поток в это время выполняет другие корутины
}

fun main() = runBlocking {
    repeat(100_000) { launch { delay(1000) } }  // ок даже на одном потоке
    // 100 000 потоков с Thread.sleep(1000) — OutOfMemoryError
}

1. Приостановка ≠ блокировка — delay возвращает управление диспатчеру, Thread.sleep удерживает поток.
2. Лёгкость — корутина это объект в куче (continuation + стейт), а не стек ~1 МБ, как у потока.
3. Кооперативность — корутина уступает поток только в точках приостановки (suspension points).

⚠️ Частая ошибка: «саспенд-функция выполняется в фоновом потоке». Нет: suspend сам по себе поток не переключает — где выполняться, решает диспатчер.

Короткий ответ: Три «поднимающих» колбэка — onCreate → onStart → onResume — выводят экран к пользователю; три «опускающих» — onPause → onStop → onDestroy — убирают. onRestart вызывается, когда остановленная Activity снова возвращается на экран.

Подробно:

     onCreate()    ← создан: setContentView, init, чтение savedInstanceState
        │
     onStart()     ← стал видимым
        │
     onResume()    ← на переднем плане, принимает ввод
        │
   [ RESUMED — работает ]
        │
     onPause()     ← потерял фокус (частично перекрыт)
        │
     onStop()      ← полностью не виден  ──onRestart()→onStart() при возврате
        │
     onDestroy()   ← уничтожен (finish или нехватка памяти)

1. onCreate — единственный обязательный; здесь инфляция layout, инициализация, восстановление из savedInstanceState.
2. onStart / onStop — граница видимости: регистрируем и снимаем то, что нужно только видимому экрану.
3. onResume / onPause — граница фокуса и ввода; onPause обязан быть коротким — следующий экран не покажется, пока он не вернётся.
4. onDestroy — финал; может не прийти при убийстве процесса, поэтому критичное сохраняем раньше.

⚠️ Частая ошибка: считать onDestroy гарантированным местом для сохранения. При process death его не будет — сохраняйте в onSaveInstanceState / onStop.

Короткий ответ: Рекомпозиция — повторный вызов @Composable-функций, когда меняется прочитанное ими состояние. Запускает её запись в наблюдаемый State (mutableStateOf, StateFlow через collectAsState и т.п.), который был прочитан внутри composable. Перевызываются только те функции, что читали именно это значение.

Подробно:

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }
    Text("Clicks: $count")           // читает count → перевызовется
    Button(onClick = { count++ }) {  // запись в count → рекомпозиция
        Text("Tap")                  // count не читает → пропустится
    }
}

1. Триггер — не «любое изменение», а запись в snapshot-состояние, которое читалось в конкретной composable. Compose отслеживает чтения и инвалидирует ровно нужные scope'ы.
2. Оптимистична — если во время рекомпозиции состояние снова поменялось, текущий проход отбрасывается и стартует заново.
3. Неупорядочена и может идти параллельно — порядок выполнения соседних composable не гарантирован; нельзя закладываться на side-effect'ы прямо в теле.

⚠️ Частая ошибка: обычная var без mutableStateOf — это не state; её изменение Compose не видит и рекомпозицию не запустит, UI «застынет».

Короткий ответ: MVVM делит экран на три роли: Model (данные и логика), View (Activity/Fragment/Composable — только рисует и передаёт действия) и ViewModel (держит состояние и переживает пересоздание View). ViewModel не знает про конкретную View — она лишь публикует состояние, на которое View подписывается.

Подробно:

┌────────┐  подписка на state   ┌───────────┐  запрос данных  ┌───────┐
│  View  │ ◄─────────────────── │ ViewModel │ ──────────────► │ Model │
│ (тупая)│ ── действия (события) ─►│ (state)   │ ◄─── данные ──── │(repo) │
└────────┘                       └───────────┘                 └───────┘

1. View — тупой рендер — берёт готовое состояние и рисует; никакой бизнес-логики, только «показать то, что дали».
2. ViewModel — держатель состояния — переживает поворот экрана (её создаёт ViewModelStoreOwner, а не пересоздаёт вместе с Activity).
3. Model — репозитории, БД, сеть; ViewModel обращается к ним, а не View напрямую.

⚠️ Частая ошибка: хранить View, Activity или Context в поле ViewModel. ViewModel живёт дольше View — после поворота ссылка указывает на уничтоженную Activity, и это утечка памяти. Нужен Context — берите AndroidViewModel.getApplication() или инжектите @ApplicationContext.

Короткий ответ: Retrofit — верхний, декларативный слой: превращает Kotlin-интерфейс с аннотациями в HTTP-запросы и парсит ответ через Converter. OkHttp под ним — сам HTTP-клиент: сокеты, пул соединений, кэш, интерцепторы, таймауты, повторы. Retrofit без OkHttp не работает — это его транспорт.

Подробно:

┌─────────────────────────────────────────┐
│ ApiService (interface + @GET/@POST)      │  ← ваш код
├─────────────────────────────────────────┤
│ Retrofit: аннотации → Request,           │
│           Converter (JSON ↔ data class)  │
├─────────────────────────────────────────┤
│ OkHttp: interceptors, connection pool,   │
│         cache, timeouts, TLS, retry      │
├─────────────────────────────────────────┤
│ Socket / сеть                            │
└─────────────────────────────────────────┘

1. Retrofit — знает про suspend и возвращает готовый data class; сам JSON не парсит.
2. Converter — kotlinx.serialization / Moshi / Gson; именно он делает JSON ↔ объект.
3. OkHttp — вся сетевая механика; один OkHttpClient на приложение, чтобы пул и кэш переиспользовались.
4. CallAdapter — поддержка suspend-функций из коробки.

⚠️ Частая ошибка: создавать новый OkHttpClient/Retrofit на каждый запрос. Тогда теряются пул соединений и кэш; клиент должен быть синглтоном на всё приложение.