Как использовать средство проверки основного потока Xcode?
Как с помощью Xcode обнаружить все области кодовой базы, где обновляется пользовательский интерфейс. Я хочу. Приложение перестает отвечать на запросы.
Я хочу включить эти фиолетовые предупреждения «Этот метод не следует вызывать в основном потоке, поскольку это может привести к зависанию Ul».
Я уже включил Main Thread Checker в «Редактировать схему» -> «Выполнить» -> «Диагностика» -> «Проверка API времени выполнения». Но я не получаю эти предупреждения, как показано на прикрепленном изображении.
Они отображаются во время выполнения. Это означает, что если вы вызываете метод пользовательского интерфейса из двух разных мест: одного из фона, другого из основного потока, и если при тестировании вы вызываете только из основного потока, у вас не будет ошибки во время выполнения...
@matt Они иногда появляются, я совершенно уверен, что в базе кода есть много областей, где фоновый поток обновляет пользовательский интерфейс.
Ответы 1
В пользовательском интерфейсе есть много причин зависания. И параметры диагностики Xcode, показанные в вопросе, — не единственные ресурсы, которые у нас есть:
Я бы посоветовал вам рассмотреть возможность использования шаблона «Профилировщик времени» в инструментах, который включает в себя инструмент «Зависания». См. видео WWDC 2023 Анализируйте зависания с помощью инструментов , 2022 года. Отслеживайте зависания с помощью Xcode и обнаружения на устройстве , а также 2021 года. Понимайте и устраняйте зависания в вашем приложении.
Например, я намеренно вызвал зависание, сжимая и распаковывая большой ресурс, используя структуру Compression в основном потоке. (То, что я сделал для проявления зависания, не имеет особого значения. Это всего лишь случайный пример того, что блокирует вызывающий поток.)
Диагностика Xcode не выявила проблему; эти диагностики сообщают только об очень конкретных проблемах. Но когда я профилировал это в Инструментах, инструмент «Зависания» определил это как «микрозависание». Затем я control нажал кнопку «Интервал» и выбрал «Установить диапазон проверки» в контекстном меню. Сузив свой анализ до времени, в течение которого произошло зависание, я затем перешел к инструменту «Профилировщик времени» и посмотрел, что делало приложение, когда оно зависало:
Я могу даже дважды щелкнуть символ в трассировке стека, и Instruments перенесет меня к коду, вызывающему ошибку:
Кроме того, я иногда считаю, что опция записи «Потоки ожидания записи» для инструмента «Профилировщик времени» в «Инструментах» также полезна в этих случаях. Это гарантирует, что мы захватим образцы производительности, даже когда один поток ожидает другого:
Вы даже можете настроить инструмент «Зависания», чтобы указать, какие зависания вы хотите обнаруживать:
В итоге я бы посоветовал посмотреть несколько таких видеороликов, и вы лучше поймете широкий спектр проблем, которые могут повлиять на скорость реагирования приложений, а также то, как использовать эти инструменты для выявления и диагностики проблем.
Вы не получаете предупреждений, поскольку не обновляете интерфейс в фоновом потоке. Так что не волнуйтесь, будьте счастливы. На самом деле, если бы вы обновили интерфейс в фоновом потоке, вы, вероятно, получили бы нечто большее, чем просто предупреждение — программа проверки основного потока, вероятно, привела бы вас к сбою.