Prestala je postojati najčešća mitova za Android optimizaciju

Postoji puno instrukcijskih vodiča koji su posvećeni povećanju performansi Androida i općenitim savjetima za optimizaciju. Neki su legitimni, a drugi temelje samo na teoriji ili su zastarjeli operativni metodi u sustavu Android ili su samo obična glupost. To uključuje preporuke za zamjenu, vrijednosti dodane na build.prop i promjenjive promjene u Linux kernelu.

Tamo je čak i mnoštvo „skripti za optimizaciju“, sve-u-jednom fleksibilni .zipovi koji obećavaju značajno povećanje performansi, trajanja baterije i ostalih stvari. Neki podešavanja zapravo mogu funkcionirati, ali većina je jednostavno placebo efekt ili još gore, zapravo negativno utjecati na vaš uređaj.

To ne znači da ljudi namjerno puštaju gadne skripte - na Play Storeu definitivno postoje lažne plaćene aplikacije, ali skripte za optimizaciju objavljene na Android forumima uglavnom su dobronamjerne; jednostavno se dogodi da programer pogrešno obavijesti, ili jednostavno eksperimentirate s raznim optimizacijskim podešavanjima. Nažalost, obično se pojavljuje svojevrsni efekt snježne kugle, posebno u scenarijima za optimizaciju „sve u jednom“. Mala šačica podešavanja u stvari može nešto učiniti, dok drugi skup podešavanja u skripti ne može učiniti apsolutno ništa - ali ove se skripte nazivaju čarobnim mecima, bez ikakvog pravog istraživanja o tome što djeluje, a što ne,

Dakle, puno sve-u-jednom skripti za optimizaciju koriste se istim metodama, od kojih su neke potpuno zastarele ili dugoročno štetne. Ukratko, većina scenarija za optimizaciju „sve u jednom“ nije ništa drugo nego zajedničko preporučeno podešavanje, bez jasne ideje kako i zašto te optimizacije „rade“ - korisnici tada pokreću skripte i tvrde da je njihova izvedba odjednom brža ( kada je zapravo najvjerojatnije vrlo jednostavan čin ponovnog pokretanja uređaja uzrokovao povećanje performansi, jer se sve u RAM-u uređaja očisti) .

U ovom ekskluzivnom članku Appuals istaknut ćemo neke od najčešćih preporuka za „ optimizaciju“ Androidovih performansi i jesu li oni jednostavno mit ili legitimni uštrb performansi uređaja.

razmjena

Na vrhu popisa mitova nalazi se Android swap - što je prilično apsurdno u smislu da se smatra Androidovom optimizacijom. Glavna zamjena je stvaranje i spajanje stranične datoteke, što će osloboditi prostor za pohranu u memoriji. To zvuči razumljivo na papiru, ali zaista se primjenjuje na poslužitelju koji gotovo da i nema interaktivnosti.

Kada redovito upotrebljavate swap svog Android telefona, to će dovesti do ozbiljnih zaostajanja koja proističu iz stvari koje prolaze kroz predmemoriju. Zamislite, na primjer, ako aplikacija pokušava prikazati grafiku koja je pohranjena u swapu, koji sada mora ponovno učitati disk nakon što je oslobodio prostor stavljanjem zamjene podataka drugom aplikacijom. Stvarno je neuredno.

Neki zaljubljenici u optimizaciju mogu reći da swap nije ponudio probleme, ali nije swap što povećava performanse - to je ugrađeni Android mehanizam lowmemorykiller, koji će redovito ubijati napuhane procese visokog prioriteta koji se ne koriste. LMK je dizajniran posebno za rukovanje uvjetima slabe memorije, poziva se iz procesa kswapd i u pravilu ubija procese u korisničkom prostoru. To se razlikuje od OOMkiller-a (ubojica izvan memorije), ali to je sasvim drugačija tema.

Poanta je u tome što uređaj s, primjerice, 1 GB RAM-a, nikada ne može doći do potrebnih podataka o performansama u swapu, pa tako zamjena apsolutno nije potrebna u Androidu. Njegova primjena jednostavno je prepuna zaostajanja i vodi degradaciji performansi, a ne optimizaciji.

zRAM - zastario i nema duže efikasnosti

zRAM je provjerena i učinkovita metoda za optimizaciju uređaja, za starije uređaje - mislite da uređaji koji se temelje na KitKat-u rade na samo oko 512 MB RAM-a. Činjenica da neki ljudi i dalje uključuju zRAM podešavanja u optimizacijske skripte ili preporučuju zRAM kao neku vrstu modernog optimizacijskog podešavanja, primjer je ljudi koji uglavnom ne slijede najnovije operativne protokole.

zRAM je bio namijenjen ulaznim više-jezgrenim SoC-ovima proračuna, poput uređaja koji koriste MTK čipsete i 512 MB RAM-a. Vrlo jeftini kineski telefoni, u osnovi. Ono što zRAM u osnovi čini je razdvajanje kernela putem enkripcijskog toka.

Kad se zRAM upotrebljava na starijim uređajima s jednom jezgrom, čak i ako se preporučuje zRAM na takvim uređajima, velike količine zaostajanja uglavnom se pojavljuju. To se također događa s KSM tehnologijom ( Kernel Same Page Merging) koja kombinira identične memorijske stranice u cilju oslobađanja prostora. To u stvari preporučuje Google, ali dovodi do većih zaostajanja na starijim uređajima, jer se stalno aktivne glavne jezgre neprekidno izvode iz memorije u potrazi za dupliciranim stranicama. U osnovi, pokušaj pokretanja optimizacijskog podešavanja usporava uređaj još više, ironično.

Sjeme - zastario od Android 3.0

Jedan od najvažnijih rasprava o optimizaciji savjeta za Android izvođače je seeder i sigurni smo da bi nas netko mogao pokušati dokazati pogrešnim u vezi s ovom temom - ali prvo moramo istražiti povijest sejača.

Aplikacija Seeder za Android

Da, postoji veliki broj izvještaja koja izjavljuju bolje performanse Androida nakon instalacije na mnogo starije Android uređaje . Međutim, ljudi iz bilo kojeg razloga vjeruju da to znači da je također primjenjiva optimizacija za moderne Android uređaje, što je apsolutno apsurdno. Činjenica da se Seeder još uvijek održava i nudi kao " moderan" alat za smanjenje zaostajanja primjer je dezinformacija - premda to nije kriv Seeder-ov programer, jer čak i njihova stranica Play Store-a primjećuje da je Seeder manje učinkovit nakon Androida 4.0+. No iz bilo kojeg razloga, Seeder se još uvijek pojavljuje u raspravama o optimizaciji za moderne Android sustave.

Ono što Seeder u osnovi radi za Android 3.0 jest adresa greške u kojoj bi Androidov runime aktivno koristio / dev / random / datoteku za stjecanje entropije. / Dev / random / međuspremnik bi postao nestabilan, a sustav bi bio blokiran dok ne popuni potrebnu količinu podataka - razmislite o sitnicama poput raznih senzora i tipki na Android uređaju.

Autor Seedera uzeo je Linux-demon rngd i sastavio se za Androidov inastroil tako da uzima slučajne podatke s mnogo bržeg i predvidljivijeg / dev / urandom puta i spaja ih u dev / random / svake sekunde, ne dopuštajući / dev / random / da se iscrpim. To je rezultiralo sustavom Android koji nije doživio nedostatak entropije i bio je mnogo glatkiji.

Google je razbio ovu pogrešku nakon Androida 3.0, ali iz nekog razloga, Seeder se još uvijek pojavljuje na popisima "preporučenih podešavanja" za optimizaciju performansi Androida. Nadalje, aplikacija Seeder ima nekoliko analoga poput sEFix-a koji uključuju Seeder-ovu funkciju, bilo da se koristi isti rngd ili alternativni obrazac, ili čak samo poveznicu između / dev / urandom i / dev / random. Za moderne Android sustave ovo je potpuno besmisleno.

Razlog je besmislen zato što novije verzije Androida koriste / dev / random / u tri glavne komponente - libcrypto, za šifriranje SSL veza, generiranje SSH ključeva itd. WPA_supplication / hostapd koji generira WEP / WPA ključeve i, na kraju, pregršt knjižnice za generiranje ID-a u stvaranju datoteka datoteka EXT2 / EXT3 / EXT4.

Dakle, kada su poboljšanja na bazi Seeder-a ili Seeder-a uključena u moderne skripte za optimizaciju Androida, ono što se završava degradacijom performansi uređaja, jer će Rngd stalno buditi uređaj i uzrokovati porast frekvencije CPU-a, što naravno negativno utječe na potrošnju baterije,

ODEX

Akcijski firmver na Android uređajima gotovo uvijek je odex. To znači da su uz standardni paket za Android aplikacije u APK formatu, koji se nalazi u / system / app / i / system / priv-app /, ista imena datoteka s .odex nastavkom. Odex datoteke sadrže optimizirane aplikacije za bajt kodove koji su već prošli kroz validator i virtualni stroj za optimizaciju, a zatim se snimili u zasebnu datoteku koristeći nešto poput alata za dexopt .

Dakle, odex datoteke trebaju zamijeniti virtualni stroj i ponuditi ubrzano pokretanje odexed aplikacije - sa donje strane, ODEX datoteke sprečavaju promjene na firmveru i stvaraju probleme s ažuriranjima, pa se iz tog razloga mnogi prilagođeni ROM-ovi poput LineageOS-a distribuiraju bez ODEX .

Generiranje ODEX datoteka vrši se na više načina, poput korištenja Odexer Alat - problem je u tome što je njegov čisto placebo efekt. Kada moderni Android sustav ne nađe odex datoteke u / sistemskom imeniku, sustav će ih zapravo stvoriti i smjestiti u / system / dalvik-cache /. Upravo se to događa kada, primjerice, pokrenete novu verziju Androida i ona neko vrijeme daje poruku „Zauzeto, optimiziranje aplikacija“.

Lowmemorykiller ugađanje

Multitasking u Androidu razlikuje se od ostalih mobilnih operativnih sustava u smislu da se temelji na klasičnom modelu gdje aplikacije tiho rade u pozadini, a nema ograničenja broja pozadinskih aplikacija ( osim ako nije postavljena jedna u Developer Options, ali ovo je općenito se preporučuje protiv) - osim toga, funkcionalnost prijelaza na pozadinsko izvršenje nije zaustavljena, iako sustav zadržava pravo ubijanja pozadinskih aplikacija u situacijama sa slabom memorijom ( pogledajte gdje smo prije u ovom slučaju govorili o ubojici niske memorije i izvan memorije vodič) .

Da se vratimo na mehanizam lowmemorykiller, Android može nastaviti raditi s ograničenom količinom memorije i nedostatkom swap-particije. Korisnik može nastaviti s pokretanjem aplikacija i prebacivanjem između njih, a sustav će tiho ubiti neiskorištene pozadinske aplikacije kako bi isprobao i oslobodio memoriju za aktivne zadatke.

To je bilo vrlo korisno za Android u ranim danima, iako iz nekog razloga postaje popularno u obliku aplikacija za ubijanje zadataka, koje su uglavnom više štetne nego korisne. Aplikacije ubojica zadataka ili se probude u zadanim intervalima ili ih pokreće korisnik, a čini se da oslobađaju velike količine RAM-a, što se smatra pozitivnim - više slobodnog RAM-a znači brži uređaj, zar ne? Međutim, to baš i nije slučaj s Androidom.

Zapravo, postojanje velike količine besplatne RAM memorije može zapravo biti štetno za rad vašeg uređaja i trajanje baterije. Kad se aplikacije spremaju u Android-ovu RAM memoriju, puno ih je lakše pozvati, pokrenuti ih itd. Android sustavu ne treba posvetiti puno resursa za prebacivanje na aplikaciju, jer ga ona već ima u memoriji.

Zbog toga ubojice zadataka nisu baš toliko popularni kao nekad, iako se Android-početnici iz nekog razloga i dalje oslanjaju na njih ( nedostatak informacija, nažalost) . Nažalost, novi je trend zamijenio ubojice zadataka, trend podešavanja mehanizama sa malim memorijskim ubojicama . To bi bila, na primjer, aplikacija MinFreeManager, a glavna ideja je povećati RAM režijske troškove prije nego što sustav počne ubijati pozadinske aplikacije.

Tako, na primjer, standardni RAM radi na granicama - 4, 8, 12, 24, 32 i 40 Mb, a kada se popuni besplatni prostor za pohranu od 40 MB, jedna je od predmemoriranih aplikacija koja se učitava u memoriju, ali ne radi će se ukinuti.

U osnovi, Android će uvijek imati najmanje 40 MB dostupne memorije, što je dovoljno za smještaj još jedne aplikacije prije nego što lowmemorykiller započne postupak čišćenja - što znači da će Android uvijek dati sve od sebe kako bi iskoristio maksimalnu količinu dostupne memorije bez ometanja korisničko iskustvo.

Nažalost, ono što su neki ljubitelji domaćih ljubitelja preporučili je da se vrijednost podigne na, primjerice, 100 MB prije nego što počne LMK. Sada će korisnik izgubiti RAM (100 - 40 = 60), pa umjesto da ovaj prostor iskoristi za pohranjivanje unatrag - kraj aplikacija, sustav će zadržati ovu količinu memorije bez ikakve svrhe.

LKM ugađanje može biti korisno za mnogo starije uređaje sa 512 RAM-a, ali tko ih više posjeduje? 2 GB moderan je "proračunski raspon", čak 4GB RAM uređaja ovih dana smatraju se "srednjim rasponom", pa su LMK podešavanja zaista zastarjela i beskorisna.

Podešavanje I / O

U mnoštvu skripti za optimizaciju za Android često ćete naći podešavanja koja se odnose na I / O podsustav. Na primjer, pogledajmo ThunderBolt! Skripta koja sadrži ove retke:

 odjek 0> $ i / red / rotacijski; echo 1024> $ i / queue / nr_requests; 

Prvi redak dat će uputama I / O planeru za rukovanje SSD-om, a drugi povećava maksimalnu veličinu I / O reda čekanja sa 128 na 1024 - jer varijabla $ i sadrži put do stabla blok uređaja u / sys, a skripta radi u petlji.

Nakon toga pronaći ćete liniju vezanu za CFQ planer:

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

Nakon toga slijedi više redaka koji pripadaju drugim projektantima, ali u konačnici su prve dvije naredbe besmislene jer:

Suvremeni Linux kernel može razumjeti s kojom vrstom medija za pohranu po zadanim postavkama radi.

Dugi red ulaza i izlaza ( poput 1024) beskoristan je na modernom Android uređaju, u stvari besmislen čak i na radnoj površini - stvarno se preporučuje samo na poslužiteljima s velikim opterećenjima . Vaš telefon nije Linux poslužitelj sa velikim opterećenjem.

Za Android uređaj gotovo da nema aplikacija koje imaju prioritet u ulazu-izlazu i nema mehaničkog pokretača, tako da je najbolji alat za planiranje redak noop / FIFO, tako da ova vrsta planera " ugađa" ne radi ništa posebno i značajno za U / I podsustav. U stvari, sve ove naredbe s više zaslona bolje su zamijenjene jednostavnim ciklusom:

 za i u / sys / blok / mmc *; do echo noop> $ i / queue / planer echo 0> $ i / queue / iostats made 

To bi omogućilo raspoređivaču noop-a za sve pogone iz gomile I / O statistike, što bi trebalo imati pozitivan utjecaj na performanse, iako vrlo maleno i gotovo potpuno zanemarivo.

Još jedno beskorisno podešavanje I / O-a koje se često nalazi u skriptu performansi su povećane vrijednosti čitanja unaprijed za SD kartice do 2MB. Mehanizam čitanja unaprijed je za rano čitanje podataka iz medija prije nego što aplikacija zatraži pristup tim podacima. U osnovi, kernel će pokušati shvatiti koji će podaci biti potrebni u budućnosti te ga unaprijed učitati u RAM-u, što bi na taj način trebalo smanjiti vrijeme povratka. To zvuči sjajno na papiru, ali algoritam za čitanje unaprijed je češće pogrešan, što dovodi do potpuno nepotrebnih operacija ulaz-izlaz, a da ne spominjemo veliku potrošnju RAM-a.

U RAID-nizovima preporučuju se visoke vrijednosti čitanja unaprijed između 1 - 8 MB, ali za Android uređaje najbolje je ostaviti zadanu vrijednost od 128 KB.

Podešavanje sustava upravljanja virtualnom memorijom

Još jedna uobičajena tehnika „optimizacije“ je podešavanje podsustava za upravljanje virtualnom memorijom. Obično cilja samo dvije varijable kernela, vm.dirty_background_ratio i vm.dirty_ratio, koje su za podešavanje veličine međuspremnika za spremanje "prljavih" podataka. Prljavi podaci obično su podaci napisani na disk, ali još ih je ostalo u memoriji i čekaju da budu zapisani na disk.

Tipične ugađajuće vrijednosti u Linux distribuciji i Androisu za podsustav upravljanja VM-om bile bi sljedeće:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Dakle, ovo što pokušava učiniti je da kada prljavi međuspremnik podataka iznosi 10% ukupne količine RAM-a, probudi protok pdflush-a i počne upisivati ​​podatke na disk - ako će rad snimanja podataka na disk biti previše intenzivan, međuspremnik će i dalje rasti, a kad dosegne 20% dostupne RAM-a, sustav će se prebaciti na sljedeći postupak pisanja u sinkronom načinu - bez preduspremnika. To znači da će rad pisanja na disk disk biti blokiran, sve dok se podaci ne zapišu na disk (AKA 'lag').

Ono što biste trebali razumjeti je da čak i ako veličina međuspremnika ne dosegne 10%, sustav će se automatski ubaciti u pdflush nakon 30 sekundi. Kombinacija 10/20 prilično je razumna, na primjer, na uređaju s 1 GB RAM-a to bi bilo jednako 100 / 200MB RAM-a, što je više nego dovoljno u odnosu na zapise praska gdje je brzina često ispod zapisa brzine u sustavu NAND - memorija ili SD kartica, primjerice kod instaliranja aplikacija ili kopiranja datoteka s računala.

Iz nekog razloga, scenaristi pokušavaju ovu vrijednost gurnuti još višim, na apsurdne stope. Na primjer, u skripti za optimizaciju Xplix možemo pronaći stopu od 50/90.

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

Na uređaju s 1 GB memorije ovo postavlja ograničenje prljavog međuspremnika na 500/900 MB, što je potpuno beskorisno za Android uređaj, jer bi to radilo samo uz stalno snimanje na disk - nešto što se događa samo na teškom Linux poslužitelj.

Thunderbolt! Skripta koristi razumniju vrijednost, ali sveukupno, još uvijek prilično besmislena:

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

Prve dvije naredbe rade se na pametnim telefonima s 512 MB RAM-a, druga - s 1 GB, a druge - s više od 1 GB. Ali u stvari postoji samo jedan razlog za promjenu zadanih postavki - uređaj s vrlo sporom unutarnjom memorijom ili memorijskom karticom. U ovom je slučaju razumno širiti vrijednosti varijabli, tj. Napraviti nešto slično:

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

Zatim, kada prenaponski sustav upiše operacije, bez potrebe za snimanjem podataka na disk, do posljednjeg se neće prebaciti na sinkroni način, što će aplikacijama omogućiti da smanje zaostajanje tijekom snimanja.

Dodatni beskorisni podešavanja i podešavanja performansi

Postoji puno više "optimizacija" vani koje stvarno ništa ne rade. Većina njih naprosto nema nikakvog učinka, dok drugi mogu poboljšati neki aspekt performansi, dok degradira uređaj na druge načine ( obično se svodi na performanse u odnosu na pražnjenje baterije) .

Evo nekoliko dodatnih popularnih optimizacija koje mogu biti, ali ne moraju biti korisne, ovisno o Android sustavu i uređaju.

  • Ubrzanje - Malo ubrzanje za poboljšanje performansi i podniževanje - štedi malo baterije.
  • Optimizacija baze podataka - teoretski bi to trebalo poboljšati performanse uređaja, ali je nesumnjivo.
  • Zipalign - Ironično je da usprkos ugrađenom Android SDK sadržaju usklađivanja sadržaja unutar APK datoteke u trgovini možete pronaći da se puno softvera ne prenosi putem zipaligna.
  • Onemogućite nepotrebne sistemske usluge, uklanjajući neiskorišteni sustav i rijetko korištene programe treće strane. U osnovi, deinstaliranje bloatwarea.
  • Prilagođeno jezgro s optimizacijama za određeni uređaj (opet, nisu sve jezgre jednako dobre).
  • Već opisan ulazni / izlazni planer noop.
  • Algoritam zasićenja TCP Westwood - Učinkovitije se koristi u zadanom Androidu Cubic za bežične mreže, dostupan u prilagođenim jezgrama.

Beskorisne postavke build.prop

LaraCraft304 sa XDA Developers foruma proveo je istraživanje i ustanovio da impresivan broj postavki /system/build.prop koji se preporučuju za upotrebu "stručnjacima" ne postoje u izvorima AOSP i CyanogenMod. Evo popisa:

 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 

Zanimljivi Članci