Således bruger mange alt-i-en-optimeringsskripter de samme metoder, hvoraf nogle er fuldstændig forældede eller skadelige i det lange løb. Sammenfattende er et flertal af 'alt-i-en' -optimeringsscripts intet andet end at slå sammen anbefalede tuninger uden nogen klar idé om, hvordan eller hvorfor disse optimeringer 'fungerer - brugerne blinker derefter scripts og hævder, at deres præstationer pludselig er hurtigere ( når det faktisk var højst sandsynligt den meget enkle handling at genstarte deres enhed, der forårsagede en præstationsforøgelse , da alt i enhedens RAM bliver renset) .
I denne eksklusive artikel for Appuals fremhæver vi nogle af de mest almindelige anbefalinger til ' optimering ” Android-ydeevne, og om de simpelthen er en myte eller en legitim tweak 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. Swaps hovedformål er at oprette og forbinde personsøgningsfilen, som frigør lagerplads i hukommelsen. Dette lyder fornuftigt på skrift , men det er virkelig anvendeligt til en server , som næsten ikke har 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 et program forsøger at vise en grafik, der er gemt i swap, som nu skal genindlæse disken efter frigørelse af plads ved at placere data swap med en anden applikation. Det er virkelig rodet.
Nogle optimeringsentusiaster kan sige, at swap ikke gav nogen problemer, men det byttes ikke, hvilket gør ydeevnen forbedret - det er den indbyggede Android-mekanisme lowmemorykiller , som regelmæssigt dræber oppustede processer med høj prioritet, som ikke bruges. LMK blev designet specielt til håndtering af hukommelsesforhold, kaldes fra kswapd proces og dræber generelt brugerrumsprocesser. Dette er forskelligt fra OOMkiller (morder uden for hukommelsen), men det er et helt andet emne.
Pointen er, at en enhed med for eksempel 1 GB RAM aldrig kan nå de nødvendige præstationsdata i en swap, og så swap er absolut ikke nødvendigt i Android. Dens gennemførelse er simpelthen fyldt med forsinkelse og fører til en nedbrydning i ydelse snarere end at optimere det.
zRAM - Forældet og ikke længere effektiv
zRAM er en gennemprøvet og effektiv metode til enhedsoptimering til ældre enheder - tænk KitKat-baserede enheder, der kun fungerer på ca. 512 MB RAM. Det faktum, at nogle mennesker stadig inkluderer zRAM-tweaks i optimeringsskripter eller anbefaler zRAM som en slags moderne optimering, er et eksempel på, at folk generelt ikke følger de nyeste operationelle protokoller.
zRAM var beregnet til entry-level budget-range multi-core SoC'er, såsom enheder, der bruger MTK chipsæt og 512 MB RAM. Meget billige kinesiske telefoner, dybest set. Hvad zRAM grundlæggende 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 tendens til at dukke op. Dette sker også med KSM-teknologien ( Kerne Samme side fletning) 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 kernehoveder kører kontinuerligt fra hukommelsen for at søge efter duplikatsider. Dybest set forsøger en ironisk forsøg på at køre optimeringsknappen enheden endnu længere.
Såmaskine - forældet siden Android 3.0
Et af de mest debatterede optimeringstip blandt Android-devs er ceder , og vi er sikre på, at nogen kan prøve at bevise os forkert om dette emne - men først skal vi undersøge såmaskinens historie.
Såmaskine-app til Android
Ja, der er et stort antal rapporter, der erklærer bedre Android-ydeevne efter installation på meget ældre Android-enheder . Men uanset årsagen mener folk, at det betyder, at det også er en anvendelig optimering til moderne Android-enheder , hvilket er absolut absurd. Det faktum, at såmaskine stadig vedligeholdes og tilbydes som en ” moderne' lagreduktionsværktøj er et eksempel på misinformation - skønt dette ikke er Seeder's udvikleres skyld, da selv deres Play Butik-side bemærker, at Seeder er mindre effektiv efter Android 4.0+. Men uanset årsag dukker Seeder stadig op i optimeringsdiskussioner til moderne Android-systemer.
Hvad Seeder grundlæggende gør for Android 3.0 er at adressere en fejl, hvor Android-runtime aktivt bruger / dev / random / filen til at erhverve entropi. / Dev / tilfældig / buffer ville blive ustabil, og systemet ville blive blokeret, indtil det fyldte den nødvendige mængde data - tænk på små ting som de forskellige sensorer og knapper på Android-enheden.
Seeders forfatter tog Linux-dæmonen rngd og kompileret til Android's inastroil, så det tog tilfældige data fra en meget hurtigere og mere forudsigelig / dev / urandom-sti og flettede dem til dev / random / hvert sekund uden at tillade / dev / random / at blive opbrugt. Dette resulterede i et Android-system, der ikke oplevede mangel på entropi og udførte meget glattere.
Google smadrede denne fejl efter Android 3.0, men af en eller anden grund dukker Seeder stadig op “Anbefalede tweaks” lister til optimering af Android-ydeevne. Desuden har Seeder-appen et par analoger som sEFix, som inkluderer Seeders funktionalitet, uanset om de bruger det samme rngd eller alternativet haveged , eller endda bare et symlink mellem / dev / urandom og / dev / random. Dette er absolut meningsløst for moderne Android-systemer.
Årsagen til dens meningsløse er, at nyere Android-versioner bruger / dev / tilfældig / i tre hovedkomponenter - libcrypto , til kryptering af SSL-forbindelser, generering af SSH-nøgler osv. WPA_supplication / hostapd, der genererer WEP / WPA-nøgler, og endelig en håndfuld biblioteker til generering af ID til oprettelse af EXT2 / EXT3 / EXT4-filsystemer.
Så når Såmaskine eller såmaskinebaserede forbedringer er inkluderet i moderne Android-optimeringsskripter, hvad der ender med at ske er en nedbrydning i enhedens ydeevne, fordi rngd vil konstant vække enheden og forårsage en stigning i CPU-frekvensen, hvilket naturligvis påvirker batteriforbruget negativt.
Odex
Aktien firmware på Android-enheder odex stort set altid. 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 den virtuelle validator og optimizer-maskine og derefter optaget 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 hurtigere lancering af odexed-applikationen - på ulempen forhindrer ODEX-filer ændringer i firmwaren og skaber problemer med opdateringer, så af denne grund distribueres mange brugerdefinerede ROM'er som LineageOS uden ODEX .
Generering af ODEX-filer sker på en række måder, som ved hjælp af Odexer Tool - problemet er, at det rent placebo-effekt er. 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 præcis, hvad der sker, når du for eksempel blinker en ny Android-version, og det giver meddelelsen 'Optaget, optimering af applikationer' i et stykke tid.
Lavmemorykiller tweaks
Multitasking i Android adskiller sig fra andre mobile operativsystemer i den forstand, at det er baseret på en klassisk model, hvor applikationer fungerer stille i baggrunden, og der er ingen begrænsninger for antallet af baggrundsapps ( medmindre en er angivet i Udviklerindstillinger, men dette anbefales generelt mod) - desuden stoppes ikke funktionaliteten i overgangen til en baggrundsudførelse, selvom systemet forbeholder sig retten til at dræbe baggrundsapps i situationer med lav hukommelse ( se hvor vi talte om lowmemorykiller og out-of-memory dræber tidligere i denne vejledning) .
At gå tilbage til lowmemorykiller mekanisme, kan Android fortsætte med at operere med en begrænset mængde hukommelse og mangel på swap-partition. Brugeren kan fortsætte med at starte applikationer og skifte mellem dem, og systemet dræber lydløst ubrugte baggrundsapps stille 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 op 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 en stor mængde gratis RAM faktisk være skadeligt for din enheds ydeevne og batterilevetid. Når apps er gemt i Android's RAM, er det meget nemmere at kalde dem op, starte dem osv. Android-systemet behøver ikke bruge meget 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, selvom Android-nybegyndere stadig har en tendens til at stole på dem af en eller anden grund ( mangel på information, desværre) . Desværre har en ny tendens erstattet task-killers, trenden med lowmemorykiller mekanismeindstillinger. Dette ville være for eksempel MinFreeManager app, og hovedideen er at øge RAM-omkostningerne, inden systemet begynder at dræbe baggrundsapps.
Så for eksempel fungerer standard RAM ved grænser - 4, 8, 12, 24, 32 og 40 Mb, og når den ledige lagerplads på 40 MB er fyldt, er en af de cachelagrede apps, der er indlæst i hukommelsen men ikke kører vil blive opsagt.
Så dybest set vil Android altid have mindst 40 MB ledig hukommelse, hvilket er nok til at rumme endnu en applikation før lowmemorykiller begynder 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 brugeroplevelsen.
Desværre anbefales det, som nogle homebrew-entusiaster startede, at værdien hæves til for eksempel 100 MB, før LMK sparker ind. Nu vil brugeren faktisk tabe RAM (100 - 40 = 60), så i stedet for at bruge denne plads til at gemme back-end-apps, vil systemet beholde denne mængde hukommelse ledig med intet formål med det.
LKM-indstilling kan være nyttigt til meget ældre enheder med 512 RAM, men hvem ejer dem længere? 2 GB er det moderne 'budgetområde', selv 4 GB RAM-enheder betragtes som 'mellemklasse' i disse dage, så LMK-tweaks er virkelig forældede og ubrugelige.
I / O-tilpasninger
I mange optimeringsscripts til Android finder du ofte tweaks, der adresserer I / O-undersystemet. Lad os f.eks. Se på Lyn! Script, som indeholder disse linjer:
ekko 0> $ i / kø / rotation; ekko 1024> $ i / kø / nr_forespørgsler;
Den første linje giver I / O-planlægningsinstruktioner i håndtering af en SSD, og den anden øger den maksimale størrelse på kø-I / O fra 128 til 1024 - fordi $ i-variablen indeholder en sti til træet med blokkenheder i / sys, og scriptet kører i en løkke.
Derefter finder du en linje relateret til CFQ-planlæggeren:
ekko 1> $ i / kø / iosched / back_seek_penalty; ekko 1> $ i / kø / iosched / lav forsinkelse; ekko 1> $ i / kø / iosched / slice_idle;
Dette efterfølges af flere linjer, der tilhører andre planlæggere, men i sidste ende er de to første kommandoer meningsløse, fordi:
En moderne Linux-kerne er som standard i stand til at forstå, hvilken type lagringsmedie den arbejder med.
En lang input-output kø ( såsom 1024) er ubrugelig på en moderne Android-enhed, faktisk er den meningsløs selv på skrivebordet - det anbefales kun den tunge servere . Din telefon er ikke en tung Linux-server.
For en Android-enhed er der næsten ingen applikationer prioriteret i input-output og ingen mekanisk driver, så den bedste planlægger er noop / FIFO-køen, så denne type planlægger “ tweak ” gør ikke noget særligt eller meningsfuldt til I / O-undersystemet. Faktisk erstattes alle disse kommandoer med flere skærmlister bedre med en simpel cyklus:
for i in / sys / blok / mmc *; gør ekko noop> $ i / kø / planlægger ekko 0> $ i / kø / iostatik færdig
Dette ville muliggøre noop-planlæggeren for alle drev fra akkumulering af I / O-statistikker, hvilket burde have en positiv indvirkning på ydeevnen, selvom den er meget lille og næsten fuldstændig ubetydelig.
En anden ubrugelig I / O-tilpasning, der ofte findes i performance-scripts, er de øgede read-ahead-værdier for SD-kort op til 2 MB. Read-ahead-mekanisme 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 vil være behov for i fremtiden, og forindlæser dem i RAM'en, hvilket således skal reducere returtiden. Dette lyder godt på papir, men den read-ahead algoritme er oftere forkert , hvilket fører til totalt unødvendige operationer af input-output, for ikke at nævne et højt RAM-forbrug.
Høje read-ahead-værdier på mellem 1 - 8 MB anbefales i RAID-arrays, men for Android-enheder er det bedst at bare lade standardværdien på 128 KB være.
Virtuelt hukommelsesstyringssystem tilpasser
En anden almindelig 'optimerings' -teknik er tuning af det virtuelle hukommelsesstyringsundersystem. 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. Snavset data er typisk data, der er skrevet til disken, men der er mere stadig i hukommelsen og venter på at blive skrevet til disken.
Typiske justeringsværdier i både Linux-distroer og Androis til VM-styringsundersystemet vil 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ågner den pdflush flow og begynder at skrive data til disken - hvis funktionen til optagelse af data på disken vil være for intens , vil bufferen fortsætte med at vokse, og når den når 20% af det tilgængelige RAM, skifter systemet til den efterfølgende skriveoperation i synkron tilstand - uden præbuffer. Dette betyder, at arbejdet med at skrive til diskapplikationen vil være blokeret, indtil dataene er skrevet til disken (AKA 'lag').
Hvad du skal forstå er, at selvom bufferstørrelsen når ikke 10% , vil systemet automatisk sparke pdflush efter 30 sekunder. En kombination af 10/20 er ret rimelig, for eksempel på en enhed med 1 GB RAM svarer dette til 100/200 MB RAM, hvilket er mere end nok med hensyn til burst-poster, hvor hastighed ofte er under hastighedsregistreringen i systemet 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 manuskriptforfattere at skubbe denne værdi endnu højere til absurde priser. For eksempel kan vi finde i Xplix optimeringsscript en hastighed 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 snavset buffer til 500/900 MB, hvilket er helt ubrugeligt for en Android-enhed, fordi det kun fungerer under konstant optagelse på disken - noget der kun sker på en tung Linux-server.
Lyn! Script bruger en mere rimelig værdi, men generelt er den stadig ret meningsløs:
hvis ['$ mem' -lt 524288]; så 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 første to 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 én grund til at ændre standardindstillingerne - en enhed med en meget langsom intern hukommelse eller et hukommelseskort. I dette tilfælde er det rimeligt at sprede værdierne af variablerne, dvs. lave noget som dette:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Derefter, når et overspændingssystem skriver operationer uden at skulle registrere data på disken, skifter op til det sidste ikke til synkron tilstand, hvilket gør det muligt for applikationer at reducere forsinkelsen under optagelse.
Yderligere ubrugelige tweaks og performance tunings
Der er mange flere 'optimeringer' derude, der virkelig ikke gør noget. De fleste af dem har simpelthen ingen effekt overhovedet, mens andre kan forbedre sig nogle aspekt af ydeevne, mens enheden nedbrydes på andre måder ( normalt koger det ned til ydeevne vs batteridrænning) .
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 til forbedring af ydeevne og undervolt - sparer lidt batteri.
- Databaseoptimering - I teorien dette skulle gerne giver en forbedring af enhedens ydeevne, men det er tvivlsomt.
- Zipalign - Ironisk nok, på trods af den indbyggede Android SDK-funktion tilpasning af indhold i APK-filen i butikken, kan du finde, at meget software ikke overføres via zipalign.
- Deaktiver unødvendige systemtjenester, fjern ubrugt system 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ætningsalgoritme TCP Westwood - Mere effektivt brugt i standard Android Cubic til trådløse netværk, tilgængelig i brugerdefinerede kerner.
Ubrugelige indstillinger build.prop
LaraCraft304 fra XDA Developers forum har gennemført 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.forsinkelse 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.HomeMærker Android Udvikling 12 minutter læst
