холодный старт приложения что такое

«Холодный» запуск Android-приложения

Всем приветъ! Давно ничего не писал.

Это будет серия постов о процессе «холодного» запуска Android приложения, с момента нажатия на иконку и до создания процесса приложения.

Общая схема

Открывая «окно»…

Перед тем как запустить новый процесс приложения, system_server создает стартовое окно используя метод PhoneWindowManager.addSplashScreen():

Стартовое окно это то, что пользователь будет видеть пока запускается само приложение. Окно будет отображаться до тех пор пока не будет запущена Activity и не будет отрисован первый кадр. То есть пока не будет завершен «холодный» запуск. Пользователь может видеть данное окно длительное время, поэтому постарайтесь сделать его приятным.

Содержимое стартового окна берется из drawable-ресурсов windowSplashscreenContent и windowBackground запускаемого Activity. Банальный пример такого окна:

Если пользователь восстанавливает Activity из режима последнего экрана(Recent screen), при этом на нажимая на иконку приложения, то system_server вызывает метод TaskSnapshotSurface.create(), чтобы создать стартовое окно из уже сделанного скриншота.

Как только стартовое окно показано пользователю, system_server готов запустить процесс приложения и вызывает метод ZygoteProcess.startViaZygote():

В коде видно, что метод ZygoteProcess.zygoteSendArgsAndGetResult() отправляет аргументы запуска через сокет Zygote-процессу.

«Разделение» Zygote-ы

Каждый процесс приложения запускается с помощью форкания(разделения) от существующего Zygote-процесса…

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

Когда система загружается процесс Zygote стартует и выполняет метод ZygoteInit.main():

Как вы видите метод ZygoteInit.main() делает 2 важные вещи:

На заметку: Начиная с Android 10 есть оптимизационная фича под названием Unspecialized App Process, которая имеет пул не специализированных Zygote-процессов, для еще более быстрого запуска приложений.

Приложение запустилось!

После форка дочерний процесс запускает метод RuntimeInit.commonInit(), который устанавливает дефолтный UncaughtExceptionHandler. Далее, процесс запускает метод ActivityThread.main():

Тут происходят две интересные вещи:

Контроль над приложением

В процессе system_server метод ActivityManagerService.attachApplication() вызывает метод ActivityManagerService.attachApplicationLocked(), который завершает настройку запускаемого приложения:

Парочка ключевых выводов:

Давайте немного подробно разберем 3-ий пункт и узнаем что и как происходит при загрузке компонентов и ресурсов приложения. Порядок шагов такой:

Эпилог

Мы начали изучать «холодную» загрузку с очень обще-абстрагированного уровня:

Теперь мы знаем, что происходит «под капотом»:

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

Источник

Русские Блоги

Холодный запуск приложения, запуск горячего старта и оптимизация реализации запуска для решения проблемы белого экрана

[Заявление Blogger] Добро пожаловать в обзор, пожалуйста, не перепечатывайте без разрешения, спасибо!

· Введение

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

Холодный запуск: приложение запускается в этом состоянии после его закрытия в фоновом режиме. Этот метод запуска называется холодным запуском.

Горячий старт: это означает, что приложение не убивается в фоновом режиме и все еще работает в фоновом режиме. Обычно мы снова открываем приложение. Этот метод запуска называется горячим стартом.

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

Давайте посмотрим на эффект белого экрана (фактически, в тот момент, когда я нажал, это был уже белый экран. Симулятор может быть экранирован, что очень интуитивно понятно на мобильном телефоне)

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

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

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

Затем примените эту тему к нужным нам действиям, таким как моя SplashActivity:

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

Примечание. Наша SplashActivity не выполняет инициализацию и компоновку, просто откройте нашу MainActivity непосредственно в onCreate. В противном случае, если вы проведете слишком много времени в SplashActivity, он будет застревать на заставке на долгое время перед входом, и наше второе открытие изменит вкус.

Давайте поговорим о нашей реализации горячего старта. Обычно, когда мы нажимаем кнопку «Назад», жизненный цикл действия выполняется onStop, onDestory-> onCreate. Вызвала нас, чтобы попытаться быть уничтоженным и воссозданным. Тем не менее, мы нажимаем кнопку домой по-другому. Жизненный цикл действия будет выполняться onStop-> onReStart, поэтому горячее начало заключается в замене кнопки домой на кнопку назад. На самом деле, приложение находится в фоновом режиме, поэтому, когда вы снова Когда вы нажмете, чтобы открыть приложение, оно запустится немедленно.

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

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

· Идея для оптимизированного запуска:

Это тот тип мышления, который я видел давным-давно: когда речь идет о страницах-заставках, объясните их вместе. Он использует EventBus, и вместо загрузки различных конфигураций и библиотек при создании приложения сначала отображается страница с заставкой. На странице заставки используйте EventBus для запуска загрузки различных конфигураций и библиотек (в приложении). После загрузки этих библиотек используйте EventBus для повторной отправки событий в основной интерфейс.

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

Наш журнал также может очень хорошо объяснить порядок их выполнения, что успешно подтверждает правильность нашего мышления.

Источник

Как уменьшить время холодного старта Android-приложения на 28%

Аншу Рустаги из команды разработки приложения Redfin рассказал, как им удалось значительно сократить время холодного старта Android-приложения.

Новое — слева, старое — справа

С первого квартала прошлого года команда приложений Redfin много работала над измерением и улучшением производительности мобильных приложений для iOS и Android. Благодаря нескольким простым решениям мы улучшили время «холодного старта» на 28%.

Что такое холодный старт

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

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

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

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

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

Покажите мне результат!

Последние пару кварталов мы отслеживали время холодного старта в statsD. Вот наши показатели медианы и 90-го процентиля за последнюю неделю:

Это огромное улучшение по сравнению с первым кварталом:

Как только в нашем приложении открывается экран карты, оно, по сути, становится обёрткой для Google Maps SDK. Поэтому мы сравниваем свои показатели с показателями приложения Google Карты и стремимся им соответствовать. На Nexus 5x мы улучшили время холодного старта от 157% показателя Карт до 112%.

Что мы сделали?

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

Децентрализация AppState — 500 мс

При запуске нашего приложения мы проводим десериализацию AppState, где содержатся все сохраненные данные, необходимые для повторного запуска приложения с неизменным пользовательским опытом. Там содержится все: от переключателей функций (мы называем их «вышибалами») до входа в систему и отслеживания данных; наше приложение зависит от доступности AppState. Как вы можете представить, это огромное количество данных. Мы внесли два улучшения, чтобы ускорить десериализацию:

Внедрение зависимостей Dagger — 300 мс

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

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

Кэширование данных для трекинга — 300 мс

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

Разделение контента на экране информации о доме — 500 мс

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

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

Что дальше?

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

Источник

Как не дать холодному запуску Android приложения отпугнуть пользователей

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

Какие виды запуска приложения существуют

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

Холодный старт

Когда пользователь нажимает значок приложения,
событие click переводится в startActivity(intent) и направляется в ActivityManagerService через Binder IPC, а ActivityManagerService выполняет несколько шагов:

Горячий старт

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

Если пользователь возвращает действие с экрана «Недавние» вместо нажатия значка средства запуска, то процесс вызывает TaskSnapshotSurface.create() для создания начального окна, в котором отображается сохраненный снимок действия.

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

Как сделать холодный запуск более приятным и не допустить плохой юзер экспириенс?

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

Далее заполнитель необходимо задать в теме приложения (values >themes.xml section) :

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

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

Теперь можно запустить проект и увидеть результат:

Источник

СОДЕРЖАНИЕ

Затронутые системы

Возможны три случая холодного старта:

Новое сообщество

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

Новый предмет

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

С другой стороны, алгоритмы контентной фильтрации теоретически гораздо менее подвержены проблеме нового элемента. Поскольку рекомендатели на основе контента выбирают, какие элементы рекомендовать, в зависимости от характеристик, которыми они обладают, даже при отсутствии взаимодействия с новым элементом, все же его функции позволят сделать рекомендацию. Это, конечно, предполагает, что новый элемент уже будет описан своими атрибутами, что не всегда так. Рассмотрим случай так называемых редакционных характеристик (например, режиссер, состав, название, год), они всегда известны, когда элемент, в данном случае фильм, добавляется в каталог. Однако другие виды атрибутов могут не быть, например, функциями, извлеченными из пользовательских обзоров и тегов. Алгоритмы на основе контента, основанные на функциях, предоставляемых пользователем, также страдают от проблемы с холодным запуском элементов, поскольку для новых элементов, если нет (или очень мало) взаимодействий, также не будут доступны (или очень мало) пользовательских обзоров и тегов.

Новый пользователь

Стратегии смягчения последствий

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

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

Завершение профиля

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

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

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

Отображение функций

Взвешивание гибридных функций

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

Дифференциация весов регуляризации

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

Источник