Всем привет ? я Максим Кузнецов a.k.a. Android-developer из Альфа-Мобайл. В этой статье хочу поделиться нашим опытом внедрения механизмов мониторинга производительности в продукты компании. Почему это важно? Потому что производительность напрямую влияет на опыт пользователей, рейтинги приложений и конверсии. Мы рассмотрим статистику, проблемы, наш горький опыт и планы на будущее. Давайте начнем! ?

Зачем тратить время на перформанс?

Как уже отметил выше, перформанс мобильных приложений влияет на UX, количество звезд в Play Market и App Store, продажи и репутацию компании. Есть множество подтверждающих исследований (ссылки приложил в конце статьи).

Статистика исследований:

• 53% посещений, вероятно, будут прекращены, если экраны загружаются дольше 3 секунд.

• Каждый второй человек ожидает, что экран загрузится быстрее, чем за две секунды.

• 46% людей говорят, что ожидание загрузки это то, что им больше всего не нравится.

• 36 % пользователей согласны с тем, что медленное приложение вызывает «пониженное мнение о компании».

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

• Если приложение тормозит, пользователи быстрее теряют интерес и меньше времени проводят в нём. Это снижает показатели вовлеченности и конверсии в покупки, что ударяет по монетизации.

С необходимостью поддержания высокой производительности мобильных приложений разобрались, двигаемся вперед.

Быстрое отступление или как понять, что экран действительно лагает?

Мы давно ходим не с кинеографом в кармане, а оптимальной частотой обновления экрана мобильных устройств считается 60 FPS.

При такой частоте обновления скорость отрисовки одного кадра должна быть равна: 1000ms / 60 = 16.6666667 миллисекундам.

Так это выглядит, когда просадок нет.

А так выглядит, когда просадка есть.

Какие есть способы измерения перформанса? Наиболее часто используемые из них:

• CPU, GPU, Memory, Energy профайлеры.

• Микро- и макро-бенчмарки.

• System tracing.

• Что-то еще.

Профайлинг CPU позволяет выявить узкие места, связанные с высокой загрузкой процессора. Это важно для плавной работа интерфейса и быстрого отклика на действия пользователя. 

Например, источником просадки может быть тяжелая верстка в RecyclerView.Adapter onCreateViewHolder(). 

Профайлинг GPU важен для приложений с интенсивной графикой, таких как игры, видеоредакторы или для работы с анимациями в Android-приложении. Он позволяет выявить проблемы с рендерингом, текстурами, шейдерами и другими аспектами, связанными с загрузкой видеокарты. 

Инструменты профайлинга GPU дают детальную информацию о том, сколько времени занимает отрисовка каждого кадра, какие операции с графикой являются самыми медленными. 

Это помогает оптимизировать использование видеопамяти, уменьшить количество вызовов OpenGL, избавиться от лишних вычислений в шейдерах и обеспечить стабильные 60 FPS.

Профайлинг памяти критичен для предотвращения утечек памяти и оптимизации использования ОЗУ.

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

Профайлинг энергопотребления важен для увеличения времени автономной работы устройства.

Инструменты профайлинга энергопотребления показывают, какие компоненты устройства (CPU, GPU, экран, сеть) потребляют больше всего энергии в каждый момент времени.

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

Микро- и макро-бенчмарки — это инструменты для измерения производительности приложения на разных уровнях.

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

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

System Trace позволяет записывать активность системы в течение короткого периода времени в файл трассировки.

Основные возможности System Trace:

• Записывает события и метки времени из ядра Linux, библиотек и приложений Android.

• Отображает точную временную информацию о работе всех процессов на устройстве в момент записи трассировки.

• Показывает, где приложение тратит время и что происходит внутри системы в конкретные моменты.

• Позволяет добавлять пользовательские метки в код приложения для более детального анализа.

Для захвата трассировки System Trace можно использовать библиотеку Perfetto. Файл трассировки можно расшифровать в веб-интерфейсе Perfetto. 

Choreographer

Перечисленные выше способы измерения перформанса требуют особых знаний и дополнительного времени инженера, которым они не всегда располагают. Также бывает важным находить неочевидные просадки FPS и при ручном тестировании. Поэтому мы хотели инструмент, который мог использовать любой член кросс-функциональной команды без погружения в библиотеки и документацию. Как мы этого достигли рассмотрим немного позже, а сейчас обратим внимание на Choreographer.

Наиболее внимательные разработчики замечали в консоли следующий текст:

I/Choreographer: Skipped 146 frames! The application may be doing too much work on its main thread.

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

Взглянем на последовательность вызовов методов, которые ведут к отрисовке первого кадра: 

• ActivityThread.handleResumeActivity() 

• WindowManagerImpl.addView() 

• WindowManagerGlobal.addView() 

• ViewRootImpl.setView() 

• ViewRootImpl.requestLayout() 

• ViewRootImpl.scheduleTraversals() 

• Choreographer.postCallback() 

• Choreographer.scheduleFrameLocked()

Метод Choreographer.scheduleFrameLocked() ставит в очередь сообщение MSG_DO_FRAME. При обработке сообщения MSG_DO_FRAME происходит вызов метода Choreographer.doFrame(), который как раз нас и интересует.

/**
 * Implement this interface to receive a callback when a new display frame is
 * being rendered. The callback is invoked on the {@link Looper} thread to
 * which the {@link Choreographer} is attached.
 */
public interface FrameCallback {
    /**
     * Called when a new display frame is being rendered.
     * <p>
     * This method provides the time in nanoseconds when the frame started being rendered.
     * The frame time provides a stable time base for synchronizing animations
     * and drawing. It should be used instead of {@link SystemClock#UptimeMillis()}
     * or {@link System#nanoTime()} for animations and drawing in the UI. Using the frame
     * time helps to reduce inter-frame jitter because the frame time is fixed at the time
     * the frame was scheduled to start, regardless of when the animations or drawing
     * callback actually runs. All callbacks that run as part of rendering a frame will
     * observe the same frame time so using the frame time also helps to syncronize effects
     * that are performed by different callbacks.
     * </p><p>
     * Please note that the framework already takes care to process animations and
     * drawing using the frame time as a stable time base. Most applications should
     * not need to use the frame time information directly.
     * </p>
     *
     * @param frameTimeNanos The time in nanoseconds when the frame started being rendered,
     * in the {@link System#nanoTime()}  timebase. Divide this value by {@code 1000000}
     * to convert it to the {@link SystemClock#uptimeMillis()} time base.
     */
    public void doFrame(long frameTimeNanos);
}

Choreographer предоставляет возможность зарегистрировать обратный вызов, который может быть запущен при любом вызове doFrame, эти колбэки будут выполняться синхронно один за другим.

Choreographer получает уведомление о начале построения следующего кадра и синхронно вызывает doFrame колбэки, которые в конечном итоге могут вызвать ваш код.

Таким образом мы можем реализовать любую механику в doFrame, например:

№1. Послать push-нотификацию с именем Activity/Fragment, где произошла просадка.

Пример кода:

private const val SLOW_FRAME_RENDER_TIME_MS = 120L

class NotificationFrameListener : Choreographer.FrameCallback {

    private val choreographer = Choreographer.getInstance()

    private var lastTimeMillis = 0L
    private var lastScreenOpenTimeMillis = 0L

    override fun doFrame(frameTimeNanos: Long) {
        val currentTimeMillis = TimeUnit.NANOSECONDS.toMillis(frameTimeNanos)
        val frameRenderTime = currentTimeMillis - lastTimeMillis
        if (frameRenderTime > SLOW_FRAME_RENDER_TIME_MS && lastTimeMillis > 0) {
            showNotification()
        }
        lastTimeMillis = currentTimeMillis
        choreographer.postFrameCallback(this)
    }
}

Пример отображения.

№2. Сохранить информацию о просадке в базу данных.

№3. Отрисовать FPS в оверлее приложения.

Пример кода:

private const val TICK_INTERVAL_MS = 500L

class OverlayFrameListener : Choreographer.FrameCallback {

    private val choreographer = Choreographer.getInstance()

    private var startTimeMillis = 0L
    private var lastTimeMillis = 0L
    private var framesRendered = 0

    override fun doFrame(frameTimeNanos: Long) {
        val currentTimeMillis = TimeUnit.NANOSECONDS.toMillis(frameTimeNanos)
        lastTimeMillis = currentTimeMillis

        if (startTimeMillis > 0) {
            val timeSpan = lastTimeMillis - startTimeMillis
            framesRendered++

            if (timeSpan > TICK_INTERVAL_MS) {
                val fps = framesRendered * 1000 / timeSpan.toDouble()
                showFps(fps.roundToInt())

                startTimeMillis = lastTimeMillis
                framesRendered = 0
            }
        } else {
            startTimeMillis = lastTimeMillis
        }

        choreographer.postFrameCallback(this)
    }
}

Пример отображения.

Открытие Activity может вызывать просадку FPS и это нормально

Одна из первых проблем, с которыми мы столкнулись — спам уведомлений при просадке. Это происходит из-за того, что при запуске Activity загружаются и инициализируются её компоненты: разметка, ресурсы, данные, выполнение различных жизненных циклов компонентов и т. д. Всё это может привести к блокировке главного потока (UI thread), что в свою очередь может сказаться на плавности анимаций и общей производительности приложения.

• Единичные просадки до 30-40 FPS длительностью до 100-200 мс — это нормально, они, как правило, незаметны для пользователя.

• Множественные просадки до 20-30 FPS длительностью до 500 мс могут быть заметны, но не критичны.

• Длительные просадки ниже 20 FPS более 1 секунды — уже проблема.

Фиксится это завязкой на методы жизненного цикла активити и регулировкой ключевых значений того, что мы считаем просадкой. 

Внутри класса Application есть интерфейс ActivityLifecycleCallbacks. Один из его методов — onActivityPreCreated. Именно здесь мы паузируем показ нотификаций, пока активити не перейдет в состояние Resumed. 

class CurrentActivityProvider: Application.ActivityLifecycleCallbacks {

    var currentActivity: Activity? = null
        private set

    var onActivityPreCreatedCallback: (() -> Unit)? = null


    override fun onActivityPreCreated(activity: Activity, savedInstanceState: Bundle?) {
        onActivityPreCreatedCallback?.invoke()
    }


    override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) = Unit

    override fun onActivityStarted(activity: Activity) = Unit


    override fun onActivityResumed(activity: Activity) {
        currentActivity = activity
    }


    override fun onActivityPaused(activity: Activity) {
        if (activity == currentActivity) {
            currentActivity = null
        }
    }


    override fun onActivityStopped(activity: Activity) = Unit

    override fun onActivitySaveInstaceState(activity: Activity, outState: Bundle) = Unit

    override fun onActivityDestroyed(activity: Activity) = Unit
}

P.S. Медленным мы считаем кадр, который отрисовывается более 80 мс на устройствах с частотой обновления экрана в 120 Гц, и более 30 мс на устройствах с 60 Гц. 

P.P.S. Вычислено эмпирически.

// TODO или что мы сделали не так?

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

Но результат первого a/b теста показал, что почти все разработчики выключали фичу почти сразу, так как информация о просадке не была комплексной и полезной. Очевидные просадки и так бросались в глаза, а остальные не были критичными. QA-инженеры особым вниманием новую фичу так же не потчевали.

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

Спасибо за внимание, по любым вопросам велкам в комменты ?