SwiftUI Instruments22.04.2025 16:01

Apple по доброте душевной поделилась с разработчиками инструментом отладки SwiftUI. Удобный он или не очень — разберёмся вместе с Surf iOS Team. 

Как запускать Instruments

По умолчанию Instruments SwiftUIоткрывает 5 полей сбора данных:

1. View Body: сколько view было создано за указанное время и сколько времени потребовалось для их создания.

2. View Properties: какие view properties изменились и вызвали изменения в интерфейсе. Речь тут о свойствах, на которые можно подписаться — State, ObservedObject, Binding.

3. Core Animation Commits: сколько было выполнено Core Animation Commits и какова была их длительность. В этом случае CAC — это единовременная задача UI framework«a по рендерингу нового состояния UI.

4. Time Profiler: сколько времени занял каждый вызов функции.

5. Hangs:  зависания в главном потоке и их длительность. Работает от iOS 16.

С помощью Core Animation Commits можно искать самые «дорогостоящие» перерисовки UI и определять причины проблем — достаточно следить за полями View Body и View Properties. 

Hangs поможет найтисамые ощутимые фризы. Стоит обратить внимание не только на их длительность, но и на количество — сколько их идёт друг за другом.

С этим инструментом легко работать с новыми проектами, где ещё не очень много кода и не так много связей. Если же у нас «тяжелый» проект,   такая отладка может занять много времени. 

Упрощаем работу с инструментами

• Для начальной отладки удобно использовать симулятор — он всегда под рукой и все окна будут на одном экране. Но для реальной проверки ВСЕГДА берите реальное устройство.

• Инструменты работают с релизной конфигурацией, а значит, любые дебажные дополнения будут проигнорированы. Prints в том числе.

• Инструменты записывают реакции на всё происходящее в приложении, так что стоит дать им время на отработку всех действий. Дождитесь открытия и полной загрузки приложения. После нажатия на кнопку или после взаимодействия с частью системы сделайте паузу — так на графиках можно будет отследить логические начало и конец каждого действия.

• Полноценную аналитику данных можно увидеть только после остановки инструментов — в реальном времени они просто отобразят не все данные (чтобы не терять время на их обработку). Потому лучше сначала снимать данные, а анализировать их уже после.

• Начинайте с простых последовательностей — например, с реакции на нажатие одной кнопки. Так получится локализовать логику происходящего и не бросаться в море данных.

Смотрим на примере шторки

Данные ниже собраны на основе кастомной шторки в приложении. Использовать системный компонент мы не могли — требовалась поддержка работы на iOS 14 и выше. 

Запускаем инструменты, дожидаемся загрузки главного экрана — это первая череда активностей на слайде. 

Берём паузу — помним, что мы никуда не торопимся, чтобы получить качественные данные для аналитики — после чего нажимаем кнопку смены города. Это вторая череда активности на скрине. 

Последняя вспышка активности — закрытие шторки. 

Завершаем сессию снятия данных, чтобы инструменты смогли их обработать и отобразить детали.

Меняем масштаб — cmd+ или жестом zoom на трекпаде — в месте открытия шторки. И тут же видим, что между стартом действия и концом отображения проходит больше секунды. Чтобы увидеть время, наводим мышку на нужный участок

Старт открытия шторки в 14.942 — ориентируемся на поле View Body.

Конец обработки открытия шторки на 15.993 — смотрим на поле View Body.

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

Поле Hangs — на этом масштабе видим блок мелких подвисаний microHang и оранжевый столбец довольно ощутимого зависания.

Чтобы понять, какие view перерисовались и какие вызвали эти перерисовки, меняем масштаб инструментов. Первой меняется состояние кнопки — и к этому нет вопросов.

Получается, что все подписанные экраны реагируют на переменную «шторки», хотя сами экраны не изменяются. И логично было бы их не только не перерисовывать, но и не пересчитывать.

Нашли неоднозначную связь подписок в коде, которую стоит изучить.

Наблюдаем за графиком

Посмотрим на поле Core Animation Commits — там, где оно становится красным.

Строка Core Animation Commits несёт общую информацию, что система проводит очень много перерисовок одновременно или делает это медленно. А детали происходящего ищем в полях View Properties и View Body.

Медленные перерисовки возникают, когда нужно обновить большие view. Тут важно понимать, действительно ли нужно перерисовывать всю view или можно переделать отдельную её часть.

Самые долгие функции надо смотреть в Time Profiler. Он умеет отображать в логах конкретные методы и места в коде. Но в рамках нашего проекта строка оказалась бесполезной.

Для поля View под графиками есть консоль вывода информации о том,   сколько и какие view перерисовывались. Можно отсортировать эти данные по времени. Но для крупных проектов это просто огромная куча данных, которую довольно сложно разгрести. Так что проще обойтись информацией из графиков — там она более наглядна и структурирована.

Подводим итоги

Мы попробовали SwiftUI Instruments и выносим вердикт — использовать их, как минимум, интересно. А на новых проектах — ещё и довольно просто. Инструменты помогут лучше понимать SwiftUI.

А ещё SwiftUI Instruments можно использовать для проверки себя — они помогут понять, оптимально ли мы используем подписки. Ведь часто на UI достаточно перерисовать один блок, а не весь экран. 

На больших проектах можно использовать инструменты для проведения рефакторинга, хотя, конечно, он может оказаться очень дорогим для внедрения и тестирования. Или для проверки добавления новой логики или фич — чтобы не сделать проект ещё более тяжёлым.

Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf Tech.

Присоединяйтесь!