Mnoho optimalizačných skriptov typu všetko v jednom teda používa rovnaké metódy, z ktorých niektoré sú úplne zastarané alebo z dlhodobého hľadiska škodlivé. Stručne zhrnuté, väčšina optimalizačných skriptov typu „všetko v jednom“ nie je nič iné ako odporúčané ladenie, ktoré nie je jasné, ako a prečo tieto optimalizácie „fungujú - používatelia potom skripty blikajú a tvrdia, že ich výkon je zrazu rýchlejší ( aj keď v skutočnosti to bol s najväčšou pravdepodobnosťou veľmi jednoduchý čin reštartu zariadenia, ktorý spôsobil zvýšenie výkonu , pretože sa všetko v pamäti RAM zariadenia vyčistí) .
V tomto exkluzívnom článku Appuals zdôrazníme niektoré z najbežnejších odporúčaní pre „ optimalizácia “ Výkon systému Android a či ide iba o mýtus alebo legitímne vyladenie výkonu zariadenia.
Zameniť
Na vrchole zoznamu mýtov je výmena Androidu - čo je dosť absurdné, pokiaľ ide o to, že sa o nej uvažuje ako o optimalizácii systému Android. Hlavným účelom výmeny je vytvorenie a pripojenie stránkovacieho súboru, ktorý uvoľní úložný priestor v pamäti. Toto znie rozumne na papieri , ale je skutočne použiteľná pre a server , ktorá nemá takmer žiadnu interaktivitu.
Ak pravidelne používate výmenu telefónu Android, povedie to k výrazným oneskoreniam, ku ktorým môže dôjsť v dôsledku toho, že veci uniknú z vyrovnávacej pamäte. Predstavte si napríklad, že sa aplikácia pokúsi zobraziť grafiku, ktorá je uložená vo swape, ktorý teraz musí po uvoľnení miesta znovu vložiť disk umiestnením swapu údajov do inej aplikácie. Je to naozaj chaotické.
Niektorí nadšenci optimalizácie môžu povedať, že zámena neponúkla žiadne problémy, ale nejde o zámenu, ktorá zvyšuje výkon - je to vstavaný mechanizmus Android lowmemorykiller , ktorý pravidelne zabíja nafúknuté procesy s vysokou prioritou, ktoré sa nepoužívajú. LMK bol navrhnutý špeciálne pre zvládnutie podmienok s nízkou pamäťou, je vyvolaný z kswapd proces a zvyčajne zabíja procesy v užívateľskom priestore. To sa líši od OOMkiller (zabijak mimo pamäte), ale to je úplne iná téma.
Jedná sa o to, že zariadenie napríklad s 1 GB pamäte RAM nikdy nedokáže pri swapu dosiahnuť potrebné údaje o výkone, a preto swap v Androide absolútne nie je potrebný. Jeho implementácia je jednoducho plná oneskorenia a vedie k degradácia skôr ako optimalizovať.
zRAM - zastaraný a už nie efektívny
zRAM je osvedčená a efektívna metóda optimalizácie zariadení pre staršie zariadenia - myslíte, že zariadenia založené na KitKat fungujú iba na asi 512 MB RAM. Skutočnosť, že niektorí ľudia stále zahŕňajú vylepšenia zRAM do optimalizačných skriptov, alebo odporúčajú zRAM ako akési moderné vylepšenie optimalizácie, je príkladom ľudí, ktorí všeobecne nedodržiavajú najnovšie operačné protokoly.
zRAM bol určený pre vstupné viacjadrové SoC so širokým rozpočtom, ako sú zariadenia využívajúce čipové sady MTK a 512 MB RAM. V podstate veľmi lacné čínske telefóny. To, čo zRAM v podstate robí, je oddelenie jadra pomocou šifrovacieho toku.
Keď sa zRAM používa na starších zariadeniach s a jedno jadro , aj keď sa zRAM odporúča na takýchto zariadeniach, má veľké množstvo oneskorení tendenciu sa hromadiť. To sa stáva aj pri technológii KSM ( Zlúčenie jadra na rovnakej stránke) ktorá kombinuje identické pamäťové stránky v snahe získať voľné miesto. Toto v skutočnosti odporúča spoločnosť Google, čo však vedie k väčším oneskoreniam na starších zariadeniach, pretože neustále aktívne vlákna jadra bežia nepretržite z pamäte a hľadajú duplicitné stránky. Pokus o spustenie optimalizačnej optimalizácie v podstate ironicky zariadenie ešte ďalej spomaľuje.
Seeder - zastaraný od verzie Android 3.0
Jedným z najdiskutovanejších tipov na optimalizáciu medzi vývojármi pre Android je céder , a sme si istí, že by sa nás niekto mohol pokúsiť dokázať, že sme sa v tejto téme mýlili - najskôr však musíme preskúmať históriu sejača.
Aplikácia Seeder 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šie zariadenia s Androidom . Ľudia však z akýchkoľvek dôvodov veria, že to znamená, že ide tiež o použiteľnú optimalizáciu pre moderné zariadenia so systémom Android , čo je absolútne absurdné. Skutočnosť, že Seeder je stále udržiavaný a ponúkaný ako „ moderný “ nástroj na znižovanie oneskorenia je príkladom dezinformácií - aj keď to nie je chyba vývojára spoločnosti Seeder, pretože dokonca aj na ich stránke v Obchode Play sa uvádza, že Seeder je po systéme Android 4.0+ menej efektívny. Z akýchkoľvek dôvodov sa Seeder stále objavuje v diskusiách o optimalizácii pre moderné systémy Android.
Seeder v zásade robí pre Android 3.0 riešenie chyby, pri ktorej by runtime systému Android aktívne používal súbor / dev / random / na získanie entropie. / Dev / random / buffer by sa stal nestabilným a systém by bol blokovaný, kým by nevyplnil požadované množstvo dát - myslite na malé veci, ako sú rôzne senzory a tlačidlá na zariadení Android.
Seederov autor vzal Linux-démona rngd , a zostavený pre inastroil systému Android tak, aby bral náhodné údaje z oveľa rýchlejšej a predvídateľnejšej cesty / dev / urandom a zlúčil ich do dev / random / každú sekundu bez toho, aby sa vyčerpal / dev / random /. Výsledkom bol systém Android, ktorý nezaznamenal nedostatok entropie a bol oveľa plynulejší.
Google túto chybu rozbil po systéme Android 3.0, ale z nejakého dôvodu sa Seeder stále objavuje „Odporúčané vylepšenia“ zoznamy na optimalizáciu výkonu systému Android. Aplikácia Seeder má navyše niekoľko analógov ako sEFix, ktoré zahŕňajú funkcionalitu Seeder, či už používajú tú istú rngd alebo alternatívu vytesaný , alebo dokonca iba symbolický odkaz medzi / dev / urandom a / dev / random. To je pre moderné systémy Android 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 pripojení SSL, generovanie kľúčov SSH atď. WPA_supplication / hostapd, ktorá generuje kľúče WEP / WPA, a nakoniec niekoľko knižníc na generovanie ID pri vytváraní súborových systémov EXT2 / EXT3 / EXT4.
Takže keď Sejačka alebo Vylepšenia založené na secích strojoch sú obsiahnuté v moderných skriptoch na optimalizáciu systému Android, čo sa nakoniec stane, je degradácia vo výkone zariadenia, pretože rngd bude neustále prebúdzať zariadenie a spôsobovať zvyšovanie frekvencie CPU, čo samozrejme negatívne ovplyvňuje spotrebu batérie.
Odex
Skladový firmvér na zariadeniach so systémom Android je skoro vždy odex. To znamená, že spolu so štandardným balíkom pre aplikácie pre Android vo formáte APK, ktorý sa nachádza v priečinkoch / system / app / a / system / priv-app /, majú rovnaké prípony súborov s príponou .odex. Súbory ODEX obsahujú optimalizované aplikácie bytecode, ktoré už prešli cez validátor a optimalizačný virtuálny stroj, potom sa zaznamenajú do samostatného súboru s využitím niečoho podobného dexopt nástroj.
Súbory odex majú teda slúžiť na odľahčenie virtuálneho stroja a ponúkajú rýchle spustenie aplikácie odexed - naopak, súbory ODEX bránia úpravám firmvéru a spôsobujú problémy s aktualizáciami, preto sa z tohto dôvodu distribuuje veľa vlastných pamätí ROM ako LineageOS. bez ODEX .
Generovanie súborov ODEX sa vykonáva rôznymi spôsobmi, napríklad pomocou nástroja Odexer Tool - problém spočíva v tom, že ide výlučne o placebo efekt. Keď moderný systém Android nenájde súbory odex v adresári / system, systém ich skutočne vytvorí a umiestni do adresára / system / dalvik-cache /. Presne to sa deje, keď napríklad flashujete novú verziu systému Android a na chvíľu sa zobrazí správa „Busy, Optimizing Applications“.
Vylepšenia Lowmemorykiller
Multitasking v Androide sa líši od ostatných mobilných operačných systémov v tom zmysle, že je založený na klasickom modeli, kde aplikácie pracujú ticho na pozadí a nie sú nijako obmedzené počet aplikácií na pozadí ( pokiaľ nie je nastavená v možnostiach pre vývojárov, ale všeobecne sa to odporúča proti) - okrem toho sa funkčnosť prechodu na vykonávanie na pozadí nezastaví, aj keď si systém vyhradzuje právo zabiť aplikácie v pozadí v situáciách s nízkou pamäťou ( pozrite sa, kde sme v tejto príručke hovorili o programoch zabývajících sa nízkou pamäťou a zabijakoch mimo pamäte) .
Ak sa chcete vrátiť späť k lowmemorykiller mechanizmus môže Android pokračovať v činnosti s obmedzeným množstvom pamäte a nedostatkom odkladacieho oddielu. Užívateľ môže pokračovať v spúšťaní aplikácií a prepínaní medzi nimi a systém potichu zabije nepoužívané aplikácie na pozadí, aby sa pokúsil uvoľniť pamäť pre aktívne úlohy.
To bolo v prvých dňoch pre Android veľmi užitočné, aj keď z nejakého dôvodu sa stalo populárnym vo forme aplikácií na zabíjanie úloh, ktoré sú všeobecne viac škodlivé ako prospešné. Aplikácie na zabíjanie úloh sa buď prebúdzajú v stanovených intervaloch, alebo ich spúšťa používateľ a zdá sa, že uvoľňujú veľké množstvo pamäte RAM, čo sa považuje za pozitívum - viac voľnej pamäte RAM znamená rýchlejšie zariadenie, však? To však nie je úplne prípad systému Android.
Veľké množstvo voľnej pamäte RAM môže byť v skutočnosti škodlivé pre výkon a životnosť batérie. Keď 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í venovať veľa zdrojov prepnutiu na aplikáciu, pretože tá je už v pamäti.
Z tohto dôvodu nie sú zabijaky úloh už také populárne ako kedysi, aj keď sa noví Androidi na ne z nejakého dôvodu stále spoliehajú ( nedostatok informácií, bohužiaľ) . Bohužiaľ, nový trend nahradil zabijakov úloh, trend lowmemorykiller ladenie mechanizmu. To by bolo napr MinFreeManager hlavnou myšlienkou je zvýšiť režijnú pamäť RAM predtým, ako systém začne zabíjať aplikácie na pozadí.
Napríklad štandardná RAM pracuje na hraniciach - 4, 8, 12, 24, 32 a 40 Mb, a keď sa zaplní voľný úložný priestor 40 MB, do pamäte sa načíta jedna z aplikácií uložených v pamäti. ale nebeží bude ukončený.
V zásade teda bude mať Android vždy minimálne 40 MB dostupnej pamäte, čo je dosť na to, aby sa do nej predtým zmestila ešte jedna aplikácia lowmemorykiller začína proces čistenia - čo znamená, že Android sa bude vždy snažiť využiť maximum dostupnej pamäte RAM bez toho, aby to ovplyvnilo používateľské skúsenosti.
Je smutné, že to, čo začali odporúčať niektorí nadšenci domácej výroby, je zvýšenie hodnoty napríklad na 100 MB pred spustením LMK. Teraz bude používateľ skutočne prehrať RAM (100 - 40 = 60), takže namiesto využitia tohto priestoru na ukladanie aplikácií typu back-end si systém uchová toto množstvo pamäte zadarmo , pričom to nemá absolútne žiadny účel.
LKM ladenie môžu byť užitočné pre oveľa staršie zariadenia s 512 RAM, ale kto už ich vlastní? 2 GB je moderný „rozpočtový rozsah“, dokonca aj 4 GB RAM zariadenia sa dnes považujú za „stredný rozsah“, 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 týkajú subsystému I / O. Napríklad sa pozrime na ThunderBolt! Skript, ktorý obsahuje tieto riadky:
echo 0> $ i / fronta / rotácia; echo 1024> $ i / front / nr_requests;
Prvý riadok poskytne inštrukcie plánovača I / O pri práci s 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 súvisiaci s plánovačom CFQ:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / front / iosched / low_latency; echo 1> $ i / front / iosched / slice_idle;
Potom nasleduje ďalších riadkov, ktoré patria iným plánovačom, ale nakoniec sú prvé dva príkazy zbytočné, pretože:
Moderné jadro Linuxu je schopné pochopiť, s akým typom pamäťového média štandardne pracuje.
Dlhý front vstup-výstup ( napríklad 1024) je na modernom zariadení so systémom Android zbytočné, v skutočnosti nemá zmysel ani na počítači - v skutočnosti sa iba odporúča ťažké servery . Váš telefón nie je odolný server Linux.
Pre zariadenie Android neexistujú prakticky žiadne aplikácie uprednostňované vo vstupno-výstupnom systéme a žiadny mechanický ovládač, takže najlepším plánovačom je fronta noop / FIFO, takže tento typ plánovača “ vyladiť “ nerobí nič zvláštne alebo zmysluplné pre subsystém I / O. V skutočnosti sú všetky tieto príkazy zoznamu pre rôzne obrazovky lepšie nahradené jednoduchým cyklom:
pre i v / sys / block / mmc *; do echo noop> $ i / front / plánovač echo 0> $ i / front / iostaty hotové
To by umožnilo plánovaču noop pre všetky disky hromadením I / O štatistík, čo by malo mať pozitívny vplyv na výkon, aj keď veľmi malý a takmer úplne zanedbateľný.
Ďalším zbytočným vylepšením I / O, ktoré sa často vyskytujú vo výkonnostných skriptoch, sú zvýšené hodnoty čítania dopredu pre SD karty až do 2 MB. Mechanizmus načítania vopred slúži na skoré načítanie údajov z média predtým, ako aplikácia požiada o prístup k týmto údajom. Takže v podstate sa jadro pokúsi prísť na to, aké údaje budú v budúcnosti potrebné, a vopred ich načíta do RAM, čo by tak malo skrátiť čas návratu. Na papieri to znie skvele, ale algoritmus čítania dopredu je bežnejší zle , čo vedie k úplne zbytočným operáciám vstup-výstup, nehovoriac o vysokej spotrebe RAM.
V diskových poliach RAID sa odporúčajú vysoké hodnoty čítania dopredu medzi 1 - 8 MB, pre zariadenia Android je však najlepšie ponechať predvolenú hodnotu 128 kB.
Vylepšenia systému pre správu virtuálnej pamäte
Ďalšou bežnou „optimalizačnou“ technikou 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 prispôsobenie veľkosti vyrovnávacej pamäte na ukladanie „špinavých“ údajov. Špinavé dáta sú zvyčajne dáta, ktoré boli zapísané na disk, ale v pamäti je ešte viac a čakajú na zápis na disk.
Typické vyladiteľné hodnoty v distribúciách Linuxu aj Androis pre subsystém správy VM by boli napríklad:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
To, čo sa to pokúša urobiť, je teda to, že keď je vyrovnávacia pamäť pre špinavé dáta 10% z celkového množstva pamäte RAM, prebudí sa pdflush tok a začne zapisovať dáta na disk - ak bude operácia záznamu dát na disk príliš intenzívne , 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 synchrónnom režime - bez predbežnej medzipamäte. To znamená, že práca zápisu na disk bude zablokované, kým sa údaje nezapíšu na disk (AKA ‘oneskorenie’).
Mali by ste pochopiť, že aj keď je veľkosť vyrovnávacej pamäte nedosahuje 10% , systém automaticky naštartuje pdflush po 30 sekundách. 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 sériové záznamy, kde rýchlosť je často nižšia ako rýchlosť 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 scenáristi snažia túto hodnotu posunúť ešte vyššie, až k absurdným mieram. Napríklad môžeme nájsť v Xplix optimalizačný skript až 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
Na zariadení s pamäťou 1 GB to nastaví limit pre špinavú vyrovnávaciu pamäť na 500/900 MB, čo je pre zariadenie Android úplne zbytočné, pretože by fungovalo iba pod neustále nahrávanie na disk - niečo, čo sa deje iba na ťažkom serveri so systémom Linux.
ThunderBolt! Skript používa rozumnejšiu hodnotu, ale celkovo je stále dosť nezmyselný:
if ['$ mem' -lt 524288]; potom sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; potom 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 RAM, druhý - s 1 GB a ďalšie - s viac ako 1 GB. V skutočnosti však existuje iba 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é rozložiť hodnoty premenných, to znamená urobiť niečo také:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Keď potom prepäťový systém zapisuje operácie, bez toho, aby musel zaznamenávať údaje na disk, posledný 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 ladenie výkonu
Existuje oveľa viac „optimalizácií“, ktoré skutočne neurobia nič. Väčšina z nich jednoducho nemá žiadny účinok, zatiaľ čo iné sa môžu vylepšiť niektoré aspekt výkonu, zatiaľ čo zariadenie degraduje inými spôsobmi ( zvyčajne sa to zníži na výkon vs. vybitie batérie) .
Tu je niekoľko ďalších populárnych optimalizácií, ktoré môžu alebo nemusia byť užitočné, v závislosti od systému a zariadenia Android.
- Akcelerácia - Malá akcelerácia na zlepšenie výkonu a nepodpätie - šetrí trochu batérie.
- Optimalizácia databázy - teoreticky toto by mal zlepšiť výkon zariadenia, ale je to pochybné.
- Zipalign - Je ironické, že aj napriek zabudovanému zarovnávaniu obsahu funkcií Android SDK v súbore APK v obchode nájdete veľa softvéru, ktorý sa neprenáša cez zipalign.
- Zakážte nepotrebné systémové služby, odstráňte nepoužívaný systém a zriedka používané aplikácie tretích strán. V zásade odinštalovanie bloatware.
- Vlastné jadro s optimalizáciami pre konkrétne zariadenie (opäť nie všetky jadrá sú rovnako dobré).
- Už popísaný I / O plánovač noop.
- Algoritmus nasýtenia TCP Westwood - efektívnejšie používaný v predvolenom systéme Android Cubic pre bezdrôtové siete, ktorý je k dispozícii vo vlastných jadrách.
Zbytočné nastavenia build.prop
LaraCraft304 z fóra vývojárov XDA uskutočnil štúdiu a zistil, že pôsobivý počet nastavení /system/build.prop odporúčaných pre použitie ako „experti“ v zdrojových AOSP a CyanogenMod neexistuje. 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 videa.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdown.mode roZnačky Android Rozvoj 12 minút čítania
