ART vs Dalvik: что сулит пользователям Android L?

Капитализм не может справиться с созданными им же производительными силами, которые переросли капиталистические производственные отношения, ставшие оковами их дальнейшего беспрепятственного роста. В недрах буржуазного общества в процессе развития капиталистического производства созданы объективные материальные предпосылки для перехода к социализму (БСЭ)

На WWDC 2014, как вы наверное помните, в рамках анонса своей мобильной iOS 8, Apple представила новые графический интерфейс (API) Metal и язык программирования Swift. Несмотря на то, что они, казалось бы, касаются только программистов, именно эти новшества сулят пользователям значительный прирост производительности приложений, запускаемых на iPhone и iPad. Любопытно, что главным достоинством новой Android L, представленной на днях в рамках конференции Google I/O, тоже стали нововведения, вроде бы далекие от пользователей, но крайне важные для их повседневного пользования Android-устройствами.

Речь идет об Android RunTime (ART) — среде выполнения приложений (runtime), которая пришла на смену виртуальной машине Dalvik. Строго говоря, ART, на разработку которой ушли два года, вышла еще в Android 4.4 KitKat, но ее относительно обтесанная версия появилась именно с релизом тестовой версии Android L. Чем же ART отличается от Dalvik? Грубо говоря, Dalvik — это интерпретатор, который переводит на машинный язык программу, написанную разработчиком на языке программирования Java и скомпилированную им в файл специального формата. Каждый раз при запуске на Android этого файла (предварительного упакованного в формат архивных исполняемых файлов-приложений), виртуальная машина Dalvik пошагово преобразует написанный программистом машинно-независимый код в машинный код, понятный процессору.

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

ART призвана решить эту проблему, сочетая в себе достоинства виртуальной машины и компилятора. Разница в том, что компиляцию под Android осуществляет не программист (как это делается, например, в случае с приложениями под iOS), а сама Android. В результате машинный код по-прежнему адаптирован к данному конкретному устройству (смартфону или планшету, на котором запущено приложение), но исполняется не пошагово, путем перевода «на лету» с Java на машинный код (т.н. Just-In-Time — JIT), а целиком — в машинном коде, на который текст программы предварительно был переведен с Java  (т.н. Ahead-Of-Time — AOT). Помимо роста быстродействия, это вдобавок сулит и снижение расхода аккумуляторной батареи, посколько с каждый запуском приложения не требуется перевод на машинный код и на процессор ложится меньшая нагрузка.

Единственными недостатками такого подходя являются дополнительное время, затрачиваемое на первый запуск (и, соответственно, компиляцию программного кода) приложения и возросший (примерно на 10%-20%) объем базового (без мультимедия и других приложений) программного кода.

Несмотря на радужные перспективы, рисуемые теорией новой среды выполнения приложений, первые испытания, проведенные около полугода назад с выходом ART, показали, что практический прирост производительности не столь значителен. В первую очередь он коснулся вычислений с плавающей точкой и отдачей дисплея — исполнение базового кода, вычисления с целочисленными данным и другие тесты показали либо совсем небольшой прирост, либо даже отставание от скорости интерпретации Java-кода приложения на Dalvik. Последнее специалистами объяснялось дополнительными контрольными процедурами, выполняемыми компилятором ART — ведь в последующем будет запускаться один и тот же код, поэтому ошибки недопустимы. Соответственно, на этой медлительности могли сказаться стремление Google перестраховаться и не слишком эффективный, сыроватый, инструментарий компиляции, который будет исправлен в последующих обновлениях.

И действительно — свежие испытания на смартфоне Nexus 5 показали гораздо более значительный прирост в производительности:

Причем помимо роста быстродействия за счет нового принципа исполнения программ, ART отличается значительным улучшением «сборки мусора» (garbage collection, GC) — специального процесса, который периодически освобождает память, удаляя объекты, не востребованные запущенными приложениями. Время, затрачиваемое на сборку мусора, сказывается, в частности, на количестве кадров в секунду, выдаваемых приложением. В ART по сравнению с Dalvik менеджер памяти ускорился на 25%, а благодаря новой функции “rosalloc” (Rows-of-Slots-Allocator) по сравнению со старой “malloc” обещается аж 10-кратный прирост в скорости динамического распределения памяти.

Таким образом, новая среда выполнения приложений ART сулит обладателям устройств на базе Android L весьма значительный прирост быстродействия в будущих приложениях. Насколько он будет сопоставим с ростом графической производительности приложений на платформе iOS 8 (релиз которой скорее всего будет сопровождаться с массовым переходом разработчиков на вышеупомянутые Metal и Swift), покажет время.

Скорее всего не случайно, что столь фундаментальные изменения почти одновременно затронули обе мобильные платформы. Добавьте сюда грядущее соперничество таких процессоров как нынешние Qualcomm Snapdragon 805, Snapdragon 810, Nvidia Tegra K1, а также будущий Apple A8 с обновленным PowerVR, растущие амбиции Intel и Microsoft по внедрению архитектуры x86 на мобильные платформы — все говорит в пользу нарастающего обострения борьбы производителей смартфонов и планшетов за сердца и кошельки потребителей.

С использованием материалов Android Police (1), (2), (3) и AnandTech