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

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

Чтобы выбрать конфигурацию профилировщика, добавьте аргумент инструментария 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

Никто

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