---

  Все     Команда     Скрипт     Служба     Приложение  

---

  Рус  

usage:  dex2oat [options]...

--dex-file=<dex-file>: specifies a .dex file to compile.
  Example: --dex-file=/system/framework/core.jar 
--zip-fd=<file-descriptor>: specifies a file descriptor of a zip file
  containing a classes.dex file to compile.
  Example: --zip-fd=5 
--zip-location=<zip-location>: specifies a symbolic name for the file
  corresponding to the file descriptor specified by --zip-fd. 
  Example: --zip-location=/system/app/Calculator.apk 
--oat-file=<file.oat>: specifies the oat output destination via a filename.
  Example: --oat-file=/system/framework/boot.oat 
--oat-fd=<number>: specifies the oat output destination via a file descriptor.
  Example: --oat-file=/system/framework/boot.oat 
--oat-location=<oat-name>: specifies a symbolic name for the file corresponding
  to the file descriptor specified by --oat-fd. 
  Example: --oat-location=/data/dalvik-cache/system@app@Calculator.apk.oat 
--oat-symbols=<file.oat>: specifies the oat output destination with full symbols.
  Example: --oat-symbols=/symbols/system/framework/boot.oat 
--bitcode=<file.bc>: specifies the optional bitcode filename.
  Example: --bitcode=/system/framework/boot.bc 
--image=<file.art>: specifies the output image filename.
  Example: --image=/system/framework/boot.art 
--image-classes=<classname-file>: specifies classes to include in an image.
  Example: --image=frameworks/base/preloaded-classes 
--base=<hex-address>: specifies the base address when creating a boot image.
  Example: --base=0x50000000 
--boot-image=<file.art>: provide the image file for the boot class path.
  Example: --boot-image=/system/framework/boot.art 
  Default: <host-prefix>/system/framework/boot.art
--host-prefix=<path>: used to translate host paths to target paths during
  cross compilation.
  Example: --host-prefix=out/target/product/crespo 
  Default: $ANDROID_PRODUCT_OUT
--android-root=<path>: used to locate libraries for portable linking.
  Example: --android-root=out/host/linux-x86 
  Default: $ANDROID_ROOT
--instruction-set=(arm|mips|x86): compile for a particular instruction
  set.
  Example: --instruction-set=x86 
  Default: arm
--compiler-backend=(Quick|QuickGBC|Portable): select compiler backend
  set.
  Example: --instruction-set=Portable 
  Default: Quick
--host: used with Portable backend to link against host runtime libraries
--dump-timing: display a breakdown of where time was spent
--runtime-arg <argument>: used to specify various arguments for the runtime,
  such as initial heap size, maximum heap size, and verbose output.
  Use a separate --runtime-arg switch for each argument.
  Example: --runtime-arg -Xms256m

    https://habr.com/ru/companies/kaspersky/articles/671180/
Для понимания принципа работы Baseline profile нужно вспомнить виды компиляции в Android. После сборки приложения мы получаем файл .apk, который содержит файлы .dex. В них находится bytecode, понятный интерпретатору. Android runtime транслирует bytecode в машинный код. Получение машинного кода из bytecode может происходить несколькими путями.

В случае с Dalvik девайсы производились с небольшой по объему оперативной памятью (RAM), поэтому шаги по оптимизации были нацелены на уменьшение ее использования. Для этого использовалась JIT (Just-In-Time) compilation — компиляция в runtime. Вместо того чтоб компилировать все приложение целиком, компилировались лишь некоторые участки кода. Так как вся компиляция происходит в процессе выполнения, это негативно сказывалось на производительности.

На замену Dalvik пришел ART с измененным подходом к компиляции. В ART появилась компиляция AOT (Ahead of time). К моменту запуска приложения весь код уже скомпилирован. Как результат, получаем выигрыш по производительности, но просадку по использованию RAM, долгую установку приложения и долгие системные обновления.

Частичная компиляция является компромиссом. По умолчанию bytecode JIT-прекомпилируется, но если встречаются участки кода, которые используются часто, тогда они AOT-компилируются. AOT-компиляция происходит при помощи утилиты dex2oat, сохраняя результат в бинарных файлах .oat. В итоге получаем гибридную схему компиляции.

Однако и эта схема имеет проблемы. AOT-компиляция происходит спустя какое-то время (после нескольких запусков приложения и прохождения ряда пользовательских сценариев). Поэтому первый опыт и впечатления могут быть подпорчены невысоким уровнем производительности. А ведь зачастую именно первый опыт формирует отношение пользователя к приложению. Поэтому в ART появились профили (profiles). Доступны два вида профилей.

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

Второй вид — Baseline profile. Это возможность указать компилятору те участки кода, которые бы вы хотели прекомпилировать на девайсах пользователей.
Эти профили как раз и формируют начальный кеш, который позволяет ускорить время запуска и производительность.

---

Из исходного текста dex2oat.cc:

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

В настоящее время у нас есть макет памяти, который выглядит примерно так:
+--------------+
| образ |
+--------------+
| boot oat |
+--------------+
| выделенное пространство |

+--------------+
Существует несколько ограничений на загрузку образа и boot.oat.

1. Ожидается, что образ будет загружен по абсолютному адресу и содержит объекты
с абсолютными указателями внутри образа.

2. Есть абсолютные указатели от методов в образе на их код в OAT.

3. Есть абсолютные указатели из кода в OAT на методы в изображении.

4. Существуют абсолютные указатели от кода в OAT к другому коду в OAT
Чтобы все сделать правильно, мы проходим несколько шагов.

1. Мы уже создали этот файл OAT с помощью CreateOatFile.
Первоначально это был наш собственный файл, но теперь он содержится в динамическом
объекте ELF (также известном как файл .so).

Компилятор, возвращаемый CreateOatFile, предоставляет PatchInformation
для ссылок на код oat и методы, которые необходимо обновить, как только мы узнаем,
где файл oat будет расположен после j,hfpf.

2. Создаем файл образа.
Ему необходимо знать, куда после себя будет загружен файл oat.
Первоначально файл oat просто отображался в памяти, чтобы мы могли предсказать,
где находится его содержимое, на основе размера файла.
Теперь, когда это файл ELF, нам нужно проверить файл ELF, чтобы понять структуру
сегмента памяти, включая то, где находится заголовок OAT.

PatchOatCodeAndMethods ImageWriter использует PatchInformation из компилятора
для исправления абсолютных ссылок в файле oat.

3. Мы исправляем заголовки программы ELF, чтобы dlopen пытался загрузить .so
в нужное место во время выполнения, смещая значения Elf32_Phdr.p_vaddr на желаемый базовый адрес.

---

---