Анализ и оптимизация запуска приложений

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

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

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

Для анализа запуска вашего приложения выполните следующие действия:

Этапы анализа и оптимизации стартапа

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

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

  • Используйте библиотеку Macrobenchmark для измерения времени выполнения каждой операции и выявления блоков, выполнение которых занимает много времени.

  • Убедитесь, что ресурсоемкая операция критически важна для запуска приложения. Если операция может подождать, пока приложение полностью не отрисуется, это поможет минимизировать ограничения ресурсов при запуске.

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

  • По возможности перенесите длительные операции в фоновый режим. Фоновые процессы всё ещё могут влиять на загрузку ЦП во время запуска системы.

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

Оптимизируйте и проводите повторные измерения, пока не будете удовлетворены временем запуска вашего приложения. Для получения дополнительной информации см. раздел «Использование метрик для обнаружения и диагностики проблем» .

Измерьте и проанализируйте время, затраченное на основные операции.

Когда у вас будет полная трассировка запуска приложения, проанализируйте её и измерьте время, затраченное на основные операции, такие как bindApplication или activityStart . Мы рекомендуем использовать Perfetto или профилировщики Android Studio для анализа этих трассировок.

Проанализируйте общее время, затраченное на запуск приложения, чтобы выявить операции, выполняющие следующие действия:

  • Эти операции занимают большие промежутки времени и могут быть оптимизированы. Каждая миллисекунда влияет на производительность. Например, обратите внимание на время отрисовки Choreographer , время начальной композиции, время загрузки библиотеки, транзакции Binder или время загрузки ресурсов. Для начала, рассмотрите все операции, которые занимают более 20 мс.
  • Заблокируйте основной поток. Для получения дополнительной информации см. раздел «Навигация по отчету Systrace» .
  • Запускать при загрузке системы не требуется.
  • Можно подождать, пока не будет нарисован первый кадр.

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

Выявите ресурсоемкие операции в основном потоке.

Рекомендуется выносить ресурсоемкие операции, такие как ввод-вывод файлов и доступ к сети, из основного потока. Это также важно при запуске приложения, поскольку ресурсоемкие операции в основном потоке могут привести к зависанию приложения и задержке других критически важных операций. StrictMode.ThreadPolicy помогает выявлять случаи, когда ресурсоемкие операции выполняются в основном потоке. Рекомендуется включать StrictMode в отладочных сборках, чтобы выявлять проблемы как можно раньше, как показано в следующем примере:

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        ...
        if (BuildConfig.DEBUG)
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectAll()
                    .penaltyDeath()
                    .build()
            )
        ...
    }
}

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

TTID и TTFD

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

Для получения информации о методах формирования отчетов о полной отрисовке пользовательского интерфейса приложения см. раздел «Повышение точности синхронизации при запуске» .

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

Проанализируйте общее состояние потока.

Выберите время запуска приложения и проанализируйте общие потоки выполнения. Основной поток должен постоянно оставаться работоспособным.

Такие инструменты, как Android Studio Profiler и Perfetto, предоставляют подробный обзор основного потока и времени, затраченного на каждом этапе. Для получения дополнительной информации о визуализации трассировки Perfetto см. документацию по пользовательскому интерфейсу Perfetto .

Определите основные фрагменты состояния ожидания основного потока.

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

Уменьшить блокировку основного потока и обеспечить непрерываемый режим сна.

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

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

Улучшить время запуска

После выявления возможностей для оптимизации, изучите возможные решения, которые помогут сократить время запуска:

  • Для ускорения TTID загружайте контент отложенно и асинхронно.
  • Сведите к минимуму вызовы функций, которые выполняют операции связывания. Если их избежать невозможно, убедитесь, что вы оптимизируете эти вызовы, кэшируя значения вместо повторных вызовов или перенося неблокирующую работу в фоновые потоки.
  • Чтобы ускорить запуск приложения, можно как можно быстрее отображать пользователю контент, требующий минимальной отрисовки, пока не загрузится остальная часть экрана.
  • Создайте и добавьте стартовый профиль для вашего приложения.
  • Используйте библиотеку Jetpack App Startup для упрощения инициализации компонентов при запуске приложения.

Анализ производительности пользовательского интерфейса

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

Ограничить работу по инициализации

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

Для оптимизации инициализации выполните следующие действия:

  • Уделите приоритетное внимание медленным этапам композиции и компоновки и выберите те, которые нуждаются в улучшении.
  • Проанализируйте каждое предупреждение от Perfetto и оповещение от Systrace, добавив пользовательские события трассировки , чтобы уменьшить дорогостоящие операции ввода-вывода и задержки.

Измерить данные кадра

Существует несколько способов измерения данных кадров. Пять основных методов сбора данных следующие:

  • Локальный сбор данных с помощью dumpsys gfxinfo : Не все кадры, обнаруженные в данных dumpsys, являются причиной медленной отрисовки вашего приложения или оказывают какое-либо влияние на конечных пользователей. Однако это хороший показатель для анализа различных циклов выпуска, позволяющий понять общую тенденцию производительности. Чтобы узнать больше об использовании gfxinfo и framestats для интеграции измерений производительности пользовательского интерфейса в ваши методы тестирования, см. раздел «Основы тестирования приложений Android» .
  • Сбор данных с помощью JankStats : Собирайте данные о времени отрисовки кадров из определенных частей вашего приложения с помощью библиотеки JankStats , записывайте и анализируйте эти данные.
  • В тестах с использованием Macrobenchmark (с Perfetto в основе)
  • Perfetto FrameTimeline : На Android 12 (уровень API 31) и выше можно собирать метрики временной шкалы кадров из трассировки Perfetto, чтобы определить, какая работа вызывает выпадение кадров. Это может стать первым шагом к диагностике причин выпадения кадров.
  • Профайлер Android Studio для обнаружения зависаний

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

В основной активности вашего приложения может содержаться большой объем информации, загружаемой из нескольких источников. Проверьте пользовательский интерфейс главной Activity и обратите особое внимание на событие Choreographer#doFrame .

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

Рассмотрите следующие возможные решения для оптимизации времени загрузки основного приложения:

  • Постарайтесь сделать вашу первоначальную композицию максимально лёгкой. Для получения дополнительной информации см. раздел «Производительность Jetpack Compose» .
  • Добавьте пользовательские точки трассировки, чтобы получить больше информации о пропущенных кадрах и сложных конфигурациях.
  • Сведите к минимуму количество и размер ресурсов растровых изображений, загружаемых при запуске. Для получения дополнительной информации см. раздел «Оптимизация растровых изображений» .

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

    var shouldLoad by remember {mutableStateOf(false)}

if (shouldLoad) {
 MyComposable()
}

    Загрузите компонуемые элементы внутри условного блока, изменив параметр shouldLoad :

    LaunchedEffect(Unit) {
 shouldLoad = true
}

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

    Для получения дополнительной информации об оптимизации производительности Compose см. раздел «Рекомендации» .

{% verbatim %} {% endverbatim %} {% verbatim%} {% endverbatim %}