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ů „vše v jednom“ není nic jiného než doporučená ladění společně, bez jasné představy o tom, jak a proč tyto optimalizace „fungují - uživatelé pak skripty blikají a tvrdí, že jejich výkon je náhle rychlejší ( i když ve skutečnosti to byl pravděpodobně velmi jednoduchý čin restartu zařízení, který způsobil zvýšení výkonu , protože se vše v paměti RAM zařízení vyčistí) .
V tomto exkluzivním článku Appuals zdůrazníme některá z nejběžnějších doporučení pro „ optimalizace “ Výkon systému Android a zda jde pouze o mýtus nebo legitimní vylepšení výkonu zařízení.
Zaměnit
V horní části seznamu mýtů je výměna systému Android - což je docela absurdní, pokud jde o to, že je považováno za optimalizaci systému Android. Hlavním účelem swapů je vytvoření a připojení stránkovacího souboru, který uvolní úložný prostor v paměti. To zní rozumně na papíře , ale je to opravdu použitelné pro a serveru , který nemá téměř žádnou interaktivitu.
Pokud pravidelně používáte výměnu telefonu Android, povede to k výrazným zpožděním, která pramení z toho, že věci proklouzly kolem mezipaměti. Představte si například, že se aplikace pokusí zobrazit grafiku, která je uložena ve swapu, který nyní musí po uvolnění místa znovu načíst disk umístěním swapu dat do jiné aplikace. Je to opravdu špinavé.
Někteří nadšenci optimalizace mohou říci, že swap nenabízel žádné problémy, ale nejde o swap zvyšující výkon - je to vestavěný mechanismus Android lowmemorykiller , který pravidelně zabíjí nafouklé procesy s vysokou prioritou, které se nepoužívají. LMK byl navržen speciálně pro zpracování podmínek s nízkou pamětí, je vyvolán z kswapd proces a obecně zabíjí procesy v uživatelském prostoru. To se liší od OOMkiller (zabiják mimo paměť), ale to je úplně jiné téma.
Jde o to, že zařízení s například 1 GB RAM nikdy nemůže během swapu dosáhnout potřebných údajů o výkonu, takže swap není v Androidu vůbec nutný. Jeho implementace je prostě plná zpoždění a vede k degradace spíše než optimalizovat výkon.
zRAM - zastaralý a již neefektivní
zRAM je osvědčená a účinná metoda pro optimalizaci zařízení, pro starší zařízení - přemýšlejte o zařízeních založených na KitKat, která pracují pouze s asi 512 MB RAM. Skutečnost, že někteří lidé stále zahrnují vylepšení zRAM do optimalizačních skriptů, nebo doporučují zRAM jako nějaký druh moderního vylepšení optimalizace, je příkladem lidí, kteří obecně nedodržují nejnovější operační protokoly.
zRAM byl určen pro základní vícejádrové SoC s nízkým rozpočtem, jako jsou zařízení využívající čipové sady MTK a 512 MB RAM. V zásadě velmi levné čínské telefony. To, co zRAM v zásadě dělá, je oddělení jádra pomocí šifrovacího proudu.
Když se zRAM používá na starších zařízeních s a jednojádrový , i když se na takových zařízeních doporučuje zRAM, má velké množství zpoždění tendenci se objevovat. To se děje také s technologií KSM ( Sloučení stejné stránky jádra) který kombinuje identické stránky paměti v nabídce do volného místa. Toto ve skutečnosti doporučuje Google, ale vede to k větším zpožděním na starších zařízeních, protože neustále aktivní jádra běží nepřetržitě z paměti a hledají duplicitní stránky. V podstatě pokus o spuštění optimalizačního vylepšení zařízení ironicky ještě více zpomalí.
Seeder - zastaralý od verze Android 3.0
Jedním z nejdiskutovanějších tipů na optimalizaci mezi zařízeními Android je cedr a jsme si jisti, že by se nás někdo mohl pokusit v tomto tématu dokázat, že se mýlíme - ale nejdříve musíme prozkoumat historii secí.
Aplikace Seeder pro Android
Ano, existuje velké množství sestav, které deklarují lepší výkon Androidu po instalaci na mnohem starší zařízení Android . Lidé však z jakéhokoli důvodu věří, že to znamená, že je to také použitelná optimalizace 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 redukci zpoždění je příkladem dezinformací - i když to není chyba vývojáře Seeder, protože i jejich stránka Play Store uvádí, že Seeder je po Androidu 4.0+ méně efektivní. Přesto se z jakéhokoli důvodu Seeder stále objevuje v diskusích o optimalizaci pro moderní systémy Android.
To, co Seeder v zásadě dělá pro Android 3.0, je řešení chyby, při které by běh 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 - přemýšlejte o maličkostech, jako jsou různé senzory a tlačítka na zařízení Android.
Seederův autor vzal linuxového démona rngd , a zkompilovaný pro inastroil Androidu, aby nabral náhodná data z mnohem rychlejší a předvídatelnější cesty / dev / urandom a spojil je do dev / random / každou sekundu, aniž by došlo k vyčerpání / dev / random /. To vyústilo v systém Android, který nezaznamenal nedostatek entropie a fungoval mnohem plynuleji.
Google tuto chybu rozbil po Androidu 3.0, ale z nějakého důvodu se Seeder stále objevuje „Doporučené vylepšení“ seznamy pro optimalizaci výkonu systému Android. Kromě toho má aplikace Seeder několik analogů, jako je sEFix, které obsahují funkce Seeder, ať už používají stejné rngd nebo alternativa vytáhl , nebo dokonce jen symbolický odkaz mezi / dev / urandom a / dev / random. To je pro moderní systémy Android naprosto zbytečné.
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 nakonec několik knihoven pro generování ID při vytváření souborových systémů EXT2 / EXT3 / EXT4.
Takže když Secí stroj nebo Vylepšení na bázi Seeder jsou zahrnuta v moderních skriptech pro optimalizaci systému Android, to, co se nakonec stane, je degradace ve výkonu zařízení, protože rngd neustále probudí zařízení a způsobí zvýšení frekvence CPU, což samozřejmě negativně ovlivní spotřebu baterie.
Odex
Akciový firmware na zařízeních Android je téměř vždy odex. To znamená, že vedle standardního balíčku pro aplikace pro Android ve formátu APK, který se nachází v / system / app / a / system / priv-app /, mají stejné názvy souborů s příponou .odex. Soubory odex obsahují optimalizované aplikace bajtových kódů, které již prošly validačním a optimalizačním virtuálním strojem a poté jsou zaznamenány do samostatného souboru využívajícího něco jako dexopt nástroj.
Soubory odex jsou tedy určeny k odlehčení virtuálního stroje a nabízejí zrychlené spuštění aplikace odexed - na druhou stranu soubory ODEX zabraňují úpravám firmwaru a vytvářejí problémy s aktualizacemi, takže z tohoto důvodu je distribuována řada vlastních ROM, jako je LineageOS bez ODEX .
Generování souborů ODEX se provádí mnoha způsoby, například pomocí nástroje Odexer Tool - problém spočívá v tom, že jde o čistě placebo efekt. Když moderní systém Android nenajde soubory odex v adresáři / system, systém je skutečně vytvoří a umístí do adresáře / system / dalvik-cache /. Přesně to se děje, když například flashujete novou verzi systému Android a na chvíli se zobrazí zpráva „Busy, Optimizing Applications“.
Vylepšení Lowmemorykiller
Multitasking v systému Android 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í tiše na pozadí a neexistují žádná omezení počtu aplikací na pozadí ( pokud není nastavena v Možnosti pro vývojáře, ale obecně se to doporučuje proti) - kromě toho se funkce přechodu na spuštění na pozadí nezastaví, i když si systém vyhrazuje právo zabít aplikace na pozadí v situacích s nízkou pamětí ( podívejte se, kde jsme dříve v této příručce mluvili o lowmemorykiller a zabijákovi mimo paměť) .
Chcete-li se vrátit do lowmemorykiller mechanismus, Android může i nadále pracovat s omezeným množstvím paměti a nedostatkem odkládacího oddílu. Uživatel může pokračovat ve spouštění aplikací a přepínat mezi nimi, a systém tiše zabije nepoužívané aplikace na pozadí, aby se pokusil uvolnit paměť pro aktivní úkoly.
To bylo v prvních dnech pro Android velmi užitečné, i když z nějakého důvodu se stalo populární v podobě aplikací zabijáků úkolů, které jsou obecně více škodlivé než přínosné. Aplikace zabývající se úlohami se budí v nastavených intervalech nebo jsou spouštěny uživatelem a zdá se, že uvolňují velké množství paměti RAM, což je považováno za pozitivní - více volné paměti RAM znamená rychlejší zařízení, že? To však není přesně případ Androidu.
Velké množství volné paměti RAM může ve skutečnosti poškodit výkon zařízení a životnost baterie. Když jsou aplikace uloženy v paměti RAM systému Android, je mnohem snazší je vyvolávat, spouštět atd. Systém Android nemusí věnovat mnoho prostředků přechodu na aplikaci, protože je již v paměti.
Z tohoto důvodu nejsou zabijáci úkolů tak populární jako dřív, i když noví Androidové se na ně z nějakého důvodu stále spoléhají ( nedostatek informací, bohužel) . Nový zabiják bohužel nahradil zabijáky úkolů, trend lowmemorykiller ladění mechanismu. To by bylo například MinFreeManager hlavní myšlenkou je zvýšit režii RAM, 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ěn volný úložný prostor 40 MB, jedna z aplikací uložených v mezipaměti je načtena do paměti ale neběží bude ukončen.
V zásadě tedy Android bude mít vždy alespoň 40 MB dostupné paměti, což je dost na to, aby se do něj dříve vešla ještě jedna aplikace lowmemorykiller zahajuje proces čištění - což znamená, že Android se vždy bude snažit využít maximální množství dostupné paměti RAM, aniž by to narušilo uživatelské prostředí.
Bohužel to, co někteří nadšenci homebrewu začali doporučovat, je zvýšit hodnotu například na 100 MB před spuštěním LMK. Nyní uživatel skutečně prohrát RAM (100 - 40 = 60), takže místo využití tohoto prostoru k ukládání aplikací typu back-end si systém ponechá toto množství paměti volný, uvolnit , s absolutně žádným účelem.
LKM tuning může být užitečné pro mnohem starší zařízení s 512 RAM, ale kdo je už vlastní? 2 GB je moderní „rozpočet“, dokonce i 4 GB RAM zařízení se dnes považují za „střední rozsah“, 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á řeší subsystém I / O. Například se pojďme podívat na Blesk! Skript, který obsahuje tyto řádky:
echo 0> $ i / fronta / rotace; echo 1024> $ i / queue / nr_requests;
První řádek poskytne instrukci plánovače I / O při práci s SSD a druhý zvyšuje maximální velikost I / O fronty 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 související s plánovačem CFQ:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
Následuje další řádky, které patří ostatním plánovačům, ale nakonec jsou první dva příkazy zbytečné, protože:
Moderní jádro Linuxu je schopno pochopit, s jakým typem paměťového média ve výchozím nastavení pracuje.
Dlouhá fronta vstupů a výstupů ( například 1024) je k ničemu na moderním zařízení Android, ve skutečnosti nemá smysl ani na ploše - je to opravdu jen doporučeno těžké servery . Váš telefon není těžký server Linux.
U zařízení Android neexistují prakticky žádné aplikace upřednostňované na vstupu a výstupu a žádný mechanický ovladač, takže nejlepším plánovačem je fronta noop / FIFO, takže tento typ plánovače “ vyladit “ nedělá nic zvláštního nebo smysluplného pro subsystém I / O. Ve skutečnosti jsou všechny tyto příkazy seznamu pro více obrazovek lépe nahrazeny jednoduchým cyklem:
pro i v / sys / block / mmc *; do echo noop> $ i / fronta / plánovač echo 0> $ i / fronta / iostats hotovo
To by umožnilo plánovač noop pro všechny disky z hromadění statistik I / O, 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ím I / O, které se často objevují ve výkonových skriptech, jsou zvýšené hodnoty čtení dopředu pro SD karty až do 2 MB. Mechanismus čtení dopředu je určen pro časná čtení dat z média, než aplikace požádá o přístup k těmto datům. V zásadě se tedy jádro pokusí zjistit, jaká data budou v budoucnu potřebovat, a předem je načte do paměti RAM, což by mělo zkrátit dobu návratu. Na papíře to zní skvěle, ale algoritmus čtení dopředu je častější špatně , což vede ke zcela zbytečným operacím vstupu-výstupu, nemluvě o vysoké spotřebě RAM.
V polích RAID se doporučují vysoké hodnoty pro čtení dopředu mezi 1 - 8 MB, ale pro zařízení Android je nejlepší ponechat výchozí hodnotu 128 kB.
Vylepšení systému pro správu virtuální paměti
Další běžnou technikou „optimalizace“ je vyladění subsystému pro správu virtuální paměti. Toto 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 čekají na zápis na disk.
Typické vyladěné hodnoty v distribucích Linuxu a Androis pro subsystém správy VM by vypadaly takto:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
To, co se to pokouší udělat, je to, že když je vyrovnávací paměť špinavých dat 10% z celkového množství paměti RAM, probudí se pdflush tok a začne zapisovat data na disk - pokud bude operace záznamu dat na disk příliš intenzivní , vyrovnávací paměť bude i nadále růst, a když dosáhne 20% dostupné RAM, systém přepne na následnou operaci zápisu v synchronním režimu - bez předběžného vyrovnávací paměti. To znamená, že práce s zápisem na disk bude blokováno, dokud nebudou data zapsána na disk (Aka „zpoždění“).
Měli byste pochopit, že i když je velikost vyrovnávací paměti nedosahuje 10% , systém automaticky spustí 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 sériové záznamy, kde rychlost je často nižší než rychlostní rekord v systému NAND - paměť nebo SD karta, 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ýše, na absurdní sazby. Například můžeme najít v Xplix optimalizační skript rychlost až 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
Na zařízení s 1 GB paměti to 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 pod neustálé nahrávání na disk - něco, co se děje pouze na těžkém serveru Linux.
Blesk! Skript používá rozumnější hodnotu, ale celkově je stále poměrně nesmyslný:
if ['$ mem' -lt 524288]; then sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; poté 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 se spouštějí 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é rozdělit hodnoty proměnných, to znamená udělat něco takového:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Když pak přepěťový systém zapisuje operace, aniž by musel zaznamenávat data na disk, poslední se nepřepne do synchronního režimu, což aplikacím umožní omezit zpoždění při nahrávání.
Další zbytečné vylepšení a ladění výkonu
Existuje mnohem více „optimalizací“, které opravdu nedělají nic. Většina z nich prostě nemá vůbec žádný účinek, zatímco ostatní se mohou zlepšit nějaký aspekt výkonu, zatímco zařízení degradujete jinými způsoby ( obvykle se snižuje na výkon vs. vybití baterie) .
Zde je několik dalších populárních optimalizací, které mohou nebo nemusí být užitečné, v závislosti na systému a zařízení Android.
- Zrychlení - malé zrychlení ke zlepšení výkonu a podtržení - šetří trochu baterie.
- Optimalizace databáze - Teoreticky to by měl poskytnout zlepšení výkonu zařízení, ale je to pochybné.
- Zipalign - Je ironií, že i přes vestavěné zarovnání obsahu funkcí Android SDK v souboru APK v obchodě najdete spoustu softwaru, který se nepřenáší přes zipalign.
- Zakažte nepotřebné systémové služby, odstraňte nepoužívaný systém a zřídka používané aplikace třetích stran. V zásadě odinstalování bloatware.
- Vlastní jádro s optimalizacemi pro konkrétní zařízení (opět ne všechna jádra jsou stejně dobrá).
- Již popsaný plánovač I / O noop.
- Algoritmus nasycení TCP Westwood - efektivněji použit ve výchozím Android Cubic pro bezdrátové sítě, k dispozici ve vlastních jádrech.
Zbytečné nastavení build.prop
LaraCraft304 z fóra XDA Developers provedla studii a zjistila, že ve zdrojových AOSP a CyanogenMod neexistuje působivé množství 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 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.modeZnačky Android Rozvoj 12 minut čtení
