Профилирование микробенчмарка

По умолчанию Microbenchmarks предоставляет информацию о времени выполнения и распределении памяти исполняемого кода. Если вы хотите выяснить причину медленной работы измеряемого кода, проверьте трассировку метода (которая по умолчанию регистрируется в поддерживаемых версиях ОС) или выберите другие конфигурации профилирования.

Чтобы выбрать конфигурацию профилировщика, добавьте аргумент инструментария androidx.benchmark.profiling.mode с одним из аргументов MethodTracing (по умолчанию), StackSampling или None , как показано в следующем фрагменте.

Дополнительную информацию о параметрах см. в разделе «Запись методов Java/Kotlin» . MethodTracing — эквивалент трассировки, а StackSampling — эквивалент выборки, как определено в этом документе.

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"]= 'StackSampling'
    }
}

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"] = "StackSampling"
    }
}

При профилировании бенчмарка выходной файл .trace копируется на хост в каталог вместе с результатами JSON . Чтобы просмотреть результаты профилирования в Android Studio, выберите ссылку «Трассировка метода» или «Трассировка выборки стека» в результатах микробенчмарка.

МетодТрассировка

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

Профилирование выполняется последовательно после измерения кода, поэтому ваш тест выдает как точные результаты синхронизации, так и профилирования.

Трассировка методов включена по умолчанию.

StackSampling

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

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

В Android 10 (API 29) и более поздних версиях для выборки стека используется Simpleperf для выборки стеков вызовов приложения, включая код C++. В Android 9 (API 28) и более ранних версиях для сбора выборок стека используется Debug.startMethodTracingSampling .

Вы можете настроить этот режим профилирования, добавив другие аргументы инструментария:

• androidx.benchmark.profiling.sampleFrequency

  • Количество выборок стека, захватываемых в секунду.
  • Тип аргумента: целое число
  • По умолчанию 1000 выборок в секунду.

• androidx.benchmark.profiling.sampleDurationSeconds

  • Продолжительность выполнения бенчмарка.
  • Тип аргумента: целое число
  • По умолчанию 5 секунд.

• androidx.benchmark.profiling.skipWhenDurationRisksAnr

  • Пропускает трассировку методов, если существует вероятность возникновения ошибки ANR. Рекомендуется оставить эту функцию включенной для CI-запусков, поскольку ошибки ANR могут вызывать проблемы при длительных CI-запусках.
  • Тип аргумента: логический
  • По умолчанию true

Никто

Этот аргумент не захватывает файл профилирования. Информация о времени и распределении ресурсов по-прежнему измеряется.