Первая часть, про архитектуру приложения. Вторая про сетевой слой. Третья — локальное хранилище и Offline-First архитектура.
Часть 4: Оптимизация производительности
Производительность — один из самых простых критериев, по которым пользователи оценивают качество приложения.
Они могут не знать, какую архитектуру вы используете и соответствует ли ваш код принципам SOLID, но сразу заметят, если приложение долго запускается, дёргается при прокрутке, потребляет слишком много памяти или быстро разряжает аккумулятор.
Именно поэтому оптимизация производительности — одна из любимых тем на собеседованиях senior iOS-разработчиков.
Интервьюеры не ожидают, что вы выучите Instruments наизусть или дословно перескажете документацию Apple. Им нужны инженеры, способные находить узкие места, правильно расставлять приоритеты при оптимизации и принимать обоснованные компромиссные решения на основе реальных производственных сценариев.
В этой статье мы рассмотрим пять вопросов, которые часто встречаются на собеседованиях по архитектуре и системному проектированию iOS-приложений.
Вопрос 16. Приложение запускается восемь секунд. Как вы будете исследовать и устранять проблему?
Почему интервьюеры задают этот вопрос
Время запуска приложения — один из важнейших показателей производительности.
Медленный запуск создаёт плохое первое впечатление и часто указывает на то, что во время старта выполняется лишняя работа.
Интервьюеры хотят понять, как вы подходите к анализу производительности, а не услышать набор случайных способов оптимизации.
Ответ уровня старшего разработчика
Сначала я определю всё, что происходит во время запуска.
Среди распространённых причин:
- слишком большое количество запросов к программному интерфейсу;
- тяжёлая инициализация базы данных;
- загрузка крупных изображений;
- синхронные операции с диском;
- дорогостоящая инициализация зависимостей;
- запуск комплекта средств аналитики;
- разбор больших документов JSON.
Вместо слепой оптимизации я профилирую приложение с помощью Instruments, чтобы найти реальное узкое место.
После этого переношу необязательную работу за пределы критического пути запуска.
Первая задача приложения — как можно быстрее показать пользователю полезный интерфейс.
Всё остальное должно выполняться позже.
Пример из производственного приложения
Допустим, во время запуска приложение выполняет следующие операции:
Инициализация базы данных ↓ Загрузка профиля пользователя ↓ Инициализация аналитики ↓ Загрузка конфигурации ↓ Загрузка главного экрана ↓ Отображение первого экрана
Пользователь несколько секунд не видит ничего.
Более эффективный подход:
Отображение сплеш скрина ↓ Отображение сохранённой версии главного экрана ↓ Фоновая инициализация сервисов ↓ Обновление данных
В результате приложение ощущается значительно быстрее, даже если фоновая работа всё ещё продолжается.
Распространённая ошибка
Многие разработчики начинают оптимизировать приложение, не проводя измерений.
Улучшения производительности всегда должны основываться на данных профилирования, а не на предположениях.
Дополнительные вопросы
- Какие инструменты Instruments вы бы использовали?
- Что должно произойти до появления первого экрана?
- Как реализовать отложенную загрузку сервисов?
- Нужно ли инициализировать аналитику во время запуска?
Вопрос 17. Как улучшить производительность прокрутки больших списков?
Почему интервьюеры задают этот вопрос
Плавная прокрутка необходима для качественного пользовательского опыта.
Интервьюеры хотят понять, разбираетесь ли вы в производительности отрисовки и эффективном обновлении интерфейса.
Ответ уровня старшего разработчика
При оптимизации прокрутки я стараюсь уменьшить объём работы, выполняемой в каждом кадре.
Некоторые подходы:
- эффективное повторное использование ячеек;
- асинхронная загрузка изображений;
- исключение лишних вычислений компоновки;
- кеширование рассчитанных значений;
- предварительная загрузка приближающегося содержимого;
- исключение повторяющихся запросов к базе данных.
Кроме того, по возможности я переношу ресурсоёмкую работу с главного потока.
Цель состоит в том, чтобы главный поток оставался свободным для отрисовки интерфейса.
Пример из производственного приложения
Представим приложение интернет-магазина, которое отображает тысячи товаров.
Каждая ячейка синхронно загружает изображение.
Во время прокрутки интерфейс зависает, потому что декодирование изображений блокирует главный поток.
Перенос загрузки и декодирования изображений в фоновые очереди, а также кеширование загруженных изображений делают прокрутку значительно более плавной.
Распространённая ошибка
Полная перезагрузка списка после каждого небольшого изменения.
Вместо этого следует обновлять только затронутые элементы.
Современные программные интерфейсы позволяют гораздо эффективнее выполнять частичные обновления.
Дополнительные вопросы
- Почему возникают пропущенные кадры?
- Как кеширование изображений повышает производительность?
- Что такое предварительная загрузка ячеек?
- Как помогают diffable data sources?
Вопрос 18. Как уменьшить потребление памяти в iOS-приложении?
Почему интервьюеры задают этот вопрос
Высокое потребление памяти приводит к аварийному завершению приложения, ухудшает многозадачность и увеличивает расход аккумулятора.
Интервьюеры хотят понять, умеете ли вы находить проблемы с памятью и предотвращать их.
Ответ уровня старшего разработчика
Сначала я определю, какие объекты занимают память.
Среди распространённых причин:
- большие кеши изображений;
- утечки памяти;
- циклы сильных ссылок;
- объекты, которые никогда не освобождаются;
- загрузка всего набора данных в память.
Вместо того чтобы постоянно хранить всё в памяти, я освобождаю больше не нужные объекты и загружаю ресурсы только по мере необходимости.
Кроме того, я использую Instruments, чтобы убедиться, что объекты корректно освобождаются.
Пример из производственного приложения
Фотогалерея загружает все изображения в полном разрешении сразу после открытия экрана.
Потребление памяти быстро растёт, пока iOS не завершает приложение.
Более правильный подход — сначала загружать уменьшенные изображения, а версии в полном разрешении получать только после того, как пользователь откроет конкретную фотографию.
Распространённая ошибка
Путать высокое потребление памяти с утечкой памяти.
Приложение может обоснованно использовать большой объём памяти без каких-либо утечек.
Утечка возникает в том случае, когда память больше невозможно освободить.
Дополнительные вопросы
- Как обнаруживать циклы удержания?
- Что вызывает предупреждения о нехватке памяти?
- Как помогают слабые ссылки?
- Какие Instruments вы бы использовали?
Вопрос 19. Как оптимизировать загрузку изображений?
Почему интервьюеры задают этот вопрос
Изображения часто являются самыми крупными ресурсами, загружаемыми мобильными приложениями.
Неправильная работа с изображениями влияет на прокрутку, время запуска, использование памяти и производительность сети.
Ответ уровня старшего разработчика
Мой подход включает:
- отложенную загрузку;
- кеширование на диске;
- кеширование в памяти;
- асинхронную загрузку;
- изменение размера изображений;
- объединение одинаковых запросов.
Я не допускаю многократной загрузки одного и того же изображения.
Вместо этого загруженные изображения кешируются и по возможности используются повторно.
Большие изображения уменьшаются до отрисовки, чтобы сократить потребление памяти.
Пример из производственного приложения
Рассмотрим ленту социальной сети.
Без кеширования приложение повторно загружает все изображения профилей каждый раз, когда пользователь возвращается в ленту.
При использовании кеша в памяти и на диске большинство изображений отображается мгновенно. Это сокращает потребление трафика и повышает воспринимаемую скорость приложения.
Распространённая ошибка
Отображение исходных изображений с разрешением 4K внутри небольших ячеек списка.
Это приводит к неоправданному расходу памяти и ресурсов графического процессора.
По возможности изображения следует уменьшать до размера, соответствующего области их отображения.
Дополнительные вопросы
- Когда использовать кеш в памяти, а когда — кеш на диске?
- Когда кешированные изображения должны удаляться?
- Как избежать повторной загрузки одного изображения?
- Как организовать предварительную загрузку изображений?
Вопрос 20. Как находить узкие места производительности?
Почему интервьюеры задают этот вопрос
Старшие инженеры решают проблемы, опираясь на фактические данные.
Интервьюеры хотят услышать описание вашего процесса отладки, а не общий набор советов по оптимизации.
Ответ уровня старшего разработчика
Я использую структурированный подход.
Шаг 1. Стабильно воспроизвести проблему.
Шаг 2. Собрать измерения с помощью Instruments.
Шаг 3. Найти самую медленную операцию.
Шаг 4. Оптимизировать только подтверждённое узкое место.
Шаг 5. Провести повторные измерения и убедиться, что производительность действительно улучшилась.
Оптимизация производительности — итеративный процесс.
Каждое изменение необходимо подтверждать данными.
Пример из производственного приложения
Пользователи сообщают, что панель управления открывается слишком медленно.
Вместо полной переработки экрана профилирование показывает, что одна операция декодирования JSON занимает три секунды.
Оптимизация именно этой операции решает проблему без лишних изменений кода.
Распространённая ошибка
Попытка оптимизировать каждую часть приложения.
Многие участки кода не оказывают заметного влияния на пользовательский опыт.
В первую очередь следует сосредоточиться на операциях, которые потребляют больше всего времени или ресурсов.
Дополнительные вопросы
- Какие инструменты Instruments вы используете чаще всего?
- Как профилировать использование центрального процессора?
- Как исследовать повышенный расход аккумулятора?
- Как измерять производительность отрисовки?
Заключение
Оптимизация производительности заключается не столько в применении отдельных приёмов, сколько в понимании того, как приложение ведёт себя в реальных условиях.
Сильные кандидаты не ограничиваются фразой: «Я бы оптимизировал приложение». Они объясняют, как будут измерять производительность, находить узкие места, оценивать компромиссы и проверять улучшения с помощью инструментов профилирования.
Именно такой образ мышления интервьюеры ожидают от старших iOS-разработчиков.
В пятой части мы рассмотрим конкурентное выполнение в Swift и многопоточность: async/await, акторы, состояния гонки, структурированную параллельность, отмену задач и проектирование отзывчивых приложений. Эти темы всё чаще встречаются на современных собеседованиях iOS-разработчиков.