- Android от А до Я: ART — новая среда выполнения приложений на Android 4.4 KitKat (замена Dalvik)
- Влияние на разработчиков
- Заключение
- ART или Dalvik на Android — что это такое, что лучше, как включить
- Основное отличие среды ART
- Как на самом деле и что лучше, ART или Dalvik?
- Как включить ART на Android
- Среда выполнения Android — Android Runtime
- СОДЕРЖАНИЕ
- Обзор
- Android изнутри: сравнение Dalvik и ART
- Виртуальная машина
- Android Dexer
- R8 и сокращение кода
- ART vs DVM в Android
- JIT + AOT в ART
Android от А до Я: ART — новая среда выполнения приложений на Android 4.4 KitKat (замена Dalvik)
Ранее мы уже писали о том, что у виртуальной машины Dalvik в KitKat появился конкурент в виде ART. Настало время более подробно рассказать о том, что это такое, и какие преимущества ждут Android пользователей в скором времени.
ART (аббревиатура термина «Android Runtime«) — это новая среда выполнения приложений, написанная на C/C++, которая отличается от существующей в Android виртуальной машины Dalvik тем, что все приложения в системе уже скомпилированы, а значит, потребность в JIT-компиляторе отпадает.
Таким образом, ART позволяет запускать приложения на разном железе (wiz. ARM,x86) без предварительной адаптации со стороны разработчиков. Помимо этого на запуск приложений в новых условиях уходит в два раза меньше времени. Не обошлось и без недостатков, один из которых связан с принципом работы в условиях ART. Данная среда приводит к тому, что вся необходимая информацию переводится в машинно-ориентированный язык еще во время установки приложений (AOT компиляция), а это требует дополнительного времени, из-за чего весь процесс установки очень сильно растягивается, а приложения занимают больше места, так как все время скомпилированы.
Хоть ART и присутствует в Android 4.4 KitKat, но по умолчанию по-прежнему используется виртуальная машина Dalvik. ART же все еще находится на стадии разработки, но каждый желающий уже может активировать новую технологию:
Settings -> Developer options -> Select runtime
Если вы такие решили протестить новую среду, то не стоит забывать, что первая загрузка может продлиться до 20 минут, а то и больше: системе потребуется много времени, чтобы перейти к новым принципам работы. Библиотека libdvm.so будут заменена на libart.so, а файлы ODEX на OAT. Последние можно найти здесь .
Отметьте себе, что переходить на ART в случае с кастомными ROM’ами не рекомендуется, так как может возникнуть проблема несочетания с текущей версией Gapps приложений, что приведет к ошибкам, вылетам системы и сделает работу на устройстве невозможной.
Так как в Android 4.4 KitKat мы имеем дело лишь с прототипом новой среда выполнения приложений, то делать выводы, исходя из теперешних практических результатов, слишком рано. ART еще абсолютно не оптимизирована, но уже можно говорить о том, что в новых условиях приложения будут шустрее, анимация станет более плавной, а реакция на прикосновение к тачскрину улучшится. Помимо этого ART сможет сократить нагрузку на процессор: для работы большинства процессов необходимо будет задействовать лишь часть ядер. Это приведет к более эффективному использованию ARM архитектуры big.LITTLE, а значит, энергопотребление Android устройств удастся сократить, а время работы — увеличить.
Фактически ART включает в себя два бекенд компилятора. Как первый, так и второй — это AOT (Ahead-of-Time) компиляторы, причем один из них используется для распознавания машинного кода и работы с GCC, cl.exe (LLVM компилятор).
Влияние на разработчиков
Как ни странно, но на создание приложений переход на ART не должен отразиться. Специфика новой среды такова, что ART читает байт-код для Dalvik, а значит, новые знания и умения добывать не придется. Работа будет осуществляться все с тем же Java байт-кодом. С другой стороны у AOT компиляции есть один недостаток: ошибки, возникающие на разном железе. В связи с этим разработчикам придется тестировать свои приложения на большем количестве Android устройств. При этом прекомпиляция позволит сократить возможный объем работы, а создавать приложения с ART можно будет на любом языке с LLVM фронтэндом. Отдельно стоит отметить доступ к машинному коду: у разработчиков будет больше возможностей, но в случае ошибки готовый продукт может нанести вред Android устройству. Последний важный момент связан с использованием JNI — стандартного механизма для запуска кода под управлением виртуальной машины Java, с которым связано обеспечение двоичной совместимости.
Вероятнее всего разработчикам различных кастомных образов рекавери придется также предусмотреть новую опцию, аналогичную той, которая позволяла очищать Dalvik кэш.
Заключение
Переход на ART приведет к тому, что производительность Android устройств возрастет, а количество лагов уменьшится. Пока мы видим лишь пробный вариант новой среды выполнения приложений, но это уже очень серьезный шаг навстречу новым изменениям. Как скоро переход будет осуществлен окончательно – пока не известно.
Источник
ART или Dalvik на Android — что это такое, что лучше, как включить
Google представила новую среду выполнения приложений как часть обновления Android 4.4 KitKat. Теперь, помимо виртуальной машины Dalvik, на современных устройствах с процессорами Snapdragon появилась возможность выбрать среду ART. (Если вы попали на эту статью с целью узнать, как включить ART на Android, пролистайте ее к окончанию, там дана эта информация).
Что такое среда выполнения приложений и причем тут виртуальные машины? В Android, для выполнения приложений, которые вы скачиваете в виде файлов APK (и которые не являются компилированным кодом) используется виртуальная машина Dalvik (по умолчанию, на данный момент времени) и задачи по компиляции ложатся именно на нее.
В виртуальной машине Dalvik для компиляции приложений используется подход Just-In-Time (JIT), подразумевающий компиляцию непосредственно при запуске или же при определенных действиях пользователя. Это может приводить к долгому времени ожидания при запуске приложения, «тормозам», более интенсивному использованию RAM.
Основное отличие среды ART
ART (Android RunTime) — новая, пока еще экспериментальная виртуальная машина, представленная в Android 4.4 и включить ее пока можно лишь в параметрах разработчика (ниже будет показано, как это сделать).
Главное отличие ART от Dalvik — подход AOT (Ahead-Of-Time) при выполнении приложений, что в общих чертах означает предварительную компиляцию устанавливаемых приложений: таким образом, первоначальная установка приложения будет занимать более продолжительное время, они будут занимать больше места в хранилище Android устройства, однако их последующий запуск будет происходить быстрее (оно уже скомпилированно), а меньшее использование процессора и оперативной памяти в связи с необходимостью повторной компиляции может, в теории, приводить к меньшему потреблению энергии.
Как на самом деле и что лучше, ART или Dalvik?
В Интернете есть уже множество различных сравнений работы Android устройств в двух средах и результаты разнятся. Один из самых масштабных и подробных таких тестов выложен на androidpolice.com (англ.):
Суммируя результаты, можно сказать, что очевидных преимуществ на данный момент времени (нужно учитывать, что работа над ART продолжается, эта среда пока только на экспериментальной стадии) у ART нет: в некоторых тестах работа с использованием этой среды показывает лучшие результаты (особенно в том, что касается производительности, но не во всех ее аспектах), а в некоторых других особых преимуществ незаметно или же Dalvik впереди. Например, если говорить о времени автономной работы, то вопреки ожиданиям, Dalvik показывает практически равные результаты с ART.
Общий вывод большинства тестов — очевидной разницы при работе что с ART, что с Dalvik нет. Однако, новая среда и используемый в ней подход выглядят многообещающе и, возможно в Android 4.5 или Android 5 такая разница будет очевидна. (Более того, Google, возможно, сделает ART средой, используемой по умолчанию).
Еще пара моментов, на которые следует обратить внимание, если вы решите включить среду ART вместо Dalvik — некоторые приложения могут работать неправильно (или не работать вообще, например WhatsApp и Titanium Backup), а полная перезагрузка Android может занять 10-20 минут: то есть, если вы включили ART и после перезагрузки телефона или планшета он завис, ждите.
Как включить ART на Android
Для того, чтобы включить среду ART, вы должны иметь Android телефон или планшет с версией ОС 4.4.x и процессором Snapdragon, например, Nexus 5 или Nexus 7 2013.
Сначала необходимо включить режим разработчика на Android. Для этого, зайдите в настройки устройства, перейдите в пункт «О телефоне» (О планшете) и несколько раз тапните по полю «Номер сборки», пока не увидите сообщение о том, что стали разработчиком.
После этого в настройках появится пункт «Для разработчиков», а там — «Выберите среду», где и следует установить ART вместо Dalvik, если у вас есть такое желание.
Источник
Среда выполнения Android — Android Runtime
Разработчики) | |
---|---|
Репозиторий | android .googlesource .com / платформа / искусство / |
Написано в | C , C ++ |
Операционная система | Android |
Тип | Среда выполнения |
Лицензия | Лицензия Apache 2.0 |
Веб-сайт | источник .android .com / devices / tech / dalvik / art .html |
Android Runtime ( ART ) — это среда выполнения приложений, используемая операционной системой Android . Заменяя Dalvik , виртуальную машину процесса, изначально используемую Android, ART выполняет преобразование байт-кода приложения в собственные инструкции , которые позже выполняются средой выполнения устройства.
СОДЕРЖАНИЕ
Обзор
Android 2.2 «Froyo» привнес в Dalvik JIT-компиляцию на основе трассировки , оптимизируя выполнение приложений за счет постоянного профилирования приложений каждый раз, когда они запускаются, и динамической компиляции часто выполняемых коротких сегментов их байт-кода в собственный машинный код . В то время как Dalvik интерпретирует остальную часть байт-кода приложения, собственное выполнение этих коротких сегментов байт-кода, называемых «трассировками», обеспечивает значительное улучшение производительности.
В отличие от Dalvik, ART вводит использование предварительной компиляции (AOT) путем компиляции целых приложений в собственный машинный код после их установки. Исключая интерпретацию Dalvik и JIT-компиляцию на основе трассировки, ART повышает общую эффективность выполнения и снижает энергопотребление, что приводит к повышению автономности работы от батареи на мобильных устройствах . В то же время ART обеспечивает более быстрое выполнение приложений, улучшенные механизмы выделения памяти и сборки мусора (GC), новые функции отладки приложений и более точное высокоуровневое профилирование приложений.
Для обеспечения обратной совместимости ART использует тот же входной байт-код, что и Dalvik, предоставляемый через стандартные файлы .dex как часть файлов APK , в то время как файлы .odex заменяются исполняемыми файлами в формате ELF. Как только приложение скомпилировано с помощью установленной на устройстве утилиты dex2oat ART , оно запускается исключительно из скомпилированного исполняемого файла ELF; в результате ART устраняет различные накладные расходы на выполнение приложений, связанные с интерпретацией Dalvik и JIT-компиляцией на основе трассировки. Недостатком ART является то, что при установке приложения для компиляции требуется дополнительное время, а приложения занимают немного больше вторичного хранилища (обычно флэш-памяти ) для хранения скомпилированного кода.
Android 4.4 «KitKat» предоставляет предварительную версию технологии ART, включая его в качестве альтернативной среды выполнения и сохраняя Dalvik в качестве виртуальной машины по умолчанию. В последующем крупном выпуске Android, Android 5.0 «Lollipop» , Dalvik был полностью заменен на ART.
Android 7.0 «Nougat» переключил свою среду выполнения Java с прекращенной Apache Harmony на OpenJDK , представив JIT-компилятор с профилированием кода для ART, что позволяет постоянно улучшать производительность приложений Android при их запуске. Компилятор JIT дополняет текущий опережающий компилятор ART и помогает повысить производительность во время выполнения и сэкономить место для хранения за счет компиляции только некоторых частей приложений.
Источник
Android изнутри: сравнение Dalvik и ART
Привет, Хабр! Около полугода назад я публиковал подробный «гайд» по JVM. Пост, в целом, зашел, а в комментариях спросили, не планируется ли “чего-то по андроиду”. Наконец, у меня дошли руки.
В этом посте поговорим о среде выполнения в Android. В частности, я постараюсь кратко, но емко изложить, чем отличается ART и Dalvik, и как со временем улучшились средства разработки в Android. Тема явно не новая, но, надеюсь, придется кстати тем, кто только начинает вникать. Кому интересно — добро пожаловать под кат.
Виртуальная машина
Сначала, давайте разберемся чем отличается JVM от DVM.
Java Virtual Machine — виртуальная машина, способная выполнять байт-код Java независимо от базовой платформы. Она опирается на принцип “Write once, run anywhere”. Байт-код Java может быть запущен на любой машине, способной поддерживать JVM.
Компилятор Java преобразует .java файлы в class-файлы (байт-код). Байт-код передается JVM, который компилирует его в машинный код для исполнения непосредственно на CPU.
- Имеет стековую архитектуру: в качестве структуры данных, куда помещаются и хранятся методы, используется стек. Он работает по схеме LIFO или “Last in — First Out” или “Последним вошел, первым вышел”.
- Может запускать только class-файлы.
- Использует JIT-компилятор.
Dalvik Virtual Machine (DVM) — виртуальная Java машина, разработанная и написанная Дэном Борнштейном (англ. Dan Bornstein) и другими, как часть мобильной платформы Android.
Можно сказать, что Dalvik — это среда для выполнения компонентов операционной системы Android и пользовательских приложений. Каждый процесс выполняется в своём, изолированном адресном пространстве. Когда пользователь запускает приложение (либо операционная система запускает один из своих компонентов), ядро виртуальной машины Dalvik (Zygote Dalvik VM) создает отдельный, защищенный процесс в общей памяти, в котором непосредственно разворачивается VM, как среда для запуска приложения. Другими словами, изнутри Android выглядит как набор виртуальных машин Dalvik, в каждой из которых исполняется приложение.
- Использует архитектуру на основе регистров: структура данных, куда помещаются методы, основана на регистрах процессора. За счет отсутствия операций POP и PUSH, команды в регистровой виртуальной машине выполняются быстрее аналогичных команд стековой виртуальной машины.
- Исполняет байт-код собственного формата: Android dexer (о нем поговорим ниже) преобразует class-файлы в формат .dex, оптимизированные для выполнения на Dalvik VM. В отличие от class-файла, dex-файл содержит сразу несколько классов.
Подробно об архитектуре DVM можно почитать тут.
Android Dexer
Разработчики Android знают, что процесс преобразования Java байткода в .dex байткод для Android Runtime является ключевым шагом в создании APK. Компилятор dex в основном работает “под капотом” в повседневной разработке приложений, но он напрямую влияет на время сборки приложения, на размер файла .dex и производительность во время выполнения.
Как уже упоминалось, сам dex-файл содержит сразу несколько классов. Повторяющиеся строки и другие константы, используемые в нескольких файлах классов, включаются только для экономии места. Байт-код Java также преобразуется в альтернативный набор команд, используемый DVM. Несжатый dex-файл обычно на несколько процентов меньше по размеру, чем сжатый архив Java (JAR), полученный из тех же файлов .class.
Изначально, 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. Далее разберем это чуть подробнее.
- Использует JIT компиляцию: всякий раз при запуске приложения,
- компилируется та часть кода, которая необходима для выполнения приложения. Остальная часть кода компилируется динамически. Это замедляет запуск и работу приложений, но уменьшает время установки.
- Ускоряет загрузку устройства, поскольку кеш приложения создается во время выполнения.
- Приложения, работающие на DVM, требуют меньше памяти, чем те, которые работают на ART.
- Уменьшает резерв батареи, увеличивая нагрузку на CPU.
- Dalvik является “устаревшим” и не используется на андроид версиях выше 4.4.
- Использует AOT компиляцию, то есть компилирует весь код во время установки приложения. Это ускоряет запуск и работу приложений, но требует большего времени установки.
- Замедляет загрузку устройства, так как кеш создается во время первой загрузки.
- Ввиду использования подхода AOT компиляции, требует больше памяти в сравнении с приложениями на DVM.
- Увеличивает резерв батареи, сокращая работу процессора из-за отсутствия компиляции при выполнении приложений.
- Улучшенная Garbage Collection или сборка мусора. Во времена использования Dalvik, сборщики мусора должны были осуществить 2 прохода по куче (heap), что и приводило к плохому UX. В случае с ART, такой ситуации нет: он чистит кучу один раз для консолидации памяти.
И небольшая схема Dalvik vs ART:
JIT + AOT в ART
Среда выполнения Android (ART), начиная с Android 7, включает компилятор JIT с профилированием кода. JIT-компилятор дополняет AOT компилятор и повышает производительность во время выполнения, экономит место на диске и ускоряет обновления приложений и системы.
Происходит это по следующей схеме:
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android
Источник