Enamlevinud Android-i optimeerimise müüdid on lahti ühendatud

Seal on palju juhendavaid juhendeid, mis on pühendatud Androidi jõudluse suurendamisele ja üldistele optimeerimisnõuannetele. Mõned neist on õigustatud ja teised põhinevad ainult teoorias või Androidi süsteemis vananenud töömeetoditel või on lihtsalt jama. See sisaldab soovitusi vahetamiseks, build.propile lisatud väärtusi ja Linuxi kerneli muutuvaid muudatusi.

Seal on isegi palju "optimeerimisskripte", kõik-ühes vilkuvad .zipid, mis tõotavad märkimisväärselt suurendada jõudlust, aku vastupidavust ja muid asju. Mõned näpunäited võivad tegelikult töötada, kuid enamus neist on lihtsalt platseeboefekt või, mis veelgi hullem, avaldab teie seadmele negatiivset mõju.

See ei tähenda, et inimesed vabastavad tahtmatuid skripte - Play poes on kindlasti võltsitud tasulisi rakendusi, kuid Androidi foorumites avaldatud optimeerimisskriptid on üldiselt heatahtlikud, lihtsalt juhtub, et arendajat on valesti teavitatud, või lihtsalt katsetades mitmesuguseid optimeerimise näpunäiteid. Kahjuks kipub tekkima omamoodi lumepalliefekt, eriti “kõik ühes” optimeerimisskriptide korral. Väike käputäis parandusi võib tegelikult midagi ära teha, samas kui mõni teine ​​skripti paranduste komplekt ei saa absoluutselt mitte midagi teha - ometi antakse need skriptid maagiatäppideks, ilma et oleks uuritud, mis töötab ja mis mitte. .

Seega kasutavad paljud kõik ühes optimeerimise skriptid samu meetodeid, millest mõned on pikemas perspektiivis täiesti vananenud või kahjulikud. Kokkuvõtlikult võib öelda, et suurem osa kõik-ühes optimeerimise skriptidest on midagi muud kui lihtsalt kokku pakutud häälestused, millel puudub selge ettekujutus, kuidas või miks need optimeerimised toimivad - kasutajad vilgutavad skripte ja väidavad, et nende jõudlus on äkki kiirem ( kui tegelikult põhjustas jõudluse suurenemine tõenäoliselt seadme seadme taaskäivitamise väga lihtne toiming, kuna kõik seadme RAM-is saavad kõik puhtaks) .

Selles Appualsi eksklusiivses artiklis toome välja mõned levinumad soovitused Androidi toimivuse optimeerimiseks ja kas need on lihtsalt müüt või seadise toimimise õigustatud näpunäide.

Vaheta

Müütide nimekirja tipus on Androidi vahetus - mis on üsna absurdne, kui mõelda sellele kui Androidi optimeerimisele. Vahetustehingute peamine eesmärk on luua ja ühendada otsingufail, mis vabastab mäluruumi. See kõlab paberil mõistlikult, kuid on tõesti rakendatav serveris, millel pole peaaegu üldse interaktiivsust.

Kui kasutate oma Android-telefoni vahetusteenust regulaarselt, põhjustab see vahemälust mööda libisevate asjade tagajärjel tõsiseid mahajäämusi. Kujutage näiteks ette, kui rakendus proovib kuvada vahetustehingus salvestatud graafikat, mis peab nüüd pärast ruumi vabastamist ketast uuesti laadima, pannes andmevahetuse teise rakendusega. See on tõesti räpane.

Mõned optimeerimisega seotud entusiastid võivad öelda, et vahetus ei tekitanud probleeme, kuid see ei muuda jõudlust veelgi - see on sisseehitatud Androidi mehhanism lowmemorykiller, mis regulaarselt tapab ülespuhutud ja ülitähtsad protsessid, mida ei kasutata. LMK oli loodud spetsiaalselt vähese mäluga tingimuste haldamiseks, see kutsutakse esile kswapdi protsessist ja üldiselt tapab kasutajaruumi protsessid. See erineb OOMkillerist (mäluväline tapja), kuid see on hoopis teine ​​teema.

Asi on selles, et näiteks 1 GB muutmäluga seade ei saa kunagi vahetusmenüüni jõudmiseks vajalikele jõudlusandmetele jõuda ja seega pole vahetus Androidis absoluutselt vajalik. Selle rakendamine on lihtsalt puudulik ja põhjustab optimeerimise asemel toimimise halvenemist .

zRAM - aegunud ja pole enam efektiivne

zRAM on tõestatud ja tõhus meetod seadme optimeerimiseks vanematele seadmetele - mõelge KitKat-põhistele seadmetele, mis töötavad ainult umbes 512 MB RAM-iga. Fakt, et mõned inimesed lisavad endiselt optimeerimisskriptidesse zRAM-i parandusi või soovitavad zRAM-i kui tänapäevast optimeerimise näpunäidet, on näide inimestest, kes üldiselt ei järgi uusimaid tööprotokolle.

zRAM oli ette nähtud algtaseme eelarvevahemiku mitmetuumaliste soC-de jaoks, nagu näiteks seadmed, mis kasutavad MTK kiibikomplekte ja 512 MB muutmälu. Väga odavad Hiina telefonid, põhimõtteliselt. See, mida zRAM põhimõtteliselt teeb, on tuuma eraldamine krüptimisvoo kaudu.

Kui zRAM-i kasutatakse ühetuumalistes vanemates seadmetes, isegi kui sellistes seadmetes soovitatakse zRAM-i, kipuvad suured kogused viivitusi kerkima. See juhtub ka KSM-tehnoloogiaga ( Kernel Same Page Merging), mis ühendab identsed mälulehed pakkumisega vaba ruumi saamiseks. Seda soovitab Google tegelikult, kuid see põhjustab vanemates seadmetes suuremat mahajäämust, sest pidevalt aktiivsed tuumad on pidevalt mälust, et otsida dubleerivaid lehti. Põhimõtteliselt aeglustab optimeerimise näpistamise käivitamine seadet veelgi irooniliselt.

Seeder - aegunud alates Android 3.0

Üks Android-versioonides kõige rohkem arutatud optimeerimisnõuandeid on külvimasin ja oleme kindlad, et keegi võib proovida tõestada, et oleme sellel teemal eksinud - kuid kõigepealt peame uurima külvimasina ajalugu.

Seederirakendus Androidi jaoks

Jah, seal on palju aruandeid, mis kuulutavad Androidi paremat toimivust pärast palju vanematesse Android-seadmetesse installimist. Inimesed usuvad, et see mingil põhjusel tähendab ka kaasaegsete Android-seadmete optimeerimist, mis on absurdne. See, et Seederit endiselt hooldatakse ja pakutakse „ moodsa” viivituse vähendamise tööriistana, on valeinformatsiooni näide - ehkki see pole Seederi arendaja süü, sest isegi nende Play poe leht märgib, et Seeder on vähem efektiivne pärast Android 4.0+. Kuid mis tahes põhjusel hüppab Seeder endiselt kaasaegsete Androidi süsteemide optimeerimise aruteludesse.

See, mida Seeder Android 3.0 jaoks põhimõtteliselt teeb, on vea aadress, kus Androidi käitusaeg kasutaks entroopia saamiseks aktiivselt faili / dev / random / file. Puhver / dev / juhuslik / puhver muutuks ebastabiilseks ja süsteem blokeeritaks, kuni see täidab vajaliku hulga andmeid - mõelge sellistele asjadele nagu Androidi seadme erinevad andurid ja nupud.

Seederi autor võttis Linuxi-deemoni rngd ja koostas Androidi inastroili jaoks nii, et see võttis juhuslikud andmed palju kiiremini ja paremini ennustatava / dev / urandom raja pealt ja liidab need dev / juhuslikuks / igaks sekundiks, lubamata / dev / random / kurnata. Selle tulemuseks oli Androidi süsteem, mis ei kogenud entroopia puudumist ja toimis palju sujuvamalt.

Google hävitas selle vea pärast Android 3.0, kuid hüppab Seeder mingil põhjusel endiselt Androidi jõudluse optimeerimise soovituslike loendite nimekirja. Lisaks on Seederi rakendusel vähe analooge, näiteks sEFix, mis hõlmavad Seederi funktsionaalsust, kas siis sama rngd või alternatiivse koosseisuga või isegi lihtsalt linkide / dev / urandom ja / dev / random vahel. See on tänapäevaste Androidi süsteemide jaoks täiesti mõttetu.

Selle mõttetu põhjus on asjaolu, et uuemates Androidi versioonides kasutatakse / dev / random / kolme peamist komponenti - libcrypto, SSL-ühenduste krüptimiseks, SSH-võtmete genereerimiseks jne. WPA_supplication / hostapd, mis genereerib WEP / WPA-võtmeid ja lõpuks käputäis teegid ID genereerimiseks failisüsteemide EXT2 / EXT3 / EXT4 loomisel.

Nii et kui tänapäevaste Androidi optimeerimisskriptide hulka on lisatud Seeder või Seederil põhinevad lisaseadmed, on seadme jõudluse halvenemine see, mis juhtub, kuna rngd ärkab seadet pidevalt ja põhjustab protsessori sageduse suurenemist, mis muidugi mõjutab negatiivselt aku tarbimist .

Odex

Androidi seadmetes olev aktsia püsivara on enamasti alati odex. See tähendab, et lisaks APK-vormingus Androidi rakenduste standardkomplektile, mis asuvad kataloogides / system / app / ja / system / priv-app /, on samad failinimed laiendiga .odex. Odex-failid sisaldavad optimeeritud baidikoodirakendusi, mis on juba läbinud valideerija ja optimeerija virtuaalse masina, seejärel registreeritakse need eraldi failina, kasutades näiteks dexopti tööriista.

Nii et odex-failid on mõeldud virtuaalse masina laadimiseks ja odexed-i rakenduse kiiremaks käivitamiseks - negatiivsed küljed takistavad ODEX-failid püsivara muutmist ja tekitavad probleeme värskendustega, seetõttu levitatakse sel põhjusel paljusid kohandatud ROM-e, nagu LineageOS, ilma ODEX .

ODEX-failide genereerimine toimub mitmel viisil, näiteks kasutades Odexeri tööriista - probleem on selles, et selle puhtal kujul on platseeboefekt. Kui tänapäevane Androidi süsteem ei leia kataloogist / system odex-faile, loob süsteem need tegelikult ja paigutab need kataloogi / system / dalvik-cache /. Täpselt see juhtub siis, kui näiteks vilkute uut Androidi versiooni ja see annab mõneks ajaks teate “Kinni, rakenduste optimeerimine”.

Lowmemorykilleri tweaks

Androidi multitegumtöötlus erineb muudest mobiilsetest opsüsteemidest selles mõttes, et see põhineb klassikalisel mudelil, kus rakendused töötavad vaikselt taustal ja taustrakenduste arvule pole piiranguid ( kui üks pole arendaja suvandites seatud, kuid see on üldiselt soovitatakse mitte) - peale selle ei peatata tausttäitmisele ülemineku funktsionaalsust, ehkki süsteem jätab endale õiguse tappatapirakendused vähese mäluga olukordades ( vaata, kus me siin varem rääkisime lowmemorykilleri ja mäluvälise tapja kohta) juhend) .

Naastes mälumõõtja mehhanismi juurde, saab Android jätkata piiratud mälumahu ja vahetuspartitsiooni puudumisega tööd. Kasutaja saab jätkata rakenduste käivitamist ja nende vahel vahetamist ning süsteem tapab vaikides kasutamata taustarakendused, et proovida aktiivsete toimingute jaoks mälu vabastada.

See oli Androidi jaoks algusest peale ülimalt kasulik, ehkki mingil põhjusel on see populaarseks saanud tööülesannete täitmise rakenduste kujul, mis on üldiselt kahjulikum kui kasulik. Task-killer rakendused kas ärkavad kindla intervalliga või käivitavad kasutaja ja näivad vabastavat suures koguses RAM-i, mida peetakse positiivseks - rohkem vaba RAM-i tähendab kiiremat seadet, eks? Androidi puhul pole see aga päris nii.

Tegelikult võib suure hulga vaba RAM-i olemasolu kahjustada teie seadme jõudlust ja aku vastupidavust. Kui rakendused salvestatakse Androidi RAM-i, on neid palju lihtsam helistada, käivitada jne. Androidi süsteem ei pea rakendusele lülitumiseks palju ressursse pühendama, kuna see on juba mälus.

Seetõttu pole ülesandemõrvarid tegelikult nii populaarsed kui kunagi varem, kuigi Androidi algajad kipuvad neile mingil põhjusel ikkagi tuginema ( kahjuks teabe puudus) . Kahjuks on taskumõrvad asendanud uus trend - madala mälumänguri mehhanismide häälestamise trend. See oleks näiteks MinFreeManageri rakendus ja peamine mõte on suurendada RAM-i üldkulusid enne, kui süsteem hakkab taustarakendusi tapma.

Näiteks töötab tavaline RAM piiridel - 4, 8, 12, 24, 32 ja 40 MB ning kui 40 MB vaba salvestusruum on täidetud, on üks vahemällu salvestatud rakendus, mis laaditakse mällu, kuid ei tööta lõpetatakse.

Nii et põhimõtteliselt on Androidil alati vähemalt 40 MB vaba mälu, millest piisab veel ühe rakenduse mahutamiseks enne, kui lowmemorykiller oma puhastusprotsessi alustab - see tähendab, et Android teeb alati oma parima, et kasutada maksimaalset saadaolevat RAM-i, ilma et peaksite segama kasutaja kogemus.

Kahjuks soovitas mõni koduabilise harrastaja tõsta väärtust näiteks 100 MB-ni enne LMK sisselülitamist. Nüüd kaotab kasutaja tegelikult RAM-i (100–40 = 60), nii et selle asemel, et seda ruumi kasutada tagasi- lõpprakenduste jaoks, hoiab süsteem selle mälumahu vaba, ilma et sellel oleks mingit eesmärki.

LKM-häälestamine võib olla kasulik palju vanematele seadmetele, millel on 512 RAM-i, kuid kellele need enam kuuluvad? 2 GB on tänapäevane „eelarvevahemik”, isegi 4 GB RAM-seadmed näevad tänapäeval olevat „keskmise ulatusega”, seega on LMK näpunäited tõesti aegunud ja kasutud.

I / O tweaks

Paljudes Androidi optimeerimisskriptides leiate sageli näpunäiteid, mis käsitlevad I / O alamsüsteemi. Vaatame näiteks ThunderBolt! Skript, mis sisaldab neid ridu:

 kaja 0> $ i / järjekord / pöörlemine; kaja 1024> $ i / järjekord / nr_taotlused; 

Esimene rida annab I / O-ajastaja juhiseid SSD-ga tegelemisel ja teine ​​suurendab I / O-järjekorra maksimaalset suurust 128-lt 1024-le - kuna muutuja $ i sisaldab tee blokeerimisseadmete puu juurde / sys ja skript töötab silmusena.

Pärast seda leiate rea, mis on seotud CFQ ajakavaga:

 kaja 1> $ i / järjekord / iosched / back_seek_penalty; kaja 1> $ i / järjekord / iosched / low_latency; kaja 1> $ i / järjekord / iosched / slice_idle; 

Sellele järgneb veel rida, mis kuuluvad teistele kavandajatele, kuid kokkuvõttes on kaks esimest käsku mõttetud, kuna:

Kaasaegne Linuxi kernel suudab vaikimisi mõista, millist tüüpi andmekandjal see töötab.

Pikk sisend-väljundijärjekord ( näiteks 1024) on tänapäevases Androidi seadmes kasutu, tegelikult mõttetu isegi töölaual - seda soovitatakse tõesti ainult raskeveokite serverites . Teie telefon pole raskeveokite Linuxi server.

Androidi seadme jaoks pole sisend-väljundis tähtsuse järjekorda seatud rakendusi ega mehaanilist draiverit, seega on parim planeerija noop / FIFO-järjekord, seega ei tee seda tüüpi ajastaja “ näpistama” midagi erilist ega tähenduslikku I / O alamsüsteem. Tegelikult on kõik need mitme ekraaniga loendi käsud parem asendada lihtsa tsükliga:

 i jaoks sisendis / sys / block / mmc *; kas kajaloop> $ i / järjekord / planeerija kaja 0> $ i / järjekord / iostats tehtud 

See võimaldaks sisend / väljundistatistika kogunemisel kõigi draivide jaoks noop planeerijat, mis peaks toimivusele positiivset mõju avaldama, ehkki väga pisike ja peaaegu täiesti tühine.

Veel üks kasutu sisend- ja väljundnäpistamine, mida sageli skriptides leidub, on SD-kaartide suurenenud lugemisväärtused kuni 2 MB. Loendurmehhanism on varajane meediumist andmete lugemine, enne kui rakendus taotleb juurdepääsu nendele andmetele. Põhimõtteliselt proovib kernel välja mõelda, milliseid andmeid tulevikus vaja läheb, ja eellaadib selle RAM-i, mis peaks seega tagastamise aega vähendama. See kõlab paberil suurepäraselt, kuid ettelugemise algoritm on sagedamini vale, mis põhjustab sisend-väljundi täiesti tarbetuid toiminguid, rääkimata suurest RAM-i tarbimisest.

RAID-massiivides soovitatakse kasutada kõrgeid eelloetavaid väärtusi vahemikus 1–8 MB, kuid Androidi seadmete puhul on kõige parem jätta vaikimisi väärtus 128 KB.

Virtuaalse mälu haldussüsteem tõmbab

Teine levinud “optimeerimise” tehnika on virtuaalse mälu haldamise alamsüsteemi häälestamine. Tavaliselt on see suunatud ainult kahele kerneli muutujale, vm.dirty_background_ratio ja vm.dirty_ratio, mis on mõeldud puhastulemuse muutmiseks "räpaste" andmete salvestamiseks. Räpased andmed on tavaliselt andmed, mis on kirjutatud kettale, kuid neid on veel mälus ja kettale kirjutamist oodatakse.

Tüüpilised näpunäited nii Linuxi distros kui ka Androisis VM-i haldussüsteemi jaoks on järgmised:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Seda proovitakse teha nii, et kui räpane andmepuhver on 10% RAM-i kogumahust, äratab see pdflush voo ja hakkab andmeid kettale kirjutama - kui kettale andmete salvestamine on liiga intensiivne, puhver kasvab jätkuvalt ja kui see jõuab 20% -ni saadaolevast RAM-ist, lülitub süsteem järgmisele kirjutamistoimingule sünkroonrežiimis - ilma eelpuhvrita. See tähendab, et kettarakendusele kirjutamine blokeeritakse, kuni andmed kirjutatakse kettale (AKA 'lag').

Peaksite mõistma, et isegi kui puhvri suurus ei ulatu 10% -ni, käivitub süsteem 30 sekundi pärast automaatselt pdflush-vormingus. Kombinatsioon 10/20 on üsna mõistlik, näiteks 1 GB muutmäluga seadmel võrduks see 100/200 MB RAM-iga, mis on enam kui piisav puhkerekordite osas, kus kiirus on sageli väiksem kui NAND-i kiirusrekord -mälu või SD-kaart, näiteks rakenduste installimisel või failide arvutist kopeerimisel.

Miskipärast üritavad stsenaristid seda väärtust veelgi kõrgemale suruda, absurdsete määradeni. Näiteks võime Xplixi optimeerimisskriptis leida kiiruse 50/90.

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

1 GB mäluga seadmes seab see määrdunud puhvri limiidi 500/900 MB-ni, mis on Androidi seadme jaoks täiesti kasutu, kuna see toimiks ainult plaadil pideva salvestamise korral - midagi, mis juhtub ainult rasketel seadmetel Linuxi server.

ThunderBolt! Skript kasutab mõistlikumat väärtust, kuid üldiselt on see endiselt üsna mõttetu:

 kui ["$ mem" -lt 524288]; siis sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; siis 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; 

Kaks esimest käsku käitatakse nutitelefonides, millel on 512 MB muutmälu, teises - 1 GB ja teised - rohkem kui 1 GB. Kuid tegelikult on vaikesätete muutmiseks ainult üks põhjus - väga aeglase sisemälu või mälukaardiga seade. Sel juhul on mõistlik levitada muutujate väärtused, st teha midagi sellist:

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

Kui ülepingesüsteem kirjutab toiminguid üles ilma plaadile andmeid salvestama, ei lülitu viimane sünkroonrežiimi, mis võimaldab rakendustel salvestamise ajal viivitust vähendada.

Täiendavad kasutud näpunäited ja jõudluse häälestamine

Seal on palju rohkem "optimeerimisi", mis tegelikult ei tee midagi. Enamikul neist pole lihtsalt mingit mõju, samas kui teised võivad toimivuse mõnda aspekti parandada, halvendades seadet muul viisil ( tavaliselt langeb see jõudluseks või aku tühjenemiseni) .

Siin on mõned populaarsed täiendavad optimeerimised, mis võivad olenevalt Androidi süsteemist ja seadmest olla kasulikud või mitte.

  • Kiirendus - väike kiirendus jõudluse ja alakoormuse parandamiseks - säästab vähe aku.
  • Andmebaasi optimeerimine - teoreetiliselt peaks see parandama seadme jõudlust, kuid on kaheldav.
  • Zipalign - Irooniline on see, et hoolimata sisseehitatud Androidi SDK funktsiooni sisu joondamisest poes APK-faili sees leitakse palju tarkvara, mida zipalign ei edasta.
  • Keelake tarbetud süsteemiteenused, eemaldades kasutamata süsteemi ja harva kasutatud kolmandate osapoolte rakendused. Põhimõtteliselt bloatware desinstallida.
  • Kohandatud kernel konkreetse seadme optimeerimisega (jällegi pole kõik tuumad võrdselt head).
  • Juba kirjeldatud I / O planeerija noop.
  • Küllastusalgoritm TCP Westwood - tõhusamalt kasutatav vaikeseadetes Android Cubic traadita võrkude jaoks, mis on saadaval kohandatud tuumades.

Kasutud seaded build.prop

XDA arendajate foorumist pärit LaraCraft304 viis läbi uuringu ja leidis, et muljetavaldavat arvu /system/build.prop sätteid, mida soovitatakse kasutada “ekspertidena”, pole allikates AOSP ja CyanogenMod. Siin on nimekiri:

 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 eADist.sys.shutHPJJJP.mode 

Huvitavad Artiklid