Najbežnejšie mýty o optimalizácii Android boli odhalené

Existuje mnoho inštruktážnych sprievodcov venovaných zvyšovaniu výkonu systému Android a tipom na celkovú optimalizáciu. Niektoré z nich sú legitímne a iné sú založené iba na teórii alebo zastaraných prevádzkových metódach v systéme Android alebo sú jednoducho nezmysly. To zahŕňa odporúčania na výmenu, hodnoty pridané do build.prop a variabilné zmeny v jadre Linuxu.

Tam sú dokonca aj tony „optimalizačných skriptov“, flashzipsy typu „všetko v jednom“, ktoré sľubujú výrazne zvýšiť výkon, výdrž batérie a ďalšie veci. Niektoré z vylepšení môžu skutočne fungovať, ale väčšina z nich je jednoducho účinkom placeba alebo, čo je horšie, má v skutočnosti negatívny vplyv na vaše zariadenie.

To neznamená, že ľudia úmyselne vydávajú škodlivé skripty - v Obchode Play sú určite falošné platené aplikácie, ale optimalizačné skripty zverejnené na fórach pre Android sú vo všeobecnosti dobre mienené, len tak sa stáva, že vývojár môže byť nesprávne informovaný, alebo jednoducho experimentovať s rôznymi vylepšeniami optimalizácie. Bohužiaľ, vyskytuje sa určitý efekt snehovej gule, najmä v optimalizačných skriptoch typu „všetko v jednom“. Malá hrsť vylepšení môže skutočne niečo urobiť, zatiaľ čo iná sada vylepšení v skripte nemusí robiť vôbec nič - tieto skripty sa však odovzdávajú ako magické guľky, bez skutočného vyšetrovania toho, čo funguje a čo nie,

Mnoho optimalizačných skriptov typu všetko v jednom teda používa rovnaké metódy, z ktorých niektoré sú z dlhodobého hľadiska úplne zastarané alebo škodlivé. Súhrnne možno povedať, že väčšina optimalizačných skriptov typu „všetko v jednom“ nie je nič iné ako iba optimálne odporúčané ladenie bez jasnej predstavy o tom, ako alebo prečo tieto optimalizácie fungujú - používatelia potom skripty preblikajú a tvrdia, že ich výkon je náhle rýchlejší ( v skutočnosti to bol s najväčšou pravdepodobnosťou samotný akt reštartu zariadenia, ktorý spôsobil zvýšenie výkonu, keď sa všetko v pamäti RAM zariadenia vyčistilo) .

V tomto exkluzívnom článku Appuals upozorníme na niektoré z najbežnejších odporúčaní na „ optimalizáciu“ výkonu systému Android a na to, či sú jednoducho mýtom alebo legitímnym vylepšením výkonu zariadenia.

výmena

Na vrchole zoznamu mýtov je Android swap - čo je dosť absurdné, pokiaľ ide o myšlienku optimalizácie pre Android. Hlavným účelom aplikácie Swaps je vytvorenie a pripojenie stránkovacieho súboru, ktorý uvoľní úložný priestor v pamäti. Znie to rozumne na papieri, ale je to skutočne použiteľné pre server, ktorý nemá takmer žiadnu interaktivitu.

Ak pravidelne používate swap telefónu s Androidom, bude to viesť k závažným oneskoreniam, ktoré vychádzajú z vecí, ktoré prekĺzavajú z vyrovnávacej pamäte. Predstavte si napríklad, že ak sa aplikácia pokúsi zobraziť grafiku, ktorá je uložená v odkladacom priestore, ktorý musí teraz znovu uvoľniť disk po uvoľnení miesta umiestnením odkladacieho priestoru s údajmi v inej aplikácii. Je to naozaj špinavé.

Niektorí nadšenci optimalizácie môžu tvrdiť, že swap neponúka žiadne problémy, ale nie je to swap, ktorý zvyšuje výkon - je to zabudovaný mechanizmus Android lowmemorykiller, ktorý bude pravidelne zabíjať nafúknuté procesy s vysokou prioritou, ktoré sa nepoužívajú. LMK bol navrhnutý špeciálne pre spracovanie stavov s nedostatkom pamäte, je vyvolaný z procesu kswapd a všeobecne zabíja procesy v užívateľskom priestore. Toto sa líši od vraha OOM (vraha mimo pamäte), ale to je celkom iná téma.

Ide o to, že zariadenie s napríklad 1 GB pamäte RAM nemôže nikdy dosiahnuť potrebné údaje o výkone pri výmene, takže výmena v systéme Android absolútne nie je potrebná. Jeho implementácia je jednoducho plná oneskorenia a vedie k zníženiu výkonnosti, nie k jej optimalizácii.

zRAM - Zastarané a už neefektívne

zRAM je osvedčená a účinná metóda optimalizácie zariadení pre staršie zariadenia - myslite na zariadenia založené na KitKat, ktoré fungujú iba na asi 512 MB pamäte RAM. Skutočnosť, že niektorí ľudia stále používajú vylepšenia zRAM v optimalizačných skriptoch, alebo odporúčajú zRAM ako nejaký druh moderného vyladenia optimalizácie, je príkladom ľudí, ktorí spravidla nedodržiavajú najnovšie operačné protokoly.

zRAM bol určený pre základné jadrové viacjadrové SoC, ako sú zariadenia využívajúce čipové sady MTK a 512 MB pamäte RAM. V podstate veľmi lacné čínske telefóny. V podstate to, čo zRAM robí, je oddelenie jadra prostredníctvom šifrovacieho toku.

Ak sa zRAM používa na starších zariadeniach s jedným jadrom, aj keď sa na také zariadenia odporúča zRAM, veľké množstvo oneskorení má sklon sa orezávať. Stáva sa to aj s technológiou KSM ( Kernel Same Page Merging), ktorá kombinuje rovnaké stránky s pamäťou a ponúka voľné miesto. Spoločnosť Google to v skutočnosti odporúča, ale na starších zariadeniach to vedie k väčším oneskoreniam, pretože neustále aktívne jadrá jadra sa nepretržite spúšťajú z pamäte a hľadajú duplicitné stránky. V podstate, pokus o spustenie optimalizácie vyladenie spomalí zariadenie ešte ďalej, ironicky.

Sejačka - zastaraná od verzie Android 3.0

Jedným z najviac diskutovaných tipov na optimalizáciu medzi zariadeniami Android devs je sejačka a sme si istí, že by sa niekto mohol pokúsiť dokázať nám, že sme v tejto téme nesprávni. Najprv však musíme preskúmať históriu sejačky.

Aplikácia sejačky pre Android

Áno, existuje veľké množstvo prehľadov, ktoré deklarujú lepší výkon systému Android po inštalácii na oveľa starších zariadeniach s Androidom . Ľudia z akéhokoľvek dôvodu sa však domnievajú, že to znamená, že je to aj použiteľná optimalizácia pre moderné zariadenia s Androidom, čo je úplne absurdné. Skutočnosť, že Seeder je stále udržiavaný a ponúkaný ako „ moderný“ nástroj na zníženie oneskorenia, je príkladom dezinformácií - hoci to nie je chyba vývojára Seedera, pretože dokonca aj na stránke Play Store sa uvádza, že Seeder je po systéme Android 4.0+ menej efektívny. Z akéhokoľvek dôvodu sa však Seeder stále objavuje v diskusiách o optimalizácii moderných systémov Android.

V podstate to, čo Seeder robí pre Android 3.0, je chyba, pri ktorej by runtime systému Android aktívne využíval súbor / dev / random / na získanie entropie. / Dev / random / buffer by sa stal nestabilným a systém by bol zablokovaný, kým nenaplnil požadované množstvo údajov - myslite málo vecí, ako sú rôzne senzory a tlačidlá na zariadení s Androidom.

Seeder autor vzal Linux-démon rngd a zostavil pre Android inastroil tak, že prevzal náhodné dáta z oveľa rýchlejšej a predvídateľnejšej / dev / urandom cesty a zlúčil ich do dev / random / každú sekundu bez toho, aby povolil / dev / random / byť vyčerpaný. To viedlo k systému Android, ktorý nezažil nedostatok entropie a vykonával oveľa plynulejšie.

Google rozbil túto chybu po Android 3.0, ale z nejakého dôvodu sa Seeder stále objavuje na zoznamoch odporúčaných vyladení na optimalizáciu výkonu systému Android. Okrem toho má aplikácia Seeder niekoľko analógov, ako je sEFix, ktoré zahŕňajú funkčnosť Seedera, či už sa používa rovnaká rngd alebo alternatíva, alebo dokonca len symbolický odkaz medzi / dev / urandom a / dev / random. Pre moderné systémy Android je to absolútne zbytočné.

Dôvod je zbytočný, pretože novšie verzie systému Android používajú / dev / random / v troch hlavných komponentoch - libcrypto, na šifrovanie spojení SSL, generovanie kľúčov SSH atď. WPA_supplication / hostapd, ktorý generuje kľúče WEP / WPA, a nakoniec aj niekoľko knižnice na generovanie ID pri vytváraní súborových systémov EXT2 / EXT3 / EXT4.

Takže keď sú v moderných skriptoch pre optimalizáciu systému Android zahrnuté vylepšenia založené na Seeder alebo Seeder, nakoniec sa to stane znížením výkonu zariadenia, pretože rngd zariadenie neustále prebudí a spôsobí zvýšenie frekvencie procesora, čo samozrejme negatívne ovplyvňuje spotrebu batérie.,

ODEX

Firmvér akcií na zariadeniach s Androidom takmer vždy odex. To znamená, že popri štandardnom balíku pre aplikácie pre Android vo formáte APK, ktoré sa nachádzajú v adresároch / system / app / a / system / priv-app /, majú rovnaké názvy súborov s príponou .odex. Súbory odexu obsahujú optimalizované bytecode aplikácie, ktoré už prešli virtuálnym počítačom validátora a optimalizátora a potom sa zaznamenajú do samostatného súboru, ktorý využíva niečo ako dexopt nástroj.

Súbory odex sú teda určené na odloženie virtuálneho počítača a ponúkajú rýchle spustenie odexedovanej aplikácie - na druhej strane, súbory ODEX bránia úpravám firmvéru a spôsobujú problémy s aktualizáciami, takže z tohto dôvodu je mnoho vlastných ROM, ako je LineageOS, distribuovaných bez ODEX .

Generovanie súborov ODEX sa uskutočňuje niekoľkými spôsobmi, napríklad pomocou nástroja Odexer Tool - problém spočíva v tom, že má čisto placebo efekt. Keď moderný systém Android nenájde odexové súbory v adresári / system, systém ich skutočne vytvorí a umiestni do adresára / system / dalvik-cache /. To sa presne deje, keď napríklad vydáte novú verziu systému Android a na chvíľu sa na ňu zobrazí správa „Zaneprázdnený, optimalizácia aplikácií“.

Vylepšenia Lowmemorykiller

Multitasking v systéme Android sa líši od ostatných mobilných operačných systémov v tom zmysle, že je založený na klasickom modeli, v ktorom aplikácie ticho pracujú na pozadí, a počet aplikácií na pozadí nie je obmedzený ( pokiaľ nie je nastavená v Možnosti vývojára, ale toto je všeobecne sa odporúča proti) - okrem toho sa funkčnosť prechodu na vykonanie na pozadí nezastaví, hoci si systém vyhradzuje právo zabíjať aplikácie na pozadí v situáciách s nedostatkom pamäte ( pozrite sa, kde sme v tomto texte hovorili o vrahovi s nízkou pamiatkou a vrahovi z nedostatku pamäte). sprievodca) .

Ak sa chcete vrátiť k mechanizmu lowmemorykiller, systém Android môže naďalej fungovať s obmedzeným množstvom pamäte a nedostatkom swapového oddielu. Používateľ môže pokračovať v spúšťaní aplikácií a prepínaní medzi nimi a systém bude ticho zabíjať nepoužívané aplikácie na pozadí, aby sa pokúsil uvoľniť pamäť pre aktívne úlohy.

Toto bolo veľmi užitočné pre Android v prvých dňoch, aj keď z nejakého dôvodu sa stalo populárnym vo forme aplikácií na zabíjanie úloh, ktoré sú vo všeobecnosti škodlivejšie ako prospešné. Aplikácie na zabíjanie úloh sa buď prebudia v nastavených intervaloch, alebo ich spúšťa užívateľ a zdá sa, že uvoľňujú veľké množstvo pamäte RAM, čo sa považuje za pozitívne - viac voľnej pamäte RAM znamená rýchlejšie zariadenie, nie? To však nie je prípad systému Android.

V skutočnosti môže mať veľké množstvo voľnej pamäte RAM skutočne škodlivý vplyv na výkon a výdrž batérie zariadenia. Ak sú aplikácie uložené v pamäti RAM systému Android, je oveľa jednoduchšie ich vyvolať, spustiť atď. Systém Android nemusí na prepnutie na aplikáciu venovať veľa zdrojov, pretože je už v pamäti.

Z tohto dôvodu nie sú zabijači úloh tak populárni, ako bývali, hoci nováčikovia z Androidov sa na nich z nejakého dôvodu stále spoliehajú ( bohužiaľ nedostatok informácií) . Bohužiaľ, nový trend nahradil zabijakov, trend ladenia mechanizmov s nízkou mierou zabíjania . Mohlo by to byť napríklad aplikácia MinFreeManager a hlavnou myšlienkou je zvýšiť réžiu pamäte RAM skôr, ako systém začne zabíjať aplikácie na pozadí.

Napríklad štandardná operačná pamäť RAM pracuje na hraniciach - 4, 8, 12, 24, 32 a 40 Mb, a keď sa naplní voľný úložný priestor 40 MB, jedna z aplikácií v pamäti cache sa načíta do pamäte, ale nie je spustená. bude ukončená.

V zásade teda bude mať Android vždy k dispozícii najmenej 40 MB dostupnej pamäte, čo je dosť na to, aby vyhovelo jednej ďalšej aplikácii skôr, ako program lowmemorykiller začne proces čistenia - čo znamená, že Android bude vždy robiť maximum, aby využil maximálne dostupné množstvo pamäte RAM bez toho, aby zasahoval do užívateľské skúsenosti.

Je smutné, že to, čo niektorí nadšenci z homebrejčiny začali odporúčať, je, že hodnota sa zvýši napríklad na 100 MB predtým, ako sa spustí LMK. Teraz používateľ skutočne stratí RAM (100 - 40 = 60), takže namiesto toho, aby využil tento priestor na uloženie Na konci koncových aplikácií bude systém uchovávať toto množstvo pamäte zadarmo a nebude mať k tomu žiadny účel.

Ladenie LKM môže byť užitočné pre oveľa staršie zariadenia s 512 RAM, ale kto ich už vlastní? 2 GB je moderný „rozpočtový rozsah“, dokonca aj 4 GB RAM zariadenia sa v súčasnosti považujú za „stredné pásmo“, takže vylepšenia LMK sú skutočne zastarané a zbytočné.

Vylepšenia I / O

V mnohých optimalizačných skriptoch pre Android často nájdete vylepšenia, ktoré sa zaoberajú subsystémom V / V. Napríklad sa pozrime na ThunderBolt! Skript, ktorý obsahuje tieto riadky:

 echo 0> $ i / front / rotačný; echo 1024> $ i / queue / nr_requests; 

Prvý riadok poskytne inštrukcie I / O plánovača pri riešení SSD a druhý zvýši maximálnu veľkosť I / O frontu zo 128 na 1024 - pretože premenná $ i obsahuje cestu k stromu blokových zariadení v / sys a skript beží v slučke.

Potom nájdete riadok týkajúci sa plánovača CFQ:

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

Nasleduje viac riadkov, ktoré patria iným plánovačom, ale nakoniec sú prvé dva príkazy zbytočné, pretože:

Moderné jadro systému Linux je schopné pochopiť, s akým typom úložného média v predvolenom nastavení pracuje.

Dlhá fronta vstupov a výstupov ( napríklad 1024) je na modernom zariadení s Androidom zbytočná, v skutočnosti nemá zmysel ani na stolných počítačoch - je to skutočne odporúčané iba pre ťažké servery . Váš telefón nie je ťažkým serverom Linux.

Pre zariadenia s Androidom neexistujú prakticky žiadne aplikácie, ktoré majú prioritu vo vstupno-výstupných a mechanických ovládačoch, takže najlepším plánovačom je fronta noop / FIFO, takže tento typ plánovača „ vyladenie“ nerobí nič špeciálne alebo zmysluplné pre Subsystém I / O. V skutočnosti sú všetky tieto príkazy na viacerých obrazovkách lepšie nahradené jednoduchým cyklom:

 pre i in / sys / block / mmc *; do echo noop> $ i / queue / plánovač echo 0> $ i / queue / iostats done 

To by umožnilo nočnému plánovaču všetkých pohonov z hromadenia I / O štatistík, čo by malo mať pozitívny vplyv na výkon, aj keď veľmi maličký a takmer úplne zanedbateľný.

Ďalším zbytočným vylepšením I / O, ktoré sa často vyskytuje v skriptoch výkonu, sú zvýšené hodnoty čítania vopred pre karty SD až do 2 MB. Mechanizmus čítania vopred umožňuje včasné načítanie údajov z médií predtým, ako aplikácia požiada o prístup k týmto údajom. V podstate sa jadro pokúsi zistiť, aké údaje budú v budúcnosti potrebné, a načíta ich do pamäte RAM, čo by malo skrátiť čas návratu. To znie skvele na papieri, ale algoritmus čítania dopredu je častejšie nesprávny, čo vedie k úplne zbytočným operáciám vstupu a výstupu, nehovoriac o vysokej spotrebe RAM.

V poliach RAID sa odporúčajú vysoké hodnoty na čítanie v rozmedzí 1 - 8 MB, ale pre zariadenia so systémom Android je najlepšie ponechať predvolenú hodnotu 128 kB.

Vylepšenia systému správy virtuálnej pamäte

Ďalšou bežnou technikou optimalizácie je vyladenie subsystému správy virtuálnej pamäte. Toto sa zvyčajne zameriava iba na dve premenné jadra, vm.dirty_background_ratio a vm.dirty_ratio, ktoré slúžia na úpravu veľkosti vyrovnávacej pamäte na ukladanie „špinavých“ údajov. Špinavé údaje sú zvyčajne údaje zapísané na disk, ale v pamäti je ešte stále viac a čaká na ich zapísanie na disk.

Typické vylepšenia hodnôt v operáciách Linux a Androis do subsystému správy VM by boli takéto:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Snaží sa to tak, že keď je špinavá dátová vyrovnávacia pamäť 10% z celkového množstva pamäte RAM, prebudí sa tok toku PDFlush a začne zapisovať údaje na disk - ak bude operácia zaznamenávania údajov na disk príliš intenzívna, vyrovnávacia pamäť bude naďalej rásť a keď dosiahne 20% dostupnej pamäte RAM, systém sa prepne na nasledujúcu operáciu zápisu v synchronnom režime - bez predbežnej vyrovnávacej pamäte. To znamená, že práca so zápisom na disk bude zablokovaná, až kým nebudú dáta zapísané na disk (AKA 'lag').

Mali by ste pochopiť, že aj keď veľkosť vyrovnávacej pamäte nedosahuje 10%, systém po 30 sekundách automaticky nakopne súbor pdflush. Kombinácia 10/20 je celkom rozumná, napríklad na zariadení s 1 GB RAM by sa to rovnalo 100/200 MB RAM, čo je viac ako dosť, pokiaľ ide o zhlukové záznamy, kde je rýchlosť často nižšia ako rýchlostný záznam v systéme NAND. - pamäť alebo karta SD, napríklad pri inštalácii aplikácií alebo kopírovaní súborov z počítača.

Z nejakého dôvodu sa autori scenárov snažia tlačiť túto hodnotu ešte vyššie, k absurdným mieram. Napríklad v skripte optimalizácie Xplix nájdeme rýchlosť až 50/90.

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

Na zariadení s 1 GB pamäte sa nastaví limit na špinavú vyrovnávaciu pamäť na 500/900 MB, čo je úplne zbytočné pre zariadenie s Androidom, pretože by fungovalo iba pri nepretržitom nahrávaní na disk - niečo, čo sa deje iba na ťažkom disku Linux server.

Thunderbolt! Skript používa rozumnejšiu hodnotu, ale celkovo je stále celkom bezvýznamný:

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

Prvé dva príkazy sa spúšťajú na smartfónoch s 512 MB pamäte RAM, druhý - s 1 GB a ďalšie - s viac ako 1 GB. V skutočnosti však existuje len jeden dôvod na zmenu predvolených nastavení - zariadenie s veľmi pomalou internou pamäťou alebo pamäťovou kartou. V tomto prípade je rozumné šíriť hodnoty premenných, to znamená urobiť niečo také:

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

Potom, keď prepäťový systém zapíše operácie bez toho, aby musel zaznamenávať dáta na disk, až do posledného sa neprepne do synchrónneho režimu, čo umožní aplikáciám znížiť oneskorenie pri nahrávaní.

Ďalšie zbytočné vylepšenia a vyladenia výkonu

Existuje oveľa viac „optimalizácií“, ktoré naozaj nerobia nič. Väčšina z nich jednoducho nemá žiadny účinok, zatiaľ čo iné môžu zlepšiť niektoré aspekty výkonu, zatiaľ čo zariadenie iným spôsobom zhoršuje ( zvyčajne sa zníži na výkon oproti vybitiu batérie) .

Tu sú niektoré ďalšie populárne optimalizácie, ktoré môžu alebo nemusia byť užitočné, v závislosti od systému a zariadenia Android.

  • Zrýchlenie - malé zrýchlenie na zlepšenie výkonu a podvrtnutia - šetrí trochu batérie.
  • Optimalizácia databázy - Teoreticky by to malo priniesť zlepšenie výkonu zariadenia, ale je to pochybné.
  • Zipalign - Je iróniou, že napriek tomu, že je vstavaná funkcia Android SDK na zarovnávanie obsahu v rámci súboru APK v obchode, môžete nájsť veľa softvéru, ktorý sa cez zipalign neprenáša.
  • Vypnite nepotrebné systémové služby, odstráňte nepoužívané systémové a zriedka používané aplikácie tretích strán. V podstate odinštalovanie bloatware.
  • Vlastné jadro s optimalizáciou pre konkrétne zariadenie (opäť nie všetky jadrá sú rovnako dobré).
  • Už popísané noop plánovača I / O.
  • Algoritmus saturácie TCP Westwood - Účinnejšie sa používa v predvolenom systéme Android Cubic pre bezdrôtové siete, ktorý je k dispozícii vo vlastných jadrách.

Nepotrebné nastavenia build.prop

LaraCraft304 z fóra XDA Developers vykonala štúdiu a zistila, že v zdrojovom AOSP a CyanogenMod neexistuje impozantný počet nastavení /system/build.prop, ktoré sa odporúčajú na použitie „expertov“. Tu je zoznam:

 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.mAD.HAD_JP_JP_ 

Zaujímavé Články