Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Configuración de ART

Esta página explica cómo configurar ART y sus opciones de compilación. Los temas que se tratan aquí incluyen la configuración de la compilación previa de la imagen del sistema, las opciones de compilación de dex2oat y cómo compensar el espacio de la partición del sistema, el espacio de la partición de datos y el rendimiento.

Ver ART y Dalvik , el formato Dalvik ejecutable , y las páginas restantes en source.android.com para trabajar con ART. Ver Comportamiento Verificación de la App en el tiempo de ejecución de Android (ART) para asegurar que sus aplicaciones funcionan correctamente.

Cómo funciona ART

ART utiliza la compilación anticipada (AOT) y, a partir de Android 7.0 (Nougat o N), utiliza una combinación híbrida de AOT, compilación just-in-time (JIT) y compilación guiada por perfiles. La combinación de todos estos modos de compilación es configurable y se discutirá en esta sección. Como ejemplo, los dispositivos Pixel se configuran con el siguiente flujo de compilación:

  1. Una aplicación se instala inicialmente sin ninguna compilación AOT. Las primeras veces que se ejecute la aplicación, se interpretará y los métodos que se ejecuten con frecuencia se compilarán con JIT.
  2. Cuando el dispositivo está inactivo y se está cargando, se ejecuta un demonio de compilación para compilar el código de uso frecuente basado en un perfil generado durante las primeras ejecuciones.
  3. El próximo reinicio de una aplicación utilizará el código guiado por perfil y evitará la compilación JIT en tiempo de ejecución para métodos ya compilados. Los métodos que se compilan con JIT durante las nuevas ejecuciones se agregarán al perfil, que luego será recogido por el demonio de compilación.

ART comprende un compilador (el dex2oat herramienta) y un tiempo de ejecución ( libart.so ) que se carga para el arranque del cigoto. El dex2oat herramienta toma un archivo APK y genera uno o más archivos de compilación de artefactos que las cargas de tiempo de ejecución. La cantidad de archivos, sus extensiones y los nombres están sujetos a cambios en las versiones, pero a partir de la versión de Android O, los archivos que se generan son:

  • .vdex : contiene el código DEX sin comprimir de la APK, con un poco de metadatos adicionales para acelerar la verificación.
  • .odex : contiene el código AOT compilado por métodos en el APK.
  • .art (optional) : contiene representaciones internas arte de algunas cadenas y clases enumeradas en la APK, utilizados para inicio de la aplicación velocidad.

Opciones de compilación

Las opciones de compilación para ART son de dos categorías:

  1. Configuración de la ROM del sistema: qué código se compila con AOT al crear una imagen del sistema.
  2. Configuración en tiempo de ejecución: cómo ART compila y ejecuta aplicaciones en un dispositivo.

Una opción núcleo ART para configurar estas dos categorías son los filtros del compilador. Filtros compilador coche cómo el arte y compila el código DEX es una opción pasa a la dex2oat herramienta. A partir de Android O, hay cuatro filtros compatibles oficialmente:

  • verificar: sólo se ejecutan código de verificación DEX.
  • aceleraba: ejecutar la verificación del código DEX y optimizar algunas instrucciones DEX para conseguir un mejor rendimiento intérprete.
  • velocidad: la verificación del código de ejecución DEX y AOT-compilar todos los métodos.
  • la velocidad de perfil: verificación de código de gestión de DEX y los métodos de compilación AOT-enumeradas en un archivo de perfil.

Configuración de ROM del sistema

Hay varias opciones de compilación ART disponibles para configurar una ROM del sistema. Cómo configurar estas opciones depende del espacio de almacenamiento disponible para el /system y el número de aplicaciones preinstaladas. Los archivos JAR / APK que se compilan en una ROM del sistema se pueden dividir en cuatro categorías:

  • Boot código ruta de clases: compilado con el compilador de filtro de velocidad por defecto.
  • Código de servidor del sistema: compilado con el compilador de filtro de velocidad por defecto.
  • Aplicaciones básicas específicas del producto: compilado con el compilador de filtro de la velocidad por defecto.
  • Todas las demás aplicaciones: compilados con el filtro compilador aceleraba de forma predeterminada.

Opciones de Makefile

  • WITH_DEXPREOPT
  • Ya sea dex2oat se invoca el código de DEX instalado en la imagen del sistema. Habilitado por defecto.

  • DONT_DEXPREOPT_PREBUILTS (desde Android L)
  • Habilitación DONT_DEXPREOPT_PREBUILTS impide que el prebuilts de ser pre-optimizado. Estas son aplicaciones que tengan include $(BUILD_PREBUILT) especificado en su Android.mk , como Gmail. Saltarse pre-optimización de aplicaciones predefinidos que pueden ser actualizados a través de Google Play ahorra /system espacio, sino que se le añade al primer momento del arranque.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (desde Android 9)
  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica el filtro compilador por defecto para las aplicaciones pre-optimizado. Estas son aplicaciones que tengan include $(BUILD_PREBUILT) especificado en su Android.mk , como Gmail. Si no se especifica, el valor predeterminado se acelera.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (nuevo en Android O MR1)
  • Permitiendo WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY pre-optimiza únicamente la ruta de clases de arranque y frascos de servidor del sistema.

  • LOCAL_DEX_PREOPT
  • Pre-optimización también puede ser activada o desactivada de forma individual mediante aplicación especificando el LOCAL_DEX_PREOPT opción en la definición del módulo. Esto puede ser útil para deshabilitar la optimización previa de aplicaciones que pueden recibir actualizaciones de Google Play de inmediato, ya que las actualizaciones dejarían obsoleto el código optimizado previamente en la imagen del sistema. Esto también es útil para ahorrar espacio en las OTA de actualización de versiones principales, ya que es posible que los usuarios ya tengan versiones más nuevas de aplicaciones en la partición de datos.

    LOCAL_DEX_PREOPT es compatible con los valores 'verdadero' o 'falso' para activar o desactivar pre-optimización, respectivamente. Además, 'nostripping' se puede especificar si antes de la optimización no debe pelar el classes.dex archivo desde el archivo JAR o APK. Normalmente, este archivo se elimina porque ya no es necesario después de la optimización previa, pero esta última opción es necesaria para permitir que las firmas APK de terceros sigan siendo válidas.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS
  • Pasa las opciones de dex2oat para controlar cómo se compila la imagen de arranque. Se puede utilizar para especificar listas de clases de imágenes personalizadas, listas de clases compiladas y filtros de compilación.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
  • Pasa las opciones dex2oat al control de cómo todo la imagen de arranque, además se compila.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS
  • Proporciona la capacidad de pasar dex2oat opciones para un módulo particular y la configuración del producto. Está situado en un producto de device.mk archivo por $(call add-product-dex-preopt-module-config,<modules>,<option>) donde <modules> es una lista de nombres y LOCAL_MODULE LOCAL_PACKAGE de JAR y APK archivos, respectivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (New in Android O)
  • Lista de aplicaciones que han sido identificados como núcleo de los productos y que son deseables para compilar con el filtro compilador de velocidad. Por ejemplo, las aplicaciones persistentes como SystemUI tienen la oportunidad de usar la compilación guiada por perfil solo en el próximo reinicio, por lo que puede ser mejor para el producto tener estas aplicaciones siempre compiladas con AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android O)
  • Lista de aplicaciones cargadas por el servidor del sistema. Estas aplicaciones serán compilados por defecto con el filtro compilador de velocidad.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android O)
  • Si se debe incluir una versión de depuración de ART en el dispositivo. De forma predeterminada, esto está habilitado para las compilaciones userdebug y eng. El comportamiento puede ser anulado por establecer explícitamente la opción de verdadero o falso.

    De manera predeterminada, el dispositivo utilizará la versión no depuración (libart.so). Al interruptor, establezca la propiedad del sistema persist.sys.dalvik.vm.lib.2 a libartd.so.

  • WITH_DEXPREOPT_PIC (Removed in Android O)
  • En Android 5.1.0 a través de Android 6.0.1, WITH_DEXPREOPT_PIC puede ser especificado para permitir código independiente de la posición (PIC). Con esto, el código compilado de la imagen no tiene que ser reubicado de / system a / data / dalvik-cache, ahorrando espacio en la partición de datos. Sin embargo, hay un ligero impacto en el tiempo de ejecución porque deshabilita una optimización que aprovecha el código dependiente de la posición. Por lo general, los dispositivos que desean ahorrar espacio en / data deben habilitar la compilación de PIC.

    En Android 7.0, la compilación PIC estaba habilitada de forma predeterminada.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (eliminado en Android O MR1)
  • Esta opción fue reemplazada por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY que también preopta los archivos jar del servidor del sistema.

Configuración de classpath de arranque

  • Lista de clases precargadas
  • La lista de clases precargadas es una lista de clases que el cigoto inicializa al inicio. Esto evita que cada aplicación tenga que ejecutar estos inicializadores de clase por separado, lo que les permite iniciarse más rápido y compartir páginas en la memoria. El archivo de lista de clases precargado se encuentra en frameworks/base/config/preloaded-classes por defecto, y contiene una lista que está afinado para el uso del teléfono típico. Esto puede ser diferente para otros dispositivos, como los wearables, y debe ajustarse en consecuencia. Tenga cuidado al ajustar esto; agregar demasiadas clases desperdicia memoria cuando se cargan las clases no utilizadas. Agregar muy pocas clases obliga a cada aplicación a tener su propia copia, lo que nuevamente desperdicia memoria.

    Uso de ejemplo (en device.mk del producto):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes
    

    Nota: Esta línea debe colocarse antes de heredar ningún archivos make de configuración de productos que consiguen el defecto de: build/target/product/base.mk

  • Lista de clases de imágenes
  • La lista de clases de imágenes es una lista de clases que dex2oat inicializa con anticipación y almacena en el archivo boot.art. Esto permite que el cigoto cargue estos resultados desde el archivo boot.art al inicio en lugar de ejecutar los inicializadores para estas clases durante la precarga. Una característica clave de esto es que las páginas cargadas desde la imagen y compartidas entre procesos se pueden limpiar, lo que permite intercambiarlas fácilmente en situaciones de poca memoria. En L, de forma predeterminada, la lista de clases de imágenes usa la misma lista que la lista de clases precargadas. A partir de post-L en AOSP, se puede especificar una lista de clases de imágenes personalizadas usando:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Uso Ejemplo (en de producto device.mk ):

    PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename>
    
  • Lista de clases compiladas
  • En AOSP posterior a L, se puede especificar un subconjunto de clases de la ruta de clases de arranque para que se compile durante la optimización previa utilizando la lista de clases compiladas. Esta puede ser una opción útil para dispositivos que tienen muy poco espacio y no pueden ajustarse a toda la imagen de inicio optimizada previamente. Sin embargo, las clases de notas no especificadas en esta lista no se compilarán, ni siquiera en el dispositivo, y deben interpretarse, lo que podría afectar el rendimiento en tiempo de ejecución. De forma predeterminada, dex2oat buscará una lista de clases compiladas en $ OUT / system / etc / compiled-classes, por lo que device.mk puede copiar una personalizada en esa ubicación. Una ubicación de archivo en particular también puede ser especificado usando:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Ejemplo de uso (en de producto device.mk ):

    PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes
    

    Nota: Esta línea debe colocarse antes de heredar ningún archivos make de configuración de productos que consiguen el defecto de: build/target/product/base.mk

Configuración en tiempo de ejecución

Opciones de Jit

Las siguientes opciones afectan a las versiones de Android solo donde el compilador ART JIT está disponible.

  • dalvik.vm.usejit: si el JIT está habilitado o no.
  • dalvik.vm.jitinitialsize (predeterminado 64K): la capacidad inicial de la caché de código. La caché de código se recopilará periódicamente y aumentará si es necesario.
  • dalvik.vm.jitmaxsize (predeterminado 64M): la capacidad máxima de la caché de código.
  • dalvik.vm.jitthreshold: (predeterminado 10000): este es el umbral que debe pasar el contador de "picor" de un método para que el método se compile con JIT. El contador de "calor" es una métrica interna del tiempo de ejecución. Incluye el número de llamadas, ramas hacia atrás y otros factores.
  • dalvik.vm.usejitprofiles: si los perfiles JIT están habilitados o no; esto puede usarse incluso si dalvik.vm.usejit es falso. Tenga en cuenta que si esto es falso, el filtro compilador velocidad perfil no AOT-compilar cualquier método y es equivalente a acelerarse.
  • dalvik.vm.jitprithreadweight (predeterminado en dalvik.vm.jitthreshold / 20): el peso de las "muestras" de JIT (consulte jitthreshold) para el subproceso de la interfaz de usuario de la aplicación. Úselo para acelerar la compilación de métodos que afectan directamente la experiencia de los usuarios cuando interactúan con la aplicación.
  • dalvik.vm.jittransitionweight: (predeterminado en dalvik.vm.jitthreshold / 10) el peso de la invocación del método que cambia entre el código de compilación y el intérprete. Esto ayuda a garantizar que los métodos involucrados se compilen para minimizar las transiciones (que son costosas).

Opciones del administrador de paquetes

Desde Android 7.0, existe una forma genérica de especificar el nivel de compilación / verificación que ocurrió en varias etapas. Los niveles de compilación se pueden configurar a través de las propiedades del sistema con los valores predeterminados:

  • pm.dexopt.install=speed-profile
  • Este es el filtro de compilación que se utiliza al instalar aplicaciones a través de Google Play. Recomendamos que el filtro de instalación se establezca en speed-profile para permitir el uso de perfiles de los archivos de metadatos dex. Tenga en cuenta que si no se proporciona un perfil o si está vacío, el perfil de velocidad es equivalente a quicken.

  • pm.dexopt.bg-dexopt=speed-profile
  • Este es el filtro de compilación que se utiliza cuando el dispositivo está inactivo, cargando y completamente cargado. Pruebe el filtro compilador velocidad de perfil para tomar ventaja de la compilación guiada por perfiles y ahorrar en almacenamiento.

  • pm.dexopt.boot=verify
  • El filtro de compilación utilizado después de una actualización inalámbrica. Es muy recomendable verificar el filtro de compilador para esta opción para evitar los tiempos de arranque muy largos.

  • pm.dexopt.first-boot=quicken
  • El filtro de compilación por primera vez que se inicia el dispositivo. El filtro utilizado aquí solo afectará el tiempo de arranque después de la fábrica. Recomendamos el filtro acelerar para que pueda evitar largos tiempos antes de que un usuario llega a utilizar el teléfono por primera vez. Tenga en cuenta que si todas las aplicaciones de /system Ya se compilan con el filtro compilador aceleraba o se compilan con el filtro de velocidad o la velocidad de perfil compilador, el pm.dexopt.first-boot no tiene ningún efecto.

Opciones de Dex2oat

Tenga en cuenta que estas opciones afectan dex2oat durante la compilación en el dispositivo, así como durante la pre-optimización, mientras que la mayoría de las opciones comentadas anteriormente sólo afectará a la validez de la optimización.

Para controlar dex2oat mientras se está compilando la imagen de arranque:

  • dalvik.vm.image-dex2oat-Xms: tamaño de pila inicial
  • dalvik.vm.image-dex2oat-Xmx: tamaño máximo de pila
  • dalvik.vm.image-dex2oat-filter: opción de filtro del compilador
  • dalvik.vm.image-dex2oat-threads: número de hilos a utilizar

Para controlar dex2oat mientras se está compilando todo la imagen de arranque, además:

  • dalvik.vm.dex2oat-Xms: tamaño de pila inicial
  • dalvik.vm.dex2oat-Xmx: tamaño máximo de pila
  • dalvik.vm.dex2oat-filter: opción de filtro del compilador

En las versiones a través de Android 6.0, se proporciona una opción adicional para compilar todo, además de la imagen de arranque:

  • dalvik.vm.dex2oat-threads: número de hilos a utilizar

A partir de Android 6.1, esto se convierte en dos opciones adicionales para compilar todo, además de la imagen de arranque:

  • dalvik.vm.boot-dex2oat-threads: número de subprocesos que se utilizarán durante el arranque
  • dalvik.vm.dex2oat-threads: número de subprocesos que se utilizarán después del arranque

A partir de Android 7.1, se proporcionan dos opciones para controlar cómo se usa la memoria al compilar todo, además de la imagen de arranque:

  • dalvik.vm.dex2oat-very-large: tamaño mínimo total de archivo dex en bytes para deshabilitar la compilación AOT
  • dalvik.vm.dex2oat-swap: use el archivo de intercambio dex2oat (para dispositivos con poca memoria)

Las opciones que controlan el tamaño inicial y máximo del montón de dex2oat no deben ser reducidos ya que podrían limitar qué aplicaciones puede ser compilado.

A partir de Android 11, se proporcionan tres opciones de afinidad de CPU para permitir que los subprocesos del compilador se restrinjan a un grupo específico de CPU:

  • dalvik.vm.boot-dex2oat-cpu-set: CPU que ejecutan subprocesos dex2oat durante el tiempo de arranque
  • dalvik.vm.image-dex2oat-cpu-set: CPU que ejecutan dex2oat mientras compilan la imagen de arranque
  • dalvik.vm.dex2oat-cpu-set: CPU que ejecutan subprocesos dex2oat después del arranque

Las CPU deben especificarse como una lista de identificadores de CPU separados por comas. Por ejemplo, para ejecutar dex2oat en las CPU 0-3, configure:

dalvik.vm.dex2oat-cpu-set=0,1,2,3

Al configurar las propiedades de afinidad de la CPU, recomendamos hacer coincidir la propiedad correspondiente para el número de subprocesos dex2oat para que coincida con el número de CPU seleccionadas para evitar memoria innecesaria y contención de E / S:

dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

A partir de Android 12, se agregaron las siguientes opciones:

  • dalvik.vm.ps-min-first-save-ms: el tiempo de espera para que el tiempo de ejecución genere un perfil de la aplicación, la primera vez que se inicia la aplicación
  • dalvik.vm.ps-min-save-period-ms: el tiempo mínimo de espera antes de actualizar el perfil de una aplicación
  • dalvik.vm.systemservercompilerfilter: el filtro del compilador que usará el dispositivo al recompilar el servidor del sistema

Configuración específica A / B

Configuración de ROM

A partir de Android 7.0, los dispositivos pueden utilizar dos particiones del sistema para permitir las actualizaciones del sistema A / B . Para ahorrar en el tamaño de la partición del sistema, los archivos seleccionados previamente se pueden instalar en la segunda partición del sistema no utilizada. Luego se copian en la partición de datos en el primer arranque.

Ejemplo de uso (en device-common.mk ):

PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

Y en el dispositivo del BoardConfig.mk :

BOARD_USES_SYSTEM_OTHER_ODEX := true

Tenga en cuenta que el código de ruta de clase de arranque, el código del servidor del sistema y las aplicaciones centrales específicas del producto siempre se compilan en la partición del sistema. De forma predeterminada, todas las demás aplicaciones se compilan en la segunda partición del sistema no utilizada. Esto puede ser controlado con el SYSTEM_OTHER_ODEX_FILTER , que tiene un valor por defecto de:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Fondo dexopt OTA

Con dispositivos habilitados para A / B, las aplicaciones se pueden compilar en segundo plano para actualizar a la nueva imagen del sistema. Ver App de compilación en segundo plano para incluir opcionalmente la secuencia de comandos de compilación y los binarios de la imagen del sistema. El filtro de compilación utilizado para esta compilación se controla con:

pm.dexopt.ab-ota=speed-profile

Recomendamos el uso de la velocidad de perfil para aprovechar el perfil guiada compilación y ahorrar en almacenamiento.