Представление трассировки в CPU Profiler предоставляет несколько способов просмотра информации из записанных трассировок.
Для трассировок методов и функций вы можете просмотреть диаграмму вызовов непосредственно на временной шкале потоков , а также на вкладках « Диаграмма пламени» , «Сверху вниз» , «Снизу вверх » и «События» на панели «Анализ» . Для кадров стека вызовов вы можете просмотреть часть кода, которая была выполнена, и причину ее вызова. Для системных трассировок вы можете просмотреть события трассировки непосредственно на временной шкале потоков , а также на вкладках «Диаграмма пламени» , «Сверху вниз» , «Снизу вверх » и «События» на панели «Анализ» .
Доступны сочетания клавиш мыши и клавиатуры для упрощения навигации по таблицам вызовов или отслеживанию событий .
Проверка трассировок с помощью таблицы вызовов
Диаграмма вызовов обеспечивает графическое представление трассировки метода или функции, где период и время вызова представлены на горизонтальной оси, а вызываемые объекты показаны на вертикальной оси. Вызовы системных API показаны оранжевым цветом, вызовы собственных методов вашего приложения — зеленым, а вызовы сторонних API (включая API языка Java) — синим. На рис. 4 показан пример диаграммы вызовов и иллюстрируется концепция собственного времени, дочернего времени и общего времени для данного метода или функции. Вы можете узнать больше об этих концепциях в разделе о том, как проверять трассировки с помощью сверху вниз и снизу вверх .
Рисунок 1. Пример диаграммы вызовов, иллюстрирующей себя, детей и общее время для метода D.
Совет: Чтобы перейти к исходному коду метода или функции, щелкните его правой кнопкой мыши и выберите «Перейти к исходному коду» . Это работает на любой вкладке панели «Анализ».
Проверьте трассы, используя вкладку «Таблица пламени».
На вкладке «Пламенная диаграмма» представлена перевернутая диаграмма вызовов, объединяющая идентичные стеки вызовов. То есть идентичные методы или функции, которые используют одну и ту же последовательность вызовов, собираются и представляются в виде одной более длинной полосы на диаграмме пламени (вместо того, чтобы отображать их в виде нескольких более коротких полос, как показано на диаграмме вызовов). Это позволяет легче увидеть, какие методы или функции потребляют больше всего времени. Однако это также означает, что горизонтальная ось не представляет временную шкалу; вместо этого он указывает относительное количество времени, необходимое для выполнения каждого метода или функции.
Чтобы проиллюстрировать эту концепцию, рассмотрим диаграмму вызовов на рисунке 2. Обратите внимание, что метод D выполняет несколько вызовов B (B 1 , B 2 и B 3 ), а некоторые из этих вызовов B вызывают C (C 1 и С3 ).
Рисунок 2. Диаграмма вызовов с несколькими вызовами методов, которые имеют общую последовательность вызовов.
Поскольку B 1 , B 2 и B 3 используют одну и ту же последовательность вызывающих абонентов (A → D → B), они агрегируются, как показано на рисунке 3. Аналогичным образом агрегируются C 1 и C 3, поскольку они имеют одну и ту же последовательность вызывающих абонентов. (А → Д → Б → С); обратите внимание, что C 2 не включен, поскольку у него другая последовательность вызовов (A → D → C).
Рисунок 3. Объединение идентичных методов, использующих один и тот же стек вызовов.
Агрегированные вызовы используются для создания диаграммы флэш-графика, как показано на рисунке 4. Обратите внимание, что для любого конкретного вызова в диаграмме флейма первыми отображаются вызываемые абоненты, которые потребляют больше всего процессорного времени.
Рисунок 4. Представление диаграммы пламени диаграммы вызовов, показанной на рисунке 5.
Проверяйте трассировки, используя режимы «Сверху вниз» и «Снизу вверх».
На вкладке «Сверху вниз» отображается список вызовов, в котором при раскрытии узла метода или функции отображаются его вызываемые объекты. На рис. 5 показан график сверху вниз для диаграммы вызовов, показанной на рис. 1. Каждая стрелка на графике указывает от вызывающего абонента к вызываемому абоненту.
Как показано на рисунке 5, при раскрытии узла метода A на вкладке «Сверху вниз» отображаются его вызываемые методы — методы B и D. После этого при расширении узла для метода D отображаются его вызываемые методы — методы B и C и т. д. Подобно вкладке Пламенная диаграмма , дерево сверху вниз объединяет информацию трассировки для идентичных методов, которые используют один и тот же стек вызовов. То есть вкладка «Пламенная диаграмма» представляет собой графическое представление вкладки «Сверху вниз» .
На вкладке «Сверху вниз» представлена следующая информация, помогающая описать время ЦП, затраченное на каждый вызов (время также представлено в процентах от общего времени потока в выбранном диапазоне):
- Self: время, которое вызов метода или функции потратил на выполнение своего собственного кода, а не кода вызываемых объектов, как показано на рисунке 1 для метода D.
- Дочерние элементы: время, которое вызов метода или функции потратил на выполнение своих вызываемых объектов, а не собственного кода, как показано на рисунке 1 для метода D.
- Итого: сумма времени метода Self и Children . Это общее время, потраченное приложением на выполнение вызова, как показано на рисунке 1 для метода D.
Рисунок 5. Дерево сверху вниз.
Рисунок 6. Дерево снизу вверх для метода C из рисунка 5.
На вкладке «Снизу вверх» отображается список вызовов, в котором при раскрытии узла функции или метода отображаются вызывающие их объекты. Используя пример трассировки, показанный на рисунке 5, на рисунке 6 показано дерево метода C снизу вверх. При открытии узла метода C в дереве снизу вверх отображаются все его уникальные вызывающие методы, методы B и D. Обратите внимание, что, хотя B вызывает C дважды, B появляется только один раз при расширении узла для метода C в дереве снизу вверх. После этого при раскрытии узла для B отображается вызывающий объект, методы A и D.
Вкладка «Снизу вверх» полезна для сортировки методов или функций по тем, которые потребляют больше всего (или меньше всего) процессорного времени. Вы можете проверить каждый узел, чтобы определить, какие вызывающие программы тратят больше всего процессорного времени на вызов этих методов или функций. По сравнению с деревом «сверху вниз» информация о времени для каждого метода или функции в дереве «снизу вверх» относится к методу наверху каждого дерева (верхний узел). Время ЦП также представлено в процентах от общего времени потока во время записи. Следующая таблица помогает объяснить, как интерпретировать информацию о времени для верхнего узла и его вызывающих объектов (подузлов).
| Себя | Дети | Общий | |
|---|---|---|---|
| Метод или функция наверху дерева снизу вверх (верхний узел) | Представляет общее время, которое метод или функция потратили на выполнение своего собственного кода, а не кода вызываемых объектов. По сравнению с деревом сверху вниз, эта информация о времени представляет собой сумму всех вызовов этого метода или функции за время записи. | Представляет общее время, которое метод или функция потратили на выполнение своих вызываемых объектов, а не собственного кода. По сравнению с деревом сверху вниз, эта информация о времени представляет собой сумму всех вызовов этого метода или вызываемых функций за время записи. | Сумма личного времени и времени детей. |
| Вызывающие абоненты (подузлы) | Представляет общее время пребывания вызываемого абонента при вызове вызывающего абонента. Используя в качестве примера дерево снизу вверх на рисунке 6, собственное время для метода B будет равно сумме собственного времени для каждого выполнения метода C при вызове B. | Представляет общее время дочерних элементов вызываемого объекта при вызове вызывающего объекта. Если использовать в качестве примера дерево снизу вверх на рисунке 6, то дочернее время для метода B будет равно сумме дочерних времен для каждого выполнения метода C при вызове B. | Сумма личного времени и времени детей. |
Примечание. Для данной записи Android Studio прекращает сбор новых данных, когда профилировщик достигает ограничения размера файла (однако это не останавливает запись). Обычно это происходит гораздо быстрее при инструментальной трассировке, поскольку этот тип трассировки собирает больше данных за более короткое время по сравнению с выборочной трассировкой. Если вы продлите время проверки на период записи, которая произошла после достижения предела, данные синхронизации на панели трассировки не изменяются (поскольку новые данные недоступны). Кроме того, на панели трассировки отображается значение NaN для информации о времени, когда вы выбираете только ту часть записи, для которой нет доступных данных.
Проверьте трассировки с помощью таблицы «События».
В таблице «События» перечислены все вызовы в выбранном в данный момент потоке. Вы можете отсортировать их, щелкая по заголовкам столбцов. Выбрав строку в таблице, вы можете перейти на временной шкале к времени начала и окончания выбранного звонка. Это позволяет точно определять местонахождение событий на временной шкале.
Рисунок 7. Просмотр вкладки «События» на панели «Анализ».
Проверка кадров стека вызовов
Стеки вызовов полезны для понимания того, какая часть кода была выполнена и почему она была вызвана. Если для программы Java/Kotlin собирается образец записи стека вызовов , стек вызовов обычно включает не только код Java/Kotlin, но также кадры из собственного кода JNI, виртуальной машины Java (например, android::AndroidRuntime::start ) и ядро системы ( [kernel.kallsyms]+offset ). Это связано с тем, что программа Java/Kotlin обычно выполняется через виртуальную машину Java. Собственный код необходим для запуска самой программы и для взаимодействия программы с системой и оборудованием. Профилировщик представляет эти кадры для точности; однако, в зависимости от вашего расследования, вы можете найти или не найти эти дополнительные кадры вызова полезными. Профилировщик предоставляет возможность сворачивать кадры, которые вас не интересуют, чтобы можно было скрыть информацию, не имеющую отношения к вашему расследованию.
В приведенном ниже примере трассировка ниже содержит множество кадров с меткой [kernel.kallsyms]+offset , которые в настоящее время бесполезны для разработки.
Чтобы свернуть эти кадры в один, выберите кнопку «Свернуть кадры» на панели инструментов, выберите пути для свертывания и нажмите кнопку «Применить» , чтобы применить изменения. В этом примере путь — [kernel.kallsyms] .
При этом кадры, соответствующие выбранному пути, сворачиваются как на левой, так и на правой панелях, как показано ниже.
Проверьте следы системы
При проверке системной трассировки вы можете просмотреть события трассировки на временной шкале потоков, чтобы просмотреть подробную информацию о событиях, происходящих в каждом потоке. Наведите указатель мыши на событие, чтобы увидеть название события и время, проведенное в каждом состоянии. Щелкните событие, чтобы просмотреть дополнительную информацию на панели «Анализ» .
Проверьте системные следы: ядра ЦП.
Помимо данных планирования ЦП, системные трассировки также включают частоту ЦП по ядрам. Это показывает объем активности каждого ядра и может дать вам представление о том, какие из них являются «большими» или «маленькими» ядрами в современных мобильных процессорах.
Рисунок 8. Просмотр активности ЦП и событий трассировки для потока рендеринга.
Панель «Ядра ЦП» (как показано на рис. 8) показывает активность потоков, запланированную на каждом ядре. Наведите указатель мыши на активность потока, чтобы увидеть, в каком потоке работает это ядро в данный конкретный момент.
Дополнительную информацию о проверке информации трассировки системы см. в разделе «Исследование проблем производительности пользовательского интерфейса» документации systrace .
Проверка системных трассировок: временная шкала рендеринга кадров
Вы можете проверить, сколько времени требуется вашему приложению для рендеринга каждого кадра в основном потоке, и RenderThread для выявления узких мест, которые вызывают зависание пользовательского интерфейса и низкую частоту кадров. Чтобы узнать, как использовать системные трассировки для исследования и уменьшения количества подтормаживаний пользовательского интерфейса, см. раздел Обнаружение подтормаживаний пользовательского интерфейса .
Проверка системных трассировок: Память процессов (RSS)
Для приложений, развернутых на устройствах под управлением Android 9 или более поздней версии, в разделе «Память процесса» (RSS) отображается объем физической памяти, используемой приложением в данный момент.
Рисунок 9. Просмотр физической памяти в профилировщике.
Общий
Это общий объем физической памяти, используемый вашим процессом в данный момент. В системах на базе Unix это известно как «Размер резидентного набора» и представляет собой комбинацию всей памяти, используемой анонимными выделениями, сопоставлениями файлов и выделениями общей памяти.
Для разработчиков Windows размер резидентного набора аналогичен размеру рабочего набора.
Выделено
Этот счетчик отслеживает, сколько физической памяти в настоящее время используется процессом при обычном распределении памяти. Это распределения, которые являются анонимными (не поддерживаются конкретным файлом) и частными (не являются общими). В большинстве приложений они состоят из выделения кучи (с помощью malloc или new ) и стековой памяти. При выгрузке из физической памяти эти выделения записываются в системный файл подкачки.
Сопоставления файлов
Этот счетчик отслеживает объем физической памяти, которую процесс использует для сопоставления файлов, то есть память, отображаемая из файлов в область памяти диспетчером памяти.
Общий
Этот счетчик отслеживает, сколько физической памяти используется для совместного использования памяти между этим процессом и другими процессами в системе.