Как мы ускорили запуск приложения Dropbox для Android на 30%

Запуск приложения — это первое, с чем сталкиваются наши пользователи после установки приложения, а затем снова и снова, при каждом его запуске. Простое и быстрое приложение приносит пользователям намного больше радости, чем приложение с множеством функций, которое загружается целую вечность. Понимая это, Android-команда Dropbox вложила много сил и средств в измерение, выявление и устранение проблем, влияющих на время запуска нашего приложения. В итоге мы улучшили время запуска нашего приложения на 30%, и вот история того, как мы этого достигли.

Страшный подъем

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

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

perfMonitor.startScenario(AppColdLaunchScenario.INSTANCE)

// perform the work needed for launching the application

perfMonitor.stopScenario(AppColdLaunchScenario.INSTANCE)

Как data-driven команда, мы отслеживаем и мониторим инициализацию приложения с помощью графиков, доступных всем инженерам. На приведенном ниже графике показаны измерения p90 при запуске приложения с конца марта до начала апреля 2020 года.

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

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

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

Больше цифр

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

1. Запуск миграции
2. Загрузка сервисов приложения
3. Загрузка начальных пользователей

Мы начали наше расследование с использования инструментов профилирования в Android Studio для измерения производительности на наших тестовых телефонах. Проблема с профилированием производительности при таком подходе заключалась в том, что наши тестовые телефоны не давали нам статистически значимой выборки того, насколько хорошо запускается приложение. Приложение Dropbox для Android установлено из Google Play Store более 1 миллиарда раз и охватывает множество типов устройств, некоторые из них — старые Nexus 5, а другие — новейшие и лучшие устройства Google. Было бы глупо пытаться профилировать такое количество конфигураций. Поэтому мы решили измерить различные этапы запуска приложения, используя сценарии и этапы сценария в производственной среде.

Вот обновленный код инициализации, в который мы добавили ведение логов для трех вышеупомянутых шагов:

perfMonitor.startScenario(AppColdLaunchScenario.INSTANCE)
perfMonitor.startRecordStep(RunMigrationsStep.INSTANCE)

// perform migrations step wrok

perfMonitor.startRecordStep(LoadAppServicesStep.INSTANCE)

// load application services step

perfMonitor.startRecordStep(LoadInitialUsers.INSTANCE)

// perform initial user loading step

perfMonitor.stopScenario(AppColdLaunchScenario.INSTANCE)

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

Нарушители производительности

На графике ниже показано общее время запуска приложения с января по октябрь 2020 года.

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

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

Библиотека Firebase Performance

Библиотека Firebase Performance включена в набор продуктов Google Firebase для измерения и отправки показателей производительности приложений. Она предоставляет полезные функции, такие как показатели производительности отдельных методов, а также инфраструктуру для мониторинга и визуализации производительности различных частей приложения. К сожалению, библиотека Firebase Performance также связана с некоторыми скрытыми расходами. Среди них — дорогостоящий процесс инициализации и, как следствие, значительным увеличением времени сборки. В ходе отладки мы обнаружили, что инициализация пакета Firebase длилась в семь раз дольше, когда был включен инструмент Firebase Performance. Чтобы решить проблему с производительностью, мы решили удалить инструмент Firebase Performance из Android-приложения Dropbox. Библиотека Firebase Performance — замечательный инструмент, который позволяет вам профилировать детали производительности на очень низком уровне, такие как отдельные вызовы функций, но, поскольку мы не использовали эти функции, мы решили, что быстрый запуск приложения перевешивает получение данных о производительности отдельных методов, и поэтому мы удалили ссылки на эту библиотеку.

Миграции

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

Загрузка пользователя

В legacy части нашего приложения мы храним метаданные контактов пользователей Dropbox на устройстве в виде больших двоичных объектов JSON. В идеале эти большие двоичные объекты JSON следует читать и преобразовывать в объекты Java только один раз. К сожалению, код для извлечения пользователей вызывался несколько раз из различных унаследованных функций приложения, и каждый раз код выполнял дорогостоящий синтаксический анализ JSON для преобразования пользовательских BLOB-объектов в JSON в объекты Java. Хранение контактов пользователей в формате JSON было очень устаревшей конструкцией и частью нашего устаревшего монолитного кода. Чтобы немедленно исправить эту проблему, мы добавили функцию кэширования проанализированных пользовательских объектов во время инициализации. По мере того как мы продолжаем работать над разрушением унаследованного монолитного кода, более эффективным и современным решением для хранения контактов пользователей будет использование базы данных Room и преобразование этих объектов в бизнес-объекты.

Что теперь?

В результате удаления ссылки на Firebase Performance, удаления дорогостоящих шагов миграции и кеширования пользовательской загрузки мы улучшили производительность запуска приложения Dropbox для Android на 30%. Благодаря этой работе мы также собрали информационные дашборды, которые помогут предотвратить ухудшение времени запуска приложения в будущем.

Мы также приняли несколько методов, которые, надеюсь, не позволят нам совершать те же ошибки производительности. Вот пара из них:

Измерение влияния на производительность запуска приложения при добавлении сторонних библиотек

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

Кеширование всего

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

Вывод

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

Источник