Levinumad Androidi optimeerimise müüdid on tühistatud

Seega kasutavad paljud kõik ühes optimeerimisskriptid samu meetodeid, millest mõned on pikas perspektiivis täiesti vananenud või kahjulikud. Kokkuvõtteks võib öelda, et enamus optimeerimisskripte 'kõik ühes' on muud kui soovitatud häälestused, millel puudub selge arusaam, kuidas või miks need optimeerimised töötavad - kasutajad vilgutavad seejärel skripte ja väidavad, et nende jõudlus on äkki kiirem ( tegelikult tõi jõudluse tõusu tõenäoliselt nende seadme taaskäivitamise väga lihtne toiming , kuna kõik seadme RAM-is puhastatakse) .

Selles Appualsi eksklusiivses artiklis toome välja mõned kõige tavalisemad soovitused optimeerimine ” Androidi toimivus ja kas see on lihtsalt müüt või seaduslik toimimine seadme jõudluse osas.

Vaheta

Müütide nimekirja tipus on Androidi vahetus - mis on üsna absurdne, kui mõelda, et seda peetakse Androidi optimeerimiseks. Vahetuste peamine eesmärk on luua ja ühendada otsingufail, mis vabastab mäluruumi. See kõlab mõistlikult paberil , kuid see on tõesti rakendatav a server , millel puudub peaaegu igasugune interaktiivsus.

Kui kasutate oma Android-telefoni vahetust regulaarselt, põhjustab see tõsiseid viivitusi, mis tulenevad vahemälust mööda libisevatest asjadest. Kujutage näiteks ette, kui mõni rakendus üritab kuvada graafikat, mis on salvestatud vahetuslepingusse, mis peab nüüd pärast ruumi vabastamist plaadi uuesti laadima, paigutades andmevahetuse teise rakendusega. See on tõesti räpane.

Mõned optimeerimisentusiastid võivad öelda, et vahetamine ei pakkunud probleeme, kuid see ei muuda jõudlust veelgi - see on sisseehitatud Android-mehhanism lowememorykiller , mis tapab regulaarselt ülespuhutud ja esmatähtsaid protsesse, mida ei kasutata. LMK on loodud spetsiaalselt vähese mäluga töötlemiseks kswapd protsess ja üldiselt tapab kasutajaruumi protsessid. See erineb OOMkiller (mälust väljas olev tapja), aga see on hoopis teine ​​teema.

Asi on selles, et seade, millel on näiteks 1 GB RAM-i, ei jõua kunagi vahetuse käigus vajalike jõudlusandmeteni ja seega pole Androidis vahetamist absoluutselt vaja. Selle rakendamine on lihtsalt täis hilinemist ja viib a degradeerumine jõudluses, mitte selle optimeerimisel.

zRAM - aegunud ja pole enam tõhus

zRAM on tõestatud ja tõhus meetod seadme optimeerimiseks vanemad seadmed - mõelge KitKati põhistele seadmetele, mis töötavad ainult umbes 512 MB RAM-iga. Asjaolu, et mõned inimesed lisavad optimeerimisskriptidesse endiselt zRAM-i näpunäiteid või soovitavad zRAM-i mingisuguse kaasaegse optimeerimise näpunäidetena, on näide sellest, kuidas inimesed tavaliselt ei järgi uusimaid operatiivprotokolle.

zRAM oli mõeldud algtaseme eelarvevahemikuga mitme tuumaga SoC-de jaoks, näiteks seadmetele, mis kasutavad MTK kiibikomplekte ja 512 MB RAM-i. Põhimõtteliselt väga odavad Hiina telefonid. Mida zRAM põhimõtteliselt teeb, on tuuma krüptovoo kaudu eraldamine.

Kui zRAM-i kasutatakse vanemates seadmetes, millel on a ühe südamikuga , isegi kui sellistes seadmetes soovitatakse zRAM-i, kipub suur hulk viive kasvama. See juhtub ka KSM-tehnoloogiaga ( Tuuma sama lehe ühendamine) mis ühendab identsed mälulehed, pakkudes vaba ruumi. Seda soovitab tegelikult Google, kuid see viib vanemate seadmete puhul suuremate mahajäämusteni, sest pidevalt aktiivsed tuumipead jooksevad pidevalt mälust topeltlehtede otsimiseks. Põhimõtteliselt aeglustab optimeerimise näpistamise käivitamine seadet irooniliselt veelgi.

Seeder - aegunud alates Android 3.0-st

Üks Androidi arendajate seas enim vaieldud optimeerimisnõuandeid on seeder ja oleme kindlad, et keegi võiks proovida tõestada, et me sellel teemal eksime - kuid kõigepealt peame uurima külviku ajalugu.

Seederi rakendus Androidile

Jah, on palju teateid, mis deklareerivad pärast installimist Androidi paremat toimivust palju vanemad Android-seadmed . Inimesed arvavad mingil põhjusel siiski, et see tähendab ka rakendatavat optimeerimist kaasaegsed Android-seadmed , mis on absoluutselt absurdne. Asjaolu, et Seederit hooldatakse ja pakutakse endiselt kui kaasaegne ” mahajäämuse vähendamise tööriist on näide väärinformatsioonist - kuigi see pole Seederi arendaja süü, sest isegi nende Play poe leht märgib, et pärast Android 4.0+ on Seeder vähem efektiivne. Kuid mingil põhjusel ilmub Seeder endiselt tänapäevaste Android-süsteemide optimeerimisdiskussioonidesse.

Mida Seeder põhimõtteliselt teeb Android 3.0 jaoks, on vea lahendamine, kus Androidi käitamise aeg kasutaks entroopia saamiseks aktiivselt / dev / random / faili. / Dev / random / buffer muutuks ebastabiilseks ja süsteem blokeeriti seni, kuni see täitis vajaliku andmemahu - mõelge sellistest pisiasjadest nagu erinevad andurid ja nupud Android-seadmes.

Seederi autor võttis Linuxi deemoni rngd ja koostatud Androidi inastroili jaoks nii, et see võttis juhuslikud andmed palju kiiremast ja prognoositavamast / dev / urandom rajast ning liitis need dev / random / iga sekundiks, lubamata / dev / random / ammenduda. Selle tulemuseks oli Android-süsteem, milles entroopia puudumist ei kogenud, ja see toimis palju sujuvamalt.

Google purustas selle vea pärast Android 3.0, kuid mingil põhjusel hüppab Seeder ikkagi üles 'Soovitatud tweaks' Androidi jõudluse optimeerimise loendid. Lisaks on Seederi rakendusel mõned analoogid, nagu sEFix, mis sisaldavad Seederi funktsionaalsust, kas seda kasutatakse rngd või alternatiiv varjatud või isegi lihtsalt / dev / urandom ja / dev / random vahelist sümboli. See on tänapäevaste Android-süsteemide jaoks täiesti mõttetu.

Selle mõttetu põhjus on see, et uuemad Androidi versioonid kasutavad / dev / random / kolmes põhikomponendis - libcrypto , SSL-ühenduste krüptimiseks, SSH-võtmete genereerimiseks jne. WPA_supplication / hostapd, mis genereerib WEP / WPA-võtmed, ja lõpuks käputäis teeke ID genereerimiseks EXT2 / EXT3 / EXT4-failisüsteemide loomisel.

Millal siis Seeder või Seederi põhised täiustused on kaasatud tänapäevastesse Androidi optimeerimisskriptidesse, mis lõpuks juhtub, on a degradeerumine seadme jõudluses, sest rngd äratab seadme pidevalt ja põhjustab protsessori sageduse kasvu, mis muidugi mõjutab aku tarbimist negatiivselt.

Odex

Android-seadmete aktsia püsivara on peaaegu alati oode. See tähendab, et kõrvuti APK-vormingus Androidi rakenduste standardpaketiga, mis on leitud / system / app / ja / system / priv-app /, on samad failinimed laiendiga .odex. Oodex-failid sisaldavad optimeeritud baitkoodirakendusi, mis on juba valideerija ja optimeerija virtuaalmasina läbinud, seejärel salvestatud eraldi faili, kasutades midagi sellist dexopt tööriist.

Seega on odex-failid mõeldud virtuaalmasina mahalaadimiseks ja odexed-rakenduse käivitamise kiirendamiseks - negatiivsed küljed takistavad ODEX-failid püsivara muutmist ja tekitavad värskendustega probleeme, nii et sel põhjusel levitatakse paljusid kohandatud ROM-e nagu LineageOS ilma ODEXita .

ODEX-failide genereerimine toimub mitmel viisil, näiteks Odexeri tööriista abil - probleem on selles, et see on puhtalt platseeboefekt. Kui kaasaegne Android-süsteem ei leia odex-faile kataloogist / system, loob süsteem need tegelikult ja paigutab need kataloogi / system / dalvik-cache /. Täpselt nii juhtub, kui näiteks vilgutate uut Androidi versiooni ja see annab korraks teate „Kinni, rakendusi optimeerides”.

Lowmemorykilleri näpistused

Multitegumtöötlus Androidis erineb teistest mobiilsetest operatsioonisüsteemidest selle poolest, et see põhineb klassikalisel mudelil, kus rakendused töötavad vaikselt taustal ja taustarakenduste arv pole piiratud ( välja arvatud juhul, kui see on määratud arendaja suvandites, kuid see on tavaliselt soovitatav) - pealegi ei peatata taustajuhtimisele ülemineku funktsionaalsust, kuigi süsteem jätab endale õiguse tappa taustarakendusi vähese mälu korral ( vaadake, kus me selles juhendis varem rääkisime lowmemorykillerist ja mälust väljas olevast tapjast) .

Mine tagasi lowememorykiller mehhanism, saab Android jätkata piiratud mäluhulga ja vahetuspartitsiooni puudumise korral. 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 algusaegadel Androidi jaoks väga kasulik, ehkki mingil põhjusel sai see populaarseks ülesandetapjarakenduste näol, mis on üldiselt pigem kahjulikud kui kasulikud. Task-killer rakendused kas ärkavad kindlaksmääratud ajavahemike järel või on kasutaja käivitatud ja näivad vabastavat suures koguses RAM-i, mida peetakse positiivseks - rohkem vaba RAM tähendab kiiremat seadet, eks? Androidi puhul pole see aga päris nii.

Tegelikult võib suures koguses vaba RAM-i omamine teie seadme jõudlust ja aku kasutusaega kahjustada. Kui rakendused on salvestatud Androidi RAM-i, on neid palju lihtsam helistada, käivitada jne. Android-süsteem ei pea rakendusele üleminekuks palju ressursse pühendama, kuna see on juba mälus olemas.

Seetõttu pole ülesandetapjad tegelikult nii populaarsed kui kunagi varem, ehkki Androidi algajad kipuvad neile mingil põhjusel endiselt lootma ( teabe puudumine, kahjuks) . Kahjuks on ülesandetapjad asendanud uus trend lowememorykiller mehhanismi häälestamine. See oleks näiteks MinFreeManager 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 mäluruum on täidetud, siis üks vahemällu salvestatud rakendustest, mis laaditakse mällu aga ei jookse lõpetatakse.

Põhimõtteliselt on Androidil alati vähemalt 40 MB vaba mälu, mis on enne ühe rakenduse mahutamiseks piisav lowememorykiller alustab oma puhastusprotsessi - see tähendab, et Android teeb alati endast parima, et kasutada maksimaalselt saadaolevat RAM-i, ilma et see häiriks kasutajakogemust.

Kahjuks soovitasid mõned kodupruuli harrastajad, et enne LMK käivitamist tõstetakse väärtus näiteks 100 MB-ni. Nüüd on kasutaja tegelikult kaotama RAM (100 - 40 = 60), nii et selle ruumi kasutamise asemel taustarakenduste salvestamiseks hoiab süsteem seda mälumahtu tasuta , millel pole absoluutselt mingit eesmärki.

LKM-i häälestamine võib olla kasulik palju vanemate seadmete jaoks, millel on 512 RAM-i, kuid kellele need enam kuuluvad? 2 GB on tänapäevane „eelarvevahemik”, isegi 4 GB RAM-seadmeid näevad tänapäeval „keskmise vahemikuga“, nii et LMK näpunäited on tõesti vananenud ja kasutud.

I / O kohandused

Paljudest Androidi optimeerimisskriptidest leiate sageli näpunäiteid, mis käsitlevad sisend- ja väljundsüsteemi. Näiteks laseb heita pilgu ÄikeBolt! Skript, mis sisaldab neid ridu:

kaja 0> $ i / järjekord / rotatsioon; kaja 1024> $ i / järjekord / nr_requests;

Esimene rida annab sisend- / väljundiplaneerijale juhised SSD-ga tegelemiseks ja teine ​​suurendab järjekorra I / O maksimaalset suurust 128-lt 1024-le - kuna muutuja $ i sisaldab teed plokiseadmete puuni / sys ja skript töötab silmusena.

Pärast seda leiate CFQ-planeerijaga seotud rea:

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 planeerijatele, kuid lõpuks on kaks esimest käsku mõttetud, kuna:

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

Pikk sisend-väljundjärjekord ( näiteks 1024) on tänapäevases Android-seadmes kasutu, tegelikult on see mõttetu isegi töölaual - seda soovitatakse tegelikult ainult raskeveokite serverid . Teie telefon ei ole suure koormusega Linuxi server.

Android-seadme jaoks ei ole sisend-väljundis esmatähtsat rakendust ega mehaanilist draiverit, seega on parim planeerija noop / FIFO-järjekord, nii et seda tüüpi ajakava ' näpistama ” ei tee sisend- / väljundsüsteemile midagi erilist ega sisukat. Tegelikult on kõik need mitme ekraaniga loendikäsklused parem asendada lihtsa tsükliga:

i jaoks / sys / plokk / mmc *; do echo noop> $ i / järjekord / ajastaja kaja 0> $ i / queue / iostats done

See võimaldaks sisend- ja väljundstatistika kogumisel kõigi ketaste noop-ajakava, mis peaks jõudlust positiivselt mõjutama, ehkki väga väike ja peaaegu tühine.

Teine kasutu I / O näpistamine, mida jõudlusskriptides sageli leitakse, on SD-kaartide suurenenud ettelugemise väärtused kuni 2 MB. Ettelugemismehhanism on mõeldud meediumilt andmete varajaseks lugemiseks, enne kui rakendus nendele andmetele juurdepääsu taotleb. Põhimõtteliselt üritab kernel välja selgitada, milliseid andmeid tulevikus vaja läheb, ja laadib need eelnevalt RAM-i, mis peaks seega vähendama tagastamisaega. See kõlab paberil suurepäraselt, kuid ettelugemise algoritm on sagedamini kasutatav vale , mis viib sisend-väljund täiesti mittevajalike toiminguteni, rääkimata suurest RAM-i tarbimisest.

RAID-massiividel on soovitatav kasutada suuri ettelugemise väärtusi vahemikus 1–8 MB, kuid Android-seadmete jaoks on parim jätta vaikeväärtuseks 128 KB.

Virtuaalne mäluhaldussüsteem muudab

Teine levinud optimeerimise tehnika on virtuaalse mäluhalduse alamsüsteemi häälestamine. Tavaliselt on see suunatud ainult kahele kerneli muutujale, vm.dirty_background_ratio ja vm.dirty_ratio, mis on mõeldud „määrdunud“ andmete salvestamise puhvri suuruse reguleerimiseks. Määrdunud andmed on tavaliselt kettale kirjutatud andmed, kuid mälus on neid veel ja need ootavad kettale kirjutamist.

Tüüpilised näpuväärtused nii Linuxi distros kui ka Androis VM-i haldamise alamsüsteemis oleksid järgmised:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Nii et see üritab teha seda, et kui määrdunud andmepuhver moodustab 10% RAM-i koguarvust, siis see ärkab pdflush voolu ja hakkab kettale andmeid kirjutama - kui kettale andmete salvestamine toimib liiga intensiivne , puhver kasvab jätkuvalt ja kui see jõuab 20% -ni olemasolevast RAM-ist, lülitub süsteem järgmisele kirjutamistoimingule sünkroonrežiimis - ilma eelpuhvrita. See tähendab, et kettarakendusse kirjutamise töö on blokeeritud, kuni andmed on kettale kirjutatud (AKA ‘lag’).

Mida peaksite mõistma, on see isegi siis, kui puhvri suurus ei ulatu 10% -ni , käivitub süsteem 30 sekundi pärast automaatselt pdflush-vormingus. 10/20 kombinatsioon on üsna mõistlik, näiteks 1 GB RAM-iga seadmes võrduks see 100/200 MB RAM-iga, mis on enam kui piisav plahvatusrekordite osas, kus kiirus on süsteemis NAND sageli alla kiirusrekordi -mälu või SD-kaart, näiteks rakenduste installimisel või failide arvutist kopeerimisel.

Millegipärast üritavad stsenaristid seda väärtust veelgi absurdsemaks muuta. Näiteks võime leida Xplix optimeerimisskripti määr isegi 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 piiriks 500/900 MB, mis on Androidi seadme jaoks täiesti kasutu, sest see töötaks ainult pidev plaadile salvestamine - midagi, mis juhtub ainult raskes Linuxi serveris.

ÄikeBolt! Skript kasutab mõistlikumat väärtust, kuid üldiselt on see siiski ü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äivad nutitelefonides, millel on 512 MB RAM-i, teine ​​- 1 GB ja teised - üle 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äärtusi, st teha midagi sellist:

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

Kui ülepingesüsteem kirjutab toiminguid, ilma et peaks plaadile andmeid salvestama, ei lülitu viimane kuni viimane sünkroonrežiimile, mis võimaldab rakendustel salvestamisel viivitust vähendada.

Täiendavad kasutud muudatused ja jõudluse häälestamine

Seal on palju rohkem optimeerimisi, mis tegelikult midagi ei tee. Enamikul neist pole lihtsalt mingit mõju, teised aga võivad paraneda mõned jõudluse aspekti, halvendades samal ajal seadet muul viisil ( tavaliselt taandub jõudlusele või aku tühjenemisele) .

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

• Kiirendus - jõudluse ja pinge vähendamiseks mõeldud väike kiirendus - säästab natuke akut.
• Andmebaasi optimeerimine - teoreetiliselt see peaks paranda seadme jõudlust, kuid see on kaheldav.
• Zipalign - Irooniline on see, et hoolimata poe APK-faili sisseehitatud Android SDK funktsioonide sisu joondamisest leiate, et palju tarkvara ei edastata zipalign'i kaudu.
• Keelake mittevajalikud süsteemiteenused, eemaldades kasutamata süsteemi ja harva kasutatavad kolmanda osapoole rakendused. Põhimõtteliselt bloatware desinstallimine.
• Konkreetse seadme optimeerimisega kohandatud tuum (jällegi pole kõik tuumad võrdselt head).
• Juba kirjeldatud I / O-ajakava noop.
• Küllastusalgoritm TCP Westwood - traadita võrkude jaoks vaikimisi Android Cubicus kasutatavam, saadaval kohandatud tuumades.

Kasulikud seaded build.prop

LaraCraft304 XDA arendajate foorumist viis läbi uuringu ja leidis, et muljetavaldavat arvu /system/build.prop sätteid, mida soovitatakse kasutada 'ekspertidel', pole allikates AOSP ja CyanogenMod olemas. 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. kernel.checkjni dalvik.vm.