Dalvik: что это, виртуальная машина и как работает

Что такое Dalvik?

Dalvik — виртуальная машина с регистровой архитектурой, созданная специально для платформы Android. Разработка началась в 2005 году компанией Дэна Борнштейна, а в 2007 году проект был приобретён Google. Первая коммерческая версия Dalvik появилась вместе с релизом Android 1.0 в 2008 году.

В отличие от стандартной Java Virtual Machine (JVM), Dalvik не исполняет Java-байт-код. Компилятор Java преобразует исходный код в class-файлы, а затем утилита dx переводит их в формат Dalvik Executable (DEX). Этот формат компактнее class-файлов: одно приложение размером 10 МБ в class-формате занимает примерно 6–7 МБ в DEX.

История создания

Дэн Борнштейн написал Dalvik как проект для операционных систем с ограниченными ресурсами. Название взято от исландской деревни Дальвик. Google выбрала Dalvik вместо JVM из-за лицензионных ограничений и необходимости глубокой оптимизации под мобильные процессоры с ARM-архитектурой. Система быстро завоевала популярность: к 2012 году на Dalvik работало более 500 миллионов Android-устройств.

Роль в экосистеме Android

Каждое Android-приложение запускается в отдельном процессе с собственным экземпляром Dalvik VM. Это обеспечивает изоляцию данных и защиту от вредоносного кода на уровне операционной системы. Такой подход сочетает преимущества виртуализации с песочницей Linux — зловред в одном приложении не может повлиять на соседние процессы.

Архитектура Dalvik: регистровая машина и DEX

Регистровая архитектура Dalvik принципиально отличается от стековой архитектуры JVM. Вместо операций с вершиной стека Dalvik оперирует регистрами — виртуальными ячейками внутри VM. Каждая инструкция содержит адреса регистров-операндов, что сокращает количество инструкций на одну операцию.

Стековая машина JVM использует инструкции типа push, pop и add — для сложения двух чисел требуется три инструкции. Dalvik решает ту же задачу одной инструкцией add-int с тремя регистрами. По данным Android Open Source Project, регистровая архитектура DEX сокращает объём байт-кода в среднем на 30% по сравнению со стековым class-форматом.

Формат DEX

DEX-файл (Dalvik Executable) содержит сжатое представление всех классов приложения. Заголовок файла включает контрольную сумму, размеры секций и смещения. Основные секции — это пулы строк, типов, прототипов методов, полей и сам байт-код. В одном DEX-файле может храниться до 65536 методов (ограничение снято введением multi-dex в Android 5.0).

Для преобразования class-файлов в DEX используется утилита dx, входящая в состав Android SDK Build Tools. Пример команды: dx --dex --output=classes.dex myapp.jar. Современные проекты используют D8 — преемник dx с улучшенной оптимизацией и поддержкой Java 8+ фич.

# Преобразование JAR в DEX с помощью dx
dx --dex --output=classes.dex myapp.jar

# Современная версия через D8
d8 --lib android.jar --output dex/ myapp.jar

Zygote: предзагрузка фреймворка

Процесс Zygote — важнейший элемент архитектуры Dalvik. При запуске системы Zygote загружает все классы Android SDK, открывает общие библиотеки и создаёт пул preload-ресурсов. Когда пользователь открывает приложение, система копирует процесс Zygote (fork), создавая новый экземпляр Dalvik VM с уже готовым фреймворком. Это сокращает время запуска приложения с ~2–3 секунд до 300–500 миллисекунд.

JIT-компиляция в Dalvik

JIT (Just-In-Time) — технология компиляции байт-кода в машинные инструкции непосредственно во время выполнения приложения. В Dalvik JIT-компилятор анализирует выполняемый DEX-код, выявляет часто используемые (hot) методы и компилирует их в нативный код для CPU.

Выбор JIT вместо полной Ahead-Of-Time (AOT) компиляции в ранних версиях Android был осознанным. Мобильные устройства имели ограниченный объём флеш-памяти (4–16 ГБ) — предварительная компиляция всех приложений заняла бы значительное место. Кроме того, ROM-память в ранних устройствах работала медленнее, чем оперативная, и чтение заранее скомпилированного кода могло снизить производительность.

Процесс JIT-компиляции

Когда приложение запускается, Dalvik начинает интерпретировать DEX-байт-код. Специальный профилировщик отслеживает, какие методы вызываются чаще всего. После превышения порога (обычно ~200 вызовов) JIT-компилятор преобразует метод в машинный код и кэширует его в оперативной памяти. Последующие вызовы используют уже скомпилированную версию без повторной компиляции.

// Пример hot-метода, который JIT скомпилирует
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

Производительность JIT

По данным Google I/O 2013, внедрение JIT в Android 2.2 Froyo ускорило выполнение приложений в среднем в 2–5 раз по сравнению с чистой интерпретацией. Однако JIT добавляет задержку при первом запуске: приложению требуется от 3 до 10 секунд на прогрев и компиляцию hot-методов. После прогрева производительность стабилизируется на уровне, близком к нативному коду.

Dalvik vs JVM: ключевые отличия

Dalvik отличается от JVM по нескольким фундаментальным параметрам. Первое — архитектура: JVM стековая, Dalvik регистровая. Второе — формат байт-кода: JVM использует class-файлы, Dalvik — DEX. Третье — управление памятью: Dalvik оптимизирована под ограниченный объём RAM мобильных устройств.

Оба подхода имеют сильные стороны. Стековая JVM требует меньше места на хранение инструкций — каждая инструкция короче, так как операнды неявно берутся со стека. Регистровая Dalvik исполняет меньше инструкций на одну операцию, что экономит процессорное время и снижает энергопотребление. Для мобильных устройств с батарейным питанием это критично.

Лицензионные аспекты

Выбор Dalvik вместо JVM также был обусловлен лицензированием. Oracle владеет правами на Java SE и JVM, и Google стремилась избежать лицензионных отчислений. Создание собственной VM с альтернативным форматом байт-кода позволило Android развиваться независимо от Oracle. Этот спор вылился в многолетний судебный процесс Oracle vs Google (2010–2021), завершившийся в пользу Google.

Формат DEX и утилита dx

DEX (Dalvik Executable) — бинарный формат, содержащий скомпилированный код Android-приложения. Каждый DEX-файл начинается с заголовка (header), за которым следуют секции: строковые константы (string_ids), типы (type_ids), прототипы методов (proto_ids), поля (field_ids), методы (method_ids), определения классов (class_defs) и область данных (data).

Утилита dx преобразует Java class-файлы в один или несколько DEX-файлов. Алгоритм работы включает дедупликацию констант — одинаковые строки или типы сохраняются один раз и ссылаются по индексу. Это существенно сокращает итоговый размер. В современных проектах dx заменена на D8 (появилась в Android Studio 3.1), которая работает в 2–3 раза быстрее и поддерживает Java 8 десахаринг.

// Пример декомпилированного DEX-байт-кода через dexdump
// Исходный код: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: преодоление лимита 65536

Ограничение DEX-формата в 65536 методов (лимит 16-битного индекса) стало серьёзной проблемой для крупных приложений. Решение появилось в Android 5.0: поддержка multi-dex позволяет приложению содержать несколько DEX-файлов. Основной classes.dex содержит точки входа, а дополнительные classes2.dex, classes3.dex и так далее — остальной код. Конфигурация multi-dex включается в build.gradle строкой multiDexEnabled true.

Управление памятью и сборка мусора

Сборка мусора в Dalvik реализована как поколенческий (generational) сборщик с маркировкой и очисткой (mark-and-sweep). Память делится на две основные области: Heap (куча) для объектов и Stack (стек) для примитивов и ссылок. При заполнении Heap Dalvik приостанавливает все потоки (STW — Stop-The-World), маркирует достижимые объекты и освобождает недостижимые.

До Android 2.2 Dalvik использовала однопоточный сборщик с длительностью пауз до 100–200 мс. В Android 2.3 Gingerbread появился concurrent-сборщик, сокративший типичные паузы до 5–10 мс. А в Android 4.0 Ice Cream Sandwich добавился сборщик с частичной (incremental) очисткой — Concurrent Mark and Sweep (CMS).

Утечки памяти

Типичная проблема Dalvik-приложений — утечки памяти через статические ссылки на Activity. Если статическое поле хранит ссылку на Context или View, сборщик мусора не может освободить Activity даже после закрытия экрана. Инструменты вроде Eclipse MAT и LeakCanary помогают обнаруживать такие утечки: они анализируют дамп Heap и показывают цепочки ссылок, удерживающих объект.

// Пример утечки памяти через статическую ссылку
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // Удерживает Activity после finish()
    }
}

Ограничения Dalvik и переход на ART

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

В Android 4.4 KitKat Google представила ART (Android Runtime) в качестве экспериментальной замены Dalvik. Начиная с Android 5.0 Lollipop ART стала единственной средой выполнения. Основное отличие — AOT-компиляция: вместо компиляции во время работы все приложения компилируются в машинный код при установке. Это устранило задержки прогрева и улучшило энергоэффективность.

Обратная совместимость

Переход с Dalvik на ART был прозрачным для разработчиков: обе среды исполняют один и тот же DEX-байт-код. Приложения, собранные для Dalvik, работают на ART без перекомпиляции — system_server компилирует их в нативный код при установке. Исключение — код, использующий рефлексию для доступа к внутренним членам Dalvik VM: такой код мог сломаться на ART из-за изменения внутренней архитектуры.