Vanlige mytologier om Android-optimaliseringsmyter

Det er mange instruksjonsguider der ute dedikert til å øke Android-ytelsen og generelle optimaliseringstips. Noen av dem er legitime, og andre er kun basert på teori, eller utdaterte operative metoder i Android-systemet, eller er bare tull. Dette inkluderer anbefalinger for å bytte, verdier lagt til build.prop og variable endringer i Linux-kjernen.

Det er til og med massevis av "optimaliseringsskripter" der ute, alt-i-ett flashable. Zip som lover å øke ytelsen, batteriets levetid og andre ting betydelig. Noen av justeringene kan faktisk fungere, men et flertall er ganske enkelt en placebo-effekt, eller verre, har faktisk en negativ innvirkning på enheten din.

Det er ikke å si at folk slipper uhyggelige skript med vilje - det er definitivt falske betalte apper i Play Store, men optimaliseringsskripter som er utgitt på Android-fora er generelt velmenende, det bare for at utvikleren kan bli feilinformert, eller bare eksperimentere med forskjellige optimaliseringsinnstillinger. Dessverre har en slags snøballeffekt en tendens til å forekomme, spesielt i “alt-i-ett” -optimaliseringsskript. En liten håndfull av tweaks kan faktisk gjøre noe, mens et annet sett med tweaks i et manus kan gjøre absolutt ingenting i det hele tatt - likevel blir disse skriptene gitt som magiske kuler, uten noen reell undersøkelse av hva som fungerer, og hva som ikke .

Dermed bruker mange alt-i-ett-optimaliseringsskripter de samme metodene, hvorav noen er helt utdaterte eller skadelige i det lange løp. Oppsummert er et flertall av “alt-i-ett” -optimaliseringsskriptene ingenting annet enn anbefalte innstillinger som smalt sammen, uten noen klar ide om hvordan eller hvorfor disse optimaliseringene “fungerer - brukere blinker deretter skriptene og hevder at ytelsen deres plutselig er raskere ( når det faktisk var mest sannsynlig den ganske enkle handlingen med å starte enheten på nytt som forårsaket en ytelsesøkning, da alt i enhetens RAM blir renset) .

I denne eksklusive artikkelen til Appuals vil vi trekke frem noen av de vanligste anbefalingene for å " optimalisere" Android-ytelse, og om de bare er en myte, eller en legitim finjustering for enhetsytelse.

Bytte

Øverst på mytelisten er Android-byttet - som er ganske absurd i forhold til å bli tenkt på som en Android-optimalisering. Byttes hovedformål er å opprette og koble til personsøkerfilen, som vil frigjøre lagringsplass i minnet. Dette høres fornuftig ut på papiret, men det er virkelig aktuelt for en server, som nesten ikke har interaktivitet.

Når du bruker Android-telefonens bytte regelmessig, vil det føre til alvorlige etterslep som stammer fra at ting glir forbi cachen. Tenk deg for eksempel hvis et program prøver å vise en grafikk, som er lagret i bytten, som nå må laste inn platen på nytt etter å ha frigjort plass ved å plassere datautveksling med et annet program. Det er virkelig rotete.

Noen optimaliseringsentusiaster kan si at bytte ikke ga noen problemer, men det er ikke bytte som gir ytelsen til å øke - det er den innebygde Android-mekanismen lowmemorykiller, som regelmessig vil drepe oppblåste prosesser med høy prioritet som ikke blir brukt. LMK ble designet spesielt for å håndtere forhold med lite minne, blir påberopt fra kswapd- prosessen og dreper generelt brukerplassprosesser . Dette er forskjellig fra OOMkiller (morderen uten minne), men det er et helt annet tema.

Poenget er at en enhet med for eksempel 1 GB RAM aldri kan nå de nødvendige ytelsesdataene i en bytte, og derfor er bytte absolutt ikke nødvendig i Android. Gjennomføringen er ganske enkelt full av etterslep og fører til en degradering i ytelsen, i stedet for å optimalisere den.

zRAM - Utdatert og ikke lenger effektivt

zRAM er en velprøvd og effektiv metode for enhetsoptimalisering, for eldre enheter - tenk KitKat-baserte enheter som kun bruker omtrent 512 MB RAM. At noen fremdeles inkluderer zRAM-justeringer i optimaliseringsskripter, eller anbefaler zRAM som en slags moderne optimaliseringsinnstilling, er et eksempel på at folk generelt ikke følger de siste operative protokollene.

zRAM var beregnet på entry-level budsjett-multi-core SoCer, for eksempel enheter som bruker MTK-brikkesett og 512 MB RAM. Veldig billige kinesiske telefoner, i utgangspunktet. Hva zRAM i utgangspunktet gjør er å skille kjernen via krypteringsstrømmen.

Når zRAM brukes på eldre enheter med en enkelt kjerne, selv om zRAM anbefales på slike enheter, har store mengder etterslep en tendens til å vokse opp. Dette skjer også med KSM-teknologien ( Kernel Same Page Merging) som kombinerer identiske minnesider i et forsøk på å frigjøre plass. Dette anbefales faktisk av Google, men fører til større etterslep på eldre enheter, fordi de konstant aktive kjernetrådene løper kontinuerlig fra minnet til å søke etter dupliserte sider. I utgangspunktet bremser det ironisk nok å prøve å kjøre optimaliseringsinnstillingen, enda lenger.

Seeder - utdatert siden Android 3.0

Et av de mest omdiskuterte optimaliseringstipsene blant Android-devs er seeder, og vi er sikre på at noen kan prøve å bevise oss galt om dette emnet - men først må vi undersøke seederens historie.

Seeder-app for Android

Ja, det er et stort antall rapporter som erklærer bedre Android-ytelse etter installasjon på mye eldre Android-enheter . Imidlertid tror folk uansett grunn dette betyr at det også er en aktuelt optimalisering for moderne Android-enheter, noe som er helt absurd. At Seeder fortsatt opprettholdes og tilbys som et “ moderne” etterslepreduseringsverktøy, er et eksempel på feilinformasjon - selv om dette ikke er feilen til Seeder's utvikler, da selv Play Store-siden deres bemerker at Seeder er mindre effektiv etter Android 4.0+. Likevel dukker Seeder frem uansett grunn i optimeringsdiskusjoner for moderne Android-systemer.

Det Seeder i utgangspunktet gjør for Android 3.0 er å adressere en feil der Android-runtime aktivt vil bruke / dev / random / filen til å skaffe seg entropi. / Dev / random / bufferen ville bli ustabil, og systemet vil bli blokkert til det fylte den nødvendige datamengden - tenk små ting som de forskjellige sensorene og knappene på Android-enheten.

Seeder's forfatter tok Linux-demon rngd, og kompilerte for Android's katastrofale slik at den tok tilfeldige data fra en mye raskere og mer forutsigbar / dev / urandom-bane, og fusjonerer dem til dev / random / hvert sekund, uten å tillate / dev / random / å bli utslitt. Dette resulterte i et Android-system som ikke opplevde mangel på entropi, og utførte mye jevnere.

Google knuste denne feilen etter Android 3.0, men av en eller annen grunn dukker Seeder frem frem på "anbefalte tweaks" -lister for Android-ytelsesoptimalisering. Videre har Seeder-appen noen få analoger som sEFix som inkluderer Seeders funksjonalitet, enten du bruker den samme rngd eller alternativet har toged, eller til og med bare en symlink mellom / dev / urandom og / dev / random. Dette er helt meningsløst for moderne Android-systemer.

Årsaken til at det er meningsløst er fordi nyere Android-versjoner bruker / dev / random / i tre hovedkomponenter - libcrypto, for kryptering av SSL-tilkoblinger, generering av SSH-nøkler, etc. WPA_supplication / hostapd som genererer WEP / WPA-nøkler, og til slutt, en håndfull biblioteker for generering av ID ved å lage EXT2 / EXT3 / EXT4 filsystemer.

Så når Seeder- eller Seeder-baserte forbedringer er inkludert i moderne Android-optimaliseringsskripter, er det som ender med å bli en forringelse i enhetsytelsen, fordi rngd hele tiden vil vekke enheten og forårsake en økning i CPU-frekvens, noe som selvfølgelig påvirker batteriforbruket negativt. .

ODEX

Aksjens firmware på Android-enheter stort sett alltid odex. Dette betyr at ved siden av standardpakken for Android-apper i APK-format, funnet i / system / app / og / system / priv-app /, har de samme filnavnene med .odex-utvidelsen. Odex-filene inneholder optimaliserte bytekode-applikasjoner som allerede har gått gjennom validatoren og den virtuelle optimaliseringsmaskinen, og deretter registrert i en egen fil ved å bruke noe som dexopt- verktøy.

Så odex-filer er ment å laste ned virtuell maskin og tilby en rask oppstart av det odexed-programmet - på ulemper forhindrer ODEX-filer endringer i firmware, og skaper problemer med oppdateringer, så av denne grunn blir mange tilpassede ROM-er som LineageOS distribuert uten ODEX .

Generering av ODEX-filer gjøres på flere måter, som å bruke Odexer Tool - problemet er at det rent er en placebo-effekt. Når moderne Android-system ikke finner odex-filer i / systemkatalogen, vil systemet faktisk opprette dem og plassere dem i / system / dalvik-cache / katalogen. Dette er nøyaktig hva som skjer når du for eksempel blinker en ny Android-versjon, og den gir meldingen “Opptatt, optimaliserer applikasjoner” en stund.

Lowmemorykiller justerer

Multitasking i Android skiller seg fra andre mobile operativsystemer i den forstand at det er basert på en klassisk modell der applikasjoner fungerer stille i bakgrunnen, og det er ingen begrensninger for antall bakgrunnsapper ( med mindre en er angitt i Developer Options, men dette er generelt anbefalt mot) - Videre stoppes ikke funksjonaliteten for overgang til en bakgrunnsutførelse, selv om systemet forbeholder seg retten til å drepe bakgrunnsapper i situasjoner med lite minne ( se hvor vi snakket om lavmemorykiller og utminner-morder tidligere i dette guide) .

For å gå tilbake til lowmemorykiller- mekanismen, kan Android fortsette å operere med en begrenset mengde minne og mangel på bytte-partisjon. Brukeren kan fortsette å starte applikasjoner og bytte mellom dem, og systemet dreper lydløst ubrukte bakgrunnsapper for å prøve å frigjøre minne for aktive oppgaver.

Dette var veldig nyttig for Android i de første dagene, selv om det av en eller annen grunn ble populært i form av oppgavemordere-apper, som generelt er mer skadelig enn gunstig. Oppgavedreper-apper våkner enten med faste intervaller, eller blir kjørt av brukeren, og ser ut til å frigjøre store mengder RAM, noe som blir sett på som et positivt - mer gratis RAM betyr en raskere enhet, ikke sant? Dette er imidlertid ikke akkurat tilfelle med Android.

Å ha en stor mengde gratis RAM kan faktisk være skadelig for enhetens ytelse og batterilevetid. Når apper er lagret i Android-RAM, er det mye enklere å ringe dem opp, starte dem osv. Android-systemet trenger ikke bruke mye ressurser på å bytte til appen, fordi den allerede er der i minnet.

På grunn av dette er ikke oppgavemordere så populære som de en gang var, selv om Android-nybegynnere fremdeles har en tendens til å stole på dem av en eller annen grunn ( mangel på informasjon, dessverre) . Dessverre har en ny trend erstattet oppgavemordere, trenden med innstillinger for lowmemorykiller- mekanismer. Dette vil for eksempel være MinFreeManager- appen, og hovedideen er å øke RAM-kostnaden før systemet begynner å drepe bakgrunnsapper.

Så for eksempel fungerer standard RAM ved grensene - 4, 8, 12, 24, 32 og 40 Mb, og når den ledige lagringsplassen på 40 MB er fylt, er en av cache-appene som er lastet inn i minnet, men ikke kjører blir sagt opp.

Så i utgangspunktet vil Android alltid ha minst 40 MB tilgjengelig minne, noe som er nok til å imøtekomme en applikasjon til før lowmemorykiller begynner opprydningsprosessen - noe som betyr at Android alltid vil gjøre sitt beste for å bruke den maksimale mengden tilgjengelig RAM uten å forstyrre Brukererfaring.

Dessverre, det som noen hjemmebryggeentusiaster begynte å anbefale, er at verdien økes til for eksempel 100 MB før LMK sparker i. Nå vil brukeren faktisk miste RAM (100 - 40 = 60), så i stedet for å bruke denne plassen til å lagre tilbake- slutter apper, systemet vil holde denne mengden minne gratis, og har absolutt ingen hensikt for det.

LKM-innstilling kan være nyttig for mye eldre enheter med 512 RAM, men hvem eier de lenger? 2 GB er den moderne "budsjettområdet", til og med 4 GB RAM-enheter blir i dag sett på som "mellomtoner", så LMK-justeringer er virkelig utdaterte og ubrukelige.

I / O justerer

I mange optimaliseringsskript for Android finner du ofte tweaks som adresserer I / O-delsystemet. La oss for eksempel se på ThunderBolt! Skript, som inneholder disse linjene:

 ekko 0> $ i / kø / rotasjon; ekko 1024> $ i / kø / nr_requests; 

Den første linjen vil gi I / O-planleggeren instruksjoner når det gjelder å håndtere en SSD, og ​​den andre øker den maksimale størrelsen på køen I / O fra 128 til 1024 - fordi $ i-variabelen inneholder en bane til treet til blokkeringsenheter i / sys, og skriptet kjøres i en loop.

Etter det finner du en linje relatert til CFQ-planleggeren:

 ekko 1> $ i / kø / iosched / back_seek_penalty; ekko 1> $ i / kø / iosched / low_latency; ekko 1> $ i / kø / iosched / slice_idle; 

Dette blir fulgt av flere linjer som tilhører andre planleggere, men til slutt er de to første kommandoene meningsløse fordi:

En moderne Linux-kjerne kan forstå hvilken type lagringsmedium den jobber med som standard.

En lang input-output-kø ( for eksempel 1024) er ubrukelig på en moderne Android-enhet, faktisk er den meningsløs selv på skrivebordet - den anbefales egentlig bare på tunge servere . Telefonen din er ikke en tungtliggende Linux-server.

For en Android-enhet er det praktisk talt ingen applikasjoner som er prioritert i input-output og ingen mekanisk driver, så den beste planleggeren er noop / FIFO-køen, så denne typen planlegger “ tweak” gjør ikke noe spesielt eller meningsfullt for I / O-delsystem. Faktisk er alle disse multikjerm-listekommandoene bedre erstattet av en enkel syklus:

 for i i / sys / block / mmc *; gjør ekko noop> $ i / kø / planlegger ekko 0> $ i / kø / iostats gjort 

Dette vil muliggjøre noop-planleggeren for alle stasjoner fra akkumulering av I / O-statistikk, noe som bør ha en positiv innvirkning på ytelsen, selv om den er veldig liten og nesten fullstendig ubetydelig.

En annen ubrukelig I / O-finjustering som ofte finnes i ytelseskripter er de økte leseverdiene for SD-kort opp til 2 MB. Mekanismen for å lese videre er for tidlig datalesing fra media, før appen ber om tilgang til disse dataene. Så i utgangspunktet vil kjernen prøve å finne ut hvilke data som vil være nødvendig i fremtiden, og forhåndsinnlaster den i RAM-en, noe som dermed skal redusere returtiden. Dette høres bra ut på papiret, men den forhåndslyste algoritmen er oftere feil, noe som fører til helt unødvendige operasjoner av input-output, for ikke å nevne et høyt RAM-forbruk.

Høy anbefalte verdier mellom 1 - 8 MB anbefales i RAID-matriser, men for Android-enheter er det best å bare legge igjen standardverdien på 128 KB.

Virtuelt minnehåndteringssystem justerer

En annen vanlig “optimalisering” -teknikk er å stille inn det underlige systemet for virtuelt minnehåndtering. Dette retter seg vanligvis mot bare to kjernevariabler, vm.dirty_background_ratio og vm.dirty_ratio, som er for å justere størrelsen på bufferen for lagring av "skitne" data. Skitne data er vanligvis data som er skrevet til disk, men det er mer i minnet og venter på å bli skrevet til disk.

Typiske justeringsverdier i både Linux-distros og Androis til VM-administrasjonsundersystemet vil være som:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Så dette prøver å gjøre er at når den skitne databufferen er 10% av den totale mengden RAM, vekker den pdflush- strømmen og begynner å skrive data til disken - hvis driften av å registrere data på disken vil være for intens, bufferen vil fortsette å vokse, og når den når 20% av tilgjengelig RAM, vil systemet bytte til den påfølgende skriveoperasjonen i synkron modus - uten forhåndsbuffer. Dette betyr at arbeidet med å skrive til diskapplikasjon blir blokkert inntil dataene er skrevet til disk (AKA 'lag').

Det du bør forstå er at selv om bufferstørrelsen ikke når 10%, vil systemet automatisk sparke inn pdflush etter 30 sekunder. En kombinasjon av 10/20 er ganske rimelig, for eksempel på en enhet med 1 GB RAM vil dette tilsvarer 100/200 MB RAM, noe som er mer enn nok når det gjelder burst-poster der hastigheten ofte er under hastighetsrekorden i system NAND -minne eller SD-kort, for eksempel når du installerer apper eller kopierer filer fra en datamaskin.

Av en eller annen grunn prøver manusforfattere å presse denne verdien enda høyere, til absurde priser. For eksempel kan vi finne i Xplix- optimaliseringsskriptet en hastighet så høyt som 50/90.

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

På en enhet med 1 GB minne setter dette grensen for en skitten buffer til 500/900 MB, noe som er helt ubrukelig for en Android-enhet, fordi det bare vil fungere under konstant opptak på platen - noe som bare skjer på en tung Linux-server.

Lyn! Skriptet bruker en mer fornuftig verdi, men samlet sett er den fremdeles ganske meningsløs:

 hvis ["$ mem" -lt 524288]; deretter sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; deretter sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; ellers sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

De to første kommandoene kjøres på smarttelefoner med 512 MB RAM, den andre - med 1 GB og andre - med mer enn 1 GB. Men faktisk er det bare en grunn til å endre standardinnstillingene - en enhet med et veldig tregt internt minne eller minnekort. I dette tilfellet er det rimelig å spre verdiene til variablene, det vil si å lage noe lignende:

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

Så når et bølgesystem skriver operasjoner, uten å måtte registrere data på platen, vil ikke den siste bytte til synkron modus, noe som gjør at applikasjoner kan redusere etterslep når du spiller inn.

Ytterligere ubrukelige justeringer og ytelsesinnstillinger

Det er mye mer "optimaliseringer" der ute som virkelig ikke gjør noe. De fleste av dem har rett og slett ingen effekt, mens andre kan forbedre ytelsesaspekten, mens de ødelegger enheten på andre måter ( vanligvis koker det til ytelse kontra batteriavløp) .

Her er noen ekstra populære optimaliseringer som kanskje eller ikke kan være nyttige, avhengig av Android-systemet og enheten.

  • Akselerasjon - Den lille akselerasjonen for å forbedre ytelsen og undervolting - sparer litt batteri.
  • Databaseoptimalisering - I teorien skal dette gi en forbedring i enhetens ytelse, men det er tvilsomt.
  • Zipalign - Ironisk nok, til tross for den innebygde Android SDK-innholdsinnretningen i APK-filen i butikken, kan du finne at mye programvare ikke overføres gjennom zipalign.
  • Deaktiver unødvendige systemtjenester, fjerne ubrukte systemer og sjelden brukte tredjepartsapplikasjoner. I utgangspunktet avinstallerer bloatware.
  • Tilpasset kjerne med optimaliseringer for en spesifikk enhet (igjen, ikke alle kjerner er like gode).
  • Allerede beskrevet I / O-planlegger noop.
  • Metningsalgoritme TCP Westwood - Brukes mer effektivt i standard Android Cubic for trådløse nettverk, tilgjengelig i tilpassede kjerner.

Nytteløse innstillinger build.prop

LaraCraft304 fra XDA Developers forum har utført en studie og funnet at et imponerende antall /system/build.prop-innstillinger som er anbefalt for bruk av “eksperter” ikke eksisterer i kilden AOSP og CyanogenMod. Her er listen:

 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_vel 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.shADdownPode.mode 

Interessante Artikler