De mest almindelige Android-optimeringsmyter afbrudt

Der er mange instruktionsvejledninger derude dedikeret til at øge Android-ydeevne og generelle tip til optimering. Nogle af dem er legitime, og andre er kun baseret på teori eller forældede operationelle metoder i Android-systemet, eller er bare almindelig vrøvl. Dette inkluderer anbefalinger til swap, værdier tilføjet til build.prop og variable ændringer i Linux-kernen.

Der er endda masser af "optimeringsskripts" derude, alt-i-én, der kan flashes. Zip, der lover at øge ydelsen, batteriets levetid og andre ting markant. Nogle af tweaks kan faktisk fungere, men et flertal er simpelthen en placebo-effekt, eller værre, faktisk har en negativ indvirkning på din enhed.

Det er ikke at sige, at folk frigiver uærlige scripts med vilje - der er bestemt falske betalte apps i Play Store, men optimeringsskripts, der er frigivet på Android-fora, er generelt velmenende, det er bare så tilfældet, at udvikleren kan blive forkert informeret, eller blot eksperimentere med forskellige optimeringstips. Desværre har en slags sneboldeffekt en tendens til at forekomme, især i “alt-i-en” -optimeringsskripts. En lille håndfuld af tweaks kan faktisk gøre noget, mens et andet sæt af tweaks i et script muligvis ikke gør noget som helst - alligevel bliver disse scripts sendt som magiske kugler uden nogen reel undersøgelse af, hvad der fungerer, og hvad der ikke gør .

Således bruger en masse alt-i-en-optimerings-scripts de samme metoder, hvoraf nogle er helt forældede eller skadelige i det lange løb. I resumé er et flertal af “alt-i-en” -optimeringsskripts intet andet end klappet sammen anbefalede tunings, uden nogen klar idé om, hvordan eller hvorfor disse optimeringer “fungerer” - brugere blinker derefter scripts og hævder, at deres ydelse pludselig er hurtigere ( når det faktisk var sandsynligvis den meget enkle handling at genstarte deres enhed, der forårsagede en øget ydelse, da alt i enhedens RAM bliver renset ud) .

I denne eksklusive artikel om Appuals vil vi fremhæve nogle af de mest almindelige anbefalinger til " optimering" af Android-ydeevne, og om de simpelthen er en myte eller en legitim finjustering for enhedens ydeevne.

Bytte rundt

Øverst på mytelisten er Android-swap - hvilket er ret absurd med hensyn til at blive betragtet som en Android-optimering. Skiftes hovedformål er at oprette og forbinde personsøgerfilen, som vil frigøre lagerplads i hukommelsen. Dette lyder fornuftigt på papir, men det er virkelig relevant for en server, der næsten ikke har nogen interaktivitet.

Når du bruger din Android-telefons swap regelmæssigt, vil det føre til alvorlige forsinkelser, der stammer fra ting, der glider forbi cachen. Forestil dig for eksempel, hvis en applikation forsøger at få vist en grafik, der er gemt i swap, som nu skal indlæse disken igen efter at have frigivet plads ved at placere data swap med et andet program. Det er virkelig rodet.

Nogle optimeringsentusiaster kan sige, at swap ikke gav nogen problemer, men det er ikke swap, der gør ydeevnen øget - det er den indbyggede Android-mekanisme lowmemorykiller, der regelmæssigt dræber oppustede, højprioriterede processer, der ikke bruges. LMK blev designet specifikt til at håndtere forhold med lav hukommelse, påberåbes fra kswapd- processen og dræber generelt pladspladser . Dette er forskelligt fra OOMkiller (mord uden for hukommelsen), men det er helt andet et andet emne.

Pointen er, at en enhed med for eksempel 1 GB RAM aldrig kan nå de nødvendige ydelsesdata i en swap, og derfor er swap absolut ikke nødvendigt i Android. Dens implementering er simpelthen fyldt med forsinkelse og fører til en forringelse i ydelsen snarere end at optimere den.

zRAM - Forældet og ikke længere effektivt

zRAM er en gennemprøvet og effektiv metode til enhedsoptimering til ældre enheder - tænk på KitKat-baserede enheder, der kun fungerer på cirka 512 MB RAM. Det faktum, at nogle mennesker stadig inkluderer zRAM-finjusteringer i optimerings-scripts, eller anbefaler zRAM som en slags moderne optimerings-justering, er et eksempel på, at folk generelt ikke følger de seneste operationelle protokoller.

zRAM var beregnet til entry-level budget-række multi-core SoC'er, såsom enheder, der anvender MTK-chipsæt og 512 MB RAM. Meget billige kinesiske telefoner, dybest set. Hvad zRAM dybest set gør, er at adskille kernen via krypteringsstrømmen.

Når zRAM bruges på ældre enheder med en enkelt kerne, selvom zRAM anbefales på sådanne enheder, har store mængder forsinkelser en tendens til at vokse op. Dette sker også med KSM-teknologien ( Kernel Same Page Fusion), som kombinerer identiske hukommelsessider i et forsøg på at frigøre plads. Dette anbefales faktisk af Google, men fører til større forsinkelser på ældre enheder, fordi de konstant aktive kernetråd løber kontinuerligt fra hukommelse til at søge efter duplikatsider. Grundlæggende er det, ironisk nok, at forsøge at køre optimeringsjusteringen nedsætte enheden yderligere.

Seeder - forældet siden Android 3.0

Et af de mest omdiskuterede optimeringstips blandt Android-devs er seeder, og vi er sikre på, at nogen kunne prøve at bevise, at vi er forkert på dette emne - men først skal vi undersøge seederens historie.

Ja, der er et stort antal rapporter, der erklærer bedre Android-ydelse efter installation på meget ældre Android-enheder . Imidlertid tror folk uanset hvad dette betyder, at det også er en relevant optimering til moderne Android-enheder, hvilket er absolut absurd. Det faktum, at Seeder stadig vedligeholdes og tilbydes som et " moderne" lagreduktionsreduceringsværktøj, er et eksempel på fejlagtig information - selvom dette ikke er Feeder's udvikler skyld, da selv deres Play Store-side bemærker, at Seeder er mindre effektiv efter Android 4.0+. Men uanset af hvilken grund dukker Seeder stadig op i optimeringsdiskussioner til moderne Android-systemer.

Hvad Seeder stort set gør for Android 3.0, er at adressere en fejl, hvor Android-runtime aktivt vil bruge / dev / random / filen til at erhverve entropi. / Dev / random / buffer ville blive ustabil, og systemet vil blive blokeret, indtil det fyldte den krævede mængde data - tænk på små ting som de forskellige sensorer og knapper på Android-enheden.

Seeder's forfatter tog Linux-demon rngd og kompilerede til Android's katastrofale, så det tog tilfældige data fra en meget hurtigere og mere forudsigelig / dev / urandom-sti og fusionerer dem til dev / random / hvert sekund uden at tillade / dev / random / at blive udmattet. Dette resulterede i et Android-system, der ikke oplevede en mangel på entropi og udførte meget glattere.

Google knuste denne fejl efter Android 3.0, men af ​​en eller anden grund dukker Seeder stadig frem på "anbefalede tweaks" -lister til optimering af Android-ydeevne. Seeder-appen har endvidere et par analoger som sEFix, der inkluderer Seeders funktionalitet, uanset om de bruger den samme rngd eller det alternative haveged, eller endda bare en symlink mellem / dev / urandom og / dev / random. Dette er absolut meningsløst for moderne Android-systemer.

Årsagen til at det er meningsløst, er fordi nyere Android-versioner bruger / dev / random / i tre hovedkomponenter - libcrypto, til kryptering af SSL-forbindelser, generering af SSH-nøgler osv. WPA_supplication / hostapd, som genererer WEP / WPA-nøgler, og til sidst en håndfuld biblioteker til generering af ID ved oprettelse af EXT2 / EXT3 / EXT4 filsystemer.

Så når Seeder- eller Seeder-baserede forbedringer er inkluderet i moderne Android-optimeringsskripts, er det, der ender med at ske, en nedbrydning i enhedens ydeevne, fordi rngd konstant vil vække enheden og forårsage en stigning i CPU-frekvens, hvilket naturligvis påvirker batteriforbruget negativt .

ODEX

Aktien firmware på Android-enheder stort set altid odex. Dette betyder, at ved siden af ​​standardpakken til Android-apps i APK-format, der findes i / system / app / og / system / priv-app /, har de samme filnavne med .odex-udvidelsen. Odex-filerne indeholder optimerede bytecode-applikationer, som allerede er passeret gennem validatoren og den optimale virtuelle maskine, derefter registreret i en separat fil ved hjælp af noget som dexopt- værktøj.

Så odex-filer er beregnet til at downloade virtuel maskine og tilbyde en hurtig opstart af det odexed-program - på den nederste side forhindrer ODEX-filer ændringer af firmwaren og skaber problemer med opdateringer, så af denne grund distribueres mange tilpassede ROM'er som LineageOS uden ODEX .

Generering af ODEX-filer udføres på en række måder, som at bruge Odexer Tool - problemet er, at det rent er en placebo-effekt. Når moderne Android-system ikke finder odex-filer i / system-biblioteket, opretter systemet faktisk dem og placerer dem i / system / dalvik-cache / biblioteket. Dette er nøjagtigt, hvad der sker, når du for eksempel blinker en ny Android-version, og den giver meddelelsen "Optaget, optimerer applikationer" i et stykke tid.

Lavmemorykiller tilpasninger

Multitasking i Android adskiller sig fra andre mobile operativsystemer i den forstand, at det er baseret på en klassisk model, hvor applikationer fungerer roligt i baggrunden, og der er ingen begrænsninger på antallet af baggrundsapps ( medmindre en er indstillet i Developer Options, men dette er generelt anbefalet imod) - Yderligere stoppes funktionaliteten ved overgang til en baggrundsudførelse ikke, selvom systemet forbeholder sig retten til at dræbe baggrundsapps i situationer med lav hukommelse ( se hvor vi talte om lavmemorykiller og dræber uden hukommelse tidligere i dette guide) .

For at vende tilbage til lowmemorykiller- mekanismen kan Android fortsætte med at operere med en begrænset mængde hukommelse og en mangel på swap-partition. Brugeren kan fortsætte med at starte applikationer og skifte mellem dem, og systemet dræber lydløst ubrugte baggrundsapps for at prøve at frigøre hukommelse til aktive opgaver.

Dette var meget nyttigt for Android i de tidlige dage, selvom det af en eller anden grund blev populært i form af task-killer-apps, som generelt er mere skadelige end gavnlige. Task-killer-apps vågner enten med bestemte intervaller eller køres af brugeren og ser ud til at frigøre store mængder RAM, hvilket ses som et positivt - mere gratis RAM betyder en hurtigere enhed, ikke? Dette er dog ikke nøjagtigt tilfældet med Android.

Faktisk kan det at have en stor mængde gratis RAM faktisk være skadeligt for enhedens ydelse og batteriets levetid. Når apps gemmes i Android's RAM, er det meget lettere at kalde dem op, starte dem osv. Android-systemet behøver ikke at bruge mange ressourcer på at skifte til appen, fordi det allerede er der i hukommelsen.

På grund af dette er task-killers ikke rigtig så populære, som de engang var, skønt Android-nybegyndere stadig er afhængige af dem af en eller anden grund ( mangel på information, desværre) . Desværre har en ny tendens erstattet task-killers, tendensen med lowmemorykiller- mekanismestillinger. Dette ville være f.eks. MinFreeManager- appen, og hovedideen er at øge RAM-overhead, før systemet begynder at dræbe baggrundsapps.

Så for eksempel fungerer standard RAM ved grænserne - 4, 8, 12, 24, 32 og 40 Mb, og når den frie lagerplads på 40 MB er fyldt, kører en af ​​de cache-apps, der indlæses i hukommelsen, men ikke kører afsluttes.

Så dybest set vil Android altid have mindst 40 MB tilgængelig hukommelse, hvilket er nok til at rumme et program mere, før lowmemorykiller starter sin oprydningsproces - hvilket betyder, at Android altid vil gøre sit bedste for at bruge den maksimale mængde tilgængelig RAM uden at forstyrre brugererfaring.

Desværre er det, hvad nogle hjemmebryggeri-entusiaster startede at anbefale, at værdien hæves til f.eks. 100 MB før LMK starter. Nu vil brugeren faktisk miste RAM (100 - 40 = 60), så i stedet for at bruge denne plads til at gemme tilbage- slut apps, vil systemet holde denne mængde hukommelse fri, og det er absolut ikke noget formål med det.

LKM-tuning kan være nyttigt til meget ældre enheder med 512 RAM, men hvem ejer dem længere? 2 GB er det moderne "budgetinterval", selv 4GB RAM-enheder betragtes som "mellemklasse" i disse dage, så LMK-justeringer er virkelig forældede og ubrugelige.

I / O tilpasninger

I en masse optimeringsskripts til Android finder du ofte justeringer, der adresserer I / O-undersystemet. Lad os f.eks. Se på ThunderBolt! Script, der indeholder disse linjer:

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

Den første linje giver I / O-planlægningsinstruktionerne til håndtering af en SSD, og ​​den anden øger den maksimale størrelse af køens I / O fra 128 til 1024 - fordi $ i-variablen indeholder en sti til træet af blok enheder i / sys, og scriptet kører i en løkke.

Efter dette finder du en linje relateret til CFQ-planlæggeren:

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

Dette efterfølges af flere linjer, der hører til andre planlæggere, men i sidste ende er de to første kommandoer meningsløse, fordi:

En moderne Linux-kerne er i stand til at forstå, hvilken type lagringsmedium den arbejder med som standard.

En lang kø for input-output ( som f.eks. 1024) er ubrugelig på en moderne Android-enhed, faktisk er den meningsløs, selv på skrivebordet - den anbefales egentlig kun på tunge servere . Din telefon er ikke en heavy duty Linux-server.

For en Android-enhed er der praktisk talt ingen applikationer, der er prioriteret i input-output og ingen mekanisk driver, så den bedste planlægger er noop / FIFO-køen, så denne type scheduler “ tweak” gør ikke noget specielt eller meningsfuldt for I / O-undersystem. Faktisk er alle disse multi-skærm listekommandoer bedre erstattet af en simpel cyklus:

 for i in / sys / block / mmc *; do echo noop> $ i / kø / scheduler echo 0> $ i / kø / iostats udført 

Dette ville muliggøre noop-planlægningen for alle drev fra akkumulering af I / O-statistikker, hvilket skulle have en positiv indvirkning på ydelsen, skønt en meget lille og næsten fuldstændig ubetydelig.

En anden ubrugelig I / O-finjustering, der ofte findes i performance-scripts, er de øgede læseværdier for SD-kort op til 2 MB. Læsemekanisme er til tidlige datalæsninger fra medierne, før appen anmoder om adgang til disse data. Så dybest set vil kernen forsøge at finde ud af, hvilke data der er brug for i fremtiden, og forindlæser dem i RAM, hvilket således bør reducere returtiden. Dette lyder godt på papiret, men algoritmen, der læses frem, er oftere forkert, hvilket fører til totalt unødvendige operationer af input-output, for ikke at nævne et stort RAM-forbrug.

Høje læseværdier mellem 1 - 8 MB anbefales i RAID-arrays, men for Android-enheder er det bedst at bare lade standardværdien på 128 KB ligge.

Virtuelt hukommelsesstyringssystem justeres

En anden almindelig "optimering" -teknik er indstilling af det undersystem til virtuel hukommelsesadministration. Dette er typisk kun målrettet mod to kernevariabler, vm.dirty_background_ratio og vm.dirty_ratio, som er til justering af størrelsen på bufferen til lagring af "beskidte" data. Beskidte data er typisk data, der er skrevet til disk, men der er mere i hukommelsen og venter på at blive skrevet til disk.

Typiske finjusteringsværdier i både Linux-distros og Androis til VM-styringsundersystemet ville være som:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Så hvad dette forsøger at gøre, er, at når den beskidte databuffer er 10% af den samlede mængde RAM, vækker den pdflush- strømmen og begynder at skrive data til disken - hvis driften af ​​optagelsesdata på disken vil være for intens, bufferen vil fortsætte med at vokse, og når den når 20% af tilgængelig RAM, skifter systemet til den efterfølgende skriveoperation i synkron tilstand - uden forbuffer. Dette betyder, at arbejdet med at skrive til diskapplikation blokeres, indtil dataene er skrevet til disk (AKA 'lag').

Hvad du skal forstå, er, at selvom bufferstørrelsen ikke når 10%, vil systemet automatisk sparke pdflush efter 30 sekunder. En kombination af 10/20 er temmelig rimelig, for eksempel på en enhed med 1 GB RAM ville dette svare til 100/200 MB RAM, hvilket er mere end nok i form af burst-poster, hvor hastigheden ofte er under hastighedsrekorden i system NAND -hukommelse eller SD-kort, f.eks. når du installerer apps eller kopierer filer fra en computer.

Af en eller anden grund forsøger manusforfattere at skubbe denne værdi endnu højere til absurde satser. For eksempel kan vi i Xplix- optimeringsskriptet finde en hastighed, der er så høj som 50/90.

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

På en enhed med 1 GB hukommelse sætter dette grænsen for en beskidt buffer til 500/900 MB, hvilket er helt ubrugeligt for en Android-enhed, fordi det kun ville arbejde under konstant optagelse på disken - noget der kun sker på en tung Linux-server.

Lyn! Script bruger en mere fornuftig værdi, men samlet set er den stadig ret meningsløs:

 hvis ["$ mem" -lt 524288]; derefter sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; derefter 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 kommandoer køres på smartphones med 512 MB RAM, den anden - med 1 GB og andre - med mere end 1 GB. Men faktisk er der kun en grund til at ændre standardindstillingerne - en enhed med en meget langsom intern hukommelse eller hukommelseskort. I dette tilfælde er det rimeligt at sprede værdierne for variablerne, det vil sige at fremstille noget lignende:

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

Når et overspændingssystem derefter skriver operationer, uden at skulle registrere data på disken, skifter op til det sidste ikke til synkron tilstand, hvilket giver applikationer mulighed for at reducere forsinkelse under optagelse.

Yderligere brugbare Tweaks og Performance Tunings

Der er meget mere "optimeringer" derude, der virkelig ikke gør noget. De fleste af dem har simpelthen ingen virkning, mens andre kan forbedre et aspekt af ydeevnen, mens de forringer enheden på andre måder ( normalt koger det ned til ydelse kontra batteriafløb) .

Her er nogle yderligere populære optimeringer, der måske eller måske ikke er nyttige, afhængigt af Android-systemet og enheden.

• Acceleration - Den lille acceleration for at forbedre ydelsen og undervolting - sparer lidt batteri.
• Databaseoptimering - I teorien skulle dette give en forbedring i enhedsydelsen, men det er tvivlsomt.
• Zipalign - Ironisk nok kan du trods den indbyggede Android SDK-indholdsindretning i APK-filen i butikken finde en masse software, der ikke transmitteres via zipalign.
• Deaktiver unødvendige systemtjenester, fjern ubrugte systemer og sjældent anvendte tredjepartsapplikationer. Grundlæggende afinstallation af bloatware.
• Tilpasset kerne med optimeringer til en bestemt enhed (igen, ikke alle kerner er lige så gode).
• Allerede beskrevet I / O-scheduler noop.
• Mætning algoritme TCP Westwood - Mere effektivt brugt i standard Android Cubic til trådløse netværk, tilgængelig i brugerdefinerede kerner.

Useless indstillinger build.prop

LaraCraft304 fra XDA Developers forum har foretaget en undersøgelse og fundet, at et imponerende antal /system/build.prop-indstillinger, der anbefales til brug af ”eksperter” ikke findes 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.shutAPPode.mode