Пользовался ли ты профилировщиком

Что проверяют

Закрытый вопрос, за которым сразу идёт настоящий: чем именно и что нашли. Проверяют, ищете ли вы причину замедления замером, а не догадками, и понимаете ли, что показывает каждый инструмент.

Как отвечать

Ответьте да и сразу переходите к конкретике: какой инструмент под какую проблему.

• Time Profiler: подвисания и нагрузка на процессор, стеки по семплам, с фильтром по потоку и раскрытием тяжёлых кадров;
• Allocations и Leaks: рост памяти и утечки, рядом Memory Graph Debugger, который наглядно показывает цикл сильных ссылок;
• Animation Hitches и Core Animation: пропуски кадров при прокрутке;
• os_signpost и свои интервалы: метки вокруг собственного кода, чтобы видеть длительность своей операции, а не гадать по чужим стекам;
• App Launch: холодный старт и всё, что происходит до первого кадра;
• MetricKit и отчёты из консоли разработчика: данные с боевых устройств, а не с вашего стола.

Расскажите один случай целиком: симптом, гипотеза, замер, найденная причина, правка, повторный замер. Убедительно звучат типовые находки: декодирование картинок в главном потоке, тяжёлая вёрстка ячейки, цикл сильных ссылок в замыкании без [weak self].

Где спотыкаются

Профилируют отладочную сборку на симуляторе. Симулятор считает на процессоре компьютера, а сборка без оптимизаций даёт другую картину, поэтому мерить надо конфигурацию release на живом устройстве.

Второе: называют процент улучшения, но не могут сказать, что именно мерили. Цифра без сценария, устройства и способа замера не значит ничего, и следующий же вопрос её разрушает.

Третье: оптимизируют по интуиции. Переписывают то, что кажется медленным, вместо того, что показал замер, и в итоге ускоряют код, выполняющийся однажды при старте, а прокрутка остаётся такой же рваной.