Mitos Mais Comuns de Otimização do Android Debunked

Há muitos guias instrucionais dedicados a aumentar o desempenho do Android e dicas gerais de otimização. Alguns deles são legítimos, e outros são baseados apenas em teoria, ou métodos operacionais desatualizados no sistema Android, ou são simplesmente absurdos. Isso inclui recomendações para troca, valores adicionados ao build.prop e mudanças de variáveis ​​no kernel do Linux.

Há ainda uma tonelada de "scripts de otimização" por aí, todos em um .zips que podem ser comprados e prometem aumentar significativamente o desempenho, a duração da bateria e outras coisas. Alguns dos ajustes podem funcionar, mas a maioria é simplesmente um efeito placebo ou, pior, tem um impacto negativo no seu dispositivo.

Isso não quer dizer que as pessoas estejam lançando intencionalmente scripts nefastos - há definitivamente aplicativos pagos falsos na Play Store, mas os scripts de otimização lançados nos fóruns do Android são geralmente bem-intencionados, acontece que o desenvolvedor pode estar mal informado, ou simplesmente experimentando vários ajustes de otimização. Infelizmente, uma espécie de efeito bola de neve tende a ocorrer, especialmente em scripts de otimização “tudo em um”. Um pequeno punhado dos ajustes pode realmente fazer alguma coisa, enquanto outro conjunto de ajustes em um script pode fazer absolutamente nada - ainda que esses scripts sejam passados ​​como sendo marcadores mágicos, sem qualquer investigação real sobre o que funciona e o que não funciona .

Assim, muitos dos scripts de otimização all-in-one estão usando os mesmos métodos, alguns dos quais são completamente desatualizados ou prejudiciais a longo prazo. Em resumo, a maioria dos scripts de otimização "tudo em um" não são nada além de ajustes recomendados, sem nenhuma ideia clara de como ou por que essas otimizações "trabalham" - os usuários exibem os scripts e afirmam que seu desempenho é repentinamente mais rápido ( quando, na verdade, era mais provável que o simples ato de reinicializar o dispositivo tenha causado um aumento de desempenho, já que tudo na memória RAM do dispositivo é eliminado) .

Neste artigo exclusivo da Appuals, destacaremos algumas das recomendações mais comuns para " otimizar" o desempenho do Android e se elas são simplesmente um mito ou um ajuste legítimo para o desempenho do dispositivo.

Troca

No topo da lista de mitos está a troca do Android - o que é bastante absurdo em termos de ser pensado como uma otimização do Android. Swaps principal objetivo é criar e conectar o arquivo de paginação, que irá liberar espaço de armazenamento na memória. Isso parece sensato no papel, mas é realmente aplicável a um servidor, que quase não tem interatividade.

Quando você usa a troca do seu telefone Android regularmente, isso leva a atrasos graves que se originam de coisas que passam pelo cache. Imagine, por exemplo, se um aplicativo tenta exibir um gráfico, que é armazenado na troca, que agora tem que recarregar o disco depois de liberar espaço, colocando a troca de dados com outro aplicativo. É muito confuso.

Alguns entusiastas de otimização podem dizer que o swap não ofereceu problemas, mas não é o swap que aumenta o desempenho - é o mecanismo Android embutido com baixo teor de memória, que regularmente mata processos inchados e de alta prioridade que não estão sendo usados. O LMK foi projetado especificamente para lidar com condições de pouca memória, é chamado pelo processo kswapd e geralmente mata os processos de espaço do usuário. Isso é diferente do OOMkiller (matador de falta de memória), mas esse é um tópico completamente diferente.

O ponto é, um dispositivo com, por exemplo, 1GB de RAM nunca pode alcançar os dados de desempenho necessários em um swap, e assim swap não é absolutamente necessário no Android. Sua implementação é simplesmente repleta de atrasos e leva a uma degradação no desempenho, em vez de otimizá-lo.

zRAM - desatualizado e não mais eficiente

O zRAM é um método comprovado e eficaz para otimização de dispositivos, para dispositivos mais antigos - pense em dispositivos baseados em KitKat que operam com apenas 512 MB de RAM. O fato de algumas pessoas ainda incluírem ajustes zRAM em scripts de otimização, ou recomendar zRAM como algum tipo de otimização moderna, é um exemplo de pessoas que geralmente não seguem os protocolos operacionais mais recentes.

O zRAM foi planejado para SoCs multinúcleo de faixa de orçamento de nível básico, como dispositivos que utilizam chipsets MTK e 512 MB de RAM. Telefones chineses muito baratos, basicamente. O que o zRAM basicamente faz é separar o kernel através do fluxo de criptografia.

Quando o zRAM é usado em dispositivos mais antigos com um único núcleo, mesmo se o zRAM for recomendado nesses dispositivos, grandes quantidades de atrasos tendem a aparecer. Isso também acontece com a tecnologia KSM ( Kernel Same Page Mesing), que combina páginas de memória idênticas em uma tentativa de liberar espaço. Isso é de fato recomendado pelo Google, mas leva a maiores atrasos em dispositivos mais antigos, porque os núcleos de núcleo constantemente ativos estão sendo executados continuamente a partir da memória para procurar por páginas duplicadas. Basicamente, tentar executar o ajuste de otimização torna o dispositivo ainda mais lento, ironicamente.

Seeder - desatualizado desde o Android 3.0

Uma das dicas de otimização mais debatidas entre os desenvolvedores de Android é a semeadora, e temos certeza de que alguém poderia tentar provar que estamos errados sobre esse assunto - mas primeiro precisamos examinar a história da semeadora.

Sim, há um grande número de relatórios que declaram melhor desempenho do Android após a instalação em dispositivos Android muito mais antigos . No entanto, as pessoas por qualquer motivo acreditam que isso significa que também é uma otimização aplicável para dispositivos Android modernos, o que é absolutamente absurdo. O fato de a Seeder ainda ser mantida e oferecida como uma ferramenta de redução de atrasos “moderna” é um exemplo de desinformação - embora isso não seja culpa do desenvolvedor da Seeder, já que até a página da Play Store nota que a Seeder é menos eficiente depois do Android 4.0+. Ainda assim, por qualquer razão, a Seeder ainda aparece em discussões de otimização para sistemas Android modernos.

O que o Seeder faz basicamente para o Android 3.0 é endereçar um bug em que o Android runtime usaria ativamente o arquivo / dev / random / para adquirir a entropia. O / dev / random / buffer ficaria instável, e o sistema seria bloqueado até preencher a quantidade necessária de dados - pense em coisas pequenas como os vários sensores e botões no dispositivo Android.

O autor de Seeder pegou o Linux-demon rngd e compilou para o inastroil do Android para que ele pegasse dados aleatórios de um caminho muito mais rápido e previsível / dev / urandom e os mesclasse em dev / random / each second, sem permitir / dev / random ficar exausto. Isso resultou em um sistema Android que não sofreu falta de entropia e teve um desempenho muito mais suave.

O Google quebrou esse bug depois do Android 3.0, mas por algum motivo, o Seeder ainda aparece nas listas de "ajustes recomendados" para otimização do desempenho do Android. Além disso, o aplicativo Seeder tem alguns análogos como sEFix, que incluem a funcionalidade do Seeder, seja usando o mesmo rngd ou o alternativo, ou até mesmo apenas um link simbólico entre / dev / urandom e / dev / random. Isso é absolutamente inútil para os sistemas Android modernos.

A razão é inútil porque versões mais novas do Android usam / dev / random / em três componentes principais - libcrypto, para criptografia de conexões SSL, geração de chaves SSH, etc. WPA_supplication / hostapd que gera chaves WEP / WPA e, finalmente, um punhado de bibliotecas para gerar ID na criação de sistemas de arquivos EXT2 / EXT3 / EXT4.

Assim, quando os aprimoramentos baseados em Seeder ou Seeder são incluídos nos scripts de otimização modernos do Android, o que acaba acontecendo é uma degradação no desempenho do dispositivo, porque o rngd despertará constantemente o dispositivo e causará um aumento na frequência da CPU, o que afeta negativamente o consumo de bateria .

Odex

O firmware estoque em dispositivos Android praticamente sempre odex. Isso significa que, juntamente com o pacote padrão para aplicativos Android no formato APK, encontrado em / system / app / e / system / priv-app /, são os mesmos nomes de arquivos com a extensão .odex. Os arquivos odex contêm aplicativos de bytecode otimizados que já passaram pela máquina virtual do validador e do otimizador e são gravados em um arquivo separado, utilizando algo como a ferramenta dexopt .

Assim, os arquivos odex destinam-se a descarregar a máquina virtual e oferecem um lançamento acelerado do aplicativo odexed - no lado negativo, os arquivos ODEX impedem modificações no firmware e criam problemas com atualizações, portanto, por esse motivo, muitos ROMs personalizados, como o LineageOS, são distribuídos sem ODEX

A geração de arquivos ODEX é feita de várias maneiras, como o uso da Ferramenta Odexer - o problema é que é apenas um efeito placebo. Quando o sistema Android moderno não encontra arquivos odex no diretório / system, o sistema irá criá-los e colocá-los no diretório / system / dalvik-cache /. Isso é exatamente o que está acontecendo quando, por exemplo, você exibe uma nova versão do Android e exibe a mensagem “Busy, Optimizing Applications” por um tempo.

Lowmemorykiller tweaks

A multitarefa no Android difere de outros sistemas operacionais móveis no sentido de que é baseada em um modelo clássico em que os aplicativos trabalham silenciosamente em segundo plano e não há restrições quanto ao número de aplicativos em segundo plano (a menos que um esteja definido em Opções do desenvolvedor, mas geralmente recomendado contra) - além disso, a funcionalidade de transição para uma execução em segundo plano não é interrompida, embora o sistema se reserve o direito de matar aplicativos em segundo plano em situações de pouca memória ( veja onde falamos sobre lowmemorykiller e out-of-memory killer anteriormente neste guia) .

Para voltar ao mecanismo lowmemorykiller, o Android pode continuar a operar com uma quantidade limitada de memória e falta de partição de swap. O usuário pode continuar a iniciar aplicativos e alternar entre eles, e o sistema silenciosamente eliminará aplicativos em segundo plano não utilizados para tentar liberar memória para tarefas ativas.

Isso foi muito útil para o Android nos primeiros dias, embora, por alguma razão, tenha se tornado popular na forma de aplicativos que matam tarefas, que geralmente são mais prejudiciais do que benéficos. Os aplicativos Task-killer são ativados em intervalos definidos ou são executados pelo usuário e parecem liberar grandes quantidades de RAM, o que é visto como positivo - mais RAM livre significa um dispositivo mais rápido, certo? Este não é exatamente o caso do Android, no entanto.

De fato, ter uma grande quantidade de RAM livre pode, na verdade, ser prejudicial ao desempenho e à duração da bateria do seu dispositivo. Quando os aplicativos são armazenados na RAM do Android, é muito mais fácil ligar para eles, iniciá-los, etc. O sistema Android não precisa dedicar muitos recursos à mudança para o aplicativo, porque ele já está lá na memória.

Por causa disso, os assassinos de tarefas não são tão populares quanto eram antes, embora os novatos do Android ainda dependam deles por alguma razão ( falta de informação, infelizmente) . Infelizmente, uma nova tendência substituiu os assassinos de tarefas, a tendência das afinações do mecanismo de baixa memória de memória . Este seria, por exemplo, o aplicativo MinFreeManager, e a idéia principal é aumentar a sobrecarga de RAM antes que o sistema comece a matar aplicativos em segundo plano.

Por exemplo, a RAM padrão opera nas bordas - 4, 8, 12, 24, 32 e 40 Mb e quando o espaço de armazenamento livre de 40 MB é preenchido, um dos aplicativos armazenados em cache é carregado na memória, mas não em execução Será encerrado.

Então, basicamente, o Android sempre terá pelo menos 40 MB de memória disponível, o que é suficiente para acomodar mais uma aplicação antes que o lowmemorykiller inicie seu processo de limpeza - o que significa que o Android sempre fará o possível para usar a quantidade máxima de RAM disponível sem interferir experiência de usuário.

Infelizmente, o que alguns entusiastas de homebrew recomendaram é que o valor seja aumentado para, por exemplo, 100 MB antes do LMK entrar em ação. Agora, o usuário perderá RAM (100 - 40 = 60), então em vez de usar esse espaço para armazenar back aplicativos finais, o sistema manterá essa quantidade de memória livre, sem absolutamente nenhum propósito para isso.

O ajuste do LKM pode ser útil para dispositivos muito mais antigos com 512 RAM, mas quem mais os possui? 2GB é o moderno "orçamento", mesmo os dispositivos de 4GB de RAM são vistos como "intermediários" nos dias de hoje, então os ajustes do LMK são realmente desatualizados e inúteis.

I / O tweaks

Em muitos dos scripts de otimização para Android, você encontrará frequentemente ajustes que abordam o subsistema de E / S. Por exemplo, vamos dar uma olhada no ThunderBolt! Script, que contém estas linhas:

 echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests; 

A primeira linha fornecerá as instruções do planejador de E / S para lidar com um SSD e a segunda aumentará o tamanho máximo da E / S da fila de 128 para 1024 - porque a variável $ i contém um caminho para a árvore de dispositivos de bloco / sys e o script é executado em um loop.

Em seguida, você encontra uma linha relacionada ao planejador CFQ:

 echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle; 

Isto é seguido por mais linhas que pertencem a outros planejadores, mas no final, os dois primeiros comandos são inúteis porque:

Um moderno kernel do Linux é capaz de entender por que tipo de mídia de armazenamento ele está trabalhando por padrão.

Uma longa fila de entrada-saída ( como 1024) é inútil em um dispositivo Android moderno, na verdade, é sem sentido mesmo no desktop - é realmente apenas recomendado em servidores pesados . Seu telefone não é um servidor Linux de serviço pesado.

Para um dispositivo Android, virtualmente não há aplicações priorizadas na entrada-saída e nenhum driver mecânico, então o melhor planejador é a fila noop / FIFO, então este tipo de agendamento “ tweak” não está fazendo nada especial ou significativo para o Subsistema de E / S. Na verdade, todos esses comandos de lista de tela múltipla são melhor substituídos por um ciclo simples:

 para i em / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / fila / iostats concluído 

Isso permitiria que o escalonador noop para todas as unidades a partir do acúmulo de estatísticas de E / S, o que deveria ter um impacto positivo no desempenho, embora um muito pequeno e quase completamente insignificante.

Outro ajuste de E / S inútil, geralmente encontrado em scripts de desempenho, é o aumento dos valores de leitura antecipada para cartões SD de até 2 MB. O mecanismo de leitura antecipada é para leituras antecipadas de dados da mídia, antes que o aplicativo solicite acesso a esses dados. Então, basicamente, o kernel tentará descobrir quais dados serão necessários no futuro e pré-carregá-los na RAM, o que deve reduzir o tempo de retorno. Isso soa bem no papel, mas o algoritmo de leitura antecipada está mais freqüentemente errado, o que leva a operações totalmente desnecessárias de entrada-saída, sem mencionar um alto consumo de RAM.

Valores altos de leitura antecipada entre 1 e 8 MB são recomendados em arrays RAID, mas, para dispositivos Android, é melhor deixar o valor padrão de 128 KB.

Ajustes do sistema de gerenciamento de memória virtual

Outra técnica comum de "otimização" é ajustar o subsistema de gerenciamento de memória virtual. Isso normalmente atinge apenas duas variáveis ​​do kernel, vm.dirty_background_ratio e vm.dirty_ratio, que são para ajustar o tamanho do buffer para armazenar dados “sujos”. Dados sujos geralmente são dados que foram gravados no disco, mas ainda há mais na memória e aguardando para serem gravados no disco.

Valores tweak típicos em distros Linux e Androis para o subsistema de gerenciamento de VMs seriam como:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Então, o que isso tenta fazer é que quando o buffer de dados sujo é de 10% da quantidade total de RAM, ele desperta o fluxo pdflush e começa a gravar dados no disco - se a operação de gravação de dados no disco for muito intensa, o buffer continuará a crescer e, quando atingir 20% da RAM disponível, o sistema alternará para a operação de gravação subseqüente no modo síncrono - sem pré-buffer. Isso significa que o trabalho de gravar no aplicativo de disco será bloqueado, até que os dados sejam gravados no disco (AKA 'lag').

O que você deve entender é que, mesmo que o tamanho do buffer não atinja 10%, o sistema irá chutar automaticamente o pdflush após 30 segundos. Uma combinação de 10/20 é bastante razoável, por exemplo, em um dispositivo com 1GB de RAM, isso equivale a 100 / 200MB de RAM, o que é mais do que suficiente em termos de registros de burst onde a velocidade é frequentemente abaixo do registro de velocidade no sistema NAND memória, ou cartão SD, como ao instalar aplicativos ou copiar arquivos de um computador.

Por alguma razão, escritores de script tentam empurrar este valor ainda mais alto, para taxas absurdas. Por exemplo, podemos encontrar no script de otimização do Xplix uma taxa tão alta quanto 50/90.

 sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90 

Em um dispositivo com 1 GB de memória, isso limita um buffer sujo para 500/900 MB, o que é completamente inútil para um dispositivo Android, porque funcionaria apenas sob gravação constante no disco - algo que só acontece em um disco pesado. Servidor Linux.

Raio! Script usa um valor mais razoável, mas no geral, ainda é bastante sem sentido:

 se ["$ mem" -lt 524288], então sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776], então sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

Os dois primeiros comandos são executados em smartphones com 512 MB de RAM, o segundo - com 1 GB e outros - com mais de 1 GB. Mas, na verdade, há apenas um motivo para alterar as configurações padrão - um dispositivo com memória interna ou cartão de memória muito lento. Nesse caso, é razoável distribuir os valores das variáveis, ou seja, fazer algo assim:

 sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60 

Então, quando um sistema de surto grava as operações, sem ter que gravar dados no disco, até o último não alternará para o modo síncrono, o que permitirá que os aplicativos reduzam o atraso durante a gravação.

Ajustes inúteis adicionais e ajustes de desempenho

Há muito mais "otimizações" por aí que realmente não fazem nada. A maioria deles simplesmente não tem efeito algum, enquanto outros podem melhorar algum aspecto do desempenho, ao mesmo tempo em que degradam o dispositivo de outras maneiras ( geralmente isso se resume a desempenho versus consumo de bateria) .

Aqui estão algumas otimizações populares adicionais que podem ou não ser úteis, dependendo do sistema e do dispositivo Android.

• Aceleração - A pequena aceleração para melhorar o desempenho e minimizar - economiza um pouco de bateria.
• Otimização de banco de dados - Em teoria, isso deve melhorar o desempenho do dispositivo, mas é duvidoso.
• Zipalign - Ironicamente, apesar do alinhamento de conteúdo do recurso Android SDK integrado no arquivo APK da loja, você pode encontrar muitos softwares que não são transmitidos por meio da zipalign.
• Desabilite serviços de sistema desnecessários, removendo o sistema não utilizado e aplicativos de terceiros raramente usados. Basicamente, desinstalar o bloatware.
• Kernel personalizado com otimizações para um dispositivo específico (novamente, nem todos os núcleos são igualmente bons).
• Já descrevi o agendador de E / S noop.
• Algoritmo de Saturação TCP Westwood - Utilizado com mais eficiência no padrão Android Cubic para redes sem fio, disponível em kernels personalizados.

Configurações inúteis build.prop

LaraCraft304 do fórum XDA Developers conduziu um estudo e descobriu que um número impressionante de configurações /system/build.prop que são recomendadas para uso de “experts” não existem na fonte AOSP e CyanogenMod. Aqui está a lista:

 ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdown.mode ro.HOME_APP_ADJ