A leggyakoribb Android-optimalizálási mítoszok feloldva

Nagyon sok oktató útmutató található az Android teljesítményének növelésére és az általános optimalizálási tippekre. Néhányuk legitim, mások csak elméletben vagy az Android rendszer elavult működési módszerein alapulnak, vagy egyszerűen ostobaságok. Ez magában foglalja a cserére vonatkozó ajánlásokat, a build.prop hozzáadott értékeket és a Linux kernel változó változásait.

Van még egy csomó „optimalizálási szkript”, mindent egyben villogó .zip, amelyek ígéretezik, hogy jelentősen növelik a teljesítményt, az akkumulátor élettartamát és egyéb dolgokat. Néhány csípés valóban működhet, de a többség egyszerűen placebóhatás, vagy ami még rosszabb, valójában negatív hatással van az eszközére.

Ez nem azt jelenti, hogy az emberek szándékosan bocsátanak ki rosszindulatú szkripteket - határozottan vannak hamis fizetős alkalmazások a Play Áruházban, de az Android fórumokon megjelenő optimalizálási szkriptek általában jó szándékúak, éppen így történik, hogy a fejlesztő tévesen tájékozódik, vagy egyszerűen csak kísérletezzen a különféle optimalizálási paraméterekkel. Sajnos egyfajta hógolyóhatás hajlamos előfordulni, különösen a „minden egyben” optimalizálási szkripteknél. Egy kicsi maroknyi csípés valójában csinál valamit, míg a szkript egy másik csomópontja egyáltalán nem csinál semmit - mégis ezeket a szkripteket varázslatgolyóknak adják át, anélkül, hogy ténylegesen megvizsgálnák, mi működik, és mi nem .

Így sok minden egyben optimalizáló szkript ugyanazokat a módszereket használja, amelyek közül néhány teljesen elavult vagy hosszú távon káros. Összefoglalva: a „minden az egyben” optimalizálási szkriptek többsége nem más, mint az összesített javasolt hangolás, és nincs világos elképzelésük arról, hogy miként és miért működnek ezek az optimalizációk - a felhasználók a szkripteket villogják, és azt állítják, hogy teljesítésük hirtelen gyorsabb ( amikor valójában valószínűleg az eszköz újraindításának nagyon egyszerű cselekedete okozta a teljesítménynövekedést, mivel az eszköz RAM-ban minden megtisztul) .

Ebben az Appuals exkluzív cikkben kiemezzük az Android teljesítmény optimalizálásának leggyakoribb ajánlásait, valamint azt, hogy ezek egyszerűen mítosz vagy törvényes csípések az eszköz teljesítményére.

Csere

A mítoszok listájának tetején található az Android csere - ami elég abszurd abban az értelemben, hogy Android optimalizálásnak tekintik. A csereügyletek fő célja a lapozófájl létrehozása és csatlakoztatása, amely felszabadítja a memória tárhelyét. Ez ésszerűnek tűnik papíron, de igazán alkalmazható egy olyan kiszolgálóra, amelynek szinte nincs interaktivitása.

Ha rendszeresen használja az Android telefon csereprogramját, akkor súlyos késésekhez vezet, amelyek abból adódnak, hogy a dolgok elcsúsznak a gyorsítótáron. Képzelje el például, ha egy alkalmazás megkísérel megjeleníteni egy grafikát, amelyet a csere tárol, amelynek most a lemez felszabadítása után újra kell töltenie a lemezt, az adatcserét egy másik alkalmazásba helyezve. Nagyon rendetlen.

Néhány optimalizálási rajongó azt mondhatja, hogy a csere nem okoz problémát, de nem az, hogy a teljesítmény növelése érdekében csere történjen - ez a beépített Android mechanizmus lowmemorykiller, amely rendszeresen megsemmisíti a felfúvódott, kiemelkedően fontos folyamatokat, amelyeket még nem használnak. Az LMK-t kifejezetten az alacsony memóriahelyzet kezelésére fejlesztették ki, a kswapd folyamatból indítják el, és általában megöli a felhasználói terület folyamatait. Ez különbözik az OOMkiller-től (memórián kívüli gyilkos), de ez egészen más téma.

A lényeg az, hogy egy eszköz, például 1 GB RAM-mal, soha nem érheti el a szükséges teljesítményadatokat csere közben, és így a csere feltétlenül nincs szükség az Android-ra. Végrehajtása egyszerűen elhalasztott, és a teljesítmény romlása helyett optimalizálja.

zRAM - elavult és már nem hatékony

A zRAM bevált és hatékony módszer az eszközoptimalizáláshoz, régebbi eszközöknél - gondoljon KitKat-alapú eszközökre, amelyek mindössze 512 MB RAM-mal működnek. Az a tény, hogy egyes emberek továbbra is tartalmazzák a zRAM-illesztéseket az optimalizálási szkriptekben, vagy a zRAM-ot valamilyen modern optimalizálási csípésként ajánlja, példa arra, hogy az emberek általában nem követik a legújabb működési protokollokat.

A zRAM-ot a belépő szintű, költségvetési tartományú, többmagos SoC-k számára tervezték, például olyan eszközök számára, amelyek MTK chipkészleteket és 512 MB RAM-ot használnak. Nagyon olcsó kínai telefonok, alapvetően. Amit a zRAM gyakorlatilag elválaszt, a kernelt elválasztja a titkosítási patakon keresztül.

Ha a zRAM-ot egymagos régebbi eszközökön használják, akkor is, ha a zRAM-ot ilyen eszközökön ajánlják, nagy mennyiségű késés hajlamos felbukkanni. Ugyanez történik a KSM technológiával ( Kernel Same Page Merging), amely egyesíti az azonos memória oldalakat, hogy szabad helyet biztosítson. Ezt valójában a Google ajánlja, de nagyobb késésekhez vezet a régebbi eszközöknél, mivel az állandóan aktív központi mozdulatok folyamatosan futnak a memóriából az ismétlődő oldalak kereséséhez. Alapvetően az optimalizálási csípés megkísérlése még ironikusan tovább lassítja az eszközt.

Vetőgép - elavult az Android 3.0 óta

Az egyik legvitatottabb optimalizálási tipp az Android készülékek között a vetőgép, és biztosak vagyunk benne, hogy valaki megpróbálhatja bebizonyí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.

Igen, sok olyan jelentés jelent, amely jobb Android teljesítményt deklarál a sokkal régebbi Android készülékekre történő telepítés után. Az emberek bármi okból úgy vélik, ez azt jelenti, hogy ez a modern Android eszközökre is alkalmazható optimalizálás, ami teljesen abszurd. Az a tény, hogy a Seedert továbbra is karbantartják és „ modern” késéscsökkentő eszközként kínálják, példa a téves információkra - bár ez nem a Seeder fejlesztõjének hibája, mivel még a Play Áruház oldaluk is rámutat arra, hogy a Seeder kevésbé hatékony az Android 4.0+ után. Mégis, bármilyen okból is, Seeder továbbra is felbukkan a modern Android rendszerek optimalizálási vitáin.

Amit Seeder alapvetően az Android 3.0-ra teszi, az egy olyan hibával foglalkozik, ahol az Android futásideje aktívan használja a / dev / random / fájlt az entrópia megszerzéséhez. A / dev / random / buffer instabillá válna, és a rendszert addig blokkolnák, amíg kitölti a szükséges adatmennyiséget - gondoljon olyan apró dolgokra, mint az Android készülék különféle érzékelői és gombjai.

Seeder szerzője elvette a Linux-demon rngd programot, és az Android inastroiljára fordította össze, hogy véletlenszerű adatokat vegyen egy sokkal gyorsabb és kiszámíthatóbb / dev / urandom útvonaltól, és egyesíti őket dev / véletlen / minden másodpercig, anélkül, hogy / dev / random / kimerülni. Ennek eredményeként olyan Android rendszer alakult ki, amelyben nem volt tapasztalható az entrópia hiánya, és sokkal simábban teljesített.

A Google az Android 3.0 után elrontotta ezt a hibát, bár valamilyen okból a Seeder továbbra is megjelenik az „ajánlott csípések” listáin az Android teljesítményének optimalizálása érdekében. Ezenkívül a Seeder alkalmazásnak van néhány analógja, például az sEFix, amelyek tartalmazzák a Seeder funkcionalitását, akár ugyanazt az rngd-t, akár az alternatív hasged-et használják, vagy akár csak egy linket a / dev / urandom és a / dev / random között. Ez teljesen értelmetlen a modern Android rendszereknél.

Ennek oka értelmetlen azért, mert az újabb Android verziók a / dev / random / három fő összetevőben használják - libcrypto, az SSL kapcsolatok titkosításához, az SSH kulcsok előállításához stb. könyvtárak azonosító generálására EXT2 / EXT3 / EXT4 fájlrendszerek létrehozásakor.

Tehát, amikor a Seeder vagy a Seeder-alapú fejlesztéseket beépítik a modern Android optimalizálási szkriptekbe, akkor az végül az eszköz teljesítményének romlásával jár, mivel az rngd folyamatosan felébreszti a készüléket, és növeli a processzor frekvenciáját, ami természetesen negatívan befolyásolja az akkumulátor fogyasztását .

ODEX

Az Android készülékek alapvető firmware-je általában mindig odex. Ez azt jelenti, hogy az Android alkalmazásoknak az APK formátumú szokásos csomagja mellett, amelyek a / system / app / és / system / priv-app / mappában találhatók, ugyanazok a fájlnevek a .odex kiterjesztéssel. Az Odex fájlok tartalmaznak olyan optimalizált bájtkód-alkalmazásokat, amelyek már átmentek az érvényesítőn és az optimalizáló virtuális gépen, majd külön fájlba rögzítették, például a dexopt eszköz használatával.

Tehát az odex fájlok célja a virtuális gép letöltése és az odexed alkalmazás gyorsabb elindítása - 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 , ODEX .

Az ODEX fájlok létrehozása többféle módon történik, például az Odexer Tool használatával - a probléma az, hogy pusztán placebo hatása van. Amikor a modern Android rendszer nem talál odex fájlokat a / system könyvtárban, a rendszer valójában létrehozza azokat és a / system / dalvik-cache / könyvtárba helyezi őket. Pontosan ez történik, amikor például egy új Android verziót villog, és egy ideig a „Foglalt, az alkalmazások optimalizálása” üzenet jelenik meg.

Az Lowmemorykiller megkönnyíti

Az Android multitasking különbözik a többi mobil operációs rendszertől abban az értelemben, hogy egy klasszikus modellre épül, ahol az alkalmazások csendesen működnek a háttérben, és nincs korlátozás a háttér alkalmazások számára ( kivéve, ha az egyik a fejlesztői beállításokban van beállítva, de ez az általánosságban javasolt ellen) - továbbá a háttér végrehajtására való áttérés funkcionalitása nem áll meg, bár a rendszer fenntartja a jogot a háttér-alkalmazások megsemmisítésére alacsony memóriahelyzetekben ( lásd itt, ahol korábban beszéltünk az lowmemorykiller-ről és a memórián kívüli gyilkosról) útmutató) .

Visszatérve az lowmemorykiller mechanizmushoz, az Android továbbra is korlátozott memóriamennyiséggel és a cserepartíció hiánya mellett működhet. A felhasználó folytathatja az alkalmazások elindítását és közöttük váltást, és a rendszer csendben megsemmisíti a nem használt háttér-alkalmazásokat, hogy megpróbálja felszabadítani a memóriát az aktív feladatok elvégzéséhez.

Ez a korai napokban nagyon hasznos volt az Android számára, bár valamilyen okból népszerűvé vált feladat-gyilkos alkalmazások formájában, amelyek általában ártalmasabbak, mint hasznosak. A feladat-gyilkos alkalmazások vagy meghatározott időközönként felébrednek, vagy a felhasználó futtatja őket, és úgy tűnik, hogy nagy mennyiségű RAM-ot szabadít fel, ami pozitívnak tekinthető - a több szabad RAM gyorsabb eszközt jelent, igaz? Ugyanakkor ez nem igaz az Android esetében.

Valójában, ha nagy mennyiségű szabad RAM van, ártalmas lehet az eszköz teljesítményére és az akkumulátor élettartamára. Ha az alkalmazásokat az Android RAM-ban tárolja, sokkal könnyebb őket felhívni, elindítani stb. Az Android rendszernek nem kell sok erőforrást fordítania az alkalmazásra való váltáshoz, mert az már a memóriában található.

Emiatt a feladat-gyilkosok nem igazán olyan népszerűek, mint korábban, bár az Android kezdők valamilyen oknál fogva továbbra is számítanak rájuk ( sajnos sajnos nincs információ) . Sajnos egy új trend váltotta fel a feladat-gyilkosokat, az alacsony memória -gyilkos mechanizmus hangolásának tendenciáját. Ez lehet például a MinFreeManager alkalmazás, és a legfontosabb ötlet az, hogy növeljék a RAM-ot, mielőtt a rendszer megkezdi a háttér-alkalmazások elpusztítását.

Tehát például a szokásos RAM RAM a 4, 8, 12, 24, 32 és 40 Mb határokon működik, és amikor a 40 MB szabad tárhely megtelik, az egyik gyorsítótárazott alkalmazás a memóriába kerül, de nem fut megszűnik.

Tehát alapvetően az Androidnak mindig legalább 40 MB szabad memóriája lesz, ami elegendő egy további alkalmazás elhelyezéséhez, mielőtt az lowmemorykiller megkezdi a tisztítási folyamatot - ami azt jelenti, hogy az Android mindig megtesz minden tőle telhetőt, hogy a rendelkezésre álló RAM maximális mennyiségét felhasználja anélkül, hogy zavarná a felhasználói tapasztalat.

Sajnos néhány homebrew rajongó azt javasolta, hogy az értéket például 100 MB-ra emeljék, mielőtt az LMK elindul. Most a felhasználó valójában RAM-ot veszít (100 - 40 = 60), tehát ahelyett, hogy ezt a helyet felhasználná a back- végén az alkalmazások, a rendszer mentesíti ezt a memóriamennyiséget, anélkül, hogy erre a célra lenne szüksége.

Az LKM hangolás hasznos lehet sokkal régebbi, 512 RAM memóriatartalmú készülékeknél, de ki a birtokolja ezeket? A 2 GB a modern „költségkeret-tartomány”, még a 4 GB-os RAM eszközöket manapság „közepes hatótávolságúnak” tekintik, tehát az LMK javításai elavultak és haszontalanok.

I / O csíp

Az Android sok optimalizáló szkriptjében gyakran találnak olyan csípeket, amelyek az I / O alrendszerre vonatkoznak. Vessen egy pillantást például a ThunderBolt-ra! Szkript, amely ezeket a sorokat tartalmazza:

 visszhang 0> $ i / sor / forgatás; echo 1024> $ i / sor / nr_requests; 

Az első sor megadja az I / O ütemező utasításokat az SSD kezelésekor, a második pedig növeli az I / O sor maximális méretét 128-ról 1024-re - mert az $ i változó a blokk eszközök fájához vezető utat tartalmaz a / sys, és a szkript hurokban fut.

Ezt követően egy sort talál a CFQ ütemezővel kapcsolatban:

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

Ezt további sorok követik, amelyek a többi tervezőhöz tartoznak, de végül az első két parancs értelmetlen, mert:

A modern Linux kernel alapértelmezés szerint képes megérteni, hogy milyen típusú adathordozóval működik.

A hosszú bemeneti-kimeneti sor ( mint például az 1024) haszontalan egy modern Android-eszközön, valójában értelmetlen még az asztalon is - valójában csak nagy teljesítményű szervereknél ajánlott. A telefon nem nehéz Linux szerver.

Android-eszközöknél gyakorlatilag nincs olyan alkalmazás, amely a bemeneti-kimeneti prioritást élvez, és nincs mechanikus meghajtó, tehát a legjobb tervező a noop / FIFO-sor, tehát az ilyen ütemező típusú „ csípés” nem tesz semmi különlegeset vagy értelmet a I / O alrendszer. Valójában ezeket a többképernyős lista parancsokat jobban helyettesíti egy egyszerű ciklus:

 i-re a / sys / block / mmc * -ben; echo noop> $ i / sor / ütemező visszhang 0> $ i / sor / iostats kész 

Ez lehetővé tenné a noop ütemezőt az összes meghajtó számára az I / O statisztikák felhalmozódása után, 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ény-parancsfájlokban, az SD-kártyák megnövelt olvasási értékei, 2 MB-ig. Az előreolvasási mechanizmus a korai adatolvasást jelenti a médiábó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, milyen adatokra lesz szükség a jövőben, és előzetesen betölti azokat a RAM-ba, ezáltal csökkenti a visszatérési időt. Ez nagyszerűen hangzik a papíron, de az előreolvasási algoritmus gyakran rossz, ami az input-output teljesen felesleges műveleteihez vezet, nem is beszélve a nagy RAM-fogyasztásról.

A RAID-tömbökben ajánlott magas, 1-8 MB közötti előreolvasási érték, de Android-eszközök esetében a legjobb, ha az alapértelmezett 128 KB értéket hagyja.

A virtuális memóriakezelő rendszer csíp

Egy másik általános „optimalizálási” módszer a virtuális memóriakezelő alrendszer hangolása. Ez jellemzően csak két kernelváltozót céloz meg, a vm.dirty_background_ratio és a vm.dirty_ratio, amelyek a „piszkos” adatok tárolására szolgáló puffer méretének beállítására szolgálnak. A piszkos adatok általában olyan adatok, amelyeket lemezre írtak, de még sok más van a memóriában, és várnak a lemezre írásra.

A virtuális gépkezelő alrendszerre jellemző tipikus csípési értékek mind a Linux disztrójában, mind az Androis-ban:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Tehát ezt megpróbálja megtenni, hogy amikor a piszkos adatpuffer a teljes RAM 10% -át teszi ki, felébreszti a pdflush flow-t és elkezdi az adatok írását a lemezre - ha a lemezre történő adatgyűjtés túl intenzív lesz, a puffer tovább növekszik, és amikor eléri a rendelkezésre álló RAM 20% -át, a rendszer szinkron módban átvált a következő írási műveletre - előpuffer nélkül. Ez azt jelenti, hogy a lemezre történő alkalmazás írása blokkolva lesz , amíg az adatokat a lemezre nem írják (AKA 'lag').

Amit meg kell értenie, hogy még akkor is, ha a pufferméret nem éri el a 10% -ot, a rendszer automatikusan pdflush formátumban indul el 30 másodperc múlva. A 10/20 kombinációja elég ésszerű, például 1 GB RAM-mal rendelkező eszköznél ez megegyezik a 100/200 MB RAM-mal, ami elegendő a sorozatrekordok tekintetében, ahol a sebesség gyakran alacsonyabb a NAND rendszer sebességrekordja alatt -memória vagy SD-kártya, például alkalmazások telepítésekor vagy fájlok számítógépről másolásakor.

Valamilyen okból a forgatókönyvírók megpróbálják ezt az értéket még magasabbra tenni, az abszurd ráta felé. Például az Xplix optimalizálási szkriptben 50/90-es arányt találhatunk.

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

Az 1 GB memóriájú készüléken ez a piszkos puffer korlátozását 500/900 MB-ra állítja, ami egy Android-eszköz számára teljesen haszontalan, mert csak a lemezen történő folyamatos felvétel mellett működne - ami csak nehéz Linux szerver.

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 parancs okostelefonokon fut, 512 MB RAM-mal, a második - 1 GB-val, és mások - több, mint 1 GB-val. De valójában csak egy ok van az alapértelmezett beállítások megváltoztatására - egy nagyon lassú belső memóriával vagy memóriakártyával rendelkező eszköz. Ebben az esetben indokolt a változók értékeinek eloszlása, vagyis az alábbiak elké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 lemezen, az utolsóig nem vált át szinkron módra, amely lehetővé teszi az alkalmazások számára, hogy csökkentsék a késést rögzítéskor.

További haszontalan javítások és teljesítmény-hangolások

Sokkal több „optimalizálás” van ott, amelyek valójában nem tesznek semmit. Legtöbbjüknek egyszerűen nincs semmilyen hatása, míg mások javíthatják a teljesítmény bizonyos aspektusait, miközben más módon rontják az eszközt ( általában teljesítményre vagy akkumulátor lemerülésre vezet) .

Itt található néhány további népszerű optimalizálás, amelyek az Android rendszertől és az eszköztől függően hasznosak lehetnek, vagy nem.

• Gyorsulás - A kis gyorsulás a teljesítmény és az alulteljesítmény javítása érdekében - kis energiát takarít meg.
• Adatbázis-optimalizálás - Elméletileg ez javíthatja az eszköz teljesítményét, de kétséges.
• Zipalign - Ironikus módon, annak ellenére, hogy a beépített Android SDK szolgáltatás tartalmi igazítása az üzletben lévő APK-fájlban sokféle szoftvert nem továbbít a zipalignon keresztül.
• Kapcsolja ki a felesleges rendszerszolgáltatásokat, eltávolítva a 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 (ismét, nem mindenmag egyformán jó).
• A már leírt I / O ütemező noop.
• Telítési algoritmus TCP Westwood - Hatékonyabban használható az alapértelmezett Android Cubicban vezeték nélküli hálózatokhoz, elérhető az egyéni magokban.

Hasznos beállítások build.prop

Az XDA Developers fórumából származó LaraCraft304 tanulmányt készített és megállapította, hogy a „szakértők” számára ajánlott /system/build.prop beállítások lenyűgöző száma nem létezik az AOSP és a CyanogenMod forrásban. 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_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.perfor performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt eADIST.sys.shutPPHJJAP.sys.shut