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

По умолчанию 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, выберите ссылку Method Trace или Stack Sampling Trace в результатах микробенчмарка.

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

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

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

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

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

Никто

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