android runtime что это
ART и Dalvik: Как оно работает
Внутри последней итерации операционной системы Android нашлось место для многих изменений и усовершенствований. Большинство из них сразу же бросается в глаза даже рядовому пользователю данной системы. Это, конечно же, установка в качестве стандартного месседжера приложения Hangouts, переделанное меню набора номеров и добавление клавиатуры Emoji. Бывалые же приверженцы Android наверняка ощутят прилив производительности в сравнении с более старыми ее релизами. Однако не обошлось и без скрытых сторон, которые, согласно логике, должны представлять интерес лишь для разработчиков. Впрочем, значимость одного из подобных нововведений особенно велика. Кроме того, вскоре оно коснется каждого из нас, а потому умолчать о его подробностях было бы просто преступлением.
Наверное, многие из вас хотя бы краем уха слышали о том, что в Android KitKat появился особый режим. Суть его заключается в более быстром запуске приложений и в более стабильном и плавном их выполнении. Возможно, попытки разобраться в данном вопросе самостоятельно не были увенчаны успехом. Оно и неудивительно: слова «виртуальная машина» и «компиляция» способны испугать кого-угодно, особенно, если информация потребляется из англоязычного источника. Для решения данной проблемы мы решили разобраться в сути вопроса самостоятельно, изложив его в максимально доступном виде.
Немного базовых понятий
Прежде чем ознакомиться с сутью нововведения, необходимо получить представление о некоторых деталях. Первая из них — среда выполнения приложений. Говоря простым языком, пресловутое понятие является сборником инструкций, которые выполняются во время работы того или иного приложения. Инструкции, в свою очередь, осуществляют перевод программного кода в код, который в состоянии запустить система. Соответственно, абсолютно все компьютерные языки нуждаются в определенной среде выполнения ради запуска приложений, написанных на них.
В качестве среды выполнения в нашей любимой операционной системе Android используются виртуальные машины, первая из которых — Dalvik — заработала еще в далеком 2007 году. Именно ей мы и обязаны периодическими зависаниями интерфейса и порой медлительными запусками приложений. Впрочем, данная проблема уже скоро может стать частью истории.
Почему именно виртуальные машины?
Данный тип среды выполнения имеет два безоговорочных плюса, которые облегчают жизнь не только разработчикам, но и нам, пользователям. Первое достоинство — защита системы. Виртуальная машина неслучайно называется виртуальной: ее работа абсолютно изолирована от операционной системы. Соответственно, ошибка или банальное зависание никак не скажется на работоспособности вашего устройства.
Второй плюс — кросплатформенность. Виртуальная машина сможет запустить приложение, даже если оно создано на PC.
Преимущества и недостатки Dalvik
Dalvik, как и все в этом мире, неидеальна. Причиной периодических подергиваний интерфейса является тип преобразования кода приложения в аппаратный. Данная машина проделывает это в прямом эфире, а называется такой тип компиляции Just-In-Time. Соответственно, предугадать появление багов практически невозможно, поскольку подобное может произойти в любой момент. Особенно велика вероятность подобного во время первого запуска, когда часть преобразованного кода даже не сохранена в кеше.
Проблема медлительности первого запуска, кстати, вовсе не случайна. Подобное происходит из-за того, что системе необходимо собрать воедино все необходимые для запуска приложения файлы и загрузить ими оперативную память. В конкретном случае больше всего страдают устройства с малым количеством оперативной памяти, для которых процесс загрузки чреват если не вылетом приложения, то хотя бы заметными задержками его выполнения.
Компиляция «на ходу» значительно нагружает процессор, однако одновременно с этим позволяет разработчикам не заниматься оптимизацией кода для каждого отдельного процессора и прочих составляющих устройства.
Исправить вышесказанное призвана новая виртуальная машина, которая успела отметиться далеко не самым замысловатым названием — Android Runtime. Или же сокращенно — ART.
Преимущества и недостатки ART
Новая виртуальная машина обрела жизнь вместе с Android 4.4 KitKat, однако на презентации ей не уделили должного внимания. Причиной этого является то, что ART все еще находится на экспериментальной стадии. Впрочем, хотя и Dalvik используется в качестве машины по умолчанию, переключиться на Android Runtime можно уже сейчас.
Однако не спешите это делать. Сначала необходимо ознакомиться с особенностям новой версии.
Наиболее заметным преимуществом ART является новый тип компиляции, который получил название Ahead-Of-Time. Читатели, знающие английский язык, наверняка сразу же догадались, в чем дело. А дело в том, что процесс преобразования кода в новой версии осуществляется до запуска приложения — еще во время установки. Соответственно, сразу же вырисовываются несколько минусов, о которых, справедливости ради, стоит упомянуть. Это, во-первых, более длительный процесс установки, а во-вторых, больший объем конечного размера приложения. Еще один недостаток является следствием незрелости ART: виртуальная машина на данный момент работает далеко не со всеми приложениями.
Впрочем, список заслуг куда более значимый. Это, к примеру, более плавная работа интерфейса и более быстрая загрузка приложений. Кроме того, поскольку процесс компиляции осуществляется лишь единожды, он не будет в дальнейшем нагружать процессор, что станет причиной улучшенной автономности устройства.
Переключиться на виртуальную машину ART в меню разработчика могут владельцы устройств под управлением Android 4.4 с процессором Snapdragon.
Развитие данной технологии имеет огромный потенциал. На карте стоит развенчание мифа о медлительности и нестабильности Android, что не только порадует владельцев устройств под ее управлением, но и ликвидирует наиболее серьезный аргумент в спорах со стороны приверженцев iOS.
На данный момент представители компании Google не сообщают о сроках окончательного внедрения и замены Dalvik на ART. Хочется верить, что это произойдет уже очень скоро.
Android изнутри: сравнение Dalvik и ART
Привет, Хабр! Около полугода назад я публиковал подробный «гайд» по JVM. Пост, в целом, зашел, а в комментариях спросили, не планируется ли “чего-то по андроиду”. Наконец, у меня дошли руки.
В этом посте поговорим о среде выполнения в Android. В частности, я постараюсь кратко, но емко изложить, чем отличается ART и Dalvik, и как со временем улучшились средства разработки в Android. Тема явно не новая, но, надеюсь, придется кстати тем, кто только начинает вникать. Кому интересно — добро пожаловать под кат.
Виртуальная машина
Сначала, давайте разберемся чем отличается JVM от DVM.
Java Virtual Machine — виртуальная машина, способная выполнять байт-код Java независимо от базовой платформы. Она опирается на принцип “Write once, run anywhere”. Байт-код Java может быть запущен на любой машине, способной поддерживать JVM.
Можно сказать, что Dalvik — это среда для выполнения компонентов операционной системы Android и пользовательских приложений. Каждый процесс выполняется в своём, изолированном адресном пространстве. Когда пользователь запускает приложение (либо операционная система запускает один из своих компонентов), ядро виртуальной машины Dalvik (Zygote Dalvik VM) создает отдельный, защищенный процесс в общей памяти, в котором непосредственно разворачивается VM, как среда для запуска приложения. Другими словами, изнутри Android выглядит как набор виртуальных машин Dalvik, в каждой из которых исполняется приложение.
Подробно об архитектуре DVM можно почитать тут.
Android Dexer
Изначально, class-файлы преобразовывались в dex-файлы с помощью встроенного DX-компилятора. Но начиная с Android Studio 3.1 и далее, компилятором по умолчанию стал D8. По сравнению с DX-компилятором, D8 компилирует быстрее и выводит dex-файлы меньшие по размеру, при этом обеспечивая более высокую производительность приложения во время исполнения. Полученный таким образом байт-код dex подвергается минификации с помощью open-source утилиты ProGuard. В итоге, мы получаем тот же dex-файл, но только меньше. Далее этот dex-файл используется для сборки apk и, наконец, для развертывания на устройстве Android.
Но следом за D8 в 2018 году пришел R8, который, по сути, является тем же D8, только с дополнениями.
При работе с Android Studio 3.4 и Android Gradle 3.4.0 plugin или выше, Proguard больше не используется для оптимизации кода во время компиляции. Вместо этого плагин работает по умолчанию с R8, который сам выполняет Code shrinking, Optimisation и Obfuscation. Хотя R8 предлагает только подмножество функций, предоставляемых Proguard, он позволяет совершить процесс преобразования Java байт-кода в dex-байт-код единоразово, что еще больше сокращает время сборки.
R8 и сокращение кода
Как правило, приложения используют сторонние библиотеки, такие как Jetpack, Gson, Google Play Services. Когда мы используем одну из этих библиотек, часто в приложении используется только малая часть каждой отдельной библиотеки. Без Code shrinking, весь код библиотеки сохраняется в вашем приложении.
Бывает так, что для улучшения читаемости и удобства поддержки приложения разработчики используют подробный код. Например, могут быть использованы значимые имена переменных и шаблон проектирования для того, чтобы другим было удобнее разобраться в коде. Но шаблоны, как правило, приводят к бОльшему объему кода, чем это необходимо.
В этом случае R8 приходит на помощь. Он позволяет существенно уменьшить размер приложения, оптимизируя размер даже того кода, который действительно используется приложением.
В качестве примера, ниже преведены цифры из доклада Shrinking Your App with R8, который был представлен на Android Dev Summit ’19:
А вот так выглядело сравнение эффективности R8 на этапе выпуска бета-версии (взято из источника Android Developers Blog):
Детальнее можно ознакомиться в оф документации и докладе.
ART vs DVM в Android
DVM была спроектирована именно для мобильных устройств и использовалась как виртуальная
машина для запуска андроид приложений вплоть до Android 4.4 Kitkat.
Начиная с этой версии, ART был представлен как среда выполнения, а в Android 5.0 (Lollipop) ART полностью заменил Dalvik.
Основное явное отличие ART от DVM состоит в том, что ART использует AOT компиляцию, а DVM — JIT компиляцию. Не так давно ART начал использовать гибрид AOT и JIT. Далее разберем это чуть подробнее.
И небольшая схема Dalvik vs ART:
JIT + AOT в ART
Среда выполнения Android (ART), начиная с Android 7, включает компилятор JIT с профилированием кода. JIT-компилятор дополняет AOT компилятор и повышает производительность во время выполнения, экономит место на диске и ускоряет обновления приложений и системы.
Происходит это по следующей схеме:
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android
Детальный анализ Android RunTime (ART) в Android L
Реверс малвари
На недавней конференции I/O компания Google официально огласила планы перехода в следующих версиях операционной системы Android на новую среду выполнения ART. Главным преимуществом ART перед Dalvik называли улучшенное энергопотребление.
При установке Java-код приложения сразу компилируется в машинный код (AOT-компиляция), тогда как Dalvik компилировал Java-код в свой байткод dex (Dalvik executable), а после запуска программы компилировал его в машинный код в реальном времени (JIT-компиляция). Поэтому ART экономит энергию. Правда, это происходит за счёт увеличения используемого пространства и замедления инсталляции приложений. Google уверяет, что замедление не критическое. Инновации вроде ART стали возможны благодаря увеличению объёма памяти в современных смартфонах.
ART полностью совместим с байткодом Dalvik, так что с точки зрения разработчиков ничего не изменилось: можно писать приложения такие же, как раньше. Новая среда при установке приложения создаёт исполняемый файл формата ELF с машинным кодом.
В ART значительно улучшена работа сборщика мусора, из-за постоянных включений которого раньше графический интерфейс «подтормаживал», замирая на доли секунды. Теперь паузы на сборку мусора сокращены практически до нуля: вместо десятков или сотен миллисекунд большинство операций сборщика мусора теперь завершается примерно за 1 миллисекунду или чуть больше.
Обычно, когда какая-нибудь компания внедряет функции для улучшенного энергопотребления, речь идёт о небольших оптимизациях. Время работы от аккумуляторов увеличивают на несколько процентов. В случае с Android L (новая версия Android, где работает ART и сделаны другие улучшения) всё обстоит современно иначе. Независимые тесты показывают, что у Nexus 5 после апгрейда ОС время работы увеличилось с 345 до 471 минуты, то есть на 36%! Тест включал в себя бесконечное обновление веб-страницы в браузере при включенном WiFi.
Правда, есть вероятность, что экономия настолько велика только в случае интенсивного использования смартфона/планшета, когда ART проявляет себя во всей красе. Если же смартфон ничего не делает с включенным дисплеем (например, в режиме чтения книги), то время работы от аккумулятора, наверное, не сильно изменится.
Заметная разница произошла в производительности приложений. Большинство программ демонстрируют прибавку в скорости 50-80%, а некоторые ускоряются в два-три раза.
Экспериментальная версия ART появилась в Android KitKat 4.4 (его можно активировать через настройки для разработчика), а в будущем ART должен полностью заменить Dalvik и будет использоваться по умолчанию.
Производительность Android Runtime vs NDK
Разрабатывая игровой движок для Android, я был уверен, что нативный код C/C++ будет исполняться быстрее чем аналогичный код на Java. Это утверждение справедливо, но не для последних версий Android. Чтобы проверить почему так происходит, решил провести небольшое исследование.
Вот метод, написанный на Java:
Вот метод на C/C++ (осознанно не освобождаю память для чистоты сравнения с Java GC):
Вот метод, который вызывает тесты Java:
Вот такие результаты получились на разных устройствах
Samsung Galaxy Tab E (Android 4.4.4) :
Java time: 2 166 748 ns
C/C++ time: 396 729 ns (C/C++ быстрее в 5 раз )
Prestigio K3 Muze (Android 8.1):
Java time: 3 477 001ns (первый запуск)
C/C++ time: 547 692ns (C/C++ в 6 раз быстрее),
НО при повторном запуске теста Java выполняется лишь на 30-40% медленнее (разогрев?).
Samsung Galaxy S21 Ultra (Android 11):
Java time: 111 000ns
C/C++ time: 121 269ns
Интересно: Java на 9% медленнее при первом запуске и 40-50% быстрее C/C++ при втором.
Включение флагов оптимизации компилятора CLang (-O3) делают код C/C++ быстрее на
30-35% (Prestigio K3 Muze Android 8.1) чем Java код, даже при втором запуске.
Но на Smasung Galaxy S21 Ultra (Android 11) Java код выполняется на 10-20% быстрее чем нативный С/C++ код скомпилированный CLang с включенными флагами оптимизации (-O3). Это чуток взорвало мой мозг.
p.s. Оба теста запускаются последовательно в одном потоке одного процесса, поэтому предполагаю, что они используют одно и то же ядро CPU.
И тут возник вопрос, почему Java код на последних Android устройствах выполняется быстрее аналогичного C/C++ кода? Как это вообще возможно?
А возможно это следующим способом. В Android Runtime наряду с Ahead-of-Time компиляцией Java кода в нативный код, по прежнему работает механизм Just-In-Time компиляции на основе собранной статистики первого запуска приложения. Где имея данные о часто выполняемых участках кода можно провести более эффективные оптимизации. Вот так примерно говорят в документации:
The JIT compiler complements ART’s current ahead-of-time (AOT) compiler and improves runtime performance. Although JIT and AOT use the same compiler with a similar set of optimizations, the generated code might not be identical. JIT makes use of runtime type information can do better inlining and makes on stack replacement (OSR) compilation possible, all of which generate slightly different code.
Есть ли смысл переписывать приложения на Java на NDK C/C++ для производительности?
Вы портируете имеющееся приложение на C/C++ на Android
Вы хотите использовать С/C++ библиотеки не доступные Java
Вы хотите использовать API недоступные в Android SDK
Ранее мы уже писали о том, что у виртуальной машины Dalvik в KitKat появился конкурент в виде ART. Настало время более подробно рассказать о том, что это такое, и какие преимущества ждут Android пользователей в скором времени.
Таким образом, ART позволяет запускать приложения на разном железе (wiz. ARM,x86) без предварительной адаптации со стороны разработчиков. Помимо этого на запуск приложений в новых условиях уходит в два раза меньше времени. Не обошлось и без недостатков, один из которых связан с принципом работы в условиях ART. Данная среда приводит к тому, что вся необходимая информацию переводится в машинно-ориентированный язык еще во время установки приложений (AOT компиляция), а это требует дополнительного времени, из-за чего весь процесс установки очень сильно растягивается, а приложения занимают больше места, так как все время скомпилированы.
Хоть ART и присутствует в Android 4.4 KitKat, но по умолчанию по-прежнему используется виртуальная машина Dalvik. ART же все еще находится на стадии разработки, но каждый желающий уже может активировать новую технологию:
Отметьте себе, что переходить на ART в случае с кастомными ROM’ами не рекомендуется, так как может возникнуть проблема несочетания с текущей версией Gapps приложений, что приведет к ошибкам, вылетам системы и сделает работу на устройстве невозможной.
Влияние на разработчиков
Вероятнее всего разработчикам различных кастомных образов рекавери придется также предусмотреть новую опцию, аналогичную той, которая позволяла очищать Dalvik кэш.
Заключение
Переход на ART приведет к тому, что производительность Android устройств возрастет, а количество лагов уменьшится. Пока мы видим лишь пробный вариант новой среды выполнения приложений, но это уже очень серьезный шаг навстречу новым изменениям. Как скоро переход будет осуществлен окончательно – пока не известно.