Как стать автором
Обновить

Как мы на 20% повысили скорость запуска приложения с помощью Baseline Profiles

Уровень сложностиСредний
Время на прочтение12 мин
Количество просмотров5K
Всего голосов 22: ↑21 и ↓1+20
Комментарии14

Комментарии 14

Графики из android vitals? Прирост на всех устройствах и версиях?

Графики из Firebase Performance, app_start событие. Устройства и версии мы не отслеживали отдельно, но по графикам видно улучшение

А в play console android vitals на cold start значения уменьшились?

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

Там же график показывает время запуска приложения...

В любом случае спасибо, было полезно.

Уберите из проекта Firebase Performance и получите ещё прирост.

Я вдруг понял, что ничего не понимаю...

Очень-очень тупой вопрос: когда я скачиваю exe на компьютер он же уже скомпилированный? Я запускаю бинарник и работаю.

На андроид не так? Приложение компилируется на конечном устройстве?

На андроид не так, как с .exe

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

Сам процесс компиляции будет зависеть от типа виртуальной машины и какой тип компилятора используется
Если это, например, ART и используется чистая AOT-компиляция, то весь код приложения будет скомпилирован в процессе установки его на устройство, то есть буквально на конечном устройстве, как вы и говорите
Если другой тип компилятора, то в мелочах по другому, это в статье я описал :)

.exe файлы могут быть не скомпилированными. Например .NET приложение, написанное на C# можно засунуть в exe, но внутри будет код MSIL, который потом тоже надо будет интерпретировать в рантайме.

Спасибо за уточнение)
Так как я не знаком с устройством .exe, не мог знать наверняка

Спасибо, было полезно узнать что то новое для себя)

Отличная статья, огромное спасибо!

Пара вопросов, если можно:

  1. Какой прирост скорости получился при использовании продвинутого сценария?

  2. Проверяли ли вы что может произойти если например поменяется флоу экранов на старте, для которого сгенерирован baseline profile, но при этом не будет актуализирован код в BaselineProfileGenerator? В таком случае просто не сработает оптимизация или может быть какое то неконсистентное состояние или креш?

Спасибо, рад, что статья понравилась :)

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

  2. Если я правильно понял вопрос, то если будет рассинхрон между тем, что содержится в baseline profile от актуального флоу экранов, то, если я правильно понимаю из презентации с Google I/O, оптимизация не сработает для тех участков кода, которые не содержатся в профиле. Там такой механизм, что скомпиленный код из профилей в файлах .odex комбинируется с байткодом из .dex файлов, и оно применяется на старте. Если эти скомпилированные куски оказались не нужны, то и импакта на производительность в этом случае будет мало.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий