Os tamanhos de página de 16 KB retornam com o Android 17 beta, mas o que isso significa?

O Autoridade Android A equipe mergulhou no novo Android 17 QPR1 Beta e se deparou com uma opção interessante escondida no menu de configurações do desenvolvedor em nosso Pixel 9 Pro XL – “inicializar com tamanho de página de 16 KB”. Os aficionados por computador podem estar familiarizados com o conceito de tamanho de página; é tudo uma questão de como os aplicativos interagem com a RAM do seu telefone. Especificamente, esta configuração altera a menor alocação de memória possível do padrão de longa duração de 4 KB para 16 KB – um aumento aparentemente significativo de 4×.

O suporte do Android para diferentes tamanhos de página não é realmente novo. Essa alternância no nível do desenvolvedor foi na verdade apresentado de volta com o Android 15 QPR1 beta para o Pixel 8, mas parece ter entrado e saído de moda nos betas recentes. Ainda assim, vimos o recurso reaparecer em alguns Pixels na versão beta recente do Android 17, então vale a pena revisitar sua importância.

O tamanho da página do computador tem esse nome devido à analogia com um livro impresso e continua sendo uma boa maneira de pensar sobre o conceito. Imagine toda a RAM do seu telefone (8 GB, 12 GB, etc.) como um livro – você poderia torná-lo do tamanho de um bolso, mas grosso, com páginas pequenas que contêm apenas algumas frases cada. Alternativamente, você pode usar páginas maiores para armazenar mais informações, tornando o livro mais fino. É o mesmo conteúdo, apenas organizado de forma diferente. Isso é tudo que há para fazer.

Quando um aplicativo solicita memória, a CPU usa índices de página para mapear a memória virtual, permitindo armazenar e recuperar dados da RAM física do seu telefone. Por padrão, os smartphones Android usam tamanhos de página de 4 KB, o que significa que um aplicativo recebe memória em múltiplos de 4 KB. No entanto, a alternância do desenvolvedor do Android aumenta esse tamanho mínimo para 16 KB. Por que?

Pense desta forma: a solicitação de memória de um aplicativo é arredondada para a página mais próxima, portanto, ele pode precisar de 9 KB, mas recebe 12 KB (três páginas), mas receberia uma fatia maior e mais desperdiçada se o tamanho da página fosse maior. Tamanhos de página menores são, portanto, mais eficientes em termos de memória. No entanto, manter 8 GB de RAM em blocos de 4 KB requer o rastreamento de cerca de 2 milhões de páginas. Gerenciar tantas solicitações de página requer a divisão desse número em vários níveis de tabelas de páginas, e examinar esses níveis para encontrar a memória que a CPU deseja pode ser caro do ponto de vista computacional. Tarefas com uso intensivo de RAM, como carregar um aplicativo volumoso, podem levar mais tempo para serem concluídas, resultando em uma experiência de usuário mais lenta.

Da mesma forma, se aplicativos maiores e mais novos geralmente solicitam memória em blocos maiores que 4 KB — por exemplo, 16 KB, 64 KB ou mais — a pequena granularidade incorre em sobrecarga significativa. Ao mudar para páginas maiores, a CPU se beneficia ao rastrear menos páginas maiores, que é exatamente o que a mudança do Android para tamanhos de página de 16 KB oferece. O Google estima que mudar para 16 KB aumenta o tempo de inicialização de aplicativos em 3% a 30% e o tempo de inicialização do sistema em 8%. No entanto, não é uma melhoria gratuita.

Por que o Android começou com páginas de 4 KB em vez de simplesmente escolher um tamanho maior? Esta é uma questão surpreendentemente complicada, porque o tamanho da página é amplamente determinado pela arquitetura da CPU. Dentro da CPU está uma Unidade de Gerenciamento de Memória (MMU) que define como os endereços virtuais são estruturados e traduzidos, bem como os tamanhos de página suportados.

Sempre que uma instrução de acesso à memória é recebida, bits específicos da instrução contêm o endereço da memória. Os bits inferiores de um endereço virtual podem ser usados ​​como deslocamento ou página dentro de uma tabela específica, enquanto os bits superiores são usados ​​para indexar tabelas de páginas. Por exemplo, um deslocamento de 12 bits fornece 2¹² bytes ou 4 KB por página; 14 bits dão 16 KB; 16 bits dão 64 KB.

Os núcleos ARMv7 (Cortex-A7/A9) encontrados nos primeiros telefones Android, como o Samsung Galaxy S2, eram de 32 bits, o que significa que cada registro de instrução da CPU tinha apenas 32 bits de largura. Para acesso à memória, a arquitetura usou os 20 bits superiores para a pesquisa de endereço de página virtual (divididos em índices de tabela de nível 1 de 12 bits e nível 2 de 8 bits) e os 12 bits inferiores para o deslocamento de página, fornecendo páginas de 4 KB.

Completando a matemática: páginas de 4 KB organizadas em regiões de 1 MB (tabelas L2 compostas por 256 entradas de 4 KB), acessíveis em 4.096 entradas de tabela L1, cobrem um total de 4 GB de RAM — os 2 GB completos.³² limite do tamanho do registro e o limite de dispositivos mais antigos de 32 bits.

A razão exata para a divisão de 4 KB/1 MB é ainda mais sutil. No ARMv7, os mapeamentos de seção de 1 MB permitiram que o MMU ignorasse a tabela L2 para obter melhor desempenho ao acessar a memória sequencial, melhorando a eficiência do buffer lookaside de tradução (TLB) e reduzindo o tráfego de memória – crítico para os primeiros smartphones alimentados por bateria. Mais tarde, a ARM introduziu as grandes extensões de endereço físico (LPAE) opcionais para ARMv7, suportando seções de 16 MB e páginas de 64 KB por meio de endereçamento de 40 bits, mas páginas de 4 KB permaneceram o padrão para Android.

Não foi até o ARMv8 em 2011 que as coisas mudaram de forma mais significativa. ARMv8 introduziu suporte de 64 bits com registros mais amplos para endereçar mais memória por meio de mais tabelas (entre outras coisas). ARMv8-A normalmente usa endereços virtuais de 48 bits (opcionalmente 52 bits em ARMv8.2+). Com páginas de 4 KB, você pode usar 12 bits para deslocamento de página como antes e dividir os 36 bits restantes para tabelas adicionais, permitindo que a CPU enderece muito mais do que 4 GB de memória. O ARMv8 também introduziu tamanhos de página configuráveis ​​de 16 KB e 64 KB, proporcionando flexibilidade para servidores e dispositivos de última geração, ao mesmo tempo que permite tamanhos de tabela ideais.

TLDR: O Android eventualmente incorporou suporte para páginas de 16 KB depois que o hardware evoluiu para suportá-lo de forma eficiente, mas 4 KB continua sendo o padrão legado para compatibilidade e eficiência de armazenamento.

Em teoria, mudar para 16 KB traz alguns benefícios. Cada tabela de páginas mapeia 4x a memória, resultando em menos acessos à memória e melhor cobertura de cache, melhorando o desempenho e a eficiência energética. Existem compensações, no entanto.

A fragmentação da memória interna é um pouco pior, resultando no desperdício de RAM adicional quando os aplicativos solicitam pequenas quantidades de memória. O próprio Android é independente do tamanho da página desde o Android 15, mas isso não significa que os aplicativos mais antigos sejam. Muitos aplicativos de “código nativo” mais antigos (como aqueles escritos em C ou usando o Android NDK) foram criados com páginas de 4 KB em mente e precisam ser reconstruídos com alinhamento de 16 KB (que também permanece compatível com 4 KB). O Google espera que a maioria dos aplicativos desenvolvidos com Kotlin já sejam compatíveis, mas isso ainda é um fardo potencialmente significativo para o desenvolvedor. Apresenta um problema específico para aplicativos que não são mais mantidos ou usam bibliotecas que ainda não foram atualizadas.

O Google ainda não mudou as páginas de 16 KB como padrão do Android, mas este é certamente o futuro da plataforma. Em novembro de 2025todos os novos apps e atualizações de apps existentes enviados ao Google Play destinados a dispositivos Android 15 ou superiores deverão oferecer suporte a tamanhos de página de 16 KB em dispositivos de 64 bits.

Claramente, a indicação é que o Android terá como padrão páginas de 16 KB em um futuro próximo. Não parece que esse prazo chegará com o Android 17, visto que 4 KB ainda é o padrão no meu Pixel executando a versão beta e 16 KB é uma opção oculta do desenvolvedor, mas pode não estar longe.

Quanto a saber se você deve entrar agora, bem, para começar, você terá que estar no programa beta do Android e, em seguida, terá que passar pelo incômodo de desbloquear seu bootloader. Isso significa que você terá que limpar seu telefone e reinstalar o sistema operacional do zero para fazer a troca. Essa opção também não aparece em todos os Pixel que vimos, mas mesmo que você consiga alinhar as estrelas, ainda terá que esperar que todos os seus aplicativos funcionem corretamente. Portanto, embora os benefícios de desempenho das páginas de 16 KB pareçam bons, provavelmente deveríamos aguardar um pouco mais antes de colher os frutos do trabalho árduo do Google e dos desenvolvedores.