Обмен технологиями

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Обзор инструментов, связанных со сбором и анализом производительности

Существует множество инструментов для сбора, анализа и отображения данных о производительности мобильных приложений, которые можно условно разделить на следующие категории. Например, мобильные инструменты производительности, которые могут собирать несколько показателей производительности, perfdog и Solopi, среди которых Solopi — с открытым исходным кодом, а pefdog — коммерческий инструмент. Инструменты, которые могут выполнять анализ сбоев, такие как коммерческий Firebase Crashlytics и инструмент Sentry с открытым исходным кодом. Если вам нужно проанализировать данные, связанные с сетью, вы можете использовать Charles или Wireshark. Кроме того, существуют комплексные инструменты управления производительностью, такие как Dynatrace. Вообще говоря, возможности, точность и удобство использования коммерческих инструментов определенно лучше, чем у инструментов с открытым исходным кодом. В качестве личного изучения и исследования я могу начать только с инструментов с открытым исходным кодом. Поэтому при написании этого блога мы также будем использовать в качестве примеров инструменты с открытым исходным кодом.

Инструмент тестирования производительности мобильных устройств：
PerfDog: инструмент для мониторинга производительности приложений, процессора, памяти, энергопотребления и других данных, поддерживающий тестирование производительности и мониторинг мобильных приложений в реальном времени.
Solopi: фокусируется на тестировании и мониторинге производительности мобильных приложений, включая мониторинг частоты кадров, процессора, памяти и других показателей в реальном времени.

Инструмент анализа сбоев：
Firebase Crashlytics: мощный инструмент отчетов и анализа сбоев, предоставляемый Google, который может отслеживать сбои приложений в режиме реального времени.
Sentry: инструмент отслеживания ошибок с открытым исходным кодом, который поддерживает несколько платформ, включая отчеты об ошибках и мониторинг производительности мобильных приложений.

Инструменты тестирования производительности сети：
Charles Proxy: прокси-инструмент для отладки сети, который собирает и анализирует данные сетевых запросов и ответов для мобильных приложений.
Wireshark: инструмент сетевого анализа с открытым исходным кодом, который поддерживает захват и анализ сетевых пакетов мобильных приложений.

Инструменты APM(Управление производительностью приложений):
Dynatrace: облачное полнофункциональное решение для мониторинга производительности, которое поддерживает мониторинг производительности мобильных приложений и анализ пользовательского опыта.

Какие показатели производительности собираются и как

  Прежде чем выполнять анализ производительности, вы должны сначала понять значение каждого показателя производительности. На примере показателей производительности, собранных Solopi, давайте рассмотрим общие показатели производительности мобильных приложений и способы их сбора.

Частота кадров

Формула расчета частоты кадров:Частота кадров = количество отрисованных кадров/период времени,Целевая частота кадров для большинства разработчиков приложений и игр составляет60 кадров в секунду( кадров в секунду), почему целевая частота кадров составляет 60 кадров в секунду? Поскольку частота обновления экрана большинства современных смартфонов и планшетов составляет 60 Гц, пока частота кадров достигает 60 кадров в секунду, то есть количество кадров, рисуемых в секунду, равно 60, визуальные эффекты пользователя будут более плавными и задержек не будет. Минимальное значение не может быть ниже 30 кадров в секунду. Это связано с тем, что монитор постоянно отображает изображение предыдущего кадра в ожидании нового кадра, в результате чего изображение становится негладким. Высокие могут достигать 90FPS (например, для устройств с высокой частотой обновления).

Как собрать информацию о частоте кадров

  Существует два способа сбора данных о частоте кадров. Один из них — использование класса Choreographer для сбора статистики частоты кадров. Это требует написания кода внутри приложения и позволяет собирать только информацию о частоте кадров приложения.Другой способ — использовать инструмент gfxinfo. Если взять в качестве примера Solopi, время тайм-аута кадра в пределах 1 секунды также рассчитывается с помощью информации инструмента gfxinfo, и выводится фактическая частота кадров. Поэтому, когда она близка к стационарной, часть частоты кадров может отображаться неправильно. Рекомендуется проводить тестирование частоты кадров в динамических сценариях, таких как скольжение или переключение страниц. Метод gfxinfo может собирать информацию о частоте кадров всех приложений и очень подходит в качестве инструмента сбора данных о производительности. Поэтому здесь мы также сосредоточимся на том, как собирать информацию о частоте кадров с помощью gfxinfo.

Существует два основных этапа сбора информации о частоте кадров.первый шаг: Получить информацию gfxinfo с помощью команды adb,Шаг 2 : анализ информации и расчет информации о частоте кадров. Содержание информации gfxinfo примерно следующее:

Статистика с: Время начала статистики, единица измерения — наносекунды.
Всего обработанных кадров: общее количество визуализированных кадров.
Неровные кадры: количество неровных кадров, то есть количество кадров, превышающих 16 мс (интервал обновления 60 кадров в секунду).
Процент некачественных кадров: отношение некачественных кадров к общему количеству кадров.
90-й процентиль: 90-й процентиль, указывающий, что 90% кадров имеют время рендеринга ниже этого значения (в миллисекундах).
95-й процентиль: 95-й процентиль, указывающий, что 95% кадров имеют время рендеринга ниже этого значения (в миллисекундах).
99-й процентиль: 99-й процентиль, указывающий, что 99% кадров имеют время рендеринга ниже этого значения (в миллисекундах).
Число пропущенных Vsync: количество несинхронизированных вертикальных синхронизаций, то есть количество пропущенных кадров, вызванных сбоем во времени рендеринга.
Число Высокая задержка ввода: количество высоких задержек ввода указывает на количество задержек, вызванных слишком длительным временем обработки входного события.
Число медленных потоков пользовательского интерфейса: количество раз, когда поток пользовательского интерфейса отвечал медленно, то есть сколько раз обработка потока пользовательского интерфейса занимала слишком много времени.

Если взять в качестве примера Solopi, частота кадров определяется по времени ожидания кадра в информации gfxinfo. Для кода конкретного проекта вы можете просмотреть исходный код Solopi.

скорость задержки/количество лагов

Количество зависаний : В течение периода тестирования количество периодов, в течение которых частота кадров оказывается ниже порогового значения. Всякий раз, когда частота кадров падает ниже порогового значения в течение определенного периода времени, это считается заиканием. Пороговое значение здесь можно настроить. Например, если оно на 60 кадров в секунду ниже целевой частоты кадров, это может быть записано как зависание. То есть, если время рендеринга кадра превышает 16 мс, он считается зависшим.

скорость задержки : Процент времени заморозки к общему времени теста. Предположим, что в тесте приложение работало 120 секунд, в течение которых частота кадров была ниже 16 FPS всего 4 раза, а общее время задержки составило 8 секунд, тогда: количество лагов: 4 раза. Уровень заикания: 8/120*100%=6,7%. В gfxinfo выше также есть данные о скорости задержки.

процессор/память

  Если взять в качестве примера Solopi, то CPU включает в себя процент использования ЦП процесса, в котором находится активность приложения верхнего уровня, и глобальный процент использования ЦП. Для однопроцессных приложений эти данные представляют собой использование ЦП приложением; В приложениях с несколькими процессами эти данные представляют собой использование процессора пользовательского интерфейса верхнего уровня. При переключении процесса Soloπ может автоматически переключиться на новые данные процесса.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

Время отклика

  Возьмите солопи в качестве примера, Содержит данные о времени ответа и времени обновления для кликов приложения. Принадлежит данным измерения приложения. Время от щелчка пользователя до первого момента, когда система выдает обновление интерфейса, — это время ответа, а время до того, как система перестанет обновлять интерфейс, — это время обновления. Логика подсчета времени ответа заключается в разделении записи экрана на кадры. Согласно официальному сайту Solopi, он автоматически распознает начальный и конечный кадр для подсчета времени ответа. Когда вы действительно используете Solopi, вы обнаружите эту статистическую страницу. Время ответа неверно. Например, когда пользователь нажимает кнопку «Пуск», при нажатии на страницу приложения включается время работы со скоростью руки кого-то посередине, и эта часть засчитывается во время ответа. Поэтому, если вы хотите рассчитать время отклика подготовленной страницы, точнее будет только записать экран и вручную определить начальный и конечный кадры страницы. Конкретные шаги для записи кадров экрана следующие:

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