Dalvik и art – Что такое art и dalvik. ART идет на смену Dalvik. Для чего нужна виртуальная машина Dalvik

alexxlab 19.03.2020 Leave a comment

Содержание

Разбираемся в тонкостях программ Art и Dalvik. ART и Dalvik: Как оно работает

Нашлось место для многих изменений и усовершенствований. Большинство из них сразу же бросается в глаза даже рядовому пользователю данной системы. Это, конечно же, установка в качестве стандартного месседжера приложения 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. Хочется верить, что это произойдет уже очень скоро.

Пока удалось найти такую информацию на сайте Youhtc.ru
«
Последние несколько лет важной частью работы создателей Android стала борьба с главной врожденной «болезнью» системы — лагами в анимации интерфейса. Первым серьезным шагом в эту сторону стал Project Butter, анонсированный вместе с Android 4.1 Jelly Bean и действительно «ускоривший» систему, но не решивший проблему в корне. В Google это осознают, поэтому готовят ART — замену виртуальной машине Dalvik.

Даже сейчас, в век многоядерных производительных процессоров, при определенном стечении обстоятельств можно заметить, что анимация в Android отрисовывается не идеально, а между некоторыми действиями есть видимые заминки. Проблема комплексная, потому для ее решения нужно было предпринять много шагов — в качестве одного из них решили сменить Dalvik на прекомпилятор ART.

Сейчас Android-код выполняется в Java-машине, созданной Google специально для мобильных устройств, при этом он «на ходу» преобразуется в аппаратный (Just-In-Time Compilation). Такой механизм позволяет разработчику приложения практически не привязываться к конкретной архитектуре или «железу», но наносит серьезный урон производительности, нагружая процессор во время компиляции. Конечно, после первого самого «тормозного» запуска программы часть полученного «нативного» кода сохраняется в кеше, однако полностью проблему лагов это не решает.

ART же представляет из себя AOT-компилятор (Ahead-Of-Time), который преобразует Java-код в «нативный» в процессе установки приложения. То есть пользователь запускает программу уже скомпилированной, что существенно ускоряет ее открытие и выполнение. Вдвойне интер

СРАВНИТЕЛЬНЫЙ АНАЛИЗ СРЕД ИСПОЛНЕНИЯ ANDROID-ПРИЛОЖЕНИЙ — DALVIK И ART

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

В настоящий момент одной из самых распространенных в сфере мобильной разработки является операционная система Android. Данная ОС является программным стеком на основе ядра Linux, который предназначен для управления памятью, устройствами и процессами. [1] Несмотря на то, что каждый смартфон на Android имеет ядро Linux, сама же Android-система имеет существенные отличия от других Linux-систем. Она содержит в себе ряд специфичных изменений, включающих в себя множество специализированных библиотек и дополнительных расширений ядра.

Все приложения, разработанные для мобильных устройств на платформе Android, исполняла своя персональная виртуальная машина Dalvik VM, созданная компанией Google в 2007 году. Исполнение программ в виртуальной машине имеет несколько преимуществ:

работа виртуальной машины полностью изолирована от операционной системы мобильного устройства, что гарантирует безопасность ядра ОС, потому как код, способный навредить ему, не взаимодействует напрямую с системными файлами;
использование виртуальной машины создает условия для кроссплатформенности. Приложения и программы, написанные для ОС Android, компилируются непосредственно перед установкой. Данное решение позволяет обеспечить большую совместимость.
Virtual Machine была специально разработана для ОС Android. Она относится к регистровым виртуальным машинам, что создает идеальную совместимость для работы на процессорах RISC-архитектуры, к которым принадлежит наиболее используемый в смартфонах процессор ARM. Все программы для данной виртуальной машины пишутся на языке программирования Java, однако, Dalvik использует не стандартный байт-код Java, а персональный. Весь исходный код пишется на языке Java, а после компиляции сгенерированные файлы формата .class конвертируются в исполняемые файлы Dalvik Executable с расширением .dex. с помощью DEX компилятора, присутствующего в составе Android SDK. Файлы формата .dex имеют небольшой размер и оптимизированы для виртуальной машины. Dalvik VM использует способ JIT (just in time) компиляции файлов. [3] Его принцип работы состоит в том, что преобразователь кода активируется во время работы приложения. Большим недостатком данного способа является высокий расход ресурсов процессора при запуске программы, что приводит к некорректной работе используемых файлов. Решить данную проблему позволяет кэширование данных. Когда приложение запускается впервые, часть данных сохраняется в кэш-память, позволяя повышать производительность, однако данный способ не является полноценным решением проблемы. Чтобы исправить все вышесказанные недостатки, инженеры Google разработали новую среду выполнения приложений, называемую Android Runtime (ART)

С выходом новой версии Android 4.4 Kitkat, появился тестовый вариант новой виртуальной машины Android RunTime, а начиная с версии Android 5.0 и выше среда ART полностью заменила Dalvik.

Самое важное отличие Android Runtime и Dalvik VM – момент компиляции байт-кода. Dalvik реазизует подход JIT, преобразуя код в реальном времени в момент исполнения программы, в то время как в ART используется технология Ahead-Of-Time (AOT, «впереди времени»), заключающаяся в компиляции кода программы в момент ее установки на устройство. Данная технология увеличивает время, затрачиваемое на установку приложения и занимаемый объем памяти в хранилище Android устройства, однако приводит к общему увеличению производительности приложения, так как оно уже скомпилировано, а меньшее использование процессора и оперативной памяти по причине отсутствия повторной компиляции приводит к улучшенному энергопотреблению. [2] Также с появлением ART удалось уменьшить время, затрачиваемое системой на сборку мусора, что позволило избежать замираний графического интерфейса и снижения производительности приложений при работе с большими объемами данных. Введение Android Runtime не повлияло на процесс разработки приложений для Android, так как ART полностью совместима с байт-кодом Dalvik VM.

Наглядное сравнение преимуществ и недостатков ART и Dalvik VM представлено в таблице 1.

Таблица 1.

Сравнение Dalvik VM и ART

Dalvik (JIT)	ART (AOT)
Требуется меньше флеш-памяти для хранения, однако необходимо больше времени на запуск приложения	Используется больше флеш-памяти для хранения, но тратится меньше ресурсов процессора и уменьшается время запуска программы
Кэш приложений создается постепенно, что приводит к ускорению загрузки устройства	Загрузка устройства происходит медленнее, так как кэш машинного кода создается при первой загрузке устройства
Лучше подходит для устройств с маленьким объемом флеш-памяти, так как кэш машинного кода занимает меньше места	Занимает больше флеш-памяти, так как кроме файлов APK хранит скомпилированный машинный код каждой программы

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

Виртуальная машина Android Runtime, реализующая высокий уровень программных оптимизаций исполняемой среды Java, обеспечивает более высокую производительность и лучший опыт взаимодействия пользователя с устройством на платформе Android, чем ее предшественник Dalvik VM.

Список литературы:

Гриффитс Д., Гриффитс Д. Head First. Программирование для Android. 2-е изд. — СПб.: Питер, 2018. — 912 с.
Meier R., Lake I. Professional Android. 4^th Edition. – Indianapolis: John Wiley & Sons, Inc., 2018. – 863 p.
Материал из Android Open Source Project – Dalvik bytecode, URL: https://source.android.com/devices/tech/dalvik/dalvik-bytecode/ (дата обращения: 11.09.2019).

Детальный анализ Android RunTime (ART) в Android L — «Хакер»

На недавней конференции I/O компания Google официально огласила планы перехода в следующих версиях операционной системы Android на новую среду выполнения ART. Главным преимуществом ART перед Dalvik называли улучшенное энергопотребление.

При установке Java-код приложения сразу компилируется в машинный код (AOT-компиляция), тогда как Dalvik компилировал Java-код в свой байткод dex (Dalvik executable), а после запуска программы компилировал его в машинный код в реальном времени (JIT-компиляция). Поэтому ART экономит энергию. Правда, это происходит за счёт увеличения используемого пространства и замедления инсталляции приложений. Google уверяет, что замедление не критическое. Инновации вроде ART стали возможны благодаря увеличению объёма памяти в современных смартфонах.

Схема работы 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, часть 2 / Ростелеком-Солар corporate blog / Habr

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

Статьи серии:

Говоря про Unix- и Linux-корни Android, нужно вспомнить и о других проектах операционных систем, влияние которых можно проследить в Android, хотя они и не являются его прямыми предками.

Я уже упомянул про BeOS, в наследство от которой Android достался Binder.

Plan 9 from Bell Labs

Plan 9 — потомок Unix, логическое продолжение, развитие его идей и доведение их до совершенства. Plan 9 был разработан в Bell Labs той же командой, которая создала Unix и C — над ним работали такие люди, как Ken Thompson, Rob Pike, Dennis Ritchie, Brian Kernighan, Tom Duff, Doug McIlroy, Bjarne Stroustrup, Bruce Ellis и другие.

В Plan 9 взаимодействие процессов между собой и с ядром системы реализовано не через многочисленные системные вызовы и механизмы IPC, а через виртуальные текстовые файлы и файловые системы (развитие принципа Unix «всё — это файл»). При этом каждая группа процессов «видит» файловую систему по-своему (пространства имён, namespaces), что позволяет запускать разные части системы в разном окружении.

Например, чтобы получить позицию курсора мыши, приложения читают текстовый файл /dev/mouse. Оконная система rio предоставляет каждому приложению свою версию этого файла, в которой видны только события, относящиеся к окну этого приложения, и используются локальные по отношению к окну координаты. Сама rio читает события «настоящей» мыши через такой же файл /dev/mouse — в том виде, в котором его видит она. Если она запущена напрямую, этот файл предоставляется ядром и действительно описывает движения настоящей мыши, но она может быть совершенно прозрачно запущена в качестве приложения под другой копией rio, без какой-то специальной поддержки с её стороны.

Plan 9 полностью поддерживает доступ к удалённым файловым системам (используется собственный протокол 9P, кроме того, поддерживаются FTP и SFTP), что позволяет программам совершенно прозрачно получать доступ к удалённым файлам, интерфейсам и ресурсам. Такая «родная» сетевая прозрачность превращает Plan 9 в распределённую операционную систему — пользователь может физически находиться за одним компьютером, на котором запущена rio, запускать приложения на нескольких других, использовать в них файлы, хранящиеся на файловом сервере и выполнять вычисления на CPU-сервере — всё это полностью прозрачно и без специальной поддержки со стороны каждой из частей системы.

За счёт красиво спроектированной архитектуры Plan 9 значительно проще и меньше, чем Unix — на самом деле ядро Plan 9 даже в несколько раз меньше известного микроядра Mach.

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Несмотря на техническое превосходство и наличие слоя совместимости с Unix, Plan 9 не получил широкого распространения. Тем не менее, многие идеи и технологии из Plan 9 получили распространение и были реализованы в других системах. Самая известная из них — кодировка UTF-8, которая была разработана в Plan 9 для обеспечения полной поддержки Unicode при сохранении обратной совместимости с ASCII — стала общепринятым стандартом.

Больше всего идей и технологий из Plan 9 реализовано в Linux:

файловая система /proc (procfs)
системный вызов clone (аналог rfork из Plan 9)
поддержка пространств имён монтирования (mount namespaces)
поддержка файловых систем, реализованных в пользовательском пространстве (filesystem in userspace, FUSE)
поддержка протокола 9P

Многое из этого используется, в том числе, и в Android. Кроме того, в Android реализован механизм intent’ов, похожий на plumber из Plan 9; о нём я расскажу в следующей статье.

Про Plan 9 можно узнать подробнее на сайте plan9.bell-labs.com (сохранённая копия в Wayback Machine), или его зеркале 9p.io

Inferno

Plan 9 получил продолжение в виде проекта Inferno, тоже разработанного в Bell Labs. К таким свойствам Plan 9, как простота и распределённость, Inferno добавляет переносимость. Программы для Inferno пишутся на высокоуровневом языке Limbo и выполняются — с использованием just-in-time компиляции — встроенной в ядро Inferno виртуальной машиной.

Inferno настолько переносим, что может запускаться

на процессорах разных архитектур: ARM, x86, IBM PowerPC, Sun SPARC, 6SGI MIPS и HP PA-RISC,
как самостоятельная операционная система или как программа под Plan 9, Unix, Windows 95 и Windows NT.

При этом приложениям, запущенным внутри Inferno, предоставляется совершенно одинаковое окружение.

Inferno получил ещё меньше распространения и известности, чем Plan 9. С другой стороны, Inferno во многом предвосхитил Android, самую популярную операционную систему на свете.

Danger

Компания Danger Research Inc. была сооснована Энди Рубином (Andy Rubin) в 1999 году, за 4 года до сооснования им же Android Inc. в 2004 году.

В 2002 году Danger выпустили свой смартфон Danger Hiptop. Многие из разработчиков Danger впоследствии работали над Android, поэтому неудивительно, что его операционная система была во многом похожа на Android. Например, в ней были реализованы:

«всегда запущенные» приложения, написанные на Java,
полноценный веб-браузер,
веб-приложения,
мессенджер,
email client,
облачная синхронизация,
магазин сторонних приложений.

Подробнее о Danger можно прочитать в статье Chris DeSalvo, одного из разработчиков, под названием The future that everyone forgot.

Java

Хотя использование высокоуровневых языков для серьёзной разработки сейчас уже никого не удивляет, из популярных операционных систем только у Android «родной» язык — высокоуровневая Java (с другой стороны, здесь можно вспомнить веб с его JavaScript, .NET для Windows и относительно высокоуровневый — но полностью компилируемый в нативный код и не использующий сборку мусора — Swift).

Несмотря на кажущиеся недостатки («Java сочетает в себе красоту синтаксиса C++ со скоростью выполнения питона»), Java обладает множеством преимуществ.

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

Программы на Java, как и на многих других высокоуровневых языках, переносимы между операционными системами и архитектурами процессора («Write once, run anywhere»). Практически это проявляется, например, в том, что приложения для Android работают без перекомпиляции на устройствах любой архитектуры (Android поддерживает ARM, ARM64, x86, x86–64 и MIPS).

В отличие от низкоуровневых языков вроде C и C++, использующих ручное управление памятью, в Java память автоматически управляется средой времени выполнения (runtime environment). Программа на Java даже не имеет прямого доступа к памяти, что автоматически предотвращает несколько классов ошибок, часто приводящих к падениям и уязвимостям в программах, написанных на низкоуровневых языках — невозможны «висячие ссылки» (из-за которых происходит use-after-free), разыменование нулевого указателя (при попытке это сделать выбрасывается NullPointerException), чтение неинициализированной памяти и выход за границы массива.

Использование полноценной сборки мусора (по сравнению с automatic reference counting) избавляет программиста от всех проблем и сложностей с циклическими ссылками и позволяет реализовывать ещё более продвинутые (advanced) зависимости между объектами.

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

Running Java is ART

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

Хотя делаются попытки создать физический процессор, который исполнял бы Java-байткод напрямую, в подавляющем большинстве случаев в качестве такого процессора используется эмулятор — Java virtual machine (JVM). Обычно используется реализация от Oracle/OpenJDK под названием HotSpot.

В Android используется собственная реализация под названием Android Runtime (ART), специально оптимизированная для работы на мобильных устройствах. В старых версиях Android (до 5.0 Lollipop) вместо ART использовалась другая реализация под названием Dalvik.

И в Dalvik, и в ART используется собственный формат байткода и собственный формат файлов, в которых хранится байткод — DEX (Dalvik executable). В отличие от class-файлов в «обычной джаве», весь Java-код приложения обычно компилируется в один DEX-файлclasses.dex. При сборке Android-приложения Java-код сначала компилируется обычным компилятором Java в class-файлы, а потом конвертируется в DEX-файлспециальной утилитой (возможно и обратное преобразование).

И HotSpot, и Dalvik, и ART дополнительно оптимизируют выполняемый код. Все три используют just-in-time compilation (JIT), то есть во время выполнения компилируют байткод в куски полностью нативного кода, который выполняется напрямую. Кроме очевидного выигрыша в скорости, это позволяет оптимизировать код для выполнения на конкретном процессоре, не отказываясь от полной переносимости байткода.

Кроме того, ART может компилировать байткод в нативный код заранее, а не во время выполнения (ahead-of-time compilation) — причём система автоматически планирует эту компиляцию на то время, когда устройство не используется и подключено к зарядке (например, ночью). При этом ART учитывает данные, собранные профилировщиком во время предыдущих запусков этого кода (profile-guided optimization). Такой подход позволяет дополнительно оптимизировать код под специфику работы конкретного приложения и даже под особенности использования этого приложения именно этим пользователем.

В результате всех этих оптимизаций производительность Java-кода на Android не сильно уступает производительности низкоуровневого кода (на C/C++), а в некоторых случаях и превосходит её.

Java-байткод, в отличие от обычного исполняемого кода, использует объектную модель Java — то есть в байткоде явно записываются такие вещи, как классы, методы и сигнатуры. Это делает возможной компиляцию других языков в Java-байткод, что позволяет написанным на них программам исполняться на виртуальной машине Java и быть в той или иной степени совместимыми (interoperable) с Java.

Существуют как JVM-реализации независимых языков — например, Jython для Python, JRuby для Ruby, Rhino для JavaScript и диалект Lisp Clojure — так и языки, исходно разработанные для компиляции в Java-байткод и выполнения на JVM, самые известные из которых — Groovy, Scala и Kotlin.

Самый новый из них, Kotlin, специально разработанный для идеальной совместимости с Java и обладающий гораздо более приятным синтаксисом (похожим на Swift), поддерживается Google как официальный язык разработки под Android наравне с Java.

Несмотря на все преимущества Java, в некоторых случаях всё-таки желательно использовать низкоуровневый язык — например, для реализации критичного по производительности компонента, такого как браузерный движок, или чтобы использовать существующую нативную библиотеку. Java позволяет вызывать нативный код через Java Native Interface (JNI), и Android предоставляет специальные средства для нативной разработки — Native Development Kit (NDK), в который входят в том числе заголовочные файлы, компилятор (Clang), отладчик (LLDB) и система сборки.

Хотя NDK в основном ориентирован на использование C/C++, с его помощью можно писать под Android и на других языках — в том числе Rust, Swift, Python, JavaScript и даже Haskell. Больше того, есть даже возможность портировать iOS-приложения (написанные на Objective-C или Swift) на Android практически без изменений.

О безопасности

Классический Unix

Модель безопасности в классическом Unix основана на системе UID/GID — специальных номеров, которые ядро хранит для каждого процесса. Процессам с одинаковым UID разрешён доступ друг к другу, процессы с разным UID защищены друг от друга. Аналогично ограничивается доступ к файлам.

По смыслу каждый UID (user ID) соответствует своему пользователю — во времена создания Unix была нормальной ситуация, когда один компьютер одновременно использовался множеством людей. Таким образом, в Unix процессы и файлы разных людей были защищены друг от друга. Чтобы разрешить общий доступ к некоторым файлам, пользователи объединялись в группы, которым и соответствовал GID (group ID).

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

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

В Unix есть и исключение из ограничений доступа — UID 0, который принято называть root. У него есть доступ ко всему в системе, и никакие ограничения на него не распространяются. Этот аккаунт использовался системным администратором; кроме того, под UID 0 запускаются многие системные сервисы.

В современном Linux эта модель была значительно расширена и обобщена, в том числе появились capabilities, позволяющие «получить часть root-прав», и реализующая мандатное управление доступом (mandatory access control, MAC) подсистема SELinux, которая позволяет дополнительно ограничить права (в том числе права root-процессов).

Всё изменилось

За несколько десятков лет, прошедших с создания Unix до создания Android, практика использования компьютеров («вычислителей») значительно изменилась.

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

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

Таким образом, в современных условиях вместо защиты разных пользователей друг от друга необходимо защищать от приложений другие приложения, пользовательские данные и саму систему. Кроме того, широкое распространение получили вирусы, которые обычно используют уязвимости в системе — для защиты от них нужно дополнительно защищать части системы друг от друга, чтобы использование одной уязвимости не давало злоумышленнику доступ ко всей системе.

Android

Хотя часть Android-приложений поставляется с системой — например, такие стандартные приложения, как Калькулятор, Часы и Камера — большинство приложений пользователи устанавливают из сторонних источников. Самый известный из них — Google Play Store, но есть и другие, например, F-Droid, Amazon Appstore, Яндекс.Store, китайские Baidu App Store, Xiaomi App Store, Huawei App Store и т.д. Кроме того, Android позволяет вручную устанавливать произвольные приложения из APK-файлов (это называют sideloading).

Как и другие Unix-подобные системы, Android использует для ограничения доступа существующий механизм UID/GID. При этом — в отличие от традиционного использования, когда UID соответствуют пользователям — в Android разные UID соответствуют разным приложениям. Поскольку процессы разных приложений запускаются с разными UID, уже на уровне ядра приложения защищены и изолированы друг от друга и не имеют доступа к системе и данным пользователя. Это образует песочницу (Application Sandbox) и позволяет пользователю устанавливать любые приложения без необходимости доверять им.

Чтобы всё-таки получить доступ к пользовательским данным, камере, совершению звонков и т.п., приложение должно получить от пользователя разрешение (permission). Некоторые из разрешений существуют в виде GID, в которые приложение добавляется, когда получает это разрешение — например, получение разрешения ACCESS_FM_RADIO помещает приложение в группу media, что позволяет ему получить доступ к файлу /dev/fm. Остальные существуют только на более высоком уровне (в виде записей в файле packages.xml) и проверяются другими компонентами системы при обращении к высокоуровневому API через Binder.

Небольшая часть системных сервисов в Android запускается под UID 0, то есть root, но большинство используют специально выделенные номера UID, повышая при необходимости свои права с помощью Linux capabilities. Кроме того, Android использует SELinux — использование SELinux в Android называют SEAndroid — для ещё большего ограничения того, какие действия разрешено выполнять приложениям и системным сервисам.

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

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

ART вместо Dalvik ?

Здравствуйте! Если вы не понимаете, что изменится для пользователя при изменении среды выполнения из Dalvik в ART, то этот пост вам будет интересен. Прежде чем говорить о новой среде, давайте поговорим о всем известной среде Dalvik Определение Dalvik Virtual Machine — виртуальная машина основанная на регистрах, разработанная Дэном Борнштейном, как часть мобильной платформы Android. Для чего нужна виртуальная машина Dalvik? Dalvik…

Определение

Dalvik Virtual Machine — виртуальная машина основанная на регистрах, разработанная Дэном Борнштейном, как часть мобильной платформы Android.

Для чего нужна виртуальная машина Dalvik?

Dalvik запускает приложения и код написанный на Java. Стандартный Java компилятор преобразует код приложения, изначально в байт-код, а потом уже в файлы с расширением «.dex». Эти файлы, в свою очередь, и использует виртуальная машина Dalvik.

Зачем Google меняет среду выполнения?

Главным фактором для Google, является ускороние работы интерфейса. Всем известно, что один большой шаг в эту сторону «корпорация» добра уже сделала с выходом Android 4.1 Jelly Bean. Как вы помните, в данной версии был анонсирован Project Butter, который действительно улучшил скорость работы интерфейса (анимации). Но Google на этом не остановились и решили изменить среду выполнения приложений, проститься с DalvikVM и начать работать в среде ART.

Как работает Dalvik и как будет работать ART?

DalvikVM работает в реальном времени, то есть преобразует код в аппаратный «на ходу» (Just-In-Time). Таким образом очень нагружая процессор.
А вот прекомпилятор ART, будет преобразовывать код сразу при установке приложения.

Плюсы прекомпилятора ART:
+ Повышение скорости выполнения «тяжёлых» задач.
+ Даёт возможность чаще отключать неиспользуемые ядра процессора. Таки образом может увеличится время автономной работы устройства.

Минусы конечно же тоже есть. Один, по-моему, главный это увеличение размера установленной программы. Конечно же обладатели устройств с 32 ГБ памяти на борту этого не по чувствуют. Но ведь есть же ещё устройства даже с 8 ГБ на борту…

Вывод

Увидеть какие плюсы имеет новая среда выполнения приложения (ART) могут уже сейчас владельцы девайсов из л нейки Nexus, с новой версией ОС Android 4.4 KitKat. Перейти с Dalvik на ART можно в настройках для разработчиков.
Но на данный момент пока не известно когда ART полностью заменит Dalvik.

На этом всё, теперь вы хоть немного понимаете как работает и как вскоре будет работать Android «изнутри». Спасибо за то, что прочли данный материал, обязательно оставляйте комментарии :)))

Что делать если Android не загружается после переключения с Dalvik на ART

Решили попробовать Art и теперь ваш Android не загружается? Не знаете как решить данную проблему? Тогда в данной статье найдете 3 способа решить данную проблему!

Как известно прогресс не стоит на месте, это касается и операционной системы Android! С приходом новейшей версии операционной системы Android 4.4 KitKat, появилась новая виртуальная машина Art с целью заменить в будущем старую среду Dalvik. Пока что Art находиться в тестовом состояние и не рекомендуется для повседневной работы, но риск дело благородное, кто решил попробовать новую среду и получил вечную загрузку (bootloop) не стоит преждевременно рвать на себе волосы. Как решить данную проблему вы узнаете в этой статье!

Способ 1 (без потери данных)

Вам понадобиться:

1. Установить recovery CWM или TWRP

2. Карта памяти

3. Скачать файловый менеджер Aroma FileManager (работает из под Recovery)

Процедура возвращения:

1. Файловый менеджер Aroma FileManager переместить на карту памяти

2. Карту памяти вставить в Android

3. Перевести Android в режим Recovery

4. «Установить» Aroma FileManager

5. Перейти по пути /system/lib (возможно необходимо будет примонтировать /system)

6. Переименовать файл lidart.so на libart.so1

7. Выйти из Aroma FileManager

8. Очистить Dalvik Cache

Способ 2 (без потери данных)

Вам понадобиться:

1. Установить recovery CWM или TWRP

2. Карта памяти

3. Скачать прошиваемый архив обновление Switch D2A_RT

Процедура возвращения:

1. Архив Switch D2A_RT.zip переместить на карту памяти

2. Карту памяти вставить в Android

3. Перевести Android в режим Recovery

4. «Установить» Switch D2A_RT.zip

5. Переключить с Art на Dalvik

6. Очистить Dalvik Cache

Способ 3 (c потерей данных)

Все очень просто и банально, необходимо сделать сброс данных до заводских настроек — wipe. Как сделать wipe читайте в подробной статье — Сброс настроек или wipe на Android.

На этом все! Оставайтесь с сайтом Android +1!

светлое будущее Android — Android на FullHub

Последние несколько лет важной частью работы создателей Android стала борьба с главной врожденной «болезнью» системы — лагами в анимации интерфейса. Первым серьезным шагом в эту сторону стал Project Butter, анонсированный вместе с Android 4.1 Jelly Bean и действительно «ускоривший» систему, но не решивший проблему в корне. В Google это осознают, поэтому готовят ART — замену виртуальной машине Dalvik.

ART же представляет из себя AOT-компилятор (Ahead-Of-Time), который преобразует Java-код в «нативный» в процессе установки приложения. То есть пользователь запускает программу уже скомпилированной, что существенно ускоряет ее открытие и выполнение. Вдвойне интересно, что ART уже встроен в Android 4.4 KitKat и активировать его можно в меню разработчика. После переключения на libart.so (библиотека компилятора) устройство перезагружается и компилирует все уже установленные приложения. Ребята из Android Police, внимательно изучившие ART, утверждают, что на кастомных прошивках из AOSP этого делать пока не стоит — могут возникнуть проблемы с пакетом программ от Google.

Даже учитывая неокончательное состояние ART, переход на него существенно влияет на скорость выполнения ресурсоемких задач и плавность работы интерфейса, а также позволяет многоядерным процессорам чаще отключать неиспользуемые ядра, что дает выигрыш во времени автономной работы устройства. Существуют у новой системы компиляции минусы, хотя их сложно назвать значительными: более продолжительное время установки и увеличение финального размера программы на 10-20%. Правда, растет размер лишь кодовой части, которая часто занимает менее половины приложения — мультимедиа (картинки, звук, видео) и другие данные своего размера не меняют.

Оказывается, Google уже не первый год работают над ART и включение его в KitKat — абсолютно обдуманное решение, позволяющее создателям системы провести серьезное тестирование, а разработчикам приложений — подготовиться к грядущему «уходу» Dalvik. Пока не ясно, насколько на новый компилятор повлияли разработчики из FlexyCore, которых Google купили в октябре текущего года, но начинался проект внутри самого поискового гиганта.

В Google пока не говорят, как скоро ART заменит Dalvik, однако ничего не мешает корпорации сделать это уже в следующей версии системы. Интересно, что как и Project Butter, компилятор не требует трудозатрат от разработчиков приложений — они все так же будут писать код на хорошо знакомом языке, используя отработанные практики.