O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Configurando ART

Esta página descreve como configurar o ART e suas opções de compilação. Os tópicos abordados aqui incluem configuração de pré-compilação da imagem do sistema, opções de compilação dex2oat e como negociar espaço de partição do sistema, espaço de partição de dados e desempenho.

Veja ART e Dalvik , o formato Dalvik Executable , e as páginas restantes no source.android.com para trabalhar com ART. Veja Comportamento Verificando App no Runtime Android (ART) para garantir que seus aplicativos funcionem corretamente.

Como funciona o ART

O ART usa compilação antecipada (AOT) e, a partir do Android 7.0 (Nougat ou N), usa uma combinação híbrida de AOT, compilação just-in-time (JIT) e compilação guiada por perfil. A combinação de todos esses modos de compilação é configurável e será discutida nesta seção. Por exemplo, os dispositivos Pixel são configurados com o seguinte fluxo de compilação:

  1. Um aplicativo é instalado inicialmente sem qualquer compilação AOT. Nas primeiras vezes que o aplicativo for executado, ele será interpretado e os métodos executados com frequência serão compilados em JIT.
  2. Quando o dispositivo está ocioso e carregando, um daemon de compilação é executado para AOT-compilar o código usado com frequência com base em um perfil gerado durante as primeiras execuções.
  3. A próxima reinicialização de um aplicativo usará o código guiado por perfil e evitará a compilação JIT no tempo de execução para métodos já compilados. Os métodos que são compilados por JIT durante as novas execuções serão adicionados ao perfil, que será selecionado pelo daemon de compilação.

ARTE compreende um compilador (a dex2oat ferramenta) e um tempo de execução ( libart.so ) que é carregado para o arranque do zigoto. O dex2oat ferramenta leva um arquivo APK e gera um ou mais arquivos de artefatos de compilação que as cargas de tempo de execução. O número de arquivos, suas extensões e nomes estão sujeitos a alterações entre as versões, mas a partir da versão do Android O, os arquivos sendo gerados são:

  • .vdex : contém o código DEX descompactado do APK, com alguns metadados adicionais para acelerar a verificação.
  • .odex : contém código AOT compilado para métodos na APK.
  • .art (optional) : contém representações internas arte de algumas cordas e classes listadas no APK, usados para inicialização do aplicativo velocidade.

Opções de compilação

As opções de compilação para ART são de duas categorias:

  1. Configuração da ROM do sistema: qual código é compilado AOT ao construir uma imagem do sistema.
  2. Configuração de tempo de execução: como o ART compila e executa aplicativos em um dispositivo.

Uma opção ART núcleo para configurar essas duas categorias é filtros compilador. Filtros compilador conduzir como ART compila código DEX e é uma opção passado para o dex2oat ferramenta. A partir do Android O, existem quatro filtros oficialmente suportados:

  • verificar: somente executar a verificação de código DEX.
  • quicken: executar a verificação de código DEX e otimizar algumas instruções DEX para obter um melhor desempenho intérprete.
  • velocidade: verificação de código de DEX corrida e AOT-compilar todos os métodos.
  • speed-perfil: verificação de código de DEX correr e métodos AOT-compilação listadas em um arquivo de perfil.

Configuração da ROM do sistema

Existem várias opções de construção de ART disponíveis para configurar uma ROM do sistema. Como configurar essas opções depende do espaço de armazenamento disponível para /system eo número de aplicações pré-instaladas. Os JARs / APKs compilados em uma ROM do sistema podem ser divididos em quatro categorias:

  • Código classpath de inicialização: compilado com o filtro compilador velocidade por padrão.
  • Código do servidor sistema: compilado com o filtro compilador velocidade por padrão.
  • Principais aplicações específicas do produto: compilado com o filtro compilador velocidade por padrão.
  • Todas as outras aplicações: compilados com o filtro compilador quicken por padrão.

Opções de makefile

  • WITH_DEXPREOPT
  • Se dex2oat é chamado em código DEX instalado na imagem do sistema. Ativado por padrão.

  • DONT_DEXPREOPT_PREBUILTS (desde Android L)
  • Permitindo DONT_DEXPREOPT_PREBUILTS impede que o prebuilts de ser pré-optimizados. Estes são os aplicativos que têm include $(BUILD_PREBUILT) especificado em seu Android.mk , como o Gmail. Ignorando pré-otimização de aplicativos pré-construídos que são susceptíveis de ser atualizado via Google Play salva /system espaço, mas não adicionar primeiro tempo de inicialização.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (desde 9 de Android)
  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica o filtro compilador padrão para aplicações de pré-optimizados. Estes são os aplicativos que têm include $(BUILD_PREBUILT) especificado em seu Android.mk , como o Gmail. Se não for especificado, o valor padrão é acelerado.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (novo no Android O MR1)
  • Permitindo WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY pré-otimiza apenas o classpath de inicialização e frascos de servidores do sistema.

  • LOCAL_DEX_PREOPT
  • Pré-otimização também pode ser ativado ou desativado em uma base aplicativo individual especificando o LOCAL_DEX_PREOPT opção na definição de módulo. Isso pode ser útil para desativar a pré-otimização de aplicativos que podem receber atualizações do Google Play imediatamente, uma vez que as atualizações tornariam o código pré-otimizado na imagem do sistema obsoleto. Isso também é útil para economizar espaço em OTAs de atualização de versão principal, uma vez que os usuários já podem ter versões mais recentes de aplicativos na partição de dados.

    LOCAL_DEX_PREOPT suporta os valores 'verdadeiro' ou 'falso' para activar ou desactivar a pré-otimização, respectivamente. Além disso, 'nostripping' pode ser especificado se pré-otimização não deve tirar a classes.dex arquivo do APK ou arquivo JAR. Normalmente, este arquivo é removido, pois não é mais necessário após a pré-otimização, mas esta última opção é necessária para permitir que as assinaturas de APK de terceiros permaneçam válidas.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS
  • Passa as opções para dex2oat para controlar como a imagem de inicialização é compilado. Ele pode ser usado para especificar listas de classes de imagens personalizadas, listas de classes compiladas e filtros do compilador.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
  • Transmite opções para dex2oat ao controle como tudo além da imagem de inicialização é compilado.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS
  • Fornece a capacidade de passar dex2oat opções para um determinado módulo e configuração do produto. Ele é definido em um produto device.mk arquivo $(call add-product-dex-preopt-module-config,<modules>,<option>) onde <modules> é uma lista de nomes LOCAL_MODULE e LOCAL_PACKAGE para JAR e APK arquivos, respectivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (New in Android O)
  • Lista de aplicativos que foram identificados como núcleo para os produtos e que são desejáveis para compilar com o filtro compilador velocidade. Por exemplo, aplicativos persistentes como SystemUI têm a chance de usar compilação guiada por perfil apenas na próxima reinicialização, então pode ser melhor para o produto ter esses aplicativos sempre compilados AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android O)
  • Lista de aplicativos carregados pelo servidor do sistema. Estas aplicações serão compilados por padrão com o filtro compilador velocidade.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android O)
  • Se deve incluir uma versão de depuração do ART no dispositivo. Por padrão, isso é habilitado para builds userdebug e eng. O comportamento pode ser substituído, definindo explicitamente a opção de verdadeiro ou falso.

    Por padrão, o dispositivo usará a versão não-debug (libart.so). Para switch, definir a propriedade do sistema persist.sys.dalvik.vm.lib.2 para libartd.so.

  • WITH_DEXPREOPT_PIC (Removed in Android O)
  • No Android 5.1.0 através Android 6.0.1, WITH_DEXPREOPT_PIC pode ser especificado para permitir código independente de posição (PIC). Com isso, o código compilado da imagem não precisa ser realocado de / system para / data / dalvik-cache, economizando espaço na partição de dados. No entanto, há um pequeno impacto no tempo de execução porque desativa uma otimização que tira proveito do código dependente da posição. Normalmente, os dispositivos que desejam economizar espaço em / data devem habilitar a compilação PIC.

    No Android 7.0, a compilação PIC era habilitada por padrão.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (removido no Android O MR1)
  • Esta opção foi substituída por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY que também pré-ativa os jars do servidor do sistema.

Configuração do classpath de inicialização

  • Lista de classes pré-carregadas
  • A lista de classes pré-carregadas é uma lista de classes que o zigoto inicializa na inicialização. Isso evita que cada aplicativo execute esses inicializadores de classe separadamente, permitindo que inicializem com mais rapidez e compartilhem páginas na memória. O arquivo de lista de aulas pré-carregado está localizado na frameworks/base/config/preloaded-classes por padrão, e contém uma lista que está sintonizado para uso do telefone normal. Isso pode ser diferente para outros dispositivos, como wearables, e deve ser ajustado de acordo. Tenha cuidado ao ajustar isso; adicionar muitas classes desperdiça memória quando classes não utilizadas são carregadas. Adicionar poucas classes força cada aplicativo a ter sua própria cópia, o que, novamente, desperdiça memória.

    Exemplo de uso (em device.mk do produto):

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

    Nota: Esta linha deve ser colocado antes de herdar qualquer makefiles de configuração do produto que chegar a um padrão de: build/target/product/base.mk

  • Lista de classes de imagens
  • A lista de classes de imagem é uma lista de classes que dex2oat inicializa antecipadamente e armazena no arquivo boot.art. Isso permite que o zigoto carregue esses resultados do arquivo boot.art na inicialização, em vez de executar os inicializadores para essas classes durante o pré-carregamento. Uma característica importante disso é que as páginas carregadas da imagem e compartilhadas entre os processos podem ser limpas, permitindo que sejam trocadas facilmente em situações de pouca memória. Em L, por padrão, a lista de classes de imagem usa a mesma lista que a lista de classes pré-carregadas. A partir do pós-L no AOSP, uma lista de classes de imagens personalizadas pode ser especificada usando:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Exemplo utilização (no produto de device.mk ):

    PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename>
    
  • Lista Compilada de Classes
  • No AOSP pós-L, um subconjunto de classes do caminho de classe de inicialização pode ser especificado para ser compilado durante a pré-otimização usando a lista de classes compiladas. Essa pode ser uma opção útil para dispositivos com pouco espaço e que não cabem em toda a imagem de inicialização pré-otimizada. No entanto, observe que as classes não especificadas nesta lista não serão compiladas - nem mesmo no dispositivo - e devem ser interpretadas, afetando potencialmente o desempenho do tempo de execução. Por padrão, dex2oat irá procurar por uma lista de classes compilada em $ OUT / system / etc / compiled-classes, então uma lista personalizada pode ser copiada para aquele local pelo device.mk. A localização do ficheiro em particular também podem ser especificados usando:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    

    Exemplo de utilização (no produto de device.mk ):

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

    Nota: Esta linha deve ser colocado antes de herdar qualquer makefiles de configuração do produto que chegar a um padrão de: build/target/product/base.mk

Configuração de tempo de execução

Opções Jit

As opções a seguir afetam as versões do Android apenas onde o compilador ART JIT está disponível.

  • dalvik.vm.usejit: se o JIT está habilitado ou não.
  • dalvik.vm.jitinitialsize (padrão 64K): a capacidade inicial do cache de código. O cache do código irá regularmente GC e aumentará se necessário.
  • dalvik.vm.jitmaxsize (padrão 64M): a capacidade máxima do cache de código.
  • dalvik.vm.jitthreshold: (padrão 10000) - Este é o limite que o contador "hotness" de um método precisa passar para que o método seja compilado JIT. O contador de "calor" é uma métrica interna do tempo de execução. Inclui o número de chamadas, ramificações anteriores e outros fatores.
  • dalvik.vm.usejitprofiles: se os perfis JIT estão habilitados ou não; isso pode ser usado mesmo se dalvik.vm.usejit for falso. Nota que, se isso é falso, o filtro compilador de velocidade de perfil não AOT-compilar qualquer método e é equivalente a acelerar.
  • dalvik.vm.jitprithreadweight (padrão para dalvik.vm.jitthreshold / 20) - O peso das "amostras" JIT (consulte jitthreshold) para o thread de IU do aplicativo. Use para acelerar a compilação de métodos que afetam diretamente a experiência do usuário ao interagir com o aplicativo.
  • dalvik.vm.jittransitionweight: (padrão para dalvik.vm.jitthreshold / 10) o peso da invocação do método que faz a transição entre o código de compilação e o interpretador. Isso ajuda a garantir que os métodos envolvidos sejam compilados para minimizar as transições (que são caras).

Opções do gerenciador de pacotes

Desde o Android 7.0, existe uma maneira genérica de especificar o nível de compilação / verificação que ocorreu em vários estágios. Os níveis de compilação podem ser configurados por meio das propriedades do sistema com os padrões sendo:

  • pm.dexopt.install=speed-profile
  • Este é o filtro de compilação usado ao instalar aplicativos por meio do Google Play. Recomendamos que o filtro de instalação seja definido como perfil de velocidade para permitir o uso de perfis dos arquivos de metadados dex. Observe que, se um perfil não for fornecido ou se estiver vazio, o perfil de velocidade é equivalente a quicken.

  • pm.dexopt.bg-dexopt=speed-profile
  • Este é o filtro de compilação usado quando o dispositivo está ocioso, carregando e totalmente carregado. Experimente o filtro compilador de velocidade de perfil para aproveitar compilação guiada por perfil e economizar no armazenamento.

  • pm.dexopt.boot=verify
  • O filtro de compilação usado após uma atualização over-the-air. Recomendamos fortemente a verificar filtro compilador para essa opção para evitar os tempos de inicialização muito longos.

  • pm.dexopt.first-boot=quicken
  • O filtro de compilação pela primeira vez que o dispositivo é inicializado. O filtro usado aqui afetará apenas o tempo de inicialização após a fábrica. Recomendamos o filtro acelerar para ele para evitar longos tempos antes que um usuário começa a usar o telefone pela primeira vez. Nota que, se todas as aplicações em /system já são compilados com o filtro compilador Quicken ou são compilados com o filtro de velocidade ou velocidade-profile compilador, o pm.dexopt.first-boot não tem efeito.

Opções Dex2oat

Note-se que estas opções afetam dex2oat durante a compilação no dispositivo, bem como durante a pré-otimização, enquanto a maioria das opções discutidas acima afetam apenas pré-otimização.

Para controlar dex2oat enquanto ele está compilando a imagem de inicialização:

  • dalvik.vm.image-dex2oat-Xms: tamanho de heap inicial
  • dalvik.vm.image-dex2oat-Xmx: tamanho máximo de heap
  • dalvik.vm.image-dex2oat-filter: opção de filtro do compilador
  • dalvik.vm.image-dex2oat-threads: número de threads a serem usados

Para controlar dex2oat enquanto ele está compilando tudo além da imagem de inicialização:

  • dalvik.vm.dex2oat-Xms: tamanho de heap inicial
  • dalvik.vm.dex2oat-Xmx: tamanho máximo de heap
  • dalvik.vm.dex2oat-filter: opção de filtro do compilador

Em versões até o Android 6.0, uma opção adicional é fornecida para compilar tudo além da imagem de inicialização:

  • dalvik.vm.dex2oat-threads: número de threads a serem usados

A partir do Android 6.1, isso se torna duas opções adicionais para compilar tudo além da imagem de inicialização:

  • dalvik.vm.boot-dex2oat-threads: número de threads a serem usados ​​durante o tempo de inicialização
  • dalvik.vm.dex2oat-threads: número de threads a serem usados ​​após o tempo de inicialização

A partir do Android 7.1, duas opções são fornecidas para controlar como a memória é usada ao compilar tudo além da imagem de inicialização:

  • dalvik.vm.dex2oat-very-large: tamanho total mínimo do arquivo dex em bytes para desativar a compilação AOT
  • dalvik.vm.dex2oat-swap: use o arquivo de troca dex2oat (para dispositivos com pouca memória)

As opções que controlam o tamanho inicial e máximo de heap para dex2oat não deve ser reduzida, uma vez que poderia limitar o que as aplicações podem ser compilados.

A partir do Android 11, três opções de afinidade de CPU são fornecidas para permitir que os threads do compilador sejam restritos a um grupo específico de CPUs:

  • dalvik.vm.boot-dex2oat-cpu-set: CPUs executando threads dex2oat durante o tempo de inicialização
  • dalvik.vm.image-dex2oat-cpu-set: CPUs executando dex2oat durante a compilação da imagem de inicialização
  • dalvik.vm.dex2oat-cpu-set: CPUs executando threads dex2oat após o tempo de inicialização

As CPUs devem ser especificadas como uma lista separada por vírgulas de IDs de CPU. Por exemplo, para executar em dex2oat nas CPUs 0-3, defina:

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

Ao definir as propriedades de afinidade da CPU, recomendamos combinar a propriedade correspondente para o número de threads dex2oat para corresponder ao número de CPUs selecionadas para evitar memória desnecessária e contenção de E / S:

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

A partir do Android 12, as seguintes opções foram adicionadas:

  • dalvik.vm.ps-min-first-save-ms: o tempo de espera pelo tempo de execução para gerar um perfil do aplicativo, a primeira vez que o aplicativo é iniciado
  • dalvik.vm.ps-min-save-period-ms: o tempo mínimo de espera antes de atualizar o perfil de um aplicativo
  • dalvik.vm.systemservercompilerfilter: o filtro do compilador que o dispositivo usará ao recompilar o servidor do sistema

Configuração específica A / B

Configuração de ROM

A partir de Android 7.0, os dispositivos podem usar duas partições do sistema para permitir atualizações do sistema A / B . Para economizar no tamanho da partição do sistema, os arquivos pré-selecionados podem ser instalados na segunda partição do sistema não utilizada. Eles são então copiados para a partição de dados na primeira inicialização.

Exemplo de utilização (em device-common.mk ):

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

E no dispositivo é BoardConfig.mk :

BOARD_USES_SYSTEM_OTHER_ODEX := true

Observe que o código do caminho de classe de inicialização, o código do servidor do sistema e os aplicativos principais específicos do produto sempre são compilados na partição do sistema. Por padrão, todos os outros aplicativos são compilados na segunda partição do sistema não utilizada. Isto pode ser controlado com o SYSTEM_OTHER_ODEX_FILTER , que tem um valor por defeito de:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Background dexopt OTA

Com dispositivos habilitados para A / B, os aplicativos podem ser compilados em segundo plano para atualização para a nova imagem do sistema. Veja compilação App no fundo para incluir opcionalmente o script compilação e binários na imagem do sistema. O filtro de compilação usado para esta compilação é controlado com:

pm.dexopt.ab-ota=speed-profile

Recomendamos a utilização de velocidade de perfil para tirar proveito de perfil guiada compilação e economizar em armazenamento.