Portanto, muitos scripts de otimização tudo-em-um estão usando os mesmos métodos, alguns dos quais estão completamente desatualizados ou são prejudiciais a longo prazo. Em resumo, a maioria dos scripts de otimização 'tudo-em-um' nada mais é do que ajustes recomendados, sem uma ideia clara de como ou por que essas otimizações 'funcionam - os usuários então atualizam os scripts e afirmam que seu desempenho é repentinamente mais rápido ( quando na verdade, provavelmente foi o simples ato de reinicializar o dispositivo que causou um aumento de desempenho , pois tudo na RAM do dispositivo é limpo) .
Neste artigo exclusivo da Appuals, iremos destacar algumas das recomendações mais comuns para “ otimizando ” Desempenho do Android, e se eles são simplesmente um mito ou um ajuste legítimo para o desempenho do dispositivo.
Troca
No topo da lista de mitos está o Android swap - o que é bastante absurdo em termos de ser considerado uma otimização Android. O objetivo principal das trocas é criar e conectar o arquivo de paginação, 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 o swap do seu telefone Android regularmente, isso levará a atrasos graves que resultam de coisas que escapam do cache. Imagine, por exemplo, se um aplicativo tenta exibir um gráfico, que está armazenado no swap, que agora tem que recarregar o disco depois de liberar espaço, colocando o swap de dados com outro aplicativo. É muito confuso.
Alguns entusiastas da otimização podem dizer que a troca não ofereceu problemas, mas não é uma troca que aumenta o desempenho - é o mecanismo integrado do Android assassino de pouca memória , que irá eliminar regularmente processos inchados de alta prioridade que não estão sendo usados. LMK foi projetado especificamente para lidar com condições de pouca memória, é invocado a partir do kswapd processo e geralmente mata os processos do espaço do usuário. Isso é diferente de OOMkiller (assassino sem memória), mas esse é um tópico totalmente diferente.
A questão é que um dispositivo com, por exemplo, 1 GB de RAM nunca pode alcançar os dados de desempenho necessários em um swap, portanto, o swap não é absolutamente necessário no Android. Sua implementação é simplesmente repleta de atrasos e leva a um degradação no desempenho, em vez de otimizá-lo.
zRAM - desatualizado e não mais eficiente
zRAM é um método comprovado e eficaz para a 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 que algumas pessoas ainda incluem ajustes de zRAM em scripts de otimização, ou recomendam zRAM como algum tipo de ajuste de otimização moderno, é um exemplo de pessoas que geralmente não seguem os protocolos operacionais mais recentes.
O zRAM foi projetado para SoCs de vários núcleos com 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 por meio do fluxo de criptografia.
Quando zRAM é usado em dispositivos mais antigos com um único nucleo , mesmo que o zRAM seja recomendado em tais dispositivos, grandes quantidades de atrasos tendem a surgir. Isso também acontece com a tecnologia KSM ( Mesclagem da mesma página do kernel) que combina páginas de memória idênticas em uma tentativa de liberar espaço. Na verdade, isso é recomendado pelo Google, mas leva a atrasos maiores em dispositivos mais antigos, porque os theads do núcleo constantemente ativos estão funcionando continuamente da memória para procurar 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 Android é cedro , e temos certeza de que alguém poderia tentar provar que estamos errados neste tópico - mas primeiro precisamos examinar a história da semeadora.
Aplicativo Seeder para Android
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 o Seeder ainda ser mantido e oferecido como um “ moderno' A ferramenta de redução de atraso é um exemplo de desinformação - embora isso não seja culpa do desenvolvedor do Seeder, já que até mesmo sua página da Play Store observa que o Seeder é menos eficaz após o Android 4.0+. Mesmo assim, por alguma razão, Seeder ainda aparece em discussões de otimização para sistemas Android modernos.
O que o Seeder basicamente faz para o Android 3.0 é corrigir um bug em que o tempo de execução do Android usaria ativamente o arquivo / dev / random / para adquirir entropia. O / dev / random / buffer se tornaria 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 demônio Linux rngd , e compilado para o inastroil do Android para que ele pegue dados aleatórios de um caminho / dev / urandom muito mais rápido e previsível e os mescle em dev / random / a cada segundo, sem permitir que / dev / random / se esgote. Isso resultou em um sistema Android que não apresentou falta de entropia e teve um desempenho muito mais suave.
O Google eliminou esse bug após o Android 3.0, mas por algum motivo, o Seeder ainda aparece no “Ajustes recomendados” listas para otimização de desempenho do Android. Além disso, o aplicativo Seeder tem alguns análogos, como o sEFix, que incluem a funcionalidade do Seeder, usando o mesmo rngd ou a alternativa haveged , ou mesmo apenas um link simbólico entre / dev / urandom e / dev / random. Isso é absolutamente inútil para os sistemas Android modernos.
A razão de ser inútil é porque as versões mais recentes do Android usam / dev / random / em três componentes principais - libcrypto , para criptografar conexões SSL, gerar 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.
Então quando Semeador ou melhorias baseadas em Seeder estão incluídas em scripts de otimização Android modernos, o que acaba acontecendo é um degradação no desempenho do dispositivo, porque rngd irá despertar constantemente o dispositivo e causar um aumento na frequência da CPU, o que, claro, afeta negativamente o consumo da bateria.
Odex
O firmware de estoque em dispositivos Android quase sempre odex. Isso significa que, juntamente com o pacote padrão para aplicativos Android no formato APK, encontrados em / system / app / e / system / priv-app /, têm os mesmos nomes de arquivo com a extensão .odex. Os arquivos odex contêm aplicativos de bytecode otimizados que já passaram pela máquina virtual validadora e otimizadora e, em seguida, gravados em um arquivo separado, utilizando algo como dexopt ferramenta.
Portanto, os arquivos odex destinam-se a descarregar a máquina virtual e oferecer uma inicialização mais rápida do aplicativo odexed - por outro lado, os arquivos ODEX evitam modificações no firmware e criam problemas com atualizações, portanto, por esta razão, muitos ROMs personalizados como o LineageOS são distribuídos sem ODEX .
A geração de arquivos ODEX é feita de várias maneiras, como usando a ferramenta Odexer - o problema é que é puramente um efeito placebo. Quando o sistema Android moderno não encontra arquivos odex no diretório / system, o sistema irá realmente criá-los e colocá-los no diretório / system / dalvik-cache /. Isso é exatamente o que acontece quando, por exemplo, você atualiza uma nova versão do Android e mostra a mensagem “Ocupado, otimizando aplicativos” por um tempo.
Ajustes de assassino de memória baixa
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 funcionam silenciosamente em segundo plano e não há restrições quanto ao número de aplicativos em segundo plano ( a menos que um seja definido nas Opções do desenvolvedor, mas geralmente não é recomendado) - 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 matador de memória baixa e matador de falta de memória anteriormente neste guia) .
Para voltar ao assassino de pouca memória mecanismo, o Android pode continuar a operar com uma quantidade limitada de memória e uma falta de partição de troca. O usuário pode continuar a lançar aplicativos e alternar entre eles, e o sistema eliminará silenciosamente os aplicativos de segundo plano não usados para tentar liberar memória para tarefas ativas.
Isso foi muito útil para o Android nos primeiros dias, embora por algum motivo tenha se tornado popular na forma de aplicativos eliminadores de tarefas, que geralmente são mais prejudiciais do que benéficos. Os aplicativos eliminadores de tarefas são ativados em intervalos definidos ou 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.
Na verdade, ter uma grande quantidade de RAM livre pode ser prejudicial ao desempenho do dispositivo e à vida útil da bateria. Quando os aplicativos são armazenados na RAM do Android, é muito mais fácil chamá-los, iniciá-los, etc. O sistema Android não precisa dedicar muitos recursos para alternar para o aplicativo, porque ele já está na memória.
Por causa disso, os eliminadores de tarefas não são realmente tão populares quanto antes, embora os novatos no Android ainda tendam a confiar neles por algum motivo ( falta de informação, infelizmente) . Infelizmente, uma nova tendência substituiu os assassinos de tarefas, a tendência de assassino de pouca memória afinações do mecanismo. Isso seria por exemplo MinFreeManager aplicativo, e a ideia 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 em cache é carregado na memória mas não correndo Será encerrado.
Então, basicamente, o Android sempre terá pelo menos 40 MB de memória disponível, o que é suficiente para acomodar mais um aplicativo antes assassino de pouca memória começa 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 na experiência do usuário.
Infelizmente, o que alguns entusiastas do homebrew começaram a recomendar é que o valor seja aumentado para, por exemplo, 100 MB antes que o LMK comece. Agora o usuário realmente perder RAM (100 - 40 = 60), então, em vez de usar este espaço para armazenar aplicativos de back-end, o sistema manterá essa quantidade de memória livre , sem absolutamente nenhum propósito para isso.
Afinação LKM pode ser útil para dispositivos muito mais antigos com 512 RAM, mas quem ainda possui esses? 2 GB é a “faixa de orçamento” moderna, até mesmo dispositivos de 4 GB de RAM são vistos como “faixa intermediária” atualmente, então os ajustes LMK estão realmente desatualizados e inúteis.
Ajustes de I / O
Em muitos scripts de otimização para Android, você frequentemente encontrará ajustes que abordam o subsistema de E / S. Por exemplo, vamos dar uma olhada no Raio! Script, que contém estas linhas:
echo 0> $ i / fila / rotacional; echo 1024> $ i / queue / nr_requests;
A primeira linha dará as instruções do agendador de I / O para lidar com um SSD, e a segunda aumenta o tamanho máximo da fila de I / O de 128 para 1024 - porque a variável $ i contém um caminho para a árvore de dispositivos de bloco em / 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;
Isso é seguido por mais linhas que pertencem a outros planejadores, mas, em última análise, os dois primeiros comandos são inúteis porque:
Um kernel Linux moderno é capaz de entender com que tipo de meio de armazenamento está trabalhando por padrão.
Uma longa fila de entrada-saída ( como 1024) é inútil em um dispositivo Android moderno, na verdade não faz sentido mesmo no desktop - é realmente recomendado apenas em servidores pesados . Seu telefone não é um servidor Linux de serviço pesado.
Para um dispositivo Android, praticamente não há aplicativos priorizados na entrada-saída e nenhum driver mecânico, então o melhor planejador é o noop / FIFO-queue, então este tipo de planejador “ puxão' não está fazendo nada de especial ou significativo para o subsistema de E / S. Na verdade, todos esses comandos de lista multitelas são melhor substituídos por um ciclo simples:
para i em / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats concluído
Isso habilitaria o agendador 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 muito pequeno e quase completamente insignificante.
Outro ajuste de I / O inútil frequentemente 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 iniciais 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 os pré-carregará na RAM, o que deve reduzir o tempo de retorno. Parece ótimo no papel, mas o algoritmo de leitura antecipada é mais frequente errado , o que leva a operações de entrada-saída totalmente desnecessárias, sem falar no alto consumo de RAM.
Altos valores de leitura antecipada entre 1 - 8 MB são recomendados em matrizes RAID, mas para dispositivos Android, é melhor apenas deixar o valor padrão de 128 KB.
Ajustes do sistema de gerenciamento de memória virtual
Outra técnica de “otimização” comum é ajustar o subsistema de gerenciamento de memória virtual. Isso normalmente visa apenas duas variáveis de kernel, vm.dirty_background_ratio e vm.dirty_ratio, que são para ajustar o tamanho do buffer para armazenar dados “sujos”. Sujo dados são normalmente dados que foram gravados no disco, mas há mais ainda na memória e esperando para serem gravados no disco.
Os valores típicos de ajuste em distros Linux e Androis para o subsistema de gerenciamento de VM seriam:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Então, o que isso tenta fazer é que quando o buffer de dados sujos é 10% da quantidade total de RAM, ele desperta pdflush fluir e começar a gravar dados no disco - se a operação de gravação de dados no disco for muito intenso , o buffer continuará a crescer e quando atingir 20% da RAM disponível, o sistema passará para a operação de gravação subsequente no modo síncrono - sem pré-buffer. Isso significa que o trabalho de gravação no aplicativo de disco será bloqueado, até que os dados sejam gravados no disco (AKA ‘lag’).
O que você deve entender é que mesmo se o tamanho do buffer não chega a 10% , o sistema iniciará automaticamente o pdflush após 30 segundos. Uma combinação de 10/20 é bastante razoável, por exemplo, em um dispositivo com 1 GB de RAM, isso seria igual a 100/200 MB de RAM, o que é mais do que suficiente em termos de registros de burst onde a velocidade geralmente está 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, os escritores do script tentam empurrar esse valor ainda mais alto, a taxas absurdas. Por exemplo, podemos encontrar no Xplix script de otimização uma taxa de até 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 define o limite de um buffer sujo para 500/900 MB, o que é completamente inútil para um dispositivo Android, porque só funcionaria em gravação constante no disco - algo que só acontece em um servidor Linux pesado.
Raio! O script usa um valor mais razoável, mas no geral, ainda é bastante sem sentido:
if ['$ 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 os 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 espalhar 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 operações, sem ter que gravar dados no disco, até o último não mudará para o modo síncrono, o que permitirá que os aplicativos reduzam o atraso na gravação.
Ajustes adicionais inúteis e ajustes de desempenho
Existem 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 alguns aspecto do desempenho, ao mesmo tempo que degradam o dispositivo de outras maneiras ( geralmente se resume a desempenho vs consumo de bateria) .
Aqui estão algumas otimizações populares adicionais que podem ou não ser úteis, dependendo do sistema Android e do dispositivo.
- Aceleração - a pequena aceleração para melhorar o desempenho e undervolting - economiza um pouco da bateria.
- Otimização de banco de dados - em teoria, devemos dar uma melhoria no desempenho do dispositivo, mas é duvidoso.
- Zipalign - Ironicamente, apesar do alinhamento de conteúdo de recursos do Android SDK embutido no arquivo APK na loja, você pode descobrir que muitos softwares não são transmitidos por meio do zipalign.
- Desative os serviços desnecessários do sistema, removendo o sistema não utilizado e os aplicativos de terceiros raramente utilizados. Basicamente, desinstalando bloatware.
- Kernel personalizado com otimizações para um dispositivo específico (novamente, nem todos os núcleos são igualmente bons).
- Noop do agendador de E / S já descrito.
- Algoritmo de saturação TCP Westwood - usado com mais eficiência no Android Cubic padrão para redes sem fio, disponível em kernels personalizados.
Configurações inúteis build.prop
LaraCraft304 do fórum de desenvolvedores XDA conduziu um estudo e descobriu que um número impressionante de configurações de /system/build.prop recomendadas para uso de “especialistas” não existe no AOSP de origem e no 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_err_rpt ersist.sys.shutdown.mode_Tag andróide Desenvolvimento 12 minutos lidos
