Dakle, puno sve-u-jednom skripti za optimizaciju koriste iste metode, od kojih su neke potpuno zastarjele ili dugoročno štetne. Ukratko, većina optimizacijskih skripti 'sve u jednom' nisu ništa drugo doli preporučena podešavanja, bez jasne ideje o tome kako i zašto te optimizacije 'funkcioniraju - korisnici zatim bljeskaju skripte i tvrde da su njihove performanse odjednom brže ( dok je zapravo najvjerojatnije vrlo jednostavan čin ponovnog pokretanja njihovog 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 ' optimiziranje ” Izvedba Androida i jesu li oni samo mit ili legitimni štih za izvedbu uređaja.
Zamijenite
Na vrhu popisa mitova nalazi se zamjena Androida - što je prilično apsurdno u smislu da se na nju misli kao na Android optimizaciju. Swaps glavna svrha je stvoriti i povezati datoteku straničenja, što će osloboditi prostor za pohranu u memoriji. Ovo zvuči razumno na papiru , ali je stvarno primjenjivo na a poslužitelju , koji gotovo da nema interaktivnosti.
Kada redovito upotrebljavate zamjenu Android telefona, to će dovesti do ozbiljnih kašnjenja koja proizlaze iz stvari koje promiču predmemoriju. Zamislite, na primjer, ako neka aplikacija pokuša prikazati grafiku koja je pohranjena u zamjeni koja sada mora ponovno učitati disk nakon što oslobodi prostor postavljanjem zamjene podataka s drugom aplikacijom. Stvarno je neuredno.
Neki entuzijasti optimizacije mogu reći da swap ne nudi probleme, ali to nije swap što povećava performanse - to je ugrađeni Android mehanizam lowmemorykiller , koji će redovito ubirati napuhnute procese visokog prioriteta koji se ne koriste. LMK je dizajniran posebno za rukovanje uvjetima s malo memorije, poziva se iz kswapd proces i općenito ubija procese korisničkog prostora. Ovo se razlikuje od OOMkiller (ubojica izvan memorije), ali to je posve druga 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 zamjeni, pa zamjena apsolutno nije potrebna u Androidu. Njegova je provedba jednostavno opterećena zaostajanjem i dovodi do degradacija u izvedbi, umjesto da je optimizira.
zRAM - zastario i više nije učinkovit
zRAM je dokazana i učinkovita metoda za optimizaciju uređaja za stariji uređaji - pomislite na uređaje zasnovane na KitKat-u koji rade na samo oko 512 MB RAM-a. Činjenica da neki ljudi još uvijek uključuju prilagodbe zRAM-a u optimizacijskim skriptama ili preporučuju zRAM kao neku vrstu modernog poboljšanja, primjer je ljudi koji uglavnom ne slijede najnovije operativne protokole.
zRAM je bio namijenjen višejezgrenim SoC-ima proračuna opsega proračuna, poput uređaja koji koriste MTK čipsetove i 512 MB RAM-a. U osnovi vrlo jeftini kineski telefoni. Ono što zRAM u osnovi radi je odvajanje jezgre putem toka šifriranja.
Kada se zRAM koristi na starijim uređajima s jednostruka , čak i ako se zRAM preporučuje na takvim uređajima, velike količine zaostajanja obično se pojavljuju. To se također događa s KSM tehnologijom ( Spajanje iste stranice kernela) koji kombinira identične memorijske stranice u želji za oslobađanjem prostora. To Google zapravo preporučuje, ali dovodi do većih zaostajanja na starijim uređajima, jer stalno aktivna jezgra theads kontinuirano radi iz memorije u potrazi za duplikatima stranica. U osnovi, pokušaj pokretanja optimizacije usporava uređaj još više, ironično.
Sijačica - zastarjela od Androida 3.0
Jedan od najviše raspravljanih savjeta o optimizaciji među Android uređajima je cedar , i sigurni smo da bi netko mogao pokušati dokazati da nismo u pravu u vezi s ovom temom - ali prvo moramo ispitati povijest sjetve.
Aplikacija sijačica za Android
Da, postoji velik broj izvještaja koji proglašavaju bolje performanse Androida nakon instalacije na puno starijih Android uređaja . Međutim, ljudi iz bilo kojeg razloga vjeruju da to znači da je to također primjenjiva optimizacija suvremeni Android uređaji , što je apsolutno apsurdno. Činjenica da se Seeder i dalje održava i nudi kao „ moderno ' alat za smanjenje zaostajanja primjer je pogrešnih informacija - premda to nije kriv programer tvrtke Seeder, jer čak i njihova stranica Trgovine Play napominje da je Seeder manje učinkovit nakon Androida 4.0+. Ipak, iz bilo kojeg razloga, Seeder se i dalje pojavljuje u raspravama o optimizaciji modernih Android sustava.
Ono što Seeder u osnovi radi za Android 3.0 jest rješavanje programske pogreške u kojoj bi Android runtime aktivno koristio / dev / random / datoteku za stjecanje entropije. / Dev / random / međuspremnik postao bi nestabilan, a sustav bi bio blokiran dok ne napuni potrebnu količinu podataka - razmislite o sitnicama poput raznih senzora i gumba na Android uređaju.
Seeder-ov autor uzeo je Linux-demon rngd , i sastavljen za Android-ov instroil tako da je uzeo slučajne podatke s puno bržeg i predvidljivijeg / razvojnog / slučajnog puta i spaja ih u razvojni / slučajni / svake sekunde, ne dopuštajući da se / dev / random / iscrpi. To je rezultiralo Android sustavom koji nije iskusio nedostatak entropije i funkcionirao je mnogo uglađenije.
Google je razbio ovu grešku nakon Androida 3.0, no iz nekog se razloga i dalje pojavljuje Seeder 'Preporučene izmjene' popisi za optimizaciju izvedbe Androida. Nadalje, aplikacija Seeder ima nekoliko analoga poput sEFix-a koji uključuju funkcionalnost Seeder-a, bez obzira koristi li istu rngd ili alternativu zavalio , ili čak samo simbolična veza između / dev / urandom i / dev / random. To je apsolutno besmisleno za moderne Android sustave.
Razlog zašto je besmislen je taj š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žnica za generiranje ID-a u stvaranju EXT2 / EXT3 / EXT4 datotečnih sustava.
Pa kad Sejačica ili su poboljšanja temeljena na Seederu uključena u moderne skripte za optimizaciju Androida, a ono što se na kraju događa je degradacija u izvedbi uređaja, jer rngd neprestano će buditi uređaj i uzrokovati povećanje frekvencije procesora, što naravno negativno utječe na potrošnju baterije.
Odex
Dionički firmware na Android uređajima uglavnom je uvijek odex. To znači da su uz standardni paket za Android aplikacije u APK formatu, koji se nalaze u / system / app / i / system / priv-app /, istog imena datoteka s nastavkom .odex. Datoteke odex sadrže optimizirane bytecode aplikacije koje su već prošle kroz validator i optimizator virtualnog stroja, a zatim snimljene u zasebnu datoteku koristeći nešto poput dexopt alat.
Tako su datoteke odex namijenjene iskrcavanju virtualnog stroja i nude ubrzano pokretanje aplikacije odexed - s donje strane ODEX datoteke sprječavaju promjene firmvera i stvaraju probleme s ažuriranjima, pa se iz tog razloga distribuiraju mnogi prilagođeni ROM-ovi poput LineageOS-a bez ODEX-a .
Generiranje ODEX datoteka vrši se na više načina, poput upotrebe alata Odexer - problem je u tome što je to čisto placebo efekt. Kada moderni Android sustav ne pronađe odex datoteke u direktoriju / system, sustav će ih zapravo stvoriti i smjestiti u direktorij / system / dalvik-cache /. Upravo se to događa kada, na primjer, trepnete novom verzijom Androida i ona neko vrijeme daje poruku 'Zauzeti, optimizirajuće aplikacije'.
Ugađanja s niskim memorijskim ubojicama
Višezadaćnost u Androidu razlikuje se od ostalih mobilnih operativnih sustava u smislu da se temelji na klasičnom modelu u kojem aplikacije rade tiho u pozadini i nema ograničenja u broju pozadinskih aplikacija ( osim ako je jedan postavljen u Opcijama za programere, ali to se općenito preporučuje) - nadalje, funkcionalnost prijelaza na pozadinsko izvršavanje nije zaustavljena, iako sustav zadržava pravo ubijanja pozadinskih aplikacija u situacijama s malo memorije ( pogledajte gdje smo ranije u ovom vodiču razgovarali o lowmemorykilleru i ubojici bez pamćenja) .
Da se vratim na lowmemorykiller mehanizam, 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 ubijati nekorištene pozadinske aplikacije kako bi pokušao osloboditi memoriju za aktivne zadatke.
Ovo je bilo vrlo korisno za Android u ranim danima, iako je iz nekog razloga postalo popularno u obliku aplikacija za ubijanje zadataka, koje su općenito više štetne nego korisne. Aplikacije koje ubijaju zadatke ili se bude u određenim intervalima ili ih pokreće korisnik i č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, posjedovanje velike količine besplatne RAM memorije zapravo može biti štetno za performanse vašeg uređaja i vijek trajanja baterije. Kada su aplikacije pohranjene u Androidovom RAM-u, puno ih je lakše pozvati, pokrenuti itd. Android sustav ne treba posvetiti puno resursa za prebacivanje na aplikaciju, jer je ona već tu u memoriji.
Zbog toga ubojice zadataka zapravo nisu toliko popularne kao nekada, premda se Android početnici iz nekog razloga i dalje na njih oslanjaju ( nedostatak informacija, nažalost) . Nažalost, novi trend zamijenio je ubojice zadataka, trend lowmemorykiller ugađanja mehanizama. To bi bilo na primjer MinFreeManager aplikacija, a glavna ideja je povećati RAM RAM-a 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 slobodni prostor od 40 MB, jedna od predmemoriranih aplikacija koja se učitava u memoriju ali ne trčanje bit će ukinut.
U osnovi, Android će uvijek imati najmanje 40 MB dostupne memorije, što je dovoljno za smještaj još jedne aplikacije prije lowmemorykiller započinje svoj postupak čišćenja - što znači da će Android uvijek učiniti sve da iskoristi maksimalnu količinu dostupne RAM-a bez ometanja korisničkog iskustva.
Nažalost, ono što su neki ljubitelji homebrewa započeli preporučeno je da se vrijednost poveća na, primjerice, 100 MB prije nego što LMK krene. Sada će korisnik zapravo izgubiti RAM-a (100 - 40 = 60), pa će umjesto da koristi ovaj prostor za pohranu pozadinskih aplikacija, sustav zadržati ovu količinu memorije besplatno , bez apsolutno nikakve svrhe za to.
LKM ugađanje može biti korisno za puno starije uređaje s 512 RAM-a, ali tko ih više posjeduje? 2 GB je moderni „proračunski raspon“, čak i 4 GB RAM uređaja danas se vidi kao „srednji raspon“, tako da su LMK dotjerivanja stvarno zastarjela i beskorisna.
Ugađanje U / I
U mnogim skriptama za optimizaciju za Android često ćete pronaći ugađanja koja se odnose na I / O podsustav. Na primjer, pogledajmo ThunderBolt! Skripta koja sadrži ove retke:
odjek 0> $ i / red / rotacijski; odjek 1024> $ i / queue / nr_requests;
Prvi će redak dati upute I / O planera za postupanje sa SSD-om, a drugi povećava maksimalnu veličinu I / O reda s 128 na 1024 - jer varijabla $ i sadrži put do stabla blokovskih uređaja u / sys, a skripta se izvodi u petlji.
Nakon toga ćete pronaći liniju povezanu s CFQ planerom:
odjek 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; odjek 1> $ i / queue / iosched / slice_idle;
Nakon toga slijedi više redaka koji pripadaju drugim planerama, ali u konačnici, prve dvije naredbe su besmislene jer:
Moderna jezgra Linuxa sposobna je razumjeti s kojim tipom medija za pohranu prema zadanim postavkama radi.
Dug ulazno-izlazni red ( kao što je 1024) je beskoristan na modernom Android uređaju, zapravo besmislen čak i na radnoj površini - doista se preporučuje samo na teški poslužitelji . Vaš telefon nije teški Linux poslužitelj.
Za Android uređaj praktički nema aplikacija kojima je prioritet u ulazu-izlazu i nema mehaničkog pokretačkog programa, pa je najbolji planer noop / FIFO-red, pa ova vrsta planera “ štipanje' ne radi ništa posebno ili značajno za I / O podsustav. U stvari, sve te naredbe popisa s više zaslona bolje je zamijeniti jednostavnim ciklusom:
za i in / sys / block / mmc *; do echo noop> $ i / queue / plane echo 0> $ i / queue / iostats done
To bi omogućilo noop planer za sve pogone iz akumulacije I / O statistike, što bi trebalo imati pozitivan utjecaj na performanse, iako vrlo malen i gotovo potpuno zanemariv.
Još jedan beskoristan I / O dotjerivanje koji se često nalazi u skriptama izvedbe je povećana vrijednost čitanja unaprijed za SD kartice do 2 MB. Mehanizam čitanja unaprijed služi za rano čitanje podataka s 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 i prethodno ih učita u RAM, što bi na taj način trebalo smanjiti vrijeme povratka. To na papiru zvuči sjajno, ali algoritam čitanja unaprijed je češći pogrešno , š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 između 1 i 8 MB, ali za Android uređaje najbolje je ostaviti zadanu vrijednost od 128 KB.
Popravak sustava za upravljanje virtualnom memorijom
Sljedeća uobičajena tehnika 'optimizacije' je podešavanje podsustava za upravljanje virtualnom memorijom. To obično cilja samo dvije varijable jezgre, vm.dirty_background_ratio i vm.dirty_ratio, koje služe za podešavanje veličine međuspremnika za pohranu 'prljavih' podataka. Prljava podaci su obično podaci koji su zapisani na disk, ali još ih ima u memoriji i čekaju da budu zapisani na disk.
Tipične vrijednosti podešavanja u Linux distribucijama i Androisu za podsustav upravljanja VM-om bile bi poput:
vm.prljavi_odnos_smjera = 10 vm.prljavi_odnos = 20
Dakle, ono što se pokušava učiniti je da se, kada prljavi međuspremnik podataka čini 10% ukupne količine RAM-a, probudi pdflush protok i započinje upisivanje podataka na disk - ako će biti operacija snimanja podataka na disk preintenzivno , međuspremnik će nastaviti rasti, a kad dosegne 20% dostupne RAM-a, sustav će se prebaciti na sljedeću operaciju upisivanja u sinkronom načinu rada - bez preduspremnika. To znači da će posao pisanja na disk biti rad blokiran, sve dok se podaci ne upišu na disk (AKA ‘zaostajanje’).
Ono što biste trebali razumjeti je da čak i ako je veličina međuspremnika ne doseže 10% , sustav će automatski pokrenuti 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/200 MB RAM-a, što je više nego dovoljno u smislu burst zapisa kada je brzina često ispod zapisa brzine u sustavu NAND -sećanje ili SD-kartica, na primjer prilikom instaliranja aplikacija ili kopiranja datoteka s računala.
Iz nekog razloga autori scenarija pokušavaju ovu vrijednost povećati do apsurdnih stopa. Na primjer, možemo naći u Xplix optimizacijski skript stopa do 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 funkcioniralo samo pod stalno snimanje na disk - nešto što se događa samo na teškom Linux poslužitelju.
ThunderBolt! Skripta koristi razumniju vrijednost, ali u cjelini je i dalje prilično besmislena:
ako ['$ mem' -lt 524288]; tada sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; zatim sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; inače sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;
Prve dvije naredbe pokreću se na pametnim telefonima s 512 MB RAM-a, druge - s 1 GB i druge - s više od 1 GB. Ali zapravo 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, odnosno napraviti nešto poput ovoga:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Zatim, kada valni sustav zapisuje operacije, bez potrebe za snimanjem podataka na disk, do zadnjeg se neće prebaciti u sinkroni način rada, što će omogućiti aplikacijama da smanje zaostajanje prilikom snimanja.
Dodatni beskorisni dotjerivanja i podešavanja izvedbe
Postoji puno više 'optimizacija' koje stvarno ne rade ništa. Većina njih jednostavno nema nikakav učinak, dok se drugi mogu poboljšati neki aspekt izvedbe, dok se uređaj pogoršava na druge načine ( obično se svodi na performanse u odnosu na pražnjenje baterije) .
Evo nekoliko dodatnih popularnih optimizacija koje mogu, ali ne moraju biti korisne, ovisno o Android sustavu i uređaju.
- Ubrzanje - Malo ubrzanje za poboljšanje performansi i poništavanje - štedi malo baterije.
- Optimizacija baze podataka - u teoriji ovo treba daju poboljšanje performansi uređaja, ali sumnjivo.
- Zipalign - Ironično je da, unatoč ugrađenom Android SDK poravnavanju sadržaja unutar APK-datoteke u trgovini, možete pronaći da se puno softvera ne prenosi putem zipalign.
- Onemogućite nepotrebne sistemske usluge uklanjanjem neiskorištenih sistemskih i rijetko korištenih aplikacija trećih strana. U osnovi, deinstaliranje bloatwarea.
- Prilagođena jezgra s optimizacijama za određeni uređaj (opet, nisu sve jezgre jednako dobre).
- Već opisan I / O 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 s foruma XDA Developers proveo je istraživanje i utvrdio da impresivan broj postavki /system/build.prop koje se preporučuju za upotrebu 'stručnjaka' ne postoji u izvornom AOSP-u i CyanogenModu. 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.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sAP.HAD.HADS.JPG.HAD.HADOznake android Razvoj 12 minuta čitanja
