Nejběžnější mýty pro optimalizaci Android jsou odhaleny

Existuje spousta instruktážních průvodců věnovaných zvyšování výkonu Androidu a tipů na celkovou optimalizaci. Některé z nich jsou legitimní a jiné jsou založeny pouze na teorii nebo zastaralých operačních metodách v systému Android, nebo jsou jen prostým nesmyslem. To zahrnuje doporučení pro výměnu, hodnoty přidané do build.prop a proměnné změny v jádře Linuxu.

K dispozici je dokonce i tuna „optimalizačních skriptů“, flashové .zipsy typu „vše v jednom“, které slibují výrazně zvýšit výkon, výdrž baterie a další věci. Některé z vylepšení mohou skutečně fungovat, ale většina z nich je prostě placebo efekt, nebo ještě horší, má ve skutečnosti negativní dopad na vaše zařízení.

To ovšem neznamená, že lidé úmyslně vydávají škodlivé skripty - v obchodě Play jsou určitě falešné placené aplikace, ale optimalizační skripty vydané na fórech Android jsou obecně dobře zamýšlené, pouze se tak stane, že vývojář může být nesprávně informován, nebo jednoduše experimentovat s různými optimalizačními vylepšeními. Bohužel se vyskytuje určitý druh sněhové koule, zejména v optimalizačních skriptech typu „vše v jednom“. Malá hrstka vylepšení může vlastně něco udělat, zatímco jiná sada vylepšení ve skriptu nemusí vůbec dělat vůbec nic - přesto se tyto skripty předávají jako magické kulky, bez jakéhokoli skutečného vyšetřování toho, co funguje a co ne .

Mnoho optimalizačních skriptů typu vše v jednom tedy používá stejné metody, z nichž některé jsou z dlouhodobého hlediska zcela zastaralé nebo škodlivé. Stručně řečeno, většina optimalizačních skriptů typu „vše v jednom“ není ničím jiným než doporučeným vyladěním, bez jasné představy o tom, jak nebo proč tyto optimalizace fungují - uživatelé pak skripty flashují a tvrdí, že jejich výkon je najednou rychlejší ( ve skutečnosti to byl s největší pravděpodobností samotný akt restartu zařízení, který způsobil zvýšení výkonu, protože všechno v paměti RAM zařízení bylo vyčištěno) .

V tomto exkluzivním článku Appuals zdůrazníme některá z nejběžnějších doporučení pro „ optimalizaci“ výkonu systému Android a zda jde pouze o mýtus nebo legitimní vylepšení výkonu zařízení.

Zaměnit

Na vrcholu seznamu mýtů je swap pro Android - což je docela absurdní, pokud jde o myšlenku na optimalizaci pro Android. Hlavním účelem swapů je vytvořit a připojit stránkovací soubor, který uvolní úložný prostor v paměti. Zní to citlivě na papíře, ale je to opravdu použitelné pro server, který nemá téměř žádnou interaktivitu.

Pokud pravidelně používáte swap telefonu s Androidem, povede to k závažným zpožděním, která pramení z věcí proklouznutí kolem mezipaměti. Představte si například, pokud se aplikace pokusí zobrazit grafiku, která je uložena ve swapu, který musí nyní znovu uvolnit disk po uvolnění místa umístěním swapu dat do jiné aplikace. Je to opravdu chaotický.

Někteří nadšenci optimalizace mohou říci, že swap nenabízí žádné problémy, ale není to swap, což zvyšuje výkon - je to vestavěný mechanismus Android lowmemorykiller, který bude pravidelně zabíjet nafouklé procesy s vysokou prioritou, které se nepoužívají. LMK byl navržen speciálně pro zpracování podmínek nedostatku paměti, je vyvolán z procesu kswapd a obecně zabíjí procesy v uživatelském prostoru. To se liší od zabijáka zabývajícího se pamětí OOM, ale to je úplně jiné téma.

Jde o to, že zařízení s například 1 GB RAM nemůže nikdy dosáhnout potřebných dat o výkonu ve swapu, takže swap v Androidu absolutně není nutný. Jeho implementace je jednoduše plná zpoždění a vede spíše ke snížení výkonu než k optimalizaci.

zRAM - Zastaralé a již neúčinné

zRAM je osvědčená a efektivní metoda pro optimalizaci zařízení, pro starší zařízení - myslím, že zařízení založená na KitKat, která pracují pouze s asi 512 MB RAM. Skutečnost, že někteří lidé stále obsahují vylepšení zRAM v optimalizačních skriptech, nebo doporučují zRAM jako nějaký druh vylepšení moderní optimalizace, je příkladem lidí, kteří obecně nedodržují nejnovější operační protokoly.

zRAM byl určen pro základní jádro vícejádrových SoC, jako jsou zařízení využívající čipové sady MTK a 512 MB paměti RAM. V podstatě velmi levné čínské telefony. To, co zRAM v zásadě dělá, je oddělení jádra pomocí šifrovacího proudu.

Pokud je zRAM používán na starších zařízeních s jedním jádrem, i když je zRAM na takových zařízeních doporučován, má velké množství zpoždění tendenci se ořezávat. To se také děje s technologií KSM ( Kernel Same Page Merging), která kombinuje identické stránky s pamětí a nabízí volné místo. Google to ve skutečnosti doporučuje, ale ve starších zařízeních to vede k většímu zpoždění, protože neustále aktivní jádra jádra běží nepřetržitě z paměti a hledají duplicitní stránky. V zásadě se pokus o spuštění optimalizace vyladí zařízení ještě dále, ironicky.

Secí stroj - zastaralý od verze Android 3.0

Jedním z nejdiskutovanějších tipů na optimalizaci mezi zařízeními Android devs je secí stroj a jsme si jisti, že by se nám někdo mohl pokusit prokázat, že jsme v tomto tématu špatní - ale nejdřív musíme prozkoumat historii segeru.

Ano, existuje velké množství přehledů, které deklarují lepší výkon systému Android po instalaci na mnohem starších zařízeních Android . Lidé z jakéhokoli důvodu se však domnívají, že se jedná o použitelnou optimalizaci pro moderní zařízení Android, což je naprosto absurdní. Skutečnost, že Seeder je stále udržován a nabízen jako „ moderní“ nástroj pro snižování zpoždění, je příkladem dezinformací - ačkoli to není chyba vývojáře Seeder, protože i na stránce Play Store poznamenává, že Seeder je po Androidu 4.0+ méně účinný. Přesto z jakéhokoli důvodu se Seeder stále objevuje v diskuzích o optimalizaci moderních systémů Android.

To, co Seeder v zásadě dělá pro Android 3.0, je chyba, kde by runtime systému Android aktivně používal / dev / random / file k získání entropie. / Dev / random / buffer by se stal nestabilním a systém by byl blokován, dokud nenaplnil požadované množství dat - pomyslete na malé věci, jako jsou různé senzory a tlačítka na zařízení Android.

Autor secího stroje vzal linuxový démon rngd a kompiloval pro Android inastroil tak, aby vzal náhodná data z mnohem rychlejší a předvídatelnější / dev / urandom cesty a sloučí je do dev / random / každou sekundu, bez povolení / dev / random / být vyčerpaný. To mělo za následek systém Android, který nezažil nedostatek entropie a byl mnohem plynulejší.

Google rozbil tuto chybu po Android 3.0, ale z nějakého důvodu se Seeder stále objevuje na seznamech doporučených vylepšení pro optimalizaci výkonu Androidu. Kromě toho má aplikace Seeder několik analogů, jako je sEFix, které zahrnují funkčnost Seeder, ať už se používá stejný rngd nebo alternativní hasged, nebo dokonce jen symbolický odkaz mezi / dev / urandom a / dev / random. To je naprosto zbytečné pro moderní systémy Android.

Důvod je nesmyslný, protože novější verze systému Android používají / dev / random / ve třech hlavních komponentách - libcrypto, pro šifrování připojení SSL, generování klíčů SSH atd. WPA_supplication / hostapd, který generuje klíče WEP / WPA, a konečně několik knihovny pro generování ID při vytváření systémů souborů EXT2 / EXT3 / EXT4.

Takže když jsou v moderních skriptech pro optimalizaci Androidu zahrnuta vylepšení Seeder nebo Seeder, nakonec se to stane snížením výkonu zařízení, protože rngd zařízení neustále probouzí a způsobuje zvýšení frekvence CPU, což samozřejmě negativně ovlivňuje spotřebu baterie .

Odex

Firmware akcií na zařízeních Android téměř vždy odex. To znamená, že vedle standardního balíčku pro aplikace pro Android ve formátu APK, které se nacházejí ve složkách / system / app / a / system / priv-app /, mají stejné názvy souborů s příponou .odex. Soubory odexu obsahují optimalizované aplikace s bajtovým kódem, které již prošly virtuálním strojem pro validátor a optimalizátor, a poté byly zaznamenány do samostatného souboru využívajícího něco jako nástroj dexopt .

Soubory odex jsou tedy určeny k tomu, aby odložily virtuální počítač a nabídly urychlené spuštění odexedované aplikace - na druhou stranu, soubory ODEX brání úpravám firmwaru a způsobují problémy s aktualizacemi, takže z tohoto důvodu je mnoho vlastních ROM, jako je LineageOS, distribuováno bez ODEX .

Generování souborů ODEX se provádí několika způsoby, například pomocí nástroje Odexer Tool - problém spočívá v tom, že jde pouze o placebo efekt. Pokud moderní systém Android nenajde odex soubory v adresáři / system, systém je skutečně vytvoří a umístí do adresáře / system / dalvik-cache /. To se přesně děje, když například vydáte novou verzi systému Android a na chvíli se zobrazí zpráva „Busy, Optimizing Applications“.

Lowmemorykiller vylepší

Multitasking v Androidu se liší od ostatních mobilních operačních systémů v tom smyslu, že je založen na klasickém modelu, kde aplikace pracují na pozadí potichu, a počet aplikací na pozadí není nijak omezen ( pokud není jedna nastavena v Možnosti vývojáře, ale toto je obecně se doporučuje proti) - kromě toho se funkce přechodu na pozadí nezastaví, ačkoli systém si vyhrazuje právo zabíjet aplikace na pozadí v situacích s nízkou pamětí ( viz, kde jsme dříve hovořili o zabijácích s nízkou pamětí a zabijácích mimo paměť). průvodce) .

Chcete-li se vrátit k mechanismu lowmemorykiller, Android může nadále pracovat s omezeným množstvím paměti a nedostatkem odkládacího oddílu. Uživatel může i nadále spouštět aplikace a přepínat mezi nimi a systém tiše zabije nepoužívané aplikace na pozadí, aby vyzkoušel a uvolnil paměť pro aktivní úkoly.

To bylo pro Android velmi užitečné v prvních dnech, i když z nějakého důvodu se stalo populárním ve formě aplikací zabijáků úloh, které jsou obecně škodlivější než prospěšné. Aplikace zabijáků úkolů se buď probudí v nastavených intervalech, nebo jsou spuštěny uživatelem a zdá se, že uvolňují velká množství paměti RAM, což je vnímáno jako pozitivní - více volné paměti RAM znamená rychlejší zařízení, že? To však není případ systému Android.

Ve skutečnosti může mít velké množství volné paměti RAM skutečně škodlivé pro výkon vašeho zařízení a výdrž baterie. Když jsou aplikace uloženy v paměti RAM systému Android, je mnohem snazší je vyvolat, spustit a podobně. Systém Android nemusí na přepnutí do aplikace věnovat mnoho prostředků, protože je již v paměti.

Z tohoto důvodu nejsou zabijáci úkolů tak populární, jako kdysi byli, ačkoli nováčci v Androidu se na ně z nějakého důvodu stále spoléhají ( bohužel nedostatek informací) . Bohužel, nový trend nahradil zabijáky úkolů, trend ladění mechanismů lowmemorykillerů . To by bylo například aplikace MinFreeManager a hlavní myšlenkou je zvýšit režii RAM dříve, než systém začne zabíjet aplikace na pozadí.

Například standardní RAM pracuje na hranicích - 4, 8, 12, 24, 32 a 40 Mb, a když je zaplněno volné úložné místo 40 MB, je jedna z aplikací v mezipaměti načtena do paměti, ale není spuštěna. bude ukončena.

V zásadě tedy bude mít Android vždy k dispozici alespoň 40 MB dostupné paměti, což je dost, aby vyhovovalo jedné další aplikaci, než lowmemorykiller začne proces čištění - to znamená, že Android bude vždy dělat maximum pro využití maximálního množství dostupné RAM, aniž by zasahoval do uživatelská zkušenost.

Je smutné, že někteří nadšenci z homebrejštiny začali doporučovat, aby hodnota byla zvýšena například na 100 MB před tím, než LMK nastartuje. Nyní uživatel skutečně ztratí RAM (100 - 40 = 60), takže místo toho, aby tento prostor využil k uložení zpět- koncových aplikací, systém udrží toto množství paměti zdarma, a to absolutně bez účelu.

Ladění LKM může být užitečné pro mnohem starší zařízení s 512 RAM, ale kdo je už vlastní? 2GB je moderní „rozpočtový rozsah“, dokonce i 4GB RAM zařízení jsou v těchto dnech vnímána jako „střední řada“, takže vylepšení LMK jsou opravdu zastaralá a zbytečná.

Vylepšení I / O

V mnoha optimalizačních skriptech pro Android často najdete vylepšení, která se týkají I / O subsystému. Například se podívejme na ThunderBolt! Skript, který obsahuje tyto řádky:

 echo 0> $ i / fronta / rotační; echo 1024> $ i / fronta / nr_requests; 

První řádek dá instrukcím I / O plánovače při práci s SSD a druhý zvětšuje maximální velikost fronty I / O ze 128 na 1024 - protože proměnná $ i obsahuje cestu ke stromu blokových zařízení v / sys a skript běží ve smyčce.

Poté najdete řádek týkající se plánovače CFQ:

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

Následuje několik řádků, které patří jiným plánovačům, ale nakonec jsou první dva příkazy zbytečné, protože:

Moderní linuxové jádro je schopno pochopit, s jakým typem paměťového média ve výchozím nastavení pracuje.

Dlouhá fronta vstup-výstup ( například 1024) je na moderním zařízení Android zbytečná, ve skutečnosti nemá smysl ani na stolním počítači - je to opravdu doporučeno pouze na těžkých serverech . Váš telefon není těžký server Linux.

U zařízení se systémem Android neexistují prakticky žádné aplikace, které by upřednostňovaly vstup-výstup a žádný mechanický ovladač, takže nejlepším plánovačem je fronta noop / FIFO, takže tento typ plánovače „ vyladění“ nedělá nic zvláštního ani smysluplného pro I / O subsystém. Ve skutečnosti jsou všechny tyto příkazy seznamu pro více obrazovek lépe nahrazeny jednoduchým cyklem:

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

To by umožnilo plánovač noop pro všechny disky z hromadění I / O statistik, což by mělo mít pozitivní dopad na výkon, i když velmi malý a téměř zcela zanedbatelný.

Dalším zbytečným vylepšeními I / O, které se často vyskytují ve výkonových skriptech, jsou zvýšené hodnoty pro čtení u SD karet až do 2 MB. Mechanismus čtení předem umožňuje včasné čtení dat z média, než aplikace požádá o přístup k těmto datům. Takže jádro se v zásadě bude snažit zjistit, jaká data budou v budoucnu potřebná, a nahraje je do paměti RAM, což by mělo zkrátit dobu návratu. To zní skvěle na papíře, ale algoritmus čtení dopředu je častěji chybný, což vede ke zcela zbytečným operacím vstup-výstup, nemluvě o vysoké spotřebě RAM.

V polích RAID se doporučují vysoké hodnoty pro čtení v rozmezí 1 - 8 MB, ale pro zařízení Android je nejlepší ponechat výchozí hodnotu 128 KB.

Vylepšuje se systém správy virtuální paměti

Další běžnou technikou „optimalizace“ je vyladění subsystému správy virtuální paměti. To se obvykle zaměřuje pouze na dvě proměnné jádra, vm.dirty_background_ratio a vm.dirty_ratio, které slouží k úpravě velikosti vyrovnávací paměti pro ukládání „špinavých“ dat. Špinavá data jsou obvykle data, která byla zapsána na disk, ale v paměti je ještě více a čeká na jejich zapsání na disk.

Typické hodnoty vyladění jak v Linuxových distribucích, tak v Androisu na subsystém správy VM by byly:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

To se tedy pokouší udělat tak, že když je špinavá datová vyrovnávací paměť 10% z celkového množství paměti RAM, probudí tok PDFlush a začne zapisovat data na disk - pokud bude operace zaznamenávání dat na disk příliš intenzivní, vyrovnávací paměť bude nadále růst a když dosáhne 20% dostupné paměti RAM, systém se přepne na následnou operaci zápisu v synchronním režimu - bez předběžné vyrovnávací paměti. To znamená, že práce zápisu na disk bude blokována, dokud nebudou data zapsána na disk (AKA 'lag').

Co byste měli pochopit je, že i když velikost vyrovnávací paměti nedosáhne 10%, systém automaticky nakopne pdflush po 30 sekundách. Kombinace 10/20 je docela rozumná, například na zařízení s 1 GB RAM by se to rovnalo 100/200 MB RAM, což je více než dost, pokud jde o burstové záznamy, kde je rychlost často pod rychlým záznamem v systému NAND - paměť nebo karta SD, například při instalaci aplikací nebo kopírování souborů z počítače.

Z nějakého důvodu se autoři scénářů snaží tuto hodnotu posunout ještě výš, k absurdním tempům. Například v optimalizačním skriptu Xplix můžeme najít rychlost až 50/90.

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

U zařízení s 1 GB paměti se nastaví limit na špinavou vyrovnávací paměť na 500/900 MB, což je pro zařízení Android zcela zbytečné, protože by fungovalo pouze při neustálém záznamu na disk - něco, co se děje pouze na těžkém Linuxový server.

Blesk! Skript používá rozumnější hodnotu, ale celkově je stále docela bezvýznamný:

 pokud ["$ mem" -lt 524288]; pak 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; 

První dva příkazy jsou spouštěny na smartphonech s 512 MB RAM, druhý - s 1 GB a další - s více než 1 GB. Ve skutečnosti však existuje pouze jeden důvod ke změně výchozího nastavení - zařízení s velmi pomalou vnitřní pamětí nebo paměťovou kartou. V tomto případě je rozumné šířit hodnoty proměnných, tj. Udělat něco takového:

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

Poté, když přepěťový systém zapíše operace, aniž by bylo nutné zaznamenávat data na disk, až do posledního se nepřepne do synchronního režimu, což umožní aplikacím snížit zpoždění při záznamu.

Další zbytečné vylepšení a vyladění výkonu

Existuje mnohem více „optimalizací“, které opravdu nic nedělají. Většina z nich prostě nemá žádný účinek, zatímco jiní mohou vylepšit některý aspekt výkonu, zatímco zařízení jiným způsobem degradují ( obvykle se sníží na výkon vs vybití baterie) .

Zde jsou některé další populární optimalizace, které mohou nebo nemusí být užitečné, v závislosti na systému a zařízení Android.

• Zrychlení - malé zrychlení pro zlepšení výkonu a podtečení - šetří trochu baterie.
• Optimalizace databáze - Teoreticky by to mělo přinést zlepšení výkonu zařízení, ale jeho pochybnosti.
• Zipalign - Je ironií, že přes vestavěné Android SDK funkce zarovnání obsahu v souboru APK v obchodě můžete najít spoustu softwaru není přenášena přes zipalign.
• Zakažte nepotřebné systémové služby, odstraňte nepoužívané systémové a zřídka používané aplikace třetích stran. V zásadě odinstalace bloatware.
• Vlastní jádro s optimalizací pro konkrétní zařízení (opět ne všechna jádra jsou stejně dobrá).
• Již popsané noop plánovače I / O.
• Algoritmus saturace TCP Westwood - Efektivnější použití ve výchozím nastavení Android Cubic pro bezdrátové sítě, dostupné ve vlastních jádrech.

Nepotřebné nastavení build.prop

LaraCraft304 z fóra XDA Developers provedlo studii a zjistilo, že ve zdrojovém AOSP a CyanogenMod neexistuje impozantní počet nastavení /system/build.prop, které jsou doporučeny pro použití „odborníků“. Zde je seznam:

 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 přetrvává.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_JIP_