Astfel, o mulțime de scripturi de optimizare all-in-one utilizează aceleași metode, dintre care unele sunt complet depășite sau dăunătoare pe termen lung. Pe scurt, majoritatea scripturilor de optimizare „all-in-one” nu sunt altceva decât reglaje recomandate, fără nici o idee clară despre cum sau de ce funcționează aceste optimizări - utilizatorii blochează apoi scripturile și susțin că performanța lor este brusc mai rapidă ( când, de fapt, cel mai probabil a fost o simplă acțiune de repornire a dispozitivului care a provocat o creștere a performanței , deoarece totul din memoria RAM a dispozitivului este curățat) .
În acest articol exclusiv Appuals, vom evidenția unele dintre cele mai frecvente recomandări pentru „ optimizare ” Performanța Android și dacă sunt pur și simplu un mit sau o modificare legitimă pentru performanța dispozitivului.
Swap
În partea de sus a listei de mituri se află swap-ul Android - ceea ce este destul de absurd în ceea ce privește faptul că este considerat o optimizare Android. Scopul principal al swaps-ului este crearea și conectarea fișierului de paginare, care va elibera spațiu de stocare în memorie. Sună sensibil pe hârtie , dar se aplică într-adevăr unui Server , care nu are aproape nici o interactivitate.
Când utilizați în mod regulat swap-ul telefonului dvs. Android, acesta va duce la întârzieri severe care decurg din lucrurile care alunecă pe lângă cache. Imaginați-vă, de exemplu, dacă o aplicație încearcă să afișeze o imagine, care este stocată în swap, care acum trebuie să reîncarce discul după ce a eliberat spațiu prin plasarea swap-ului de date cu o altă aplicație. Este foarte dezordonat.
Unii pasionați de optimizare pot spune că swap-ul nu a oferit probleme, dar nu este un swap, ceea ce face ca performanțele să crească - este mecanismul Android încorporat lowmemorykiller , care va ucide în mod regulat procesele umflate, cu prioritate ridicată, care nu sunt utilizate. LMK a fost conceput special pentru gestionarea condițiilor de memorie redusă, este invocat din kswapd proces și, în general, ucide procesele spațiului utilizatorului. Acest lucru este diferit de OOMkiller (criminal fără memorie), dar acesta este cu totul alt subiect.
Ideea este că un dispozitiv cu, de exemplu, 1 GB de RAM nu poate ajunge niciodată la 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 în performanță, mai degrabă decât să o optimizăm.
zRAM - Învechit și nu mai eficient
zRAM este o metodă dovedită și eficientă pentru optimizarea dispozitivelor, pentru dispozitive mai vechi - gândiți-vă la dispozitivele bazate pe KitKat care funcționează doar cu aproximativ 512 MB de RAM. Faptul că unii oameni mai includ modificări zRAM în scripturile de optimizare sau recomandă zRAM ca un fel de optimizare modernă de optimizare, este un exemplu de oameni care nu respectă în general cele mai recente protocoale operaționale.
zRAM a fost destinat pentru SoC-urile multi-core de la nivel bugetar de bază, cum ar fi dispozitivele care utilizează chipset-uri MTK și 512 MB de RAM. Telefoane chinezești foarte ieftine, practic. Ceea ce face zRAM este să separe nucleul prin fluxul de criptare.
Când zRAM este utilizat pe dispozitive mai vechi cu un nucleu unic , chiar dacă zRAM este recomandat pe astfel de dispozitive, cantități mari de întârzieri tind să apară. Acest lucru se întâmplă și cu tehnologia KSM ( Kernel fuzionează aceeași pagină) care combină pagini de memorie identice într-o încercare de a elibera spațiu. De fapt, acest lucru este recomandat de Google, dar duce la decalaje mai mari pe dispozitivele mai vechi, deoarece nucleele de bază active în mod constant rulează continuu din memorie pentru a căuta pagini duplicate. Practic, încercarea de a rula optimizarea optimizării încetinește și mai mult dispozitivul, ironic.
Semănător - Învechit de la Android 3.0
Unul dintre cele mai dezbătute sfaturi de optimizare printre dezvoltatorii Android este cedru și suntem siguri că cineva ar putea încerca să ne dovedească greșit pe această temă - dar mai întâi trebuie să examinăm istoria semănătorului.
Aplicație semănătoare pentru Android
Da, există un număr mare de rapoarte care declară performanțe Android mai bune după instalare pe dispozitive Android mult mai vechi . Cu toate acestea, oamenii din orice motiv consideră că acest lucru înseamnă că este, de asemenea, o optimizare aplicabilă pentru dispozitive Android moderne , ceea ce este absolut absurd. Faptul că Seeder este încă menținut și oferit ca „ modern' instrumentul de reducere a întârzierilor este un exemplu de dezinformare - deși aceasta nu este vina dezvoltatorului Seeder, deoarece chiar și pagina lor din Magazinul Play notează că Seeder este mai puțin eficient după Android 4.0+. Cu toate acestea, din orice motiv, Seeder apare încă în discuțiile de optimizare pentru sistemele Android moderne.
Ceea ce face practic Seeder pentru Android 3.0 este să abordeze o eroare în care runtime-ul Android ar folosi în mod activ fișierul / dev / random / pentru a dobândi entropie. / Dev / random / buffer ar deveni instabil, iar sistemul va fi blocat până când va umple cantitatea necesară de date - gândiți-vă la lucruri mărunte precum diferiții senzori și butoane de pe dispozitivul Android.
Autorul lui Seeder a luat demonul Linux rngd , și compilat pentru inastroil-ul Android, astfel încât să ia date aleatorii dintr-o cale / dev / urandom mult mai rapidă și mai previzibilă și să le îmbine în dev / random / în fiecare secundă, fără a permite / dev / random / să se epuizeze. Acest lucru a dus la un sistem Android care nu a experimentat o lipsă de entropie și a funcționat mult mai ușor.
Google a distrus această eroare după Android 3.0, dar, dintr-un anumit motiv, Seeder apare încă „Modificări recomandate” liste pentru optimizarea performanței Android. În plus, aplicația Seeder are câțiva analogi, cum ar fi sEFix, care includ funcționalitatea Seeder, indiferent dacă folosește același lucru rngd sau alternativa au forjat , sau chiar doar o legătură simbolică î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 folosesc / dev / random / în trei componente principale - libcrypto , pentru criptarea conexiunilor SSL, generarea de chei SSH, etc. WPA_supplication / hostapd care generează chei WEP / WPA și, în cele din urmă, o mână de biblioteci pentru generarea ID-ului în crearea sistemelor de fișiere EXT2 / EXT3 / EXT4.
Deci când Semănătoare sau îmbunătățirile bazate pe semănătoare sunt incluse în scripturile moderne de optimizare Android, ceea ce se întâmplă se întâmplă este degradare în ceea ce privește performanța dispozitivului, deoarece rngd va trezi în mod constant dispozitivul și va provoca o creștere a frecvenței procesorului, ceea ce, desigur, afectează negativ consumul bateriei.
Odex
Firmware-ul stoc pe dispozitivele Android este aproape întotdeauna odex. Aceasta înseamnă că, alături de pachetul standard pentru aplicațiile Android în format APK, găsite în / system / app / și / system / priv-app /, au aceleași nume de fișiere cu extensia .odex. Fișierele odex conțin aplicații bytecode optimizate care au trecut deja prin validatorul și mașina virtuală de optimizare, apoi înregistrate într-un fișier separat utilizând ceva de genul dexopt instrument.
Deci, fișierele odex sunt menite să descarce mașina virtuală și să ofere o lansare accelerată a aplicației odexed - dezavantaj, fișierele ODEX împiedică modificările firmware-ului și creează probleme cu actualizările, deci din acest motiv sunt distribuite multe ROM-uri personalizate precum LineageOS fără ODEX .
Generarea fișierelor ODEX se face în mai multe moduri, cum ar fi utilizarea instrumentului Odexer - problema este că este doar un efect placebo. Când sistemul Android modern nu găsește fișiere odex în directorul / system, sistemul le va crea de fapt și le va plasa în directorul / system / dalvik-cache /. Exact acest lucru se întâmplă atunci când, de exemplu, afișați o nouă versiune Android și afișează mesajul „Aplicații ocupate, optimizate” pentru o vreme.
Modificări 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 unul este setat în Opțiuni pentru dezvoltatori, dar acest lucru este recomandat în general î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țiile de fundal în situații de memorie redusă ( vezi unde am vorbit despre lowmemorykiller și killer out-of-memory mai devreme în acest ghid) .
Pentru a reveni la 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ăți active.
Acest lucru a fost extrem de util pentru Android în primele zile, deși, dintr-un anumit motiv, a devenit popular sub formă de aplicații de ucidere a sarcinilor, care sunt în general mai dăunătoare decât benefice. Aplicațiile de eliminare a sarcinilor fie se trezesc la intervale fixe, fie sunt conduse de utilizator și par să elibereze cantități mari de memorie RAM, ceea ce este văzut ca fiind pozitiv - mai multă memorie RAM gratuită înseamnă un dispozitiv mai rapid, nu? Totuși, nu este exact cazul cu Android.
De fapt, a avea o cantitate mare de memorie RAM gratuită poate fi de fapt dăunător pentru performanța dispozitivului și durata de viață a bateriei. Când aplicațiile sunt stocate în memoria RAM a Android-ului, este mult mai ușor să le apelați, să le lansați etc. Sistemul Android nu trebuie să aloce prea multe resurse pentru trecerea la aplicație, deoarece este deja acolo în memorie.
Din această cauză, ucigașii de sarcini nu sunt cu adevărat la fel de populari ca odinioară, deși începătorii Android tind să se bazeze pe ei din anumite motive ( lipsa de informații, din păcate) . Din păcate, o nouă tendință a înlocuit ucigașii de sarcini, tendința de lowmemorykiller reglaje mecanism. Acesta ar fi de exemplu MinFreeManager și ideea principală este de a crește memoria RAM înainte ca sistemul să înceapă uciderea aplicațiilor de fundal.
De exemplu, memoria RAM standard funcționează la margini - 4, 8, 12, 24, 32 și 40 Mb, iar când spațiul de stocare liber de 40 MB este umplut, una dintre aplicațiile cache care este încărcată în memorie dar nu alergând 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 încă o aplicație lowmemorykiller începe 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 a recomandat ca valoarea să fie mărită la, de exemplu, 100 MB înainte ca LMK să intre. Acum, utilizatorul va efectiv pierde RAM (100 - 40 = 60), deci, în loc să utilizeze acest spațiu pentru a stoca aplicații back-end, sistemul va păstra această cantitate de memorie gratuit , fără niciun scop.
Reglare LKM poate fi util pentru dispozitive mult mai vechi cu 512 RAM, dar cine le mai deține? 2 GB este „gama bugetară” modernă, chiar și dispozitivele RAM de 4 GB sunt văzute ca „de gamă medie” în zilele noastre, astfel încât modificările LMK sunt cu adevărat învechite și inutile.
Modificări I / O
În multe 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 Fulger! Script, care conține aceste rânduri:
ecou 0> $ i / coadă / rotație; echo 1024> $ i / queue / nr_requests;
Prima linie va da instrucțiunile planificatorului I / O în tratarea unui SSD, iar a doua crește dimensiunea maximă a cozii I / O 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ă.
În continuare, veți găsi o linie legată de programatorul CFQ:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
Aceasta este urmată de mai multe linii care aparțin altor planificatori, dar în cele din urmă, primele două comenzi sunt inutile deoarece:
Un nucleu Linux modern este capabil să înțeleagă cu ce tip de mediu de stocare funcționează implicit.
O lungă coadă de intrare-ieșire ( cum ar fi 1024) este inutil pe un dispozitiv Android modern, de fapt este lipsit de sens chiar și pe desktop - este recomandat doar pe servere grele . Telefonul dvs. nu este un server Linux greu.
Pentru un dispozitiv Android, practic nu există aplicații prioritare în intrare-ieșire și nici un driver mecanic, deci cel mai bun planificator este coada noop / FIFO, deci acest tip de planificator „ ajustare fina' nu face nimic special sau semnificativ pentru subsistemul I / O. De fapt, toate acele comenzi listă multi-ecran sunt mai bine înlocuite cu un ciclu simplu:
pentru i in / sys / block / mmc *; nu echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done
Acest lucru ar permite programatorului noop pentru toate unitățile de la acumularea de statistici I / O, care ar trebui să aibă un impact pozitiv asupra performanței, deși unul foarte mic și aproape complet neglijabil.
O altă modificare inutilă de I / O întâlnită adesea în scripturile de performanță este creșterea valorilor read-forward pentru cardurile SD de până la 2 MB. Mecanismul de citire anticipată este pentru citirile timpurii ale datelor din mass-media, înainte ca aplicația să solicite accesul la aceste date. Deci, în principiu, 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 să reducă timpul de returnare. Sună grozav pe hârtie, dar algoritmul read-forward este mai des gresit , ceea ce duce la operații total inutile de intrare-ieșire, ca să nu mai vorbim de un consum mare de RAM.
Valorile mari de citire anticipată cuprinse între 1 - 8 MB sunt recomandate în matricile RAID, dar pentru dispozitivele Android, este mai bine să lăsați doar valoarea implicită de 128 KB.
Modificări ale sistemului de gestionare a memoriei virtuale
O altă tehnică comună de „optimizare” este reglarea subsistemului de gestionare a memoriei virtuale. Aceasta vizează de obicei doar două variabile ale nucleului, vm.dirty_background_ratio și vm.dirty_ratio, care sunt pentru ajustarea dimensiunii bufferului pentru stocarea datelor „murdare”. Murdar datele sunt de obicei date care au fost scrise pe disc, dar mai sunt încă în memorie și așteaptă să fie scrise pe disc.
Valorile tipice de ajustare atât în distribuțiile Linux, cât și în Androis la subsistemul de gestionare a VM ar fi ca:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Deci, ceea ce încearcă să facă este că atunci când tamponul de date murdar este de 10% din cantitatea totală de RAM, se trezește pdflush curge și începe să scrie date pe disc - dacă operația de înregistrare a datelor pe disc va fi prea intens , buffer-ul va continua să crească, iar când va ajunge la 20% din RAM-ul disponibil, sistemul va trece la operația de scriere ulterioară în modul sincron - fără pre-buffer. Aceasta înseamnă că lucrarea de scriere pe aplicația pe disc va fi blocat, până când datele sunt scrise pe disc (AKA „lag”).
Ce ar trebui să înțelegeți este că, chiar dacă dimensiunea bufferului nu ajunge la 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 de RAM, aceasta ar fi egală cu 100/200 MB de RAM, ceea ce este mai mult decât suficient în ceea ce privește înregistrările de rafală, unde viteza este adesea sub înregistrarea de viteză în sistemul NAND -memorie sau card SD, cum ar fi atunci când instalați aplicații sau copiați fișiere de pe un computer.
Din anumite motive, scenariștii încearcă să împingă această valoare și mai mult, până la rate absurde. De exemplu, putem găsi în Xplix script de optimizare 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 de memorie, acest lucru stabilește limita unui 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 ce se întâmplă doar pe un server Linux greu.
Fulger! Scriptul folosește o valoare mai rezonabilă, dar, în general, este încă destul de lipsit de sens:
if ['$ 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 de RAM, a doua - cu 1 GB și altele - cu mai mult de 1 GB. Dar, de fapt, există un singur motiv pentru a modifica setările implicite - un dispozitiv cu o memorie internă foarte lentă sau un card de memorie. În acest caz, este rezonabil să răspândiți valorile variabilelor, adică să faceți așa ceva:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Apoi, atunci când un sistem de supratensiune scrie operațiuni, fără a fi nevoie să înregistreze date pe disc, până la ultima nu va trece la modul sincron, ceea ce va permite aplicațiilor să reducă întârzierea la înregistrare.
Modificări inutile suplimentare și reglaje de performanță
Există mult mai multe „optimizări” acolo, care chiar nu fac nimic. Majoritatea nu au niciun efect, în timp ce altele se pot îmbunătăți niste aspect al performanței, în timp ce degradează dispozitivul în alte moduri ( de obicei se reduce la performanță față de consumul 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 a îmbunătăți performanța și subtensiunea - economisește puțină baterie.
- Optimizarea bazei de date - În teorie acest lucru ar trebui să oferă o îmbunătățire a performanței dispozitivului, dar este îndoielnic.
- Zipalign - În mod ironic, în ciuda alinierii conținutului Android SDK î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 de sistem inutile, eliminând sistemul neutilizat și aplicațiile terță parte rareori utilizate. Practic, dezinstalând bloatware.
- Kernel personalizat cu optimizări pentru un anumit dispozitiv (din nou, nu toate nucleele sunt la fel de bune).
- Descris deja I / O scheduler noop.
- Algoritmul de saturație TCP Westwood - Utilizat mai eficient în Android Cubic implicit pentru rețelele fără fir, disponibil în nuclee personalizate.
Setări inutile build.prop
LaraCraft304 de la forumul XDA Developers a efectuat un studiu și a constatat că un număr impresionant de setări /system/build.prop care sunt recomandate pentru utilizare „experți” 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. 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.ADISEtichete Android Dezvoltare 12 minute citite
