Dermed bruker mange alt-i-ett-optimaliseringsskripter de samme metodene, hvorav noen er helt utdaterte eller skadelige i det lange løp. Oppsummert er flertallet av 'alt-i-ett' -optimaliseringsskripter bare anbefalt innstillinger som er slått sammen, uten noen klar ide om hvordan eller hvorfor disse optimaliseringene 'fungerer - brukere blinker deretter manusene og hevder at ytelsen plutselig er raskere. ( når det faktisk var det mest sannsynlig den veldig enkle handlingen med å starte enheten på nytt som forårsaket en ytelsesøkning , ettersom alt i enhetens RAM blir ryddet ut) .
I denne eksklusive artikkelen til Appuals fremhever vi noen av de vanligste anbefalingene for optimalisering ” Android-ytelse, og om de bare er en myte, eller en legitim tweak for enhetsytelse.
Bytte
På toppen av mytelisten er Android-byttet - som er ganske absurd når det gjelder å bli tenkt på som en Android-optimalisering. Bytter hovedformål er å opprette og koble til personsøkingsfilen, som frigjør lagringsplass i minnet. Dette høres fornuftig ut på papir , men det er virkelig aktuelt for en server , som nesten ikke har interaktivitet.
Når du bruker byttet på Android-telefonen din regelmessig, vil det føre til alvorlige forsinkelser som stammer fra ting som glir forbi hurtigbufferen. Tenk deg for eksempel hvis et program prøver å vise et grafikkbilde som er lagret i byttet, som nå må laste inn platen igjen etter å ha frigjort plass ved å plassere databytte med et annet program. Det er veldig rotete.
Noen optimaliseringsentusiaster kan si at bytte ikke ga noen problemer, men det er ikke bytte som gjør ytelsen øker - 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, påkalles fra kswapd prosess, og dreper generelt brukerromsprosesser. Dette er forskjellig fra OOMkiller (morder 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 et bytte, og så er bytte absolutt ikke nødvendig i Android. Implementeringen er rett og slett full av forsinkelse og fører til en nedbrytning i ytelse, i stedet for å optimalisere den.
zRAM - Utdatert og ikke lenger effektiv
zRAM er en velprøvd og effektiv metode for enhetsoptimalisering, for eldre enheter - tenk KitKat-baserte enheter som bare bruker 512 MB RAM. Det faktum at noen fremdeles inkluderer zRAM-justeringer i optimaliseringsskript, eller anbefaler zRAM som en slags moderne optimalisering, er et eksempel på at folk generelt ikke følger de nyeste operasjonsprotokollene.
zRAM var ment for inngangsnivå med flere kjerner SoC, 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 enkjernet , selv om zRAM anbefales på slike enheter, har store mengder lags en tendens til å dukke opp. Dette skjer også med KSM-teknologien ( Kernel Same Page Fletting) som kombinerer identiske minnesider i et forsøk på å frigjøre plass. Dette er faktisk anbefalt av Google, men fører til større forsinkelser på eldre enheter, fordi de konstant aktive kjernehullene kjører kontinuerlig fra minnet for å søke etter duplikatsider. I utgangspunktet forsøker enheten å kjøre optimaliseringsjusteringen, enda mer, ironisk nok.
Såmaskin - Utdatert siden Android 3.0
En av de mest omdiskuterte optimaliseringstipsene blant Android-devs er seder , og vi er sikre på at noen kan prøve å bevise oss feil om dette emnet - men først må vi undersøke såmaskinens historie.
Såmaskin-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 årsak at dette betyr at det også er en anvendelig optimalisering for moderne Android-enheter , som er helt absurd. Det at Seeder fremdeles blir vedlikeholdt og tilbys som en moderne' lagreduksjonsverktøy er et eksempel på feilinformasjon - selv om dette ikke er feilen til Seeders utvikler, da til og med deres Play Store-side bemerker at Seeder er mindre effektiv etter Android 4.0+. Likevel, uansett grunn, dukker Seeder fremdeles opp i optimaliseringsdiskusjoner for moderne Android-systemer.
Det Seeder i utgangspunktet gjør for Android 3.0, er å løse en feil der Android-kjøretid aktivt vil bruke / dev / random / filen for å skaffe seg entropi. / Dev / random / buffer ville bli ustabil, og systemet ville bli blokkert til det fylte den nødvendige mengden data - tenk på små ting som de forskjellige sensorene og knappene på Android-enheten.
Seeders forfatter tok Linux-demonen rngd , og samlet for Android's inastroil, slik at det tok tilfeldige data fra en mye raskere og mer forutsigbar / dev / urandom-bane, og slår dem sammen til dev / random / hvert sekund, uten å la / dev / random / bli utmattet. 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, fremstår fortsatt Seeder “Anbefalte justeringer” lister for optimalisering av Android-ytelse. Videre har Seeder-appen noen få analoger som sEFix som inkluderer Seeders funksjonalitet, enten de bruker det samme rngd eller alternativet har tatt , eller til og med bare en symlink mellom / dev / urandom og / dev / random. Dette er helt meningsløst for moderne Android-systemer.
Grunnen til at det er meningsløst er at 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 å generere ID for å lage EXT2 / EXT3 / EXT4-filsystemer.
Så når Såmaskin eller såmaskinbaserte forbedringer er inkludert i moderne Android-optimaliseringsskript. Det som ender med å skje er en nedbrytning i enhetsytelse, fordi rngd vil stadig vekke enheten og forårsake en økning i CPU-frekvensen, noe som selvfølgelig negativt påvirker batteriforbruket.
Odex
Aktien firmware på Android-enheter ganske mye 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 bytecode-applikasjoner som allerede har gått gjennom validatoren og den optimale virtuelle maskinen, og deretter registrert i en egen fil ved bruk av noe som dexopt verktøy.
Så odex-filer er ment å laste ned virtuell maskin og tilby en rask oppstart av odexed-applikasjonen - på nedsiden forhindrer ODEX-filer endringer i firmware, og skaper problemer med oppdateringer, så av denne grunn distribueres mange tilpassede ROM-er som LineageOS uten ODEX .
Generering av ODEX-filer gjøres på en rekke måter, som å bruke Odexer Tool - problemet er at det bare 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 det gir meldingen 'Opptatt, optimalisering av applikasjoner' en stund.
Lowmemorykiller justeringer
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 på antall bakgrunnsapper ( med mindre en er angitt i Utvikleralternativer, men dette anbefales generelt mot) - videre stoppes ikke funksjonaliteten til overgang til bakgrunnskjøring, selv om systemet forbeholder seg retten til å drepe bakgrunnsapper i lite hukommelsessituasjoner ( se hvor vi snakket om lowmemorykiller og out-of-memory killer tidligere i denne guiden) .
Å gå tilbake til lowmemorykiller kan Android fortsette å operere med en begrenset mengde minne og mangel på byttepartisjon. Brukeren kan fortsette å starte applikasjoner og veksle mellom dem, og systemet vil stille drepe ubrukte bakgrunnsapper for å prøve å frigjøre minne for aktive oppgaver.
Dette var veldig nyttig for Android i de tidlige dager, men av en eller annen grunn ble det populært i form av oppgave-killer-apper, som generelt er mer skadelige enn fordelaktige. Task-killer-apper våkner enten med bestemte intervaller, eller kjøres 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 lettere å ringe dem opp, starte dem osv. Android-systemet trenger ikke å bruke mye ressurser på å bytte til appen, fordi det allerede er der i minnet.
På grunn av dette er oppgave-drapsmenn egentlig ikke så populære som de en gang var, selv om Android-nybegynnere fremdeles pleier å stole på dem av en eller annen grunn ( mangel på informasjon, dessverre) . Dessverre har en ny trend erstattet task-killers, trenden med lowmemorykiller mekanismestemminger. Dette vil være for eksempel MinFreeManager app, og hovedideen er å øke RAM-kostnadene før systemet begynner å drepe bakgrunnsapper.
Så for eksempel fungerer standard RAM ved grenser - 4, 8, 12, 24, 32 og 40 Mb, og når den ledige lagringsplassen på 40 MB er fylt, blir en av de bufrede appene som er lastet inn i minnet men ikke kjører vil bli avsluttet.
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 sin oppryddingsprosess - noe som betyr at Android alltid vil gjøre sitt beste for å bruke den maksimale mengden tilgjengelig RAM uten å forstyrre brukeropplevelsen.
Dessverre, det noen hjemmebryggere startet anbefalt, er at verdien økes til for eksempel 100 MB før LMK sparker inn. Nå vil brukeren faktisk å tape RAM (100 - 40 = 60), så i stedet for å bruke denne plassen til å lagre back-end-apper, vil systemet beholde denne mengden minne gratis , med absolutt ingen hensikt for det.
LKM-innstilling kan være nyttig for mye eldre enheter med 512 RAM, men hvem eier dem lenger? 2 GB er det moderne 'budsjettområdet', til og med 4 GB RAM-enheter ser ut som 'mellomklasse' i disse dager, så LMK-justeringer er virkelig utdaterte og ubrukelige.
I / O-justeringer
I mange optimaliseringsskript for Android finner du ofte tilpasninger som adresserer I / O-delsystemet. La oss for eksempel se på Lyn! Skript, som inneholder disse linjene:
ekko 0> $ i / kø / rotasjon; ekko 1024> $ i / kø / nr_forespørsler;
Den første linjen vil gi I / O-planleggerinstruksjonene for å 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 med blokkenheter i / sys, og skriptet kjører i en løkke.
Etter det finner du en linje relatert til CFQ-planleggeren:
ekko 1> $ i / kø / iosched / back_seek_penalty; ekko 1> $ i / kø / iosched / lav forsinkelse; ekko 1> $ i / kø / iosched / slice_idle;
Dette følges av flere linjer som tilhører andre planleggere, men til slutt er de to første kommandoene meningsløse fordi:
En moderne Linux-kjerne er i stand til å forstå hvilken type lagringsmedium den jobber med som standard.
En lang inngangs- og utgangskø ( slik som 1024) er ubrukelig på en moderne Android-enhet, faktisk er den meningsløs selv på skrivebordet - det er egentlig bare anbefalt på tunge servere . Telefonen din er ikke en tung Linux-server.
For en Android-enhet er det praktisk talt ingen applikasjoner prioritert i inngangsutgangen og ingen mekanisk driver, så den beste planleggeren er noop / FIFO-køen, så denne typen planlegger “ finjustere ” gjør ikke noe spesielt eller meningsfylt med I / O-delsystemet. Faktisk erstattes alle disse flerskjermslistekommandoene bedre med en enkel syklus:
for i in / sys / block / mmc *; gjør ekko noop> $ i / kø / planlegger ekko 0> $ i / kø / iostatistikk ferdig
Dette ville muliggjøre noop-planleggeren for alle stasjoner fra akkumulering av I / O-statistikk, noe som burde ha en positiv innvirkning på ytelsen, selv om den er veldig liten og nesten helt ubetydelig.
En annen ubrukelig I / O-justering som ofte finnes i ytelseskripter, er de økte read-ahead-verdiene for SD-kort opp til 2 MB. Lesemekanisme er for tidlige dataavlesninger 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åndslaster den i RAM-en, noe som dermed skal redusere returtiden. Dette høres bra ut på papiret, men lese-frem-algoritmen er oftere feil , som fører til totalt unødvendige operasjoner av input-output, for ikke å nevne et høyt RAM-forbruk.
Høye leseverdier på mellom 1 - 8 MB anbefales i RAID-arrays, men for Android-enheter er det best å bare la standardverdien være 128 KB.
System for styring av virtuelt minne
En annen vanlig “optimalisering” -teknikk er innstilling av delsystemet for styring av virtuelt minne. Dette retter seg vanligvis bare mot to kjernevariabler, vm.dirty_background_ratio og vm.dirty_ratio, som er for å justere størrelsen på bufferen for lagring av 'skitne' data. Skitten data er vanligvis data som er skrevet til disken, men det er mer fremdeles i minnet og venter på å bli skrevet til disken.
Typiske justeringsverdier i både Linux-distribusjoner og Androis til VM-styringsundersystemet vil være som:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Så hva dette prøver å gjøre er at når den skitne databufferen er 10% av den totale mengden RAM, våkner den pdflush flyte og begynner å skrive data til disken - hvis operasjonen med å registrere data på disken vil være for intens , vil bufferen 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 vil være blokkert, til dataene er skrevet til disken (AKA ‘lag’).
Det du bør forstå er at selv om bufferstørrelsen når ikke 10% vil systemet automatisk sparke pdflush etter 30 sekunder. En kombinasjon av 10/20 er ganske rimelig, for eksempel på en enhet med 1 GB RAM vil dette tilsvare 100/200 MB RAM, noe som er mer enn nok når det gjelder burst-poster der hastigheten ofte er under hastighetsrekorden i systemet 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 optimaliseringsskript en hastighet så høy 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, som er helt ubrukelig for en Android-enhet, fordi den bare vil fungere under konstant innspilling på platen - noe som bare skjer på en tung Linux-server.
Lyn! Skript bruker en mer fornuftig verdi, men generelt er det fortsatt ganske meningsløst:
hvis ['$ mem' -lt 524288]; så 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 sakte internminne eller minnekort. I dette tilfellet er det rimelig å spre verdiene til variablene, det vil si å lage noe slikt:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Når et overspenningssystem skriver operasjoner, uten å måtte registrere data på platen, vil ikke det siste skifte til synkron modus, noe som gjør det mulig for applikasjoner å redusere forsinkelsen under opptak.
Ekstra ubrukelige justeringer og ytelsesinnstillinger
Det er mange flere 'optimaliseringer' der ute som virkelig ikke gjør noe. De fleste av dem har rett og slett ingen effekt overhodet, mens andre kan forbedre seg noen aspekt av ytelse, mens degraderer enheten på andre måter ( vanligvis koker det ned til ytelse vs batteridrift) .
Her er noen ekstra populære optimaliseringer som kan eller ikke kan være nyttige, avhengig av Android-systemet og enheten.
- Akselerasjon - Den lille akselerasjonen for å forbedre ytelsen og undervoltingen - sparer litt batteri.
- Databaseoptimalisering - I teorien dette bør gi en forbedring i enhetsytelsen, men det er tvilsomt.
- Zipalign - Ironisk nok, til tross for den innebygde Android SDK-funksjonen for innholdsjustering i APK-filen i butikken, kan du finne at mye programvare ikke overføres gjennom zipalign.
- Deaktiver unødvendige systemtjenester, fjern ubrukt system og sjelden brukte tredjepartsapplikasjoner. I utgangspunktet avinstallerer du bloatware.
- Tilpasset kjerne med optimaliseringer for en bestemt enhet (igjen, ikke alle kjerner er like gode).
- Har allerede beskrevet I / O planlegger noop.
- Metningsalgoritme TCP Westwood - Mer effektivt brukt i standard Android Cubic for trådløse nettverk, tilgjengelig i egendefinerte kjerner.
Ubrukelige innstillinger build.prop
LaraCraft304 fra XDA Developers forum har gjennomført en studie og funnet at et imponerende antall /system/build.prop innstillinger som anbefales for bruk 'eksperter' ikke finnes i kilden AOSP og CyanogenMod. Her er listen:
ro.ril.disable.power.collapse ro.mot.eri.losalert.forsink 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 ersist.sys.shutdown.mode ro.HomeMerker Android Utvikling 12 minutter lest
