Így sok minden az egyben optimalizáló szkript ugyanazokat a módszereket használja, amelyek közül néhány hosszú távon teljesen elavult vagy káros. Összefoglalva, a „mindent az egyben” optimalizáló szkriptek többsége nem más, mint összecsapott, ajánlott hangolások, nincs világos elképzelésük arról, hogyan vagy miért működnek ezek az optimalizálások - a felhasználók ezután villogtatják a szkripteket, és azt állítják, hogy a teljesítményük hirtelen gyorsabb ( amikor valójában valószínűleg a készülék egyszerű újraindítása okozta a teljesítmény növekedését , mivel az eszköz RAM-jából mindent megtisztítanak) .
Ebben az Appuals exkluzív cikkben kiemeljük a „ optimalizálás ” Az Android teljesítménye, és hogy egyszerűen mítoszról van szó, vagy az eszköz teljesítményének törvényes módosításáról.
Csere
A mítoszlista tetején található az Android-csere - ami elég abszurd abból a szempontból, hogy Android-optimalizációnak gondolják. A Swaps fő célja a lapozófájl létrehozása és összekapcsolása, amely felszabadítja a tárhelyet a memóriában. Ez értelmesen hangzik papíron , de valóban alkalmazható a szerver , amelynek szinte nincs interaktivitása.
Ha rendszeresen használja androidos telefonjának cseréjét, az súlyos lemaradásokhoz vezet, amelyek abból fakadnak, hogy a dolgok elcsúsztak a gyorsítótár alatt. Képzeljük el például, ha egy alkalmazás megpróbál megjeleníteni egy grafikát, amelyet a csere tárol, és amelynek a hely felszabadulása után újratöltenie kell a lemezt azáltal, hogy az adatcserét egy másik alkalmazással helyezi el. Nagyon rendetlen.
Egyes optimalizálási rajongók azt mondhatják, hogy a csere nem jelentett problémát, de nem a csere miatt növeli a teljesítményt - ez a beépített Android-mechanizmus lowmemorykiller , amely rendszeresen megöli a fel nem használt, kiemelt fontosságú folyamatokat, amelyeket nem használnak. Az LMK-t kifejezetten az alacsony memóriájú körülmények kezelésére tervezték, a kswapd folyamatot, és általában megöli a felhasználói tér folyamatait. Ez különbözik a OOMkiller (memórián kívüli gyilkos), de ez egy teljesen más téma.
A lényeg az, hogy egy eszköz, például 1 GB RAM-mal, soha nem tudja elérni a szükséges teljesítményadatokat cserében, ezért az Android-on feltétlenül nincs szükség cserére. Megvalósítása egyszerűen tele van késéssel és a degradáció teljesítményben, nem pedig optimalizálni.
zRAM - Elavult és már nem hatékony
A zRAM egy bevált és hatékony módszer az eszközök optimalizálására, a régebbi eszközök - gondoljunk olyan KitKat-alapú eszközökre, amelyek csak körülbelül 512 MB RAM-mal működnek. Az a tény, hogy egyesek még mindig beépítik a zRAM-módosításokat az optimalizálási szkriptekbe, vagy a zRAM-ot valamiféle modern optimalizálási csípésként javasolják, példa arra, hogy az emberek általában nem követik a legújabb operációs protokollokat.
A zRAM belépőszintű, többmagos SoC-khoz készült, például MTK lapkakészleteket és 512 MB RAM-ot használó eszközökhöz. Nagyon olcsó kínai telefonok, alapvetően. A zRAM alapvetően a kernelt választja el a titkosítási folyamon keresztül.
Ha a zRAM-ot régebbi eszközökön használják a egyetlen mag , még akkor is, ha az ilyen eszközökön a zRAM-ot javasoljuk, a késések nagy mennyisége általában növekszik. Ez történik a KSM technológiával is ( Kernel azonos oldal egyesítése) amely azonos memóriaoldalakat ötvöz a szabad hely érdekében. Ezt valójában a Google javasolja, de nagyobb lemaradásokhoz vezet a régebbi eszközöknél, mert az állandóan aktív magfejek folyamatosan futnak a memóriából a duplikált oldalak keresése érdekében. Alapvetően az optimalizálási csípés futtatásával ironikusan tovább lassítja az eszközt.
Seeder - Elavult az Android 3.0 óta
Az egyik legvitatottabb optimalizálási tipp az Android fejlesztői között cédrus , és biztosak vagyunk benne, hogy valaki megpróbálhatja bizonyítani, hogy tévedtünk ebben a témában - de először meg kell vizsgálnunk a vetőgép történetét.
Seeder alkalmazás Androidra
Igen, számos olyan jelentés van, amely jobb telepítést követően deklarálja az Android teljesítményét sokkal régebbi Android-eszközök . Az emberek azonban bármilyen okból úgy gondolják, hogy ez azt jelenti, hogy ez is optimalizálható modern Android-eszközök , ami abszolút abszurd. Az a tény, hogy a Seedert továbbra is karbantartják és „ modern' a lemaradáscsökkentő eszköz a félretájékoztatás példája - bár ez nem a Seeder fejlesztőjének hibája, hiszen még a Play Áruház-oldaluk is megjegyzi, hogy a Seeder kevésbé hatékony az Android 4.0+ után. Mégis bármilyen okból, a Seeder továbbra is felbukkan a modern Android-rendszerek optimalizálási vitáiban.
Amit Seeder alapvetően az Android 3.0-hoz tesz, az egy olyan hiba elhárítása, ahol az Android futásideje aktívan a / dev / random / fájlt használja az entrópia megszerzéséhez. A / dev / random / buffer instabillá válna, és a rendszer blokkolva maradna, amíg meg nem tölti a szükséges mennyiségű adatot - gondolj olyan apróságokra, mint az Android-eszköz különféle érzékelői és gombjai.
Seeder szerzője a Linux-démont vette át rngd , és az Android inastroiljához állították össze, így véletlenszerű adatokat vett fel egy sokkal gyorsabb és kiszámíthatóbb / dev / urandom útvonalról, és egyesíti őket dev / random / másodpercenként, anélkül, hogy a / dev / random / kimerülne. Ez egy olyan Android rendszert eredményezett, amely nem tapasztalta az entrópia hiányát, és sokkal simábban teljesített.
A Google összetörte ezt a hibát az Android 3.0 után, de valamilyen oknál fogva a Seeder még mindig felbukkan „Ajánlott módosítások” listák az Android teljesítmény optimalizálásához. Ezenkívül a Seeder alkalmazásnak van néhány analógja, például a sEFix, amelyek tartalmazzák a Seeder funkcióit, függetlenül attól, hogy ugyanazt használják-e rngd vagy az alternatíva ostromolt , vagy akár csak szimbolikus kapcsolat a / dev / urandom és / dev / random között. Ez abszolút értelmetlen a modern Android rendszerekben.
Az értelmetlenség oka az, hogy az újabb Android verziók a / dev / random / három fő összetevőben használják - libcrypto , SSL-kapcsolatok titkosításához, SSH-kulcsok létrehozásához stb. WPA_supplication / hostapd, amely WEP / WPA kulcsokat generál, és végül egy maroknyi könyvtár az azonosító létrehozásához az EXT2 / EXT3 / EXT4 fájlrendszerek létrehozásakor.
Így amikor Vetőgép vagy a Seeder-alapú fejlesztéseket tartalmazzák a modern Android-optimalizáló szkriptek, ami végül megtörténik, az a degradáció az eszköz teljesítményében, mert rngd folyamatosan felébreszti az eszközt, és megnöveli a CPU frekvenciáját, ami természetesen negatívan befolyásolja az akkumulátor fogyasztását.
Odex
Az Android készülékek állományának firmware-je nagyjából mindig odex. Ez azt jelenti, hogy az APK formátumú Android-alkalmazások szabványos csomagja mellett, amely a / system / app / és / system / priv-app / fájlban található, ugyanazok a fájlnevek vannak a .odex kiterjesztéssel. Az odex fájlok optimalizált bytecode alkalmazásokat tartalmaznak, amelyek már átmentek a validátoron és az optimalizáló virtuális gépen, majd külön fájlba kerültek, például: dexopt eszköz.
Tehát az odex fájlok célja a virtuális gép kitöltése és az odexed alkalmazás gyorsabb elindítása - hátrányosan az ODEX fájlok megakadályozzák a firmware módosítását, és problémákat okoznak a frissítésekkel, ezért sok egyedi ROM-ot, például a LineageOS-t terjesztenek ODEX nélkül .
Az ODEX fájlok generálása számos módon történik, például az Odexer Tool használatával - a probléma az, hogy pusztán placebo hatása. Amikor a modern Android rendszer nem talál odex fájlokat a / system könyvtárban, a rendszer valóban létrehozza őket, és elhelyezi őket a / system / dalvik-cache / könyvtárban. Pontosan ez történik, amikor például egy új Android verziót villant fel, és ez egy ideig a „Foglalt, alkalmazások optimalizálása” üzenetet adja.
Lowmemorykiller csíp
A multitasking az Androidban abban különbözik a többi mobil operációs rendszertől, hogy egy klasszikus modellen alapszik, ahol az alkalmazások csendesen működnek a háttérben, és nincsenek korlátozások a háttéralkalmazások számára ( hacsak nincs megadva a Fejlesztői beállításokban, de ez általában nem ajánlott) - ezenkívül a háttérfuttatásra való áttérés funkcionalitása nem áll le, bár a rendszer fenntartja a jogot a háttéralkalmazások megölésére alacsony memóriahelyzetekben ( lásd ebben a kézikönyvben, hol beszéltünk a lowmemorykillerről és a memórián kívüli gyilkosról) .
Visszatérni a lowmemorykiller Az Android korlátozott memóriamennyiséggel és cserepartíció hiányával folytathatja működését. A felhasználó továbbra is elindíthatja az alkalmazásokat, és válthat közöttük, és a rendszer csendben megöli a fel nem használt háttéralkalmazásokat, hogy megpróbáljon memóriát felszabadítani az aktív feladatokhoz.
Ez nagyon hasznos volt az Android számára az első napokban, bár valamilyen oknál fogva népszerűvé vált feladatölő alkalmazások formájában, amelyek általában inkább károsak, mint előnyösek. A Feladatgyilkos alkalmazások vagy meghatározott időközönként felébrednek, vagy a felhasználó futtatja őket, és úgy tűnik, hogy felszabadítanak nagy mennyiségű RAM-ot, ami pozitívumnak tekinthető - a több szabad RAM gyorsabb eszközt jelent, igaz? Az Android esetében azonban nem ez a helyzet.
Valójában nagy mennyiségű szabad RAM-mal valójában káros lehet készüléke teljesítménye és az akkumulátor élettartama. Amikor az alkalmazásokat az Android RAM-jában tárolják, sokkal könnyebb őket meghívni, elindítani stb. Az Android rendszernek nem kell sok forrást fordítania az alkalmazásra való áttérésre, mert már ott van a memóriában.
Emiatt a feladatölők nem igazán olyan népszerűek, mint egykor, bár az Android kezdők valamilyen oknál fogva továbbra is rájuk támaszkodnak ( információhiány, sajnos) . Sajnos egy új trend váltotta fel a feladatölőket, a trend lowmemorykiller mechanizmus hangolások. Ez lenne például MinFreeManager alkalmazás, és a fő gondolat az, hogy növelje a RAM általános költségét, mielőtt a rendszer megkezdi a háttéralkalmazások megölését.
Így például a standard RAM határokon működik - 4, 8, 12, 24, 32 és 40 Mb, és ha a 40 MB szabad tárterület megtelt, akkor az egyik gyorsítótárazott alkalmazás a memóriába töltődik. de nem fut megszűnik.
Tehát alapvetően az Android mindig legalább 40 MB szabad memóriával rendelkezik, ami elegendő ahhoz, hogy korábban még egy alkalmazást befogadjanak lowmemorykiller megkezdi a tisztítási folyamatot - ami azt jelenti, hogy az Android mindig mindent megtesz a rendelkezésre álló RAM maximális mennyiségének felhasználása érdekében, anélkül, hogy a felhasználói élménybe ütközne.
Sajnos néhány házi készítésű rajongó azt ajánlotta, hogy az értéket emeljék például 100 MB-ra, mielőtt az LMK beindul. Most a felhasználó elveszít RAM (100 - 40 = 60), így ahelyett, hogy ezt a helyet felhasználná háttéralkalmazások tárolására, a rendszer megtartja ezt a memóriamennyiséget ingyenes , abszolút semmi célja.
LKM hangolás hasznos lehet sokkal régebbi, 512 RAM-mal rendelkező eszközökhöz, de már kié ezek? A 2 GB a modern „költségvetési tartomány”, még a 4 GB-os RAM-eszközöket is „középkategóriásnak” tekintik manapság, így az LMK-fejlesztések valóban elavultak és haszontalanok.
I / O csípések
Számos Android-optimalizálási szkriptben gyakran talál olyan csípéseket, amelyek az I / O alrendszert kezelik. Például vessünk egy pillantást a Villámcsapás! Script, amely ezeket a sorokat tartalmazza:
visszhang 0> $ i / sor / rotáció; echo 1024> $ i / queue / nr_requests;
Az első sor az I / O ütemezőnek ad utasításokat az SSD kezeléséhez, a második pedig megnöveli az I / O sor maximális méretét 128-ról 1024-re - mert az $ i változó útvonalat tartalmaz a blokkoló eszközök fájához a / sys, és a szkript ciklusban fut.
Ezt követően talál egy sort, amely a CFQ ütemezőhöz kapcsolódik:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
Ezt követi további sorok, amelyek más tervezőkhöz tartoznak, de végül az első két parancs értelmetlen, mert:
Egy modern Linux kern képes megérteni, hogy milyen típusú adathordozóval működik alapértelmezés szerint.
Hosszú bemeneti-kimeneti sor ( például 1024) használhatatlan egy modern Android-eszközön, valójában értelmetlen még asztali számítógépen is - valójában csak ezen ajánlott nagy teherbírású szerverek . Telefonja nem nagy igénybevételű Linux szerver.
Egy Android-eszköz esetében gyakorlatilag nincsenek a bemenet-kimenet prioritásként kezelt alkalmazások és nincs mechanikus meghajtó, így a legjobb tervező a noop / FIFO-sor, tehát ez a típusú ütemező csípés' nem tesz semmi különöset vagy értelmeset az I / O alrendszerrel szemben. Valójában ezeket a több képernyős lista parancsokat jobb helyettesíteni egy egyszerű ciklussal:
i-re in / sys / blokk / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done
Ez lehetővé tenné a noop ütemező számára az összes meghajtó számára az I / O statisztikák felhalmozását, amelynek pozitív hatással kell lennie a teljesítményre, bár nagyon apró és szinte teljesen elhanyagolható.
Egy másik haszontalan I / O csípés, amelyet gyakran találnak a teljesítményszkriptekben, az SD-kártyák 2MB-ig megnövelt előreolvasási értékei. Az előretekintési mechanizmus a médiából történő korai adatok beolvasására szolgál, mielőtt az alkalmazás hozzáférést kér az adatokhoz. Tehát alapvetően a kernel megpróbálja kitalálni, hogy milyen adatokra lesz szükség a jövőben, és előre betölti a RAM-ba, ami csökkenti a visszatérési időt. Ez papíron jól hangzik, de az előreolvasási algoritmus gyakrabban fordul elő rossz , ami teljesen felesleges bemeneti-kimeneti műveletekhez vezet, nem beszélve a magas RAM-fogyasztásról.
A RAID-tömbökben nagy, 1–8 MB közötti előrejelzési értékek ajánlottak, de Android-eszközök esetében a legjobb, ha csak az alapértelmezett 128 KB-ot hagyja meg.
A virtuális memóriakezelő rendszer módosítja
Egy másik általános „optimalizálási” technika a virtuális memóriakezelő alrendszer hangolása. Ez általában csak két kernelváltozót céloz meg, a vm.dirty_background_ratio és a vm.dirty_ratio, amelyek a puffer méretének beállítására szolgálnak a „piszkos” adatok tárolásához. Piszkos Az adatok általában lemezre írt adatok, de még több van a memóriában, és várakozás merül fel a lemezre.
A virtuális gép-kezelő alrendszer tipikus beállításai a Linux disztribúcióiban és az Androis-ban is a következők:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Tehát ez azt próbálja megtenni, hogy amikor a piszkos adatpuffer a RAM teljes mennyiségének 10% -a, akkor felébred pdflush áramlik, és elkezdi írni az adatokat a lemezre - ha az adatok lemezre történő rögzítése meg fog történni túl intenzív , a puffer tovább növekszik, és amikor eléri a rendelkezésre álló RAM 20% -át, a rendszer szinkron módban - előpuffer nélkül - átáll a későbbi írási műveletre. Ez azt jelenti, hogy a lemezre írás munkája az lesz blokkolva van, amíg az adatok nem lesznek lemezre írva (AKA ’lemaradás’).
Amit meg kell értenie, akkor is, ha a puffer mérete nem éri el a 10% -ot , a rendszer 30 másodperc múlva automatikusan beindul pdflush formátumban. A 10/20 kombinációja meglehetősen ésszerű, például 1 GB RAM-mal rendelkező eszközön ez 100/200 MB RAM-mal egyenlő, ami több mint elegendő a sorozatfelvételi rekordok szempontjából, ahol a sebesség gyakran a NAND rendszer sebességi rekordja alatt van. -memória vagy SD-kártya, például alkalmazások telepítésekor vagy fájlok számítógépről történő másolásakor.
Valamilyen oknál fogva a forgatókönyvírók megpróbálják ezt az értéket még magasabbra, abszurd szintre emelni. Például megtalálhatjuk a Xplix optimalizáló szkript akár 50/90 arányban is.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
1 GB memóriával rendelkező eszközön ez a piszkos puffer korlátját 500/900 MB-ra állítja be, ami teljesen haszontalan egy Android-eszköz esetében, mert csak állandó felvétel a lemezre - ami csak egy nehéz Linux szerveren történik.
Villámcsapás! A szkript ésszerűbb értéket használ, de összességében még mindig meglehetősen értelmetlen:
ha ['$ mem' -lt 524288]; akkor sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; majd 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;
Az első két parancsot 512 MB RAM-mal rendelkező okostelefonokon futtatják, a másodikat - 1 GB-mal, és másokat - több mint 1 GB-mal. De valójában csak egy oka van az alapértelmezett beállítások megváltoztatásának - egy nagyon lassú belső memóriával rendelkező eszköz vagy memóriakártya. Ebben az esetben ésszerű a változók értékeinek elterjesztése, vagyis valami ilyesmi készítése:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Ezután, amikor a túlfeszültségű rendszer műveleteket ír anélkül, hogy adatokat kellene rögzítenie a lemezre, az utolsóig nem vált át szinkron módba, ami lehetővé teszi az alkalmazások számára, hogy csökkentse a késleltetést a felvétel során.
További haszontalan trükkök és teljesítményhangolások
Sokkal több olyan „optimalizálás” létezik, amelyek valójában nem csinálnak semmit. Legtöbbjüknek egyszerűen nincs semmilyen hatása, míg mások javulhatnak néhány a teljesítmény szempontja, miközben más módon rontja az eszközt ( általában a teljesítmény és az akkumulátor lemerülésének szintje) .
Íme néhány további népszerű optimalizálás, amely hasznos lehet vagy nem, az Android rendszertől és eszköztől függően.
- Gyorsulás - A teljesítmény és az aláfeszültség növelése érdekében a kis gyorsulás egy kis akkumulátort takarít meg.
- Adatbázis-optimalizálás - Elméletileg ez kellene javítani az eszköz teljesítményét, de kétséges.
- Zipalign - Ironikus módon annak ellenére, hogy a boltban az Android SDK beépített funkcióinak tartalmi összehangolása az APK-fájlban található, sok szoftvert nem továbbítanak a zipalignon keresztül.
- Tiltsa le a felesleges rendszerszolgáltatásokat, eltávolítva a fel nem használt rendszert és a ritkán használt, harmadik féltől származó alkalmazásokat. Alapvetően a bloatware eltávolítása.
- Egyéni kernel egy adott eszköz optimalizálásával (megint nem minden mag egyformán jó).
- Már leírt I / O ütemező noop.
- Telítettségi algoritmus TCP Westwood - Hatékonyabban használható az alapértelmezett vezeték nélküli hálózatokhoz készült Android Cubic alkalmazásban, egyedi kernelekben elérhető.
Haszontalan beállítások build.prop
Az XDA Developers fórumának LaraCraft304 végzett egy tanulmányt, és megállapította, hogy az AOSP és a CyanogenMod forrásban nem létezik olyan lenyűgöző számú /system/build.prop beállítás, amelyet „szakértőknek” ajánlanak. Itt van a lista:
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. 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_PAD_PRO.Dys.Pod.roCímkék android Fejlődés 12 perc olvasás
