AOT — что это, Ahead-Of-Time компиляция и как работает

Q: Что такое AOT-компиляция простыми словами?

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

Q: Чем AOT отличается от JIT?

AOT компилирует код при установке (дольше установка, но быстрее запуск). JIT компилирует код во время работы (быстрая установка, но первые секунды приложение медленнее). Современные системы комбинируют оба подхода.

Q: Почему Android перешёл с Dalvik на ART с AOT?

Google хотела устранить проблему JIT-прогрева — задержек в первые секунды работы приложения. AOT-компиляция в ART обеспечила мгновенный запуск и снизила энергопотребление, что было критически важно для мобильных устройств.

Q: Как AOT влияет на размер приложения?

Размер APK не меняется — AOT-компиляция создаёт OAT-файлы на системном разделе, которые на 15–30% больше исходных DEX. Пользователь видит это как уменьшение свободного места встроенной памяти, а не как увеличение размера скачиваемого файла.

Q: Что такое профилированная AOT?

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

Автор: IT Sectr Опубликовано: 2026-04-16 Время чтения: 9 мин

AOT (Ahead-Of-Time) — технология компиляции, при которой исходный код или байт-код преобразуется в машинные инструкции до запуска программы, на этапе сборки или установки. В Android AOT-компиляция стала ключевой инновацией среды выполнения ART, заменившей Dalvik в версии 5.0 Lollipop. По данным Google, 2024, AOT-компиляция в ART устраняет задержки прогрева и снижает энергопотребление приложений на 10–15% по сравнению с JIT-подходом.

Главное

AOT — Ahead-Of-Time компиляция: преобразование кода в машинный до запуска программы.
В Android AOT выполняется утилитой dex2oat при установке APK или в фоновом режиме.
Главное преимущество AOT — мгновенный запуск приложений без фазы прогрева.
Недостаток — увеличенное время установки и дополнительный объём на диске на 15–30%.
Современные системы используют гибридный подход: JIT для первых запусков, AOT для hot-методов.

Что такое AOT-компиляция?

Ahead-Of-Time (AOT) — метод компиляции, при котором программа преобразуется в машинный код до момента её запуска. Термин "Ahead-Of-Time" противопоставляется JIT (Just-In-Time): если JIT компилирует "как раз вовремя", то AOT — "заранее". AOT-компилятор получает на вход исходный код или промежуточное представление (байт-код) и генерирует исполняемый файл, готовый к запуску.

История AOT восходит к традиционным компиляторам C и C++, где компиляция всегда выполняется до запуска. В контексте управляемых языков (Java, C#, Dart) AOT — более поздняя инновация: долгое время считалось, что динамические возможности (рефлексия, динамическая загрузка классов) делают AOT сложно реализуемой. Google решила эту задачу для Android, создав dex2oat — AOT-компилятор DEX-байт-кода в нативный код.

Принцип работы AOT

AOT-компилятор выполняет полный цикл трансляции. Первый этап — парсинг и построение абстрактного синтаксического дерева (AST). Второй — анализ и оптимизация: удаление мёртвого кода, инлайнинг, оптимизация циклов. Третий — генерация машинного кода для целевой архитектуры (ARM, ARM64, x86). Результат — исполняемый файл, который не требует дополнительной обработки во время выполнения.

bash

# Ручной запуск AOT-компилятора dex2oat
dex2oat --dex-file=classes.dex \
        --oat-file=classes.oat \
        --arch=arm64 \
        --instruction-set-variant=generic

# Проверка скомпилированного OAT-файла
oatdump --oat-file=classes.oat --output=oat_dump.txt

AOT в Android: dex2oat и OAT-файлы

В Android AOT-компиляция реализована через утилиту dex2oat (dalvik executable to optimized android translator). Когда пользователь устанавливает приложение, система запускает dex2oat, который считывает DEX-файлы из APK, оптимизирует байт-код и создаёт OAT-файл — ELF-бинарник с нативным кодом. Этот файл сохраняется в разделе /data/dalvik-cache/.

Процесс компиляции включает несколько уровней оптимизации. Базовый уровень — верификация байт-кода и базовые оптимизации (dead code elimination, constant folding). Средний — инлайнинг методов, loop unrolling, анализ escape-анализа. Максимальный — глобальные оптимизации всего приложения, включая девиртуализацию и оптимизацию размера стека. Уровень оптимизации зависит от режима компиляции (speed, speed-profile, space).

Структура OAT-файла

OAT-файл имеет формат ELF (Executable and Linkable Format) — тот же, что используют нативные Linux-бинарники. Внутри OAT-файла находится скомпилированный код для каждого метода приложения, а также метаданные: информация о классах, полях, методах и связях между ними. ART использует эти метаданные для быстрой загрузки классов и разрешения символьных ссылок без полного парсинга DEX.

Компонент OAT	Назначение
ELF header	Заголовок формата ELF
Code section	Машинный код скомпилированных методов
OAT header	Метаданные ART: версия, размеры секций
DEX sections	Исходные DEX-данные для рефлексии
Link table	Таблица связей для JNI и нативных библиотек

AOT vs JIT: сравнительный анализ

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

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

Критерий	AOT	JIT
Запуск	Мгновенный	С прогревом
Установка	Дольше (компиляция)	Быстро
Дисковое место	+15–30%	Минимально
Энергопотребление	Стабильное	Пики при компиляции
Адаптивность	Низкая	Высокая

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

Интересный нюанс: AOT-код не всегда быстрее JIT. JIT имеет доступ к профильной информации времени выполнения — точным типам объектов, частоте вызовов, реальным паттернам ветвления. Это позволяет применять оптимизации, недоступные AOT (например, профильно-управляемый инлайнинг). На практике разница в производительности скомпилированного кода между AOT и JIT составляет ±5–10% в зависимости от сценария.

Преимущества AOT-компиляции

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

Второе — энергоэффективность. AOT не создаёт пиковых нагрузок на CPU, характерных для JIT-компиляции. Процессор работает в стабильном режиме, что снижает энергопотребление на 10–15% в период первых 30–60 секунд работы приложения. Для типичного пользователя, запускающего 20–30 приложений в день, это даёт заметный прирост времени автономной работы.

Упрощение runtime

AOT-компиляция упрощает среду выполнения. Когда весь код уже скомпилирован, отпадает необходимость в JIT-компиляторе, интерпретаторе и профилировщике в runtime. Это уменьшает размер самой среды выполнения и снижает вероятность ошибок. ART в режиме полной AOT занимает примерно на 15% меньше оперативной памяти, чем аналогичная среда с активным JIT.

Недостатки AOT-компиляции

Главный недостаток AOT — время установки. На ранних устройствах с Android 5.0 установка крупных приложений (100–200 МБ) могла занимать 2–5 минут из-за AOT-компиляции. Это создавало негативный пользовательский опыт: после скачивания APK приходилось ждать, прежде чем можно было открыть приложение. Google частично решила эту проблему в Android 7.0, перейдя на гибридную схему.

Второй недостаток — занимаемое место. OAT-файлы на 15–30% больше исходных DEX-файлов. На устройствах с 8–16 ГБ встроенной памяти каждое приложение "съедает" дополнительное место на системном разделе. Для пользователей с большим количеством установленных приложений (50–100) это может привести к нехватке места для системных обновлений.

Отсутствие адаптивности

AOT-код фиксируется на момент компиляции. Если приложение использует разные паттерны выполнения в зависимости от версии Android, модели устройства или пользовательских настроек, AOT не может адаптироваться. Оптимизации, выбранные для одного сценария, могут быть неоптимальны для другого. JIT в этом плане гибче: он перекомпилирует hot-методы при изменении условий выполнения.

AOT за пределами Android: Flutter, .NET, Go

AOT-компиляция применяется не только в Android. Flutter использует AOT для компиляции Dart-кода в нативный код под iOS и Android. Это обеспечивает производительность UI на уровне 60 fps даже на слабых устройствах. На этапе разработки Flutter использует JIT (hot reload), а для релизной сборки — AOT, объединяя преимущества обоих подходов.

В экосистеме .NET технология ReadyToRun (R2R) позволяет компилировать сборки в нативный код заранее. Это сокращает время запуска .NET-приложений на 30–50%. Компилятор Go изначально является AOT-компилятором: программы на Go компилируются в один статический бинарник без внешних зависимостей, что делает их идеальными для контейнерной среды.

dart

// Flutter: AOT-компиляция Dart в нативный код
// Релизная сборка использует AOT
flutter build apk --release

// Результат: libapp.so с AOT-скомпилированным Dart-кодом
// Разработка использует JIT (hot reload)
flutter run

AOT и безопасность

Дополнительное преимущество AOT — усложнение обратной разработки. Скомпилированный нативный код труднее декомпилировать, чем байт-код. Инструменты вроде JADX и APKTool работают с DEX-форматом, но не могут восстановить исходный код из OAT-файлов на том же уровне детализации. Это не заменяет обфускацию (ProGuard, R8), но создаёт дополнительный барьер для анализаторов.

Гибридная стратегия: профилированная компиляция

Современный стандарт в Android — профилированная AOT-компиляция, реализованная в ART начиная с Android 7.0. При установке приложение не компилируется полностью — вместо этого используется быстрая верификация байт-кода и JIT для первых запусков. Это решает проблему долгой установки, характерную для чистой AOT в Android 5.0–6.0.

После 2–3 запусков приложения профилировщик ART собирает данные о реальном использовании и определяет, какие методы наиболее критичны для производительности. Затем в фоновом режиме (обычно ночью, когда устройство заряжается) dex2oat компилирует эти hot-методы в нативный код. После фоновой компиляции приложение получает производительность, эквивалентную полной AOT, без негативного влияния на пользовательский опыт при установке.

kotlin

// Программное управление режимом компиляции (Android 9+)
fun requestProfileCompilation(context: Context) {
    val pm = context.packageManager
    // Рекомендуется использовать профилированную компиляцию
    pm.setComponentEnabledSetting(
        ComponentName(context, javaClass()),
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
        PackageManager.DONT_KILL_APP
    )
}

Оптимизация под гибридный режим

Для максимальной выгоды от гибридной компиляции разработчикам стоит придерживаться нескольких правил. Используйте базовые профили (baseline profiles) — предварительно собранные профили, которые поставляются вместе с APK и позволяют ART начать AOT-компиляцию hot-методов сразу после установки. Baseline profiles сокращают время до достижения полной производительности с 2–3 запусков до первого же запуска.

Часто задаваемые вопросы

Что такое AOT-компиляция простыми словами?

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

Чем AOT отличается от JIT?

AOT компилирует код при установке (дольше установка, но быстрее запуск). JIT компилирует код во время работы (быстрая установка, но первые секунды приложение медленнее). Современные системы комбинируют оба подхода.

Почему Android перешёл с Dalvik на ART с AOT?

Google хотела устранить проблему JIT-прогрева — задержек в первые секунды работы приложения. AOT-компиляция в ART обеспечила мгновенный запуск и снизила энергопотребление, что было критически важно для мобильных устройств.

Как AOT влияет на размер приложения?

Размер APK не меняется — AOT-компиляция создаёт OAT-файлы на системном разделе, которые на 15–30% больше исходных DEX. Пользователь видит это как уменьшение свободного места встроенной памяти, а не как увеличение размера скачиваемого файла.

Что такое профилированная AOT?

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

Итоги

AOT (Ahead-Of-Time) — компиляция байт-кода в машинный код до запуска программы, на этапе установки.
В Android AOT реализован через утилиту dex2oat, создающую ELF-бинарники (OAT-файлы).
Главные преимущества AOT: мгновенный запуск, стабильная производительность и низкое энергопотребление.
Главные недостатки: увеличенное время установки и дополнительное дисковое место на 15–30%.
AOT применяется не только в Android, но и в Flutter (Dart), .NET (R2R) и Go.
Современный ART использует профилированную AOT: JIT для первых запусков, фоновая компиляция hot-методов.
Baseline profiles позволяют начать AOT-компиляцию ключевых методов сразу после установки приложения.

Мы разработаем мобильное приложение под ключ

IT Sectr создаёт приложения для iOS и Android для стартапов и бизнеса с 2017 года. Мы проконсультируем вас и предложим наилучшее решение.

Обсудить проект