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

Esta página foi traduzida pela API Cloud Translation.

Otimizando os tempos de inicialização

Este documento fornece orientações aos parceiros para melhorar os tempos de inicialização de dispositivos Android específicos. O tempo de inicialização é um componente importante do desempenho do sistema, pois os usuários devem aguardar a conclusão da inicialização antes de poderem usar o dispositivo. Para dispositivos como carros onde a inicialização a frio acontece com mais frequência, ter um tempo de inicialização rápido é fundamental (ninguém gosta de esperar dezenas de segundos apenas para inserir um destino de navegação).

O Android 8.0 permite tempos de inicialização reduzidos ao oferecer suporte a várias melhorias em vários componentes. A tabela a seguir resume essas melhorias de desempenho (conforme medidas em dispositivos Google Pixel e Pixel XL).

Componente	Melhoria
Bootloader	Economizei 1,6s removendo o log UART Economizou 0,4s mudando para LZ4 de GZIP
Kernel do dispositivo	Economizou 0,3s removendo configurações de kernel não utilizadas e reduzindo o tamanho do driver Economizou 0,3s com otimização de pré-busca dm-verity Economizou 0,15s para remover espera/teste desnecessários no driver Salvou 0,12s para remover CONFIG_CC_OPTIMIZE_FOR_SIZE
Ajuste de E/S	2s salvos na inicialização normal Economizou 25s na primeira inicialização
init.*.rc	Economizou 1,5 s ao paralelizar os comandos init Economizou 0,25s ao iniciar o zigoto cedo 0,22s salvo pelo cpuset tune
Animação de inicialização	Iniciado 2s antes na inicialização sem fsck acionado, muito maior na inicialização com inicialização acionada por fsck 5s salvos no Pixel XL com desligamento imediato da animação de inicialização
Política SELinux	Salvo 0,2s por genfscon

Otimizando o Bootloader

Para otimizar o bootloader para tempos de inicialização aprimorados:

Para logar:
- Desative a gravação de log no UART, pois pode levar muito tempo com muitos logs. (Nos dispositivos Google Pixel, descobrimos que diminui a velocidade do bootloader 1.5s).
- Registre apenas situações de erro e considere armazenar outras informações na memória com um mecanismo separado para recuperação.
Para descompressão do kernel, considere usar LZ4 para hardware contemporâneo em vez de GZIP (exemplo de patch ). Lembre-se de que diferentes opções de compactação do kernel podem ter tempos de carregamento e descompactação diferentes, e algumas opções podem funcionar melhor do que outras para seu hardware específico.
Verifique os tempos de espera desnecessários para entrada de modo especial/debouncing e minimize-os.
Passe o tempo de inicialização gasto no bootloader para o kernel como cmdline.
Verifique o clock da CPU e considere a paralelização (requer suporte multi-core) para carregar o kernel e inicializar a E/S.

Otimizando Kernel

Use as dicas a seguir para otimizar o kernel para tempos de inicialização aprimorados.

Minimizando o defconfig do dispositivo

Minimizar a configuração do kernel pode reduzir o tamanho do kernel para descompressão de carregamento mais rápida, inicialização e superfícies de ataque menores. Para otimizar o defconfig do dispositivo:

Identifique drivers não utilizados . Revise os /dev e /sys e procure por nós com rótulos SELinux gerais (o que indica que esses nós não estão configurados para serem acessíveis pelo espaço do usuário). Remova esses nós, se encontrados.

Desativar CONFIGs não utilizados . Revise o arquivo .config gerado pela compilação do kernel para desmarcar explicitamente qualquer CONFIG não utilizado que foi ativado por padrão. Por exemplo, removemos os seguintes CONFIGs não utilizados do Google Pixel:

CONFIG_ANDROID_LOGGER=y
CONFIG_IMX134=y
CONFIG_IMX132=y
CONFIG_OV9724=y
CONFIG_OV5648=y
CONFIG_GC0339=y
CONFIG_OV8825=y
CONFIG_OV8865=y
CONFIG_s5k4e1=y
CONFIG_OV12830=y
CONFIG_USB_EHCI_HCD=y
CONFIG_IOMMU_IO_PGTABLE_FAST_SELFTEST=y
CONFIG_IKCONFIG=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_TI_DRV2667=y
CONFIG_CHR_DEV_SCH=y
CONFIG_MMC=y
CONFIG_MMC_PERF_PROFILING=y
CONFIG_MMC_CLKGATE=y
CONFIG_MMC_PARANOID_SD_INIT=y
CONFIG_MMC_BLOCK_MINORS=32
CONFIG_MMC_TEST=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_MMC_SDHCI_MSM_ICE=y
CONFIG_MMC_CQ_HCI=y
CONFIG_MSDOS_FS=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_EEPROM_AT24=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_HBTP_INPUT=y
# CONFIG_VGA_ARB is not set
CONFIG_USB_MON=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_STORAGE_CYPRESS_ATACB=y
CONFIG_SW_SYNC_USER=y
CONFIG_SEEMP_CORE=y
CONFIG_MSM_SMEM_LOGGING=y
CONFIG_IOMMU_DEBUG=y
CONFIG_IOMMU_DEBUG_TRACKING=y
CONFIG_IOMMU_TESTS=y
CONFIG_MOBICORE_DRIVER=y
# CONFIG_DEBUG_PREEMPT is not set

Remova CONFIGs que levam a execuções de teste desnecessárias em cada inicialização . Embora útil no desenvolvimento, tais configurações (ou seja, CONFIG_IOMMU_IO_PGTABLE_FAST_SELFTEST) devem ser removidas em um kernel de produção.

Minimizando o tamanho do driver

Alguns drivers no kernel do dispositivo podem ser removidos se a função não for usada para reduzir ainda mais o tamanho do kernel. Por exemplo, se a WLAN estiver conectada por meio de PCIe, o suporte SDIO não será usado e deverá ser removido durante o tempo de compilação. Para obter detalhes, consulte o kernel do Google Pixel: net: wireless: cnss: add opção para desabilitar o suporte SDIO.

Removendo a otimização do compilador para tamanho

Remova a configuração do kernel para CONFIG_CC_OPTIMIZE_FOR_SIZE. Esse sinalizador foi originalmente introduzido quando a suposição era de que um tamanho de código menor geraria hit de hot cache (e, portanto, seria mais rápido). No entanto, essa suposição não é mais válida, pois os SoCs móveis modernos se tornaram mais poderosos.

Além disso, remover o sinalizador pode habilitar o aviso do compilador para variáveis não inicializadas, que é suprimido em kernels Linux quando o sinalizador CONFIG_CC_OPTIMIZE_FOR_SIZE está presente (fazer essa alteração sozinha nos ajudou a descobrir muitos bugs significativos em alguns drivers de dispositivos Android).

Adiando a inicialização

Muitos processos são iniciados durante a inicialização, mas apenas os componentes no caminho crítico (bootloader > kernel > init > montagem do sistema de arquivos > zygote > servidor do sistema) afetam diretamente o tempo de inicialização. Perfil initcall durante a inicialização do kernel para identificar periféricos/componentes que são lentos e não críticos para iniciar o processo de inicialização e, em seguida, atrase esses periféricos/componentes até mais tarde no processo de inicialização, movendo-se para módulos de kernel carregáveis. Mover para o probe dispositivo/driver assíncrono também pode ajudar a colocar em paralelo componentes lentos no kernel > init caminho crítico.

BoardConfig-common.mk:
    BOARD_KERNEL_CMDLINE += initcall_debug ignore_loglevel

driver:
    .probe_type = PROBE_PREFER_ASYNCHRONOUS,

Nota: As dependências do driver devem ser resolvidas com cuidado adicionando o suporte EPROBEDEFER .

Otimizando a eficiência de E/S

Melhorar a eficiência de E/S é fundamental para tornar o tempo de inicialização mais rápido, e a leitura de qualquer coisa desnecessária deve ser adiada até depois da inicialização (em um Google Pixel, cerca de 1,2 GB de dados são lidos na inicialização).

Ajustando o sistema de arquivos

A leitura antecipada do kernel do Linux entra em ação quando um arquivo é lido desde o início ou quando os blocos são lidos sequencialmente, tornando necessário ajustar os parâmetros do agendador de E/S especificamente para inicialização (que tem uma caracterização de carga de trabalho diferente das aplicações normais).

Os dispositivos que suportam atualizações contínuas (A/B) se beneficiam muito do ajuste do sistema de arquivos na primeira inicialização (por exemplo, 20s no Google Pixel). Como exemplo, ajustamos os seguintes parâmetros para o Google Pixel:

on late-fs
  # boot time fs tune
    # boot time fs tune
    write /sys/block/sda/queue/iostats 0
    write /sys/block/sda/queue/scheduler cfq
    write /sys/block/sda/queue/iosched/slice_idle 0
    write /sys/block/sda/queue/read_ahead_kb 2048
    write /sys/block/sda/queue/nr_requests 256
    write /sys/block/dm-0/queue/read_ahead_kb 2048
    write /sys/block/dm-1/queue/read_ahead_kb 2048

on property:sys.boot_completed=1
    # end boot time fs tune
    write /sys/block/sda/queue/read_ahead_kb 512
    ...

Diversos

Ative o tamanho de pré-busca de hash dm-verity usando a configuração do kernel DM_VERITY_HASH_PREFETCH_MIN_SIZE (o tamanho padrão é 128).
Para melhor estabilidade do sistema de arquivos e uma verificação forçada que ocorre em cada inicialização, use a nova ferramenta de geração ext4 configurando TARGET_USES_MKE2FS em BoardConfig.mk.

Analisando E/S

Para entender as atividades de E/S durante a inicialização, use os dados do kernel ftrace (também usados pelo systrace):

trace_event=block,ext4 in BOARD_KERNEL_CMDLINE

Para detalhar o acesso a cada arquivo, faça as seguintes alterações no kernel (somente kernel de desenvolvimento; não use em kernels de produção):

diff --git a/fs/open.c b/fs/open.c
index 1651f35..a808093 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -981,6 +981,25 @@
 }
 EXPORT_SYMBOL(file_open_root);
 
+static void _trace_do_sys_open(struct file *filp, int flags, int mode, long fd)
+{
+       char *buf;
+       char *fname;
+
+       buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+       if (!buf)
+               return;
+       fname = d_path(&filp-<f_path, buf, PAGE_SIZE);
+
+       if (IS_ERR(fname))
+               goto out;
+
+       trace_printk("%s: open(\"%s\", %d, %d) fd = %ld, inode = %ld\n",
+                     current-<comm, fname, flags, mode, fd, filp-<f_inode-<i_ino);
+out:
+       kfree(buf);
+}
+
long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 {
 	struct open_flags op;
@@ -1003,6 +1022,7 @@
 		} else {
 			fsnotify_open(f);
 			fd_install(fd, f);
+			_trace_do_sys_open(f, flags, mode, fd);

Use os scripts a seguir para ajudar a analisar o desempenho da inicialização.

system/extras/boottime_tools/bootanalyze/bootanalyze.py Mede o tempo de inicialização com um detalhamento de etapas importantes no processo de inicialização.
system/extras/boottime_tools/io_analysis/check_file_read.py boot_trace Fornece informações de acesso para cada arquivo.
system/extras/boottime_tools/io_analysis/check_io_trace_all.py boot_trace Fornece detalhamento no nível do sistema.

Otimizando o init.*.rc

O init é a ponte do kernel até que a estrutura seja estabelecida, e os dispositivos geralmente passam alguns segundos em diferentes estágios de inicialização.

Executando tarefas em paralelo

Embora o init atual do Android seja mais ou menos um único processo encadeado, você ainda pode executar algumas tarefas em paralelo.

Execute comandos lentos em um serviço de script de shell e junte-se a isso mais tarde, aguardando uma propriedade específica. O Android 8.0 oferece suporte a esse caso de uso com um novo comando wait_for_property .
Identifique operações lentas no init. O sistema registra o comando init exec/wait_for_prop ou qualquer ação demorada (no Android 8.0, qualquer comando demorando mais de 50 ms). Por exemplo:
```
init: Command 'wait_for_coldboot_done' action=wait_for_coldboot_done returned 0 took 585.012ms
```
A revisão deste log pode indicar oportunidades de melhorias.
Inicie serviços e habilite dispositivos periféricos no caminho crítico antecipadamente. Por exemplo, alguns SOCs exigem iniciar serviços relacionados à segurança antes de iniciar o SurfaceFlinger. Revise o log do sistema quando o ServiceManager retornar "aguardar serviço" — isso geralmente é um sinal de que um serviço dependente deve ser iniciado primeiro.
Remova quaisquer serviços e comandos não utilizados em init.*.rc. Qualquer coisa não usada no init do estágio inicial deve ser adiada para inicialização concluída.

Nota: O serviço de propriedade faz parte do processo de inicialização, portanto, chamar setproperty durante a inicialização pode levar a um longo atraso se o init estiver ocupado em comandos internos.

Usando o ajuste do agendador

Use o ajuste do agendador para inicialização antecipada. Exemplo de um Google Pixel:

on init
    # boottime stune
    write /dev/stune/schedtune.prefer_idle 1
    write /dev/stune/schedtune.boost 100
    on property:sys.boot_completed=1
    # reset stune
    write /dev/stune/schedtune.prefer_idle 0
    write /dev/stune/schedtune.boost 0

    # or just disable EAS during boot
    on init
    write /sys/kernel/debug/sched_features NO_ENERGY_AWARE
    on property:sys.boot_completed=1
    write /sys/kernel/debug/sched_features ENERGY_AWARE

Alguns serviços podem precisar de um aumento de prioridade durante a inicialização. Exemplo:

init.zygote64.rc:
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
    class main
    priority -20
    user root
...

Iniciando o zigoto cedo

Dispositivos com criptografia baseada em arquivo podem iniciar o zygote mais cedo no gatilho zygote-start (por padrão, o zygote é iniciado na classe main, que é muito posterior ao zygote-start). Ao fazer isso, certifique-se de permitir que o zygote seja executado em todas as CPUs (já que a configuração incorreta do cpuset pode forçar o zygote a ser executado em CPUs específicas).

Desativar economia de energia

Durante a inicialização do dispositivo, a configuração de economia de energia para componentes como UFS e/ou controlador de CPU pode ser desabilitada.

Cuidado: A economia de energia deve ser ativada no modo de carregador para maior eficiência.

on init
    # Disable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 0
    write /sys/module/lpm_levels/parameters/sleep_disabled Y
on property:sys.boot_completed=1
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/module/lpm_levels/parameters/sleep_disabled N
on charger
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/class/typec/port0/port_type sink
    write /sys/module/lpm_levels/parameters/sleep_disabled N

Adiar a inicialização não crítica

A inicialização não crítica, como ZRAM, pode ser adiada para boot_complete.

on property:sys.boot_completed=1
   # Enable ZRAM on boot_complete
   swapon_all /vendor/etc/fstab.${ro.hardware}

Otimizando a animação de inicialização

Use as dicas a seguir para otimizar a animação de inicialização.

Configurando o início antecipado

O Android 8.0 permite iniciar a animação de inicialização antecipadamente, antes de montar a partição userdata. No entanto, mesmo ao usar a nova cadeia de ferramentas ext4 no Android 8.0, o fsck ainda é acionado periodicamente por motivos de segurança, causando um atraso na inicialização do serviço bootanimation.

Para fazer bootanimation começar cedo, divida a montagem fstab em duas fases:

Na fase inicial, monte apenas as partições (como system/ e vendor/ ) que não exigem verificações de execução e, em seguida, inicie os serviços de animação de inicialização e suas dependências (como servicemanager e surfaceflinger).
Na segunda fase, monte partições (como data/ ) que exigem verificações de execução.

A animação de inicialização será iniciada muito mais rápido (e em tempo constante), independentemente do fsck.

Acabamento limpo

Depois de receber o sinal de saída, o bootanimation desempenha a última parte, cuja duração pode diminuir o tempo de inicialização. Um sistema que inicializa rapidamente não precisa de animações longas que possam ocultar efetivamente quaisquer melhorias feitas. Recomendamos fazer o loop de repetição e o final curtos.

Otimizando o SELinux

Use as dicas a seguir para otimizar o SELinux para tempos de inicialização aprimorados.

Use expressões regulares limpas (regex) . O regex mal formado pode levar a muita sobrecarga ao corresponder à política SELinux para sys/devices em file_contexts . Por exemplo, a regex /sys/devices/.*abc.*(/.*)? força erroneamente uma verificação de todos os subdiretórios /sys/devices que contêm "abc", habilitando correspondências para /sys/devices/abc e /sys/devices/xyz/abc . Melhorando este regex para /sys/devices/[^/]*abc[^/]*(/.*)? habilitará uma correspondência apenas para /sys/devices/abc .
Mova os rótulos para genfscon . Esse recurso existente do SELinux passa prefixos de correspondência de arquivos para o kernel no binário do SELinux, onde o kernel os aplica aos sistemas de arquivos gerados pelo kernel. Isso também ajuda a corrigir arquivos criados pelo kernel mal rotulados, evitando condições de corrida que podem ocorrer entre processos do espaço do usuário que tentam acessar esses arquivos antes que ocorra a nova rotulagem.

Ferramenta e métodos

Use as ferramentas a seguir para ajudá-lo a coletar dados para destinos de otimização.

Bootchart

Bootchart fornece quebra de carga de CPU e E/S de todos os processos para todo o sistema. Ele não requer a reconstrução da imagem do sistema e pode ser usado como uma rápida verificação de sanidade antes de mergulhar no systrace.

Para habilitar o bootchart:

adb shell 'touch /data/bootchart/enabled'
adb reboot

Após a inicialização, busque o gráfico de inicialização:

$ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh

Quando terminar, exclua /data/bootchart/enabled para evitar a coleta de dados sempre.

Systrace

O Systrace permite coletar rastreamentos do kernel e do Android durante a inicialização. A visualização do systrace pode ajudar na análise de problemas específicos durante a inicialização. (No entanto, para verificar o número médio ou o número acumulado durante toda a inicialização, é mais fácil examinar diretamente o rastreamento do kernel).

Para habilitar o systrace durante a inicialização:

Em frameworks/native/cmds/atrace/atrace.rc , altere:

  write /sys/kernel/debug/tracing/tracing_on 0
  write /sys/kernel/tracing/tracing_on 0

Para:

  #    write /sys/kernel/debug/tracing/tracing_on 0
  #    write /sys/kernel/tracing/tracing_on 0

Isso habilita o rastreamento (que está desabilitado por padrão).

No arquivo device.mk , adicione a seguinte linha:

PRODUCT_PROPERTY_OVERRIDES +=    debug.atrace.tags.enableflags=802922
PRODUCT_PROPERTY_OVERRIDES +=    persist.traced.enable=0

No arquivo BoardConfig.mk do dispositivo, adicione o seguinte:

BOARD_KERNEL_CMDLINE := ... trace_buf_size=64M trace_event=sched_wakeup,sched_switch,sched_blocked_reason,sched_cpu_hotplug

Para análise detalhada de E/S, adicione também block e ext4 e f2fs.

No arquivo init.rc específico do dispositivo, adicione o seguinte:

on property:sys.boot_completed=1          // This stops tracing on boot complete
write /d/tracing/tracing_on 0
write /d/tracing/events/ext4/enable 0
write /d/tracing/events/f2fs/enable 0
write /d/tracing/events/block/enable 0

Após a inicialização, busque o rastreamento:

adb root && adb shell atrace --async_stop -z -c -o /data/local/tmp/boot_trace
adb pull /data/local/tmp/boot_trace
$ANDROID_BUILD_TOP/external/chromium-trace/systrace.py --from-file=boot_trace

Observação: o Chrome não pode lidar com arquivos muito grandes. Considere cortar o arquivo boot_trace usando tail , head ou grep para as partes necessárias. A análise de E/S geralmente requer a análise direta do boot_trace capturado, pois há muitos eventos.