Como o compilador Ark da Huawei pode melhorar o desempenho de aplicativos Android

click fraud protection

A Huawei divulgou detalhes importantes sobre o funcionamento de seu novo Ark Compiler, prometendo melhorar drasticamente o desempenho do aplicativo no Android. Continue lendo para saber mais

Grande parte da conversa recente em torno da Huawei girou em torno da infeliz situação política da empresa devido a um Ordem executiva dos EUA que restringiu muitas empresas de realizar negócios com a Huawei. As repercussões de uma decisão tão crucial são enormes demais para não prestarmos atenção. Mas numa realidade alternativa onde esta ordem executiva não exista, a Huawei teria estado no centro das atenções pela sua revelou recentemente o Ark Compiler, a mais recente inovação que pretende preencher a lacuna de desempenho do aplicativo entre Android e iOS.

Antes de mergulhar no que é Ark Compiler, precisamos dar um passo atrás e entender o que é um compilador e a finalidade que ele serve no sistema Android.

Breve história de compiladores e intérpretes no Android

Um compilador é um programa de computador que traduz código de uma linguagem para outra, geralmente sendo linguagem de máquina nativa. Isso pode então ser executado diretamente pelo computador ou por meio de outro programa (intérprete). Esta tradução é necessária porque escrevemos código em linguagens de programação legíveis por humanos (como Java e Kotlin), enquanto o computador entende apenas a linguagem de máquina nativa (código binário na forma de 1's e 0). O compilador serve, portanto, como uma ponte entre as instruções que um ser humano escreve e a capacidade da máquina de compreender e executar essas instruções. A rapidez e eficiência com que essa conversão e interpretação subsequente ocorrem define a eficiência do compilador, portanto introduzindo uma correlação direta entre a eficiência do compilador com o desempenho e eficiência do código e, por extensão, aplicativos.

VM Dalvik

Nos primeiros dias do Android, o sistema operacional utilizava o que era chamado de Dalvik VM (o intérprete) junto com um compilador JIT (just-in-time). Este vídeo mais antigo do Android Basics 101 da XDA TV A série aborda a VM Dalvik e a configuração JIT, que atendiam às necessidades dos primeiros sistemas Android, onde as restrições de memória eram abundantes. A VM Dalvik pegou o bytecode Java e o converteu em código de máquina conforme e quando o código precisava ser executado (daí o Just-In-Time). Isso foi necessário porque o espaço de armazenamento nos telefones era uma restrição real naquela época, então essa abordagem permitiu que os aplicativos funcionassem com arquivos menores no sistema.

A compilação e a interpretação de aplicativos em tempo de execução tinham a desvantagem de um desempenho geral mais lento do aplicativo, pois a compilação ocorreria paralelamente quando o usuário estivesse usando o aplicativo.

A Dalvik também tinha limitações com seu mecanismo de coleta de lixo. Dalvik acompanhou coletivamente cada alocação de memória. Depois que Dalvik determina que um pedaço de memória não está mais sendo usado pelo programa, ele libera essa memória de volta para a pilha sem qualquer intervenção do programador. Esse processo é chamado de Coleta de Lixo (GC) e tem como objetivo encontrar objetos de memória em um programa que não é mais acessado e então recuperar os recursos usados ​​por esses objetos para liberar memória. O sistema determina quando um GC é necessário coletivamente, para que os desenvolvedores de aplicativos não possam escolher quando os eventos de GC ocorrem [mesmo no ART]. Portanto, se um evento de GC ocorresse no meio de qualquer atividade de processamento intensivo no aplicativo em primeiro plano, o sistema pausaria a execução do processo e iniciar o GC, aumentando assim o tempo de processamento e introduzindo uma "jank" perceptível no Usuários.

Estas e outras restrições levaram o Google a explorar abordagens alternativas para um desempenho mais rápido.

Tempo de execução do Android

Com o Android 4.4 KitKat, o Google introduziu ART (tempo de execução do Android) na forma de visualização com um compilador AOT (Ahead-Of-Time) e com o Android 5.0 Lollipop, o Google abandonou o Dalvik em favor do ART como o único intérprete disponível. ART com AOT converteu o código em linguagem de máquina no momento da instalação do aplicativo, em vez de esperar para fazer essa conversão quando o aplicativo estiver em uso. Essa abordagem acelerou o tempo de inicialização do aplicativo, mas também introduziu desvantagens na forma de tempos de instalação mais lentos e aumento do uso de espaço em disco. Para equilibrar tudo, o Google adotado uma combinação de AOT, JIT e compilação guiada por perfil com ART no Android 7.0 Nougat, para garantir que nenhum fator único seja afetado drasticamente.

Implementação ART do Android

A ART também trabalhou para tornar a coleta de lixo menos intrusiva. O processo de GC foi otimizado para ser mais rápido em geral, com menos pausas (uma pausa curta versus as duas pausas de Dalvik), menos fragmentação e menos uso de memória. A apresentação do Google no Google I/O 2014 detalha melhor as limitações do GC da Dalvik e as melhorias do ART nesse sentido.

Mesmo com essas mudanças ao longo dos anos, a premissa básica da abordagem do Google envolvia a interpretação do código durante a execução enquanto variava o tempo do elemento de compilação (tradução). A coleta de lixo também continua a ser um problema para os desenvolvedores de aplicativos devido à sua natureza ininterrupta e coletiva. Indiscutivelmente, o desempenho do aplicativo Android é prejudicado, pois continua a haver despesas gerais envolvidas.

Compilador Ark da Huawei

A Huawei tem trabalhado no desenvolvimento de uma solução mais eficiente e, consequentemente, contratou centenas de especialistas na área. O resultado deste esforço é o Ark Compiler, que a Huawei afirma ser o primeiro compilador estático que permite a tradução direta para linguagem de máquina, eliminando completamente a necessidade de um intérprete. O Ark Compiler também foi desenvolvido com o objetivo de maximizar a eficiência de execução de Java e C, portanto, teoricamente, deve-se ver os melhores resultados com essas linguagens.

Gráfico da Huawei. Texto traduzido pelo usuário XDA MyKeyVans.

A Huawei apresenta alguns recursos principais do Ark Compiler conforme abaixo:

  • Técnicas de compilação como AOT e JIT podem converter alguns programas em código de máquina e executá-los diretamente na CPU, mas essas técnicas são incapazes de se libertar completamente do intérprete e das limitações a ele associadas. O Ark Compiler utiliza compilação estática, o que permite que ele se desvincule do interpretador dinâmico, abrindo a possibilidade de aumentar o desempenho do aplicativo "trancos e barrancos."
  • A compilação estática tem a desvantagem potencial de ser muito rígida e incapaz de fazer ajustes que um compilador dinâmico pode fazer durante a execução. A Huawei afirma que a compilação estática do Ark Compiler resolve isso "traduzindo perfeitamente os recursos dinâmicos da linguagem de programação em código de máquina."
  • Os processos de compilação existentes ocorrem durante ou após a instalação do pacote de aplicativos no dispositivo móvel. Ark Compiler foi projetado para implantação durante o desenvolvimento de software, o que presumimos que ajuda a remover sobrecargas de tempo durante a instalação e execução. Presumimos que os desenvolvedores de aplicativos seriam capazes de compilar diretamente diferentes linguagens em código de máquina nativo durante a execução do aplicativo. processo de desenvolvimento, e o APK resultante poderia, portanto, não precisar de interação com um intérprete ou máquina virtual para função. Teoricamente, isso reduziria as despesas gerais relacionadas ao JNI, por exemplo.
  • Ark Compiler também muda a natureza coletiva da coleta de lixo. Ele permite que eventos de GC ocorram separadamente para diferentes threads Java. Essa abordagem compartimentada afirma oferecer menos erros em aplicativos em primeiro plano.

Como resultado dessas mudanças, o Ark Compiler pode aparentemente melhora a fluência da operação do sistema Android em até 24%, a velocidade de resposta em até 44% e a suavidade dos aplicativos de terceiros em até 60%, alegando trazer o desempenho do aplicativo Android no mesmo nível do iOS.

O Ark Compiler está atualmente compilado e otimizado para arquitetura de chip ARM. A Huawei espera que, no futuro, o design colaborativo de hardware e software funcione no sentido de maximizar as capacidades do chip Kirin.

O Ark Compiler suporta o uso padrão de Java, permitindo a compilação direta de aplicativos de terceiros sem a necessidade do desenvolvedor do aplicativo fazer qualquer modificação no código. Ark Compiler também permite “ajustes na estrutura do código” para melhorias adicionais de desempenho e memória. A Huawei optou por tornar o Ark Compiler um sistema de código aberto, o que permitiria que desenvolvedores terceiros adotassem e adaptar a tecnologia às suas necessidades, promovendo sua adoção entre desenvolvedores de aplicativos e telefones celulares fabricantes.

Embora a Huawei não mencione nenhum contra ao Ark Compiler, pode-se esperar grandes tamanhos de aplicativos no mesmo pelo menos, mas isso não deve causar problemas nos dispositivos da geração atual que vêm com amplo armazenar. Também esperamos que o Ark Compiler não esteja disponível para todas as arquiteturas de CPU, já que os problemas de compatibilidade do Google não são a dor de cabeça da Huawei. Ark Compiler foi projetado para ser usado durante o desenvolvimento e não durante a instalação; isso apresenta uma indicação de que a Huawei pode ter modificado a forma como os aplicativos são implantados e instalados em dispositivos Android, e também pode ter trabalhado em seu próprio design de APK. Se correto, isso poderia representar um grande problema de compatibilidade no ecossistema, e demoraria muito até que se tornasse um recurso padrão do Android, se é que alguma vez o faria.

Não compilar no dispositivo do usuário também levanta uma grande questão sobre otimização. Atualmente, o ART otimiza por microarquitetura, o que significa que o binário resultante seria diferente para um dispositivo Snapdragon versus um dispositivo Exynos, ou mesmo para um Snapdragon 845 versus um Snapdragon 625. Esta abordagem faz sentido para fabricantes que têm controle total do SoC, como Apple e Huawei. No entanto, com o resto do mundo Android usando muitos SoCs diferentes, forçar uma otimização genérica a ser usada em todos os dispositivos será um obstáculo para a padronização do Ark Compiler, novamente. Conseqüentemente, não espere que o Ark Compiler chegue em sua ROM personalizada favorita tão cedo.

Para esclarecimento, o Ark Compiler foi desenvolvido para funcionar com Android, e a Huawei não mencionou nada em relação ao seu suposto sistema operacional homebrew e sua compatibilidade com o Ark Compiler, portanto não fazemos suposições nesse sentido.

A Huawei planeja realizar duas grandes conferências dedicadas aos desenvolvedores e ao ecossistema mais amplo. Estas são a Conferência de Desenvolvedores de Dispositivos Huawei da China e a Conferência de Desenvolvedores da Aliança Verde da China. Ambos os eventos abordarão questões específicas de código aberto relacionadas ao Ark Compiler da Huawei, em um esforço para tornar os benefícios desta tecnologia tão amplamente acessíveis quanto possível.


Agradecimentos especiais ao Colaborador Sênior Reconhecido do XDA Dees_Troy e desenvolvedor reconhecido arte97 pela sua assistência e contribuições.

Nota: A Huawei/Honor parou de fornecer códigos oficiais de desbloqueio do bootloader para seus dispositivos. Portanto, os bootloaders de seus dispositivos não podem ser desbloqueados, o que significa que os usuários não podem fazer root ou instalar ROMs personalizados.