Cele mai comune mituri de optimizare a Android au fost deconectate

Există o mulțime de ghiduri instrucționale dedicate creșterii performanței Android și sfaturi de optimizare generală. Unele dintre ele sunt legitime, iar altele se bazează doar în teorie, sau metode operaționale depășite în sistemul Android sau sunt doar prostii. Aceasta include recomandări de schimb, valori adăugate la build.prop și modificări variabile în nucleul Linux.

Există chiar și o tonă de „scripturi de optimizare”, zip-uri tot-într-unul flashable, care promit să crească semnificativ performanța, durata de viață a bateriei și alte lucruri. Unele dintre modificări pot funcționa efectiv, dar majoritatea sunt pur și simplu un efect placebo sau, mai rău, au un impact negativ asupra dispozitivului.

Asta nu înseamnă că oamenii lansează în mod intenționat scripturi nefaste - există cu siguranță aplicații fals plătite pe Play Store, dar scripturile de optimizare lansate pe forumurile Android sunt în general bine intenționate, dar se întâmplă ca dezvoltatorul să fie informat greșit, sau pur și simplu experimentând diverse modificări de optimizare. Din păcate, un fel de efect de bulă de zăpadă tinde să apară, în special în scripturile de optimizare „all-in-one”. O mică mână de modificări poate face ceva, în timp ce un alt set de modificări dintr-un script nu poate face absolut nimic - totuși, aceste scripturi sunt transmise ca fiind gloanțe magice, fără nici o investigație reală asupra a ceea ce funcționează și ce nu .

Astfel, o mulțime de scripturi de optimizare all-in-one folosesc aceleași metode, unele dintre ele fiind complet depășite sau dăunătoare pe termen lung. În rezumat, majoritatea scripturilor de optimizare „all-in-one” nu sunt altceva decât ajustări recomandate, fără nici o idee clară despre cum sau de ce aceste „optimizări” funcționează - utilizatorii flash apoi scripturile și susțin că performanța lor este brusc mai rapidă. ( când, de fapt, cel mai probabil a fost actul foarte simplu de repornire a dispozitivului lor care a determinat o creștere a performanței, deoarece totul din memoria RAM a dispozitivului este curățat) .

În acest articol exclusiv al Appuals, vom evidenția câteva dintre cele mai frecvente recomandări pentru „ optimizarea” performanței Android și dacă acestea sunt pur și simplu un mit sau o modificare legitimă a performanței dispozitivului.

schimb

În partea de sus a listei de mituri se află swapul Android - care este destul de absurd în ceea ce privește faptul că este considerat a fi o optimizare Android. Scopul principal al Swaps este crearea și conectarea fișierului de paginare, care va elibera spațiu de stocare în memorie. Acest lucru sună sensibil pe hârtie, dar este aplicabil într-adevăr pentru un server, care nu are aproape nicio interactivitate.

Atunci când utilizați swap-ul telefonului Android în mod regulat, acesta va duce la întârzieri severe care decurg din lucrurile care se strecoară pe lângă cache. Imaginați-vă, de exemplu, dacă o aplicație încearcă să afișeze o grafică, care este stocată în swap, care acum trebuie să reîncarce discul după eliberarea spațiului, prin plasarea schimbului de date cu o altă aplicație. Este într-adevăr dezordonat.

Unii pasionați de optimizare pot spune că swap-ul nu oferă niciun fel de probleme, dar nu schimbă performanța - crește performanța - este mecanismul Android integrat lowmemorykiller, care va ucide în mod regulat procesele umflate, cu prioritate ridicată, care nu sunt utilizate. LMK a fost proiectat special pentru gestionarea condițiilor de memorie redusă, este invocat din procesul kswapd și, în general, ucide procesele de spațiu ale utilizatorilor. Acest lucru este diferit de OOMkiller (criminal în afara memoriei), dar acesta este un subiect diferit cu totul.

Ideea este că un dispozitiv cu, de exemplu, 1 GB RAM nu poate atinge niciodată datele de performanță necesare într-un swap, astfel încât swap-ul nu este absolut necesar în Android. Implementarea sa este pur și simplu plină de întârziere și duce la o degradare a performanței, în loc să o optimizeze.

zRAM - depășit și nu mai eficient

zRAM este o metodă dovedită și eficientă pentru optimizarea dispozitivelor, pentru dispozitivele mai vechi - gândiți-vă că dispozitivele bazate pe KitKat funcționează doar cu aproximativ 512 MB RAM. Faptul că unii oameni includ încă modificări zRAM în scripturile de optimizare sau recomandă zRAM ca un fel de modificare modernă a optimizării, este un exemplu în care oamenii nu respectă ultimele protocoale operaționale.

zRAM a fost destinat SoC-urilor multi-core la nivel bugetar la nivel de intrare, cum ar fi dispozitivele care folosesc chipset-uri MTK și 512 MB RAM. Telefoane chinezești foarte ieftine, practic. Ceea ce face zRAM este, de fapt, separarea nucleului prin fluxul de criptare.

Atunci când zRAM este utilizat pe dispozitive mai vechi cu un singur nucleu, chiar dacă zRAM este recomandat pe astfel de dispozitive, cantități mari de întârzieri tind să crească. Acest lucru se întâmplă, de asemenea, cu tehnologia KSM ( Kernel Same Page Merging) care combină pagini de memorie identice, într-o ofertă către spațiu liber. Acest lucru este de fapt recomandat de Google, dar duce la întârzieri mai mari pe dispozitivele mai vechi, deoarece core nucleele active în mod constant rulează continuu din memorie pentru a căuta pagini duplicate. Practic, încercarea de a executa modificarea optimizării încetinește dispozitivul și mai departe, ironic.

Seeder - depășit din Android 3.0

Unul dintre cele mai dezbătute sfaturi de optimizare printre dezvoltatorii Android este seeder și suntem siguri că cineva ar putea încerca să ne dovedească greșit pe acest subiect - dar mai întâi trebuie să examinăm istoricul seeder.

Aplicație Seeder pentru Android

Da, există un număr mare de rapoarte care declară performanțe Android mai bune după instalarea pe dispozitive Android mult mai vechi . Cu toate acestea, oamenii din orice motiv consideră că acest lucru înseamnă că este și o optimizare aplicabilă pentru dispozitivele Android moderne, ceea ce este absolut absurd. Faptul că Seeder este în continuare menținut și oferit ca instrument „ modern” de reducere a lagului este un exemplu de dezinformare - deși acest lucru nu este vina dezvoltatorului Seeder, deoarece chiar și pagina lor Play Store notează că Seeder este mai puțin eficient după Android 4.0+. Cu toate acestea, indiferent de motiv, Seeder apare în discuțiile de optimizare pentru sistemele Android moderne.

Ceea ce face în mod practic Seeder pentru Android 3.0 este abordarea unui bug în care runtime-ul Android ar folosi în mod activ fișierul / dev / random / pentru a dobândi entropie. Bufferul / dev / random / ar deveni instabil, iar sistemul ar fi blocat până când va umple cantitatea necesară de date - gândiți-vă la mici lucruri precum diferiții senzori și butoane de pe dispozitivul Android.

Autorul Seeder a preluat Linux-demon rngd și a compilat pentru inastroil Android, astfel încât a preluat date aleatorii dintr-o cale mult mai rapidă și mai previzibilă / dev / urandom și le contopește în dev / random / în fiecare secundă, fără a permite / dev / random / a deveni epuizat Acest lucru a dus la un sistem Android care nu a prezentat o lipsă de entropie și a avut o performanță mult mai lină.

Google a spart acest bug după Android 3.0, dar, din anumite motive, Seeder apare în continuare pe listele „modificări recomandate” pentru optimizarea performanței Android. Mai mult, aplicația Seeder are câțiva analogi precum sEFix, care includ funcționalitatea Seeder, indiferent dacă folosim același rngd sau alternativul areged, sau chiar doar un simbol între / dev / urandom și / dev / random. Acest lucru este absolut inutil pentru sistemele Android moderne.

Motivul pentru care este inutil este că versiunile Android mai noi utilizează / dev / random / în trei componente principale - libcrypto, pentru criptarea conexiunilor SSL, generarea cheilor SSH, etc. WPA_supplication / hostapd care generează chei WEP / WPA și, în final, o mână de biblioteci pentru generarea ID în crearea sistemelor de fișiere EXT2 / EXT3 / EXT4.

Așadar, atunci când îmbunătățirile bazate pe Seeder sau Seeder sunt incluse în scripturile moderne de optimizare Android, ceea ce se termină se întâmplă este o degradare a performanței dispozitivului, deoarece rngd va trezi constant dispozitivul și va provoca o creștere a frecvenței procesorului, ceea ce, desigur, afectează negativ consumul bateriei. .

ODEX

Firmware-ul pe stoc pe dispozitivele Android este mereu odex. Acest lucru înseamnă că, alături de pachetul standard pentru aplicații Android în format APK, găsit în / system / app / și / system / priv-app /, există aceleași nume de fișier cu extensia .odex. Fișierele odex conțin aplicații bytecode optimizate, care au trecut deja prin mașina virtuală a validatorului și a optimizatorului, apoi înregistrate într-un fișier separat folosind ceva precum instrumentul de dexopt .

Deci, fișierele odex sunt menite să descarce mașina virtuală și să ofere o lansare accelerată a aplicației odexed - pe dezavantaj, fișierele ODEX împiedică modificările la firmware și creează probleme cu actualizările, astfel încât din acest motiv multe ROM-uri personalizate precum LineageOS sunt distribuite fără ODEX .

Generarea fișierelor ODEX se face în mai multe moduri, cum ar fi utilizarea Odexer Tool - problema este că efectul său placebo este pur. Când sistemul Android modern nu găsește fișiere odex în directorul / sistem, sistemul le va crea și le va plasa în directorul / system / dalvik-cache /. Acest lucru este exact ceea ce se întâmplă atunci când, de exemplu, blițează o nouă versiune Android și dă mesajul „Ocupat, optimizarea aplicațiilor” pentru o perioadă.

Reduceri lowmemorykiller

Multitasking-ul în Android diferă de alte sisteme de operare mobile, în sensul că se bazează pe un model clasic în care aplicațiile funcționează liniștit în fundal și nu există restricții privind numărul de aplicații de fundal ( cu excepția cazului în care una este setată în Opțiuni pentru dezvoltatori, dar aceasta este în general, recomandat împotriva) - în plus, funcționalitatea tranziției la o execuție de fundal nu este oprită, deși sistemul își rezervă dreptul de a ucide aplicații de fundal în situații de memorie scăzută ( vezi unde am vorbit despre lowmemorykiller și killer din memorie mai devreme în acest ghid) .

Pentru a reveni la mecanismul lowmemorykiller, Android poate continua să funcționeze cu o cantitate limitată de memorie și o lipsă de partiție swap. Utilizatorul poate continua să lanseze aplicații și să comute între ele, iar sistemul va ucide în tăcere aplicațiile de fundal neutilizate pentru a încerca să elibereze memorie pentru activitățile active.

Acest lucru a fost extrem de util pentru Android în primele zile, deși, din anumite motive, a devenit popular sub formă de aplicații care utilizează task-killer, care sunt în general mai dăunătoare decât benefice. Aplicațiile de tip Task se trezesc la intervale setate sau sunt administrate de utilizator și par să elibereze cantități mari de memorie RAM, ceea ce este considerat pozitiv - mai mult RAM gratuit înseamnă un dispozitiv mai rapid, nu? Acesta nu este exact cazul Android, însă.

De fapt, existența unei cantități mari de memorie RAM gratuită poate fi de fapt dăunătoare pentru performanțele dispozitivului și durata de viață a bateriei. Când aplicațiile sunt stocate în memoria RAM a lui Android, este mult mai ușor să le apelezi, să le lansezi, etc. Sistemul Android nu trebuie să aloce resurse pentru a comuta la aplicație, deoarece există deja în memorie.

Din această cauză, ucigașii nu sunt la fel de populari ca altădată, deși începătorii Android încă tind să se bazeze pe ei din anumite motive ( lipsă de informații, din păcate) . Din păcate, o nouă tendință a înlocuit task-killers, tendința de reglarea mecanismelor lowmemorykiller . Aceasta ar fi, de exemplu, aplicația MinFreeManager, iar ideea principală este de a crește memoria aeriană RAM înainte ca sistemul să înceapă să omoare aplicații de fundal.

De exemplu, RAM-ul standard funcționează la borduri - 4, 8, 12, 24, 32 și 40 Mb, iar când spațiul de stocare gratuit de 40 MB este completat, una dintre aplicațiile din cache care este încărcată în memorie, dar care nu rulează va fi reziliat.

Deci, practic, Android va avea întotdeauna cel puțin 40 MB de memorie disponibilă, ceea ce este suficient pentru a găzdui o altă aplicație înainte ca lowmemorykiller să înceapă procesul de curățare - ceea ce înseamnă că Android va face întotdeauna tot posibilul să utilizeze cantitatea maximă de RAM disponibilă fără a interfera cu experiența utilizatorului.

Din păcate, ceea ce au început unii pasionați de homebrew recomandat este ca valoarea să fie ridicată la, de exemplu, 100 MB înainte de a începe LMK. Acum, utilizatorul va pierde de fapt RAM (100 - 40 = 60), deci în loc să folosească acest spațiu pentru a stoca înapoi- Aplicații finale, sistemul va păstra această cantitate de memorie liberă, fără niciun scop.

Reglarea LKM poate fi utilă pentru dispozitive mult mai vechi cu 512 RAM, dar cine mai deține cele? 2 GB este „gama bugetară” modernă, chiar și dispozitivele RAM de 4 GB sunt considerate „de nivel mediu” în aceste zile, astfel încât modificările LMK sunt cu adevărat depășite și inutile.

Reglaje I / O

Într-o mulțime de scripturi de optimizare pentru Android veți găsi adesea modificări care se adresează subsistemului I / O. De exemplu, să aruncăm o privire la ThunderBolt! Script, care conține aceste linii:

 ecou 0> $ i / coadă / rotativ; echo 1024> $ i / queue / nr_requests; 

Prima linie va oferi instrucțiunile de planificare E / S în tratarea unui SSD, iar a doua mărește dimensiunea maximă a I / O de coadă de la 128 la 1024 - deoarece variabila $ i conține o cale către arborele dispozitivelor bloc din / sys, iar scriptul rulează într-o buclă.

După aceasta, găsiți o linie legată de planificatorul CFQ:

 ecou 1> $ i / coadă / iosched / back_seek_penalty; ecou 1> $ i / coadă / iosched / low_latency; ecou 1> $ i / coadă / iosched / slice_idle; 

Aceasta este urmată de mai multe linii care aparțin altor planificatori, dar, în cele din urmă, primele două comenzi nu au rost, deoarece:

Un kernel modern Linux este capabil să înțeleagă cu ce tip de suport de stocare funcționează implicit.

O coadă lungă de intrare-ieșire ( cum ar fi 1024) este inutilă pe un dispozitiv Android modern, de fapt, fără sens, chiar și pe desktop - este recomandată doar pe serverele grele . Telefonul dvs. nu este un server Linux de mare încărcare.

Pentru un dispozitiv Android, nu există practic nicio aplicație prioritară la intrare-ieșire și niciun driver mecanic, deci cel mai bun planificator este coada noop / FIFO, astfel că acest tip de „ tweak” al planificatorului nu face nimic special sau semnificativ pentru Subsistem de I / O. De fapt, toate acele comenzi de listă cu mai multe ecrane sunt mai bine înlocuite cu un ciclu simplu:

 pentru i in / sys / block / mmc *; do echo noop> $ i / coadă / planificator ecou 0> $ i / coadă / iostate terminate 

Acest lucru ar permite programatorul noop pentru toate unitățile din acumularea statisticilor E / S, ceea ce ar trebui să aibă un impact pozitiv asupra performanței, deși una foarte mică și aproape complet neglijabilă.

Un alt modificare inutilă de E / S întâlnită adesea în scripturile de performanță este creșterea valorilor citite pentru cardurile SD de până la 2MB. Mecanismul de read-forward este pentru citirea timpurie a datelor de pe media, înainte ca aplicația să solicite accesul la aceste date. Deci, practic, nucleul va încerca să-și dea seama ce date vor fi necesare în viitor și le va preîncărca în memoria RAM, ceea ce ar trebui astfel să reducă timpul de întoarcere. Acest lucru sună excelent pe hârtie, dar algoritmul citit este greșit mai des, ceea ce duce la operații total inutile de intrare-ieșire, ca să nu mai vorbim de un consum mare de RAM.

Valori ridicate de citire între 1 - 8 MB sunt recomandate în matricile RAID, dar pentru dispozitivele Android, este bine să lăsați doar valoarea implicită de 128 KB.

Sistemul virtual de gestionare a memoriei modifică

O altă tehnică comună de „optimizare” este reglarea subsistemului de gestionare a memoriei virtuale. În mod obișnuit, acestea vizează doar două variabile de kernel, vm.dirty_background_ratio și vm.dirty_ratio, care sunt pentru ajustarea dimensiunii bufferului pentru stocarea datelor „murdare”. Datele murdare sunt în mod obișnuit date care au fost scrise pe disc, dar mai sunt încă în memorie și așteaptă să fie scrise pe disc.

Valorile de modificare tipice atât în ​​distros Linux, cât și în Androis pentru subsistemul de gestionare a VM ar fi:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Așadar, ceea ce încearcă să facă este că atunci când bufferul de date murdare este de 10% din cantitatea totală de memorie RAM, trezește fluxul pdflush și începe să scrie date pe disc - dacă operația de înregistrare a datelor pe disc va fi prea intensă, bufferul va continua să crească, iar atunci când va ajunge la 20% din memoria RAM disponibilă, sistemul va trece la operația de scriere ulterioară în modul sincron - fără pre-tampon. Aceasta înseamnă că activitatea de scriere pe aplicația pe disc va fi blocată, până când datele sunt scrise pe disc (AKA „lag”).

Ceea ce ar trebui să înțelegeți este că, chiar dacă dimensiunea tamponului nu atinge 10%, sistemul va începe automat în pdflush după 30 de secunde. O combinație de 10/20 este destul de rezonabilă, de exemplu pe un dispozitiv cu 1 GB RAM ar echivala cu 100/200 MB de memorie RAM, ceea ce este mai mult decât suficient în ceea ce privește înregistrările de spargere în care viteza este adesea sub recordul de viteză în sistemul NAND. -memory sau card SD, cum ar fi atunci când instalați aplicații sau copiați fișiere de pe un computer.

Dintr-un anumit motiv, scenariștii încearcă să împingă această valoare și mai mare, la rate absurde. De exemplu, putem găsi în scriptul de optimizare Xplix o rată de până la 50/90.

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

Pe un dispozitiv cu 1 GB memorie, acest lucru stabilește o limită pentru un tampon murdar la 500/900 MB, ceea ce este complet inutil pentru un dispozitiv Android, deoarece ar funcționa doar sub înregistrare constantă pe disc - ceva care se întâmplă doar pe un produs greu Server Linux.

Fulger! Scriptul folosește o valoare mai rezonabilă, dar, în general, este încă destul de lipsit de semnificație:

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

Primele două comenzi sunt rulate pe smartphone-uri cu 512 MB RAM, a doua - cu 1 GB, iar altele - cu mai mult de 1 GB. Dar, de fapt, există un singur motiv pentru a schimba setările implicite - un dispozitiv cu o memorie internă foarte lentă sau un card de memorie. În acest caz, este rezonabil să răspândim valorile variabilelor, adică să facem așa ceva:

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

Apoi, când un sistem de supratensiune scrie operații, fără a fi necesar să înregistreze date pe disc, până la ultima nu se va trece la modul sincron, ceea ce va permite aplicațiilor să reducă decalajul la înregistrare.

Tweaks și inovații suplimentare de performanță

Există mult mai multe „optimizări” care nu fac nimic. Cele mai multe dintre ele pur și simplu nu au niciun efect, în timp ce altele pot îmbunătăți unele aspecte ale performanței, în timp ce degradează dispozitivul în alte moduri (de obicei se reduce la performanță și la scurgerea bateriei) .

Iată câteva optimizări populare suplimentare care pot fi sau nu utile, în funcție de sistemul și dispozitivul Android.

  • Accelerare - accelerația mică pentru îmbunătățirea performanțelor și subervolirea - economisește puțină baterie.
  • Optimizarea bazelor de date - Teoretic acest lucru ar trebui să ofere o îmbunătățire a performanței dispozitivului, dar este îndoielnic.
  • Zipalign - În mod ironic, în ciuda alinierii conținutului de caracteristici SDK Android încorporat în fișierul APK din magazin, puteți găsi o mulțime de software care nu este transmis prin zipalign.
  • Dezactivați serviciile inutile ale sistemului, eliminând sistemul neutilizat și aplicațiile terțe utilizate rar. Practic, dezinstalarea bloatware.
  • Nucleu personalizat cu optimizări pentru un anumit dispozitiv (din nou, nu toate nucleele sunt la fel de bune).
  • A fost deja descris programator I / O noop.
  • Algoritmul de saturație TCP Westwood - utilizat mai eficient în Android-ul Cubic implicit pentru rețelele wireless, disponibil în sâmburi personalizate.

Setări inutile build.prop

LaraCraft304 de la forumul dezvoltatorilor XDA a realizat un studiu și a constatat că un număr impresionant de setări /system/build.prop recomandate pentru utilizarea „experților” nu există în sursa AOSP și CyanogenMod. Iată 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.m 

Articole Interesante