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

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

Подробно:

	ARC	Трассирующий GC
Механизм	подсчёт сильных ссылок, подготовленный компилятором	обход достижимого графа во время сборки
Освобождение	при последнем release; его точка зависит от времени жизни и оптимизации	по политике сборщика после установления недостижимости
Задержки	retain/release и синхронная цепочка deinit могут стоить времени	зависят от реализации: паузы, инкрементальная или конкурентная работа
Циклы	недостижимый сильный цикл сам не собирается	недостижимые циклы могут быть собраны

1. Время жизни — последняя строка области видимости не обязательно совпадает с последним release. Оптимизатор может менять время жизни в разрешённых языком пределах; при необходимости используют withExtendedLifetime.
2. Ресурсы — deinit полезен для финальной очистки, но для обязательного своевременного close, отмены или отписки лучше явная операция и, где подходит, defer. Retain cycle может вообще не дать deinit выполниться.
3. Слабые ссылки — weak не удерживает объект и обнуляется; unowned требует доказательства, что объект ещё жив при обращении. Выбор следует из модели владения.

⚠️ Частая ошибка: «ARC работает только при компиляции и не имеет пауз». Во время выполнения остаются расходы на подсчёт ссылок и освобождение, а дорогой deinit может задержать поток.

Короткий ответ: Очередь — абстракция «список задач», а не поток: 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.