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

Короткий ответ: ARC — автоматический подсчёт ссылок: компилятор ещё на этапе компиляции вставляет вызовы retain/release вокруг работы с сильными ссылками. Объект умирает ровно в момент, когда счётчик ссылок падает до нуля — детерминированно и без пауз. Цена: циклы ссылок ARC собрать не может.

Подробно:

	ARC	Трассирующий GC
Кто решает	компилятор: вставка retain/release	рантайм: обход графа объектов
Момент освобождения	детерминированный: счётчик = 0	недетерминированный, при сборке
Паузы	нет	stop-the-world / инкрементальные
Циклы	не собирает — нужны weak/unowned	собирает автоматически
Накладные расходы	атомарные инкременты счётчика	память под кучу + CPU на трассировку

1. Компилятор, а не рантайм — retain вставляется при появлении новой сильной ссылки, release — при выходе из области видимости; оптимизатор выкидывает парные лишние вызовы.
2. Детерминированный deinit — ресурс освобождается сразу, поэтому deinit пригоден для закрытия файлов, инвалидации таймеров, отписок.
3. Плата — ретейн-циклы остаются ответственностью программиста.

⚠️ Частая ошибка: называть ARC «сборщиком мусора, только быстрее». ARC не сканирует память в рантайме — вся работа расставлена компилятором заранее, поэтому и пауз нет, и циклы сами не находятся.

Короткий ответ: Очередь — абстракция «список задач», а не поток: GCD мультиплексирует очереди по общему пулу потоков. Serial выполняет задачи строго по одной в порядке FIFO, concurrent запускает несколько параллельно. Main — единственная очередь с контрактом «выполняюсь на мейн-треде»; global — системные concurrent очереди, по одной на класс QoS.

Подробно:

Очередь	Тип	Особенность
DispatchQueue.main	serial	привязана к мейн-треду; весь UI
DispatchQueue.global(qos:)	concurrent	системные, общие на приложение
DispatchQueue(label:)	serial по умолчанию	своя; attributes: .concurrent — параллельная

QoS	Для чего
.userInteractive	анимации, реакция на жест — «прямо сейчас»
.userInitiated	пользователь ждёт результат (открытие экрана)
.utility	долгая работа с прогрессом (загрузка файла)
.background	невидимая работа: синк, индексация

1. Очередь ≠ поток — serial очередь не владеет потоком: её задачи могут выполняться на разных потоках пула, но никогда одновременно.
2. QoS решает планирование — системе QoS говорит, сколько CPU и энергии дать: .userInteractive — вне очереди, .background может подождать.

⚠️ Частая ошибка: «создал очередь — создал поток». Нет: тысячи очередей обслуживаются десятком потоков пула. А вот заблокировать много потоков через sync-ожидания — путь к thread explosion.

Короткий ответ: loadView создаёт вью → viewDidLoad — одноразовая настройка (геометрии ещё нет!) → viewWillAppear — обновление перед каждым показом → viewWillLayoutSubviews/viewDidLayoutSubviews — единственные места, где фреймы валидны → viewDidAppear — анимации и тяжёлые старты → viewWillDisappear/viewDidDisappear.

Подробно:

loadView ─► viewDidLoad ─► viewWillAppear ─► viewWillLayoutSubviews
 (создать    (один раз)     (каждый показ)          │ layout pass
  view)                                             ▼
viewDidDisappear ◄─ viewWillDisappear ◄─ viewDidAppear ◄─ viewDidLayoutSubviews
                                          (на экране)      (фреймы валидны!)

1. viewDidLoad — один раз за жизнь вью-контроллера: добавить сабвью, констрейнты, подписки. Размеров вью ещё нет.
2. viewWillAppear — каждый показ: обновить данные, состояние баров.
3. viewDidLayoutSubviews — bounds актуальны: скругления, пути CAShapeLayer, зависящая от размеров вёрстка. Вызывается многократно — без тяжёлой работы.
4. viewDidAppear — вью на экране: запуск анимаций, дорогие операции, аналитика.
5. viewWillDisappear/viewDidDisappear — остановить таймеры, сохранить состояние.

⚠️ Частая ошибка: читать view.bounds в viewDidLoad — там либо размер из сториборда, либо нули, но не реальная геометрия устройства. Всё, что зависит от размеров, живёт в viewDidLayoutSubviews.

Короткий ответ: View — не вью в смысле UIKit, а лёгкое значение-описание: чертёж того, что показать. Структуры дёшево создавать и выбрасывать, поэтому SwiftUI свободно пересоздаёт их при каждом пересчёте body. Долгоживущая часть — render tree (attribute graph) — живёт за кулисами; именно там хранятся состояние и идентичность.

Подробно:

1. Чертёж, а не экземпляр — UIView — тяжёлый объект с жизненным циклом и слоем; View-структура — пара полей и body, без ресурсов.
2. Состояние снаружи — @State хранится фреймворком и привязан к идентичности вью в дереве, а не к структуре: структура умерла, значение осталось.
3. Diffing — SwiftUI сравнивает новое описание со старым и минимально мутирует персистентное дерево; в пиксели уходит только разница.

body → View-значения (дёшево, пересоздаются каждый раз)
            │ diff
            ▼
attribute graph / render tree (живёт долго:
@State, идентичность, анимации)

⚠️ Частая ошибка: приравнять «пересоздание структур» к «перерисовке UI». Создание описаний — копейки; дорогим бывает рендер, и он происходит только там, где diff нашёл изменение.

Короткий ответ: Потому что в UIKit вью-контроллер по умолчанию — точка сборки всего: жизненный цикл вью, лейаут, data source таблицы, навигация и сетевые вызовы. Разгружается он выносом обязанностей в отдельные объекты — менять архитектуру для этого не обязательно.

Подробно:

1. Диагноз — MVC у Apple не плох сам по себе; проблема в том, что «C» удобно принимает любой код, и без дисциплины вью-контроллер растёт до тысяч строк.
2. Что выносить:

Обязанность	Куда выносится
UITableViewDataSource / delegate	отдельный объект-датасорс
Кусок экрана со своей логикой	child view controller
Сеть, кэш, аналитика	простые сервисные объекты
Конфигурация сабвью	сами вью (configure(with:))

3. Итог — вью-контроллер остаётся дирижёром: связывает сервисы, вью и навигацию, но не делает всю работу сам.

⚠️ Частая ошибка: отвечать «MVC — плохая архитектура, поэтому все ушли в MVVM». Плоха недисциплинированная реализация: без выноса обязанностей тот же перегруз повторится и с ViewModel.