I più comuni miti sull'ottimizzazione di Android sono stati sfatati

Esistono molte guide didattiche dedicate all'aumento delle prestazioni di Android e suggerimenti generali per l'ottimizzazione. Alcuni di essi sono legittimi e altri si basano solo in teoria, o metodi operativi obsoleti nel sistema Android, o sono semplicemente assurdità. Ciò include raccomandazioni per lo scambio, valori aggiunti a build.prop e modifiche variabili nel kernel di Linux.

Ci sono anche un sacco di "script di ottimizzazione" là fuori, zip. Flashable all-in-one che promettono di aumentare significativamente le prestazioni, la durata della batteria e altre cose. Alcune delle modifiche possono effettivamente funzionare, ma la maggior parte è semplicemente un effetto placebo, o peggio, ha effettivamente un impatto negativo sul dispositivo.

Ciò non vuol dire che le persone rilascino intenzionalmente script malvagi: sul Play Store ci sono sicuramente applicazioni a pagamento fasulle, ma gli script di ottimizzazione rilasciati sui forum Android sono generalmente ben intenzionati, succede solo che lo sviluppatore potrebbe essere informato male, o semplicemente sperimentando varie modifiche di ottimizzazione. Sfortunatamente, si verifica una sorta di effetto valanga, specialmente negli script di ottimizzazione "all-in-one". Una piccola manciata di modifiche può effettivamente fare qualcosa, mentre un'altra serie di modifiche in una sceneggiatura potrebbe non fare assolutamente nulla - tuttavia questi script vengono tramandati come proiettili magici, senza alcuna vera indagine su ciò che funziona e cosa no .

Pertanto, molti script di ottimizzazione all-in-one utilizzano gli stessi metodi, alcuni dei quali sono completamente obsoleti o dannosi a lungo termine. In sintesi, la maggior parte degli script di ottimizzazione "all-in-one" non sono altro che sintonizzazioni consigliate e messe a repentaglio, senza una chiara idea di come o perché queste ottimizzazioni "funzionano: gli utenti quindi eseguono il flash degli script e affermano che le loro prestazioni sono improvvisamente più veloci ( quando in effetti, è stato molto probabilmente l'atto molto semplice di riavviare il dispositivo che ha causato un aumento delle prestazioni, poiché tutto nella RAM del dispositivo viene ripulito) .

In questo articolo esclusivo di Appuals, metteremo in evidenza alcuni dei consigli più comuni per " ottimizzare" le prestazioni di Android e se si tratta semplicemente di un mito o di una modifica legittima delle prestazioni del dispositivo.

Scambiare

In cima all'elenco dei miti c'è lo swap per Android, che è abbastanza assurdo in termini di ottimizzazione per Android. Lo scopo principale degli swap è quello di creare e connettere il file di paging, che libererà spazio di memoria in memoria. Sembra ragionevole sulla carta, ma è davvero applicabile a un server, che non ha quasi interattività.

Quando usi lo scambio del tuo telefono Android regolarmente, si verificheranno gravi ritardi derivanti da cose che scivolano oltre la cache. Immagina, ad esempio, se un'applicazione tenta di visualizzare un'immagine, che è memorizzata nello scambio, che ora deve ricaricare il disco dopo aver liberato spazio posizionando lo scambio di dati con un'altra applicazione. È davvero disordinato.

Alcuni appassionati di ottimizzazione possono dire che lo swap non ha offerto problemi, ma non è lo swap a migliorare le prestazioni: è il meccanismo Android incorporato lowmemorykiller, che ucciderà regolarmente i processi gonfiati e ad alta priorità che non vengono utilizzati. LMK è stato progettato specificamente per la gestione di condizioni di memoria insufficiente, viene richiamato dal processo kswapd e generalmente uccide i processi dello spazio utente. Questo è diverso da OOMkiller (killer di memoria insufficiente), ma è un argomento completamente diverso.

Il punto è che un dispositivo con, ad esempio, 1 GB di RAM non può mai raggiungere i dati sulle prestazioni necessari in uno scambio, quindi lo scambio non è assolutamente necessario in Android. La sua implementazione è semplicemente irta di ritardi e porta a un peggioramento delle prestazioni, piuttosto che a ottimizzarlo.

zRAM: obsoleto e non più efficiente

zRAM è un metodo collaudato ed efficace per l'ottimizzazione dei dispositivi, per i dispositivi più vecchi - pensa ai dispositivi basati su KitKat che funzionano solo con circa 512 MB di RAM. Il fatto che alcune persone includano ancora le modifiche di zRAM negli script di ottimizzazione o che raccomandino zRAM come una sorta di modifica dell'ottimizzazione moderna, è un esempio di persone che generalmente non seguono gli ultimi protocolli operativi.

zRAM era destinato a SoC multi-core entry-level di fascia economica, come dispositivi che utilizzano chipset MTK e 512 MB di RAM. Praticamente telefoni cinesi molto economici. Quello che sostanzialmente fa zRAM è separare il kernel tramite il flusso di crittografia.

Quando zRAM viene utilizzato su dispositivi meno recenti con un solo core, anche se su tali dispositivi si consiglia zRAM, si verificano ritardi di grandi quantità di ritardi. Questo succede anche con la tecnologia KSM ( Kernel Same Page Merging) che combina pagine di memoria identiche nel tentativo di liberare spazio. Questo è di fatto raccomandato da Google, ma porta a ritardi maggiori sui dispositivi più vecchi, perché i core core costantemente attivi corrono continuamente dalla memoria alla ricerca di pagine duplicate. Fondamentalmente, provare a eseguire l'ottimizzazione ottimizza ulteriormente il dispositivo, ironicamente.

Seminatrice: obsoleta da Android 3.0

Uno dei suggerimenti per l'ottimizzazione più dibattuti tra gli sviluppatori Android è Seeder, e siamo sicuri che qualcuno potrebbe provare a dimostrarci errato su questo argomento, ma prima dobbiamo esaminare la storia di Seeder.

App Seeder per Android

Sì, esiste un gran numero di report che dichiarano migliori prestazioni Android dopo l'installazione su dispositivi Android molto più vecchi . Tuttavia, le persone per qualsiasi motivo credono che ciò significhi che è anche un'ottimizzazione applicabile per i moderni dispositivi Android, il che è assolutamente assurdo. Il fatto che Seeder sia ancora mantenuto e offerto come uno strumento " moderno" di riduzione del ritardo è un esempio di disinformazione - sebbene questo non sia colpa dello sviluppatore di Seeder, poiché anche la loro pagina Play Store nota che Seeder è meno efficace dopo Android 4.0+. Tuttavia, per qualsiasi motivo, Seeder continua a comparire nelle discussioni sull'ottimizzazione per i moderni sistemi Android.

Quello che Seeder fondamentalmente fa per Android 3.0 è risolvere un bug in cui il runtime Android userebbe attivamente il file / dev / random / per acquisire entropia. Il / dev / random / buffer diventerebbe instabile e il sistema sarebbe bloccato fino a riempire la quantità richiesta di dati - pensa a piccole cose come i vari sensori e pulsanti sul dispositivo Android.

L'autore di Seeder ha preso il demone Linux rngd e ha compilato per il disastroso Android in modo che prendesse i dati casuali da un percorso / dev / urandom molto più veloce e prevedibile e li unisse in dev / random / ogni secondo, senza consentire / dev / random / per esaurirsi. Ciò ha comportato un sistema Android che non ha sperimentato una mancanza di entropia e si è comportato in modo molto più fluido.

Google ha eliminato questo bug dopo Android 3.0, ma per qualche motivo, Seeder appare ancora negli elenchi di "modifiche consigliate" per l'ottimizzazione delle prestazioni di Android. Inoltre, l'app Seeder ha alcuni analoghi come sEFix che includono la funzionalità di Seeder, sia usando lo stesso rngd o l'alternativa alternativa, sia anche solo un collegamento simbolico tra / dev / urandom e / dev / random. Questo è assolutamente inutile per i moderni sistemi Android.

Il motivo per cui è inutile è perché le versioni Android più recenti usano / dev / random / in tre componenti principali: libcrypto, per crittografare connessioni SSL, generare chiavi SSH, ecc. WPA_supplication / hostapd che genera chiavi WEP / WPA e, infine, una manciata di librerie per la generazione di ID nella creazione di file system EXT2 / EXT3 / EXT4.

Quindi, quando i miglioramenti basati su Seeder o Seeder sono inclusi nei moderni script di ottimizzazione Android, ciò che finisce per accadere è un degrado delle prestazioni del dispositivo, perché rngd risveglierà costantemente il dispositivo e causerà un aumento della frequenza della CPU, che ovviamente influisce negativamente sul consumo della batteria .

Odex

Il firmware di serie sui dispositivi Android praticamente sempre odex. Ciò significa che accanto al pacchetto standard per le app Android in formato APK, che si trova in / system / app / e / system / priv-app /, hanno gli stessi nomi di file con l'estensione .odex. I file odex contengono applicazioni bytecode ottimizzate che sono già passate attraverso il validatore e l'ottimizzatore della macchina virtuale, quindi registrate in un file separato utilizzando qualcosa come lo strumento dexopt .

Quindi i file odex sono pensati per scaricare la macchina virtuale e offrire un avvio accelerato dell'applicazione odexed - sul lato negativo, i file ODEX impediscono le modifiche al firmware e creano problemi con gli aggiornamenti, quindi per questo motivo molte ROM personalizzate come LineageOS sono distribuite senza ODEX .

La generazione di file ODEX viene eseguita in diversi modi, come l'utilizzo di Odexer Tool: il problema è che è puramente un effetto placebo. Quando il moderno sistema Android non trova i file odex nella directory / system, il sistema li creerà e li posizionerà nella directory / system / dalvik-cache /. Questo è esattamente ciò che sta accadendo quando, ad esempio, si esegue il flashing di una nuova versione di Android e viene visualizzato il messaggio "Occupato, ottimizzazione delle applicazioni" per un po '.

Modifiche a Lowmemorykiller

Il multitasking in Android differisce dagli altri sistemi operativi mobili, nel senso che si basa su un modello classico in cui le applicazioni funzionano silenziosamente in background e non ci sono restrizioni sul numero di app in background (a meno che non sia impostato in Opzioni sviluppatore, ma questo è generalmente sconsigliato) - inoltre, la funzionalità di passaggio a un'esecuzione in background non viene interrotta, sebbene il sistema si riservi il diritto di uccidere le app in background in situazioni di memoria insufficiente ( vedere dove abbiamo già parlato di killer memoria insufficiente e killer memoria insufficiente in precedenza in questo guida) .

Per tornare al meccanismo lowmemorykiller, Android può continuare a funzionare con una quantità limitata di memoria e una mancanza di partizione di swap. L'utente può continuare ad avviare applicazioni e passare da una all'altra e il sistema ucciderà silenziosamente le app in background non utilizzate per provare a liberare memoria per le attività attive.

Questo è stato molto utile per Android nei primi giorni, anche se per qualche motivo è diventato popolare sotto forma di app task-killer, che sono generalmente più dannose che benefiche. Le app killer si svegliano a intervalli prestabiliti o vengono eseguite dall'utente e sembrano liberare grandi quantità di RAM, che viene vista come positiva: più RAM libera significa un dispositivo più veloce, giusto? Questo non è esattamente il caso di Android, tuttavia.

In effetti, avere una grande quantità di RAM libera può effettivamente essere dannoso per le prestazioni del dispositivo e la durata della batteria. Quando le app sono archiviate nella RAM di Android, è molto più facile richiamarle, avviarle, ecc. Il sistema Android non ha bisogno di dedicare molte risorse per passare all'app, perché è già presente nella memoria.

Per questo motivo, i killer non sono così popolari come una volta, anche se i novizi Android tendono ancora a fare affidamento su di loro per qualche motivo ( mancanza di informazioni, purtroppo) . Sfortunatamente, una nuova tendenza ha sostituito i task-killer, la tendenza delle accordature dei meccanismi a basso consumo di memoria . Questo sarebbe ad esempio l' app MinFreeManager e l'idea principale è quella di aumentare il sovraccarico di RAM prima che il sistema inizi a uccidere le app in background.

Ad esempio, la RAM standard funziona ai bordi: 4, 8, 12, 24, 32 e 40 Mb e quando viene riempito lo spazio di archiviazione libero di 40 MB, una delle app memorizzate nella cache viene caricata nella memoria ma non in esecuzione sarà terminato.

Quindi, in sostanza, Android avrà sempre almeno 40 MB di memoria disponibile, che è sufficiente per ospitare un'altra applicazione prima che lowmemorykiller inizi il suo processo di pulizia, il che significa che Android farà sempre del suo meglio per utilizzare la massima quantità di RAM disponibile senza interferire con il l'esperienza utente.

Purtroppo, ciò che alcuni appassionati di homebrew hanno iniziato a raccomandare è che il valore sia aumentato, ad esempio, a 100 MB prima che entri LMK. Ora l'utente perderà effettivamente la RAM (100 - 40 = 60), quindi invece di utilizzare questo spazio per archiviare- fine alle app, il sistema manterrà libera questa quantità di memoria, senza alcuno scopo.

L'ottimizzazione LKM può essere utile per dispositivi molto più vecchi con 512 RAM, ma chi ne possiede più? 2 GB è la moderna "fascia di budget", anche i dispositivi RAM da 4 GB sono visti come "di fascia media" in questi giorni, quindi le modifiche LMK sono davvero obsolete e inutili.

Modifiche I / O

In molti script di ottimizzazione per Android troverai spesso modifiche che riguardano il sottosistema I / O. Ad esempio, diamo un'occhiata a ThunderBolt! Script, che contiene queste righe:

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

La prima riga fornirà le istruzioni dello scheduler I / O quando si tratta di un SSD e la seconda aumenta la dimensione massima dell'I / O della coda da 128 a 1024, poiché la variabile $ i contiene un percorso all'albero dei dispositivi a blocchi in / sys e lo script viene eseguito in un ciclo.

Successivamente, trovi una linea relativa allo scheduler CFQ:

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

Questo è seguito da più righe che appartengono ad altri pianificatori, ma alla fine i primi due comandi sono inutili perché:

Un moderno kernel Linux è in grado di capire con quale tipo di supporto di archiviazione lavora per impostazione predefinita.

Una lunga coda di input-output ( come 1024) è inutile su un moderno dispositivo Android, infatti è insignificante anche su desktop: è davvero consigliata solo su server pesanti . Il tuo telefono non è un server Linux pesante.

Per un dispositivo Android, non ci sono praticamente applicazioni con priorità nell'input-output e nessun driver meccanico, quindi il miglior pianificatore è la coda noop / FIFO, quindi questo tipo di scheduler " tweak" non sta facendo nulla di speciale o significativo per il Sottosistema I / O. In effetti, tutti questi comandi dell'elenco multi-schermo sono meglio sostituiti da un semplice ciclo:

 per i in / sys / block / mmc *; echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done 

Ciò consentirebbe allo scheduler noop per tutte le unità dall'accumulo di statistiche I / O, che dovrebbe avere un impatto positivo sulle prestazioni, sebbene molto piccolo e quasi completamente trascurabile.

Un altro inutile tweak I / O che si trova spesso negli script delle prestazioni è l'aumento dei valori read-ahead per le schede SD fino a 2 MB. Il meccanismo di lettura anticipata è per le prime letture dei dati dai media, prima che l'app richieda l'accesso a tali dati. Quindi, in sostanza, il kernel tenterà di capire quali dati saranno necessari in futuro e li precaricherà nella RAM, il che dovrebbe quindi ridurre i tempi di ritorno. Questo suona alla grande sulla carta, ma l'algoritmo read-ahead è più spesso sbagliato, il che porta a operazioni totalmente inutili di input-output, per non parlare di un elevato consumo di RAM.

Valori di lettura anticipata compresi tra 1 e 8 MB sono raccomandati negli array RAID, ma per i dispositivi Android, è meglio lasciare solo il valore predefinito di 128 KB.

Modifiche al sistema di gestione della memoria virtuale

Un'altra tecnica di "ottimizzazione" comune è l'ottimizzazione del sottosistema di gestione della memoria virtuale. Questo di solito prende di mira solo due variabili del kernel, vm.dirty_background_ratio e vm.dirty_ratio, che servono a regolare le dimensioni del buffer per l'archiviazione di dati "sporchi". I dati sporchi sono in genere dati che sono stati scritti su disco, ma ce ne sono altri ancora in memoria e in attesa di essere scritti su disco.

I valori tipici di tweak in entrambe le distro Linux e Androis nel sottosistema di gestione della VM sarebbero i seguenti:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Quindi, ciò che tenta di fare è che quando il buffer di dati sporchi è il 10% della quantità totale di RAM, si risveglia il flusso pdflush e inizia a scrivere i dati sul disco - se l'operazione di registrazione dei dati sul disco sarà troppo intensa, il buffer continuerà a crescere e quando raggiungerà il 20% della RAM disponibile, il sistema passerà alla successiva operazione di scrittura in modalità sincrona - senza pre-buffer. Ciò significa che il lavoro di scrittura sull'applicazione disco verrà bloccato, fino a quando i dati non verranno scritti sul disco ("ritardo" di AKA).

Quello che dovresti capire è che anche se la dimensione del buffer non raggiunge il 10%, il sistema avvia automaticamente pdflush dopo 30 secondi. Una combinazione di 10/20 è abbastanza ragionevole, ad esempio su un dispositivo con 1 GB di RAM questo equivarrebbe a 100/200 MB di RAM, che è più che sufficiente in termini di record di scoppio in cui la velocità è spesso inferiore al record di velocità nel sistema NAND -memoria o scheda SD, ad esempio durante l'installazione di app o la copia di file da un computer.

Per qualche ragione, gli sceneggiatori cercano di spingere questo valore ancora più in alto, a tassi assurdi. Ad esempio, possiamo trovare nello script di ottimizzazione di Xplix una velocità massima di 50/90.

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

Su un dispositivo con 1 GB di memoria, questo imposta un limite su un buffer sporco a 500/900 MB, che è completamente inutile per un dispositivo Android, perché funzionerebbe solo con una registrazione costante sul disco - qualcosa che accade solo su un disco pesante Server Linux.

Fulmine! Lo script utilizza un valore più ragionevole, ma nel complesso è ancora abbastanza insignificante:

 if ["$ mem" -lt 524288]; quindi sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; quindi 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; 

I primi due comandi vengono eseguiti su smartphone con 512 MB di RAM, il secondo - con 1 GB e altri - con oltre 1 GB. Ma in realtà c'è solo un motivo per modificare le impostazioni predefinite: un dispositivo con una memoria interna o una scheda di memoria molto lenta. In questo caso è ragionevole diffondere i valori delle variabili, ovvero fare qualcosa del genere:

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

Quindi, quando un sistema di sovratensione scrive operazioni, senza dover registrare dati sul disco, fino all'ultimo non passerà alla modalità sincrona, che consentirà alle applicazioni di ridurre il ritardo durante la registrazione.

Ulteriori modifiche inutili e ottimizzazioni delle prestazioni

Ci sono molte più "ottimizzazioni" là fuori che davvero non fanno nulla. La maggior parte di essi semplicemente non ha alcun effetto, mentre altri possono migliorare alcuni aspetti delle prestazioni, degradando il dispositivo in altri modi (di solito si riduce a prestazioni rispetto al consumo della batteria) .

Ecco alcune ottimizzazioni popolari aggiuntive che potrebbero essere o non essere utili, a seconda del sistema e del dispositivo Android.

  • Accelerazione: la piccola accelerazione per migliorare le prestazioni e la minima tensione consente di risparmiare una piccola batteria.
  • Ottimizzazione del database - In teoria questo dovrebbe dare un miglioramento delle prestazioni del dispositivo, ma è dubbio.
  • Zipalign - Ironia della sorte, nonostante l'allineamento del contenuto della funzionalità SDK Android integrata all'interno del file APK nel negozio, è possibile trovare un sacco di software che non viene trasmesso tramite zipalign.
  • Disabilita i servizi di sistema non necessari, rimuovendo il sistema inutilizzato e le applicazioni di terze parti utilizzate di rado. Fondamentalmente, disinstallare bloatware.
  • Kernel personalizzato con ottimizzazioni per un dispositivo specifico (di nuovo, non tutti i nuclei sono ugualmente buoni).
  • Noop dello scheduler I / O già descritto.
  • Algoritmo di saturazione TCP Westwood: utilizzato in modo più efficiente in Android Cubic predefinito per reti wireless, disponibile in kernel personalizzati.

Impostazioni inutili build.prop

LaraCraft304 del forum degli sviluppatori XDA ha condotto uno studio e ha scoperto che un numero impressionante di impostazioni /system/build.prop consigliate per l'uso "esperti" non esistono nel sorgente AOSP e CyanogenMod. Ecco la 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.shutdownPode_AD.AD.AP 

Articoli Interessanti