Среда выполнения android что это

Объяснение и сравнение сред выполнения Android

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

Мы в AddictiveTips всегда гордились тем, что упрощали технические концепции и давали ответы в терминах, приемлемых для обычного пользователя и новичка в технологиях. Следовательно, когда Google решил представить ART с Android 4.4 KitKat, мы увидели в этом возможность познакомить наших читателей с новой средой выполнения и помочь всем понять, о чем все это идет, и чем она отличается от виртуальной машины Dalvik, которая ART строится, чтобы заменить.

Что такое среда выполнения?

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

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

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

Зачем вообще использовать виртуальную машину?

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

• Виртуальные машины предоставляют изолированную среду для выполнения кода. Следовательно, даже если приложение содержит вредоносный фрагмент кода, который может повредить основную ОС, он не будет напрямую влиять на системные файлы, и, таким образом, основная ОС будет защищена от повреждения. Большим преимуществом является большая стабильность и надежность операционной системы.
• APK-файлы приложения, которые поставляются через Play Store (или любой другой источник, если на то пошло), представляют собой некомпилированные инструкции, которые разработчики полагаются на виртуальную машину для компиляции перед выполнением и запуска на устройстве. Это обеспечивает большую совместимость; если бы разработчик предоставил уже скомпилированный код, и он был скомпилирован для процессора на базе Snapdragon, например, он мог бы некорректно работать на чипе Tegra. Следовательно, эта компиляция на устройстве решает эту проблему.

Итак, что такое Dalvik и что с ним не так?

Это вопрос, который нужно задать, не так ли? Dalvik существует с момента запуска Android в 2007 году, и с тех пор он не сильно изменился, за исключением подхода к компиляции Just-In-Time (JIT), представленного в Android 2.2 Froyo, который в основном компилирует приложения прямо тогда, когда они запущен, или когда пользователь предоставляет необходимые инструкции. Это полезно, а также является улучшением по сравнению с предыдущим традиционным подходом интерпретатора, который компилировал и запускал код построчно по мере выполнения, но недостатком являются огромные накладные расходы при первом запуске приложения.

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

Что такое ИСКУССТВО и как оно улучшает ситуацию?

ART или Android RunTime (довольно неубедительное название, да, мы знаем) — это новая экспериментальная виртуальная машина, которую Google представила с Android 4.4 KitKat в качестве опции для разработчиков (при этом Dalvik по-прежнему используется по умолчанию). Основное различие между ART и Dalvik заключается в подходе к компиляции, который используют оба из них — ART использует новую концепцию Ahead-Of-Time (AOT) в отличие от JIT Dalvik, которая в основном компилирует приложения еще до их запуска. Это означает, что первая установка займет больше времени, а приложения будут занимать больше места во внутренней памяти, но в то же время, поскольку приложение будет полностью скомпилировано, как только оно будет установлено, время запуска будет намного быстрее. Точно так же, поскольку часть компиляции выполняется только один раз во время установки, нагрузка на процессор ниже, что приводит к увеличению времени автономной работы и общей производительности.

Dalvik Vs. ART — Сравнение

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

Дальвик

ИЗОБРАЗИТЕЛЬНОЕ ИСКУССТВО

Использует подход Just-In-Time (JIT), который приводит к меньшему потреблению дискового пространства, но более длительному времени загрузки приложения. Использует подход с опережением времени (AOT), который компилирует приложения при их установке, что приводит к более быстрому времени загрузки и меньшему использованию процессора. Кэш накапливается со временем, поэтому время загрузки ускоряется Кэш создается при первой загрузке, поэтому перезагрузка устройства занимает значительно больше времени. Лучше работает с более низкими внутренними запоминающими устройствами, так как занимаемое пространство меньше Потребляет гораздо больше внутренней памяти, так как в ней хранятся скомпилированные приложения в дополнение к APK. Стабильна и проверена временем — виртуальная машина, которую предпочитают разработчики приложений. В высшей степени экспериментальный и новый — пока не так много поддержки со стороны разработчиков приложений.

Вы говорите, что ИСКУССТВО экспериментально…

Да, и прямо сейчас он доступен только на устройствах с чипсетами Snapdragon и под управлением Android 4.4 KitKat. У вас есть возможность переключиться с Dalvik на ART из скрытых параметров разработчика, если вы захотите, но имейте в виду, что некоторые из ваших приложений могут работать некорректно. Кроме того, если в Dalvik уже создан кеш приложения, первая перезагрузка после переключения может занять до получаса.

Google в первую очередь сделал ART доступным вместе с KitKat, чтобы разработчики могли поиграть с ним и заложить основу для постоянного перехода в будущем. И это отнюдь не означает, что АРТ уже сегодня готова к употреблению. Это будет в будущем, но пока это экспериментальная версия, которая не подходит для повседневного использования конечным пользователем.

Что касается преимуществ АРТ, то здесь есть смешанные сообщения. По мнению большинства обозревателей, тестовые устройства состоят из четырехъядерных процессоров с более чем 2 гигабайтами оперативной памяти, что является более чем адекватной настройкой, чтобы действительно наблюдать прирост скорости от ART. Тем не менее, по сообщениям случайных пользователей, скорость увеличивается более чем на 50%, а время автономной работы — более чем на 30%. Третьи утверждают, что это не более чем эффект плацебо.

Честно говоря, ничего нельзя сказать, пока он не станет доступным для масс и не потеряет экспериментальный тег. Следовательно, мы отложим эту дискуссию на потом. Что можно сказать с уверенностью, так это то, что будущее за АРТ. Google собирается опередить время компиляции, чтобы действительно соответствовать iOS, своему крупнейшему аналогу, и ART проложит путь. Независимо от того, насколько глупым может показаться это название или насколько оно неполно сейчас, мы продолжим видеть 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

Источник