Vanligaste Android Optimeringsmyter debunked

Således använder många allt-i-ett-optimeringsskript samma metoder, varav några är helt föråldrade eller skadliga på lång sikt. Sammanfattningsvis är en majoritet av 'allt-i-ett' -optimeringsskript inget annat än rekommenderade stämningar som släppts ihop, utan någon tydlig uppfattning om hur eller varför dessa optimeringar 'fungerar - användarna blinkar sedan manusen och hävdar att deras prestanda plötsligt är snabbare ( när det i själva verket var det troligtvis den mycket enkla åtgärden att starta om sin enhet som orsakade en prestationsökning , eftersom allt i enhetens RAM rensas bort) .

I den här exklusiva artikeln kommer vi att lyfta fram några av de vanligaste rekommendationerna för ' optimerande' Android-prestanda, och om de helt enkelt är en myt eller en legitim tweak för enhetsprestanda.

Byta

Högst upp på mytlistan är Android-bytet - vilket är ganska absurt när det gäller att betraktas som en Android-optimering. Swaps huvudsyfte är att skapa och ansluta personsökningsfilen, vilket frigör lagringsutrymme i minnet. Det låter förnuftigt på papper , men det är verkligen tillämpligt på en server , som nästan inte har någon interaktivitet.

När du använder din Android-telefons byte regelbundet leder det till allvarliga förseningar som härrör från saker som glider förbi cachen. Tänk dig till exempel om ett program försöker visa en grafik som är lagrad i swap, som nu måste ladda om skivan efter att ha frigjort utrymme genom att placera data swap med ett annat program. Det är verkligen rörigt.

Vissa optimeringsentusiaster kan säga att swap inte gav några problem, men det är inte att byta vilket gör prestandaförhöjningarna - det är den inbyggda Android-mekanismen lowmemorykiller , som regelbundet dödar uppblåsta, högprioriterade processer som inte används. LMK designades speciellt för hantering av lågminnesförhållanden, åberopas från kswapd process och dödar i allmänhet användarutrymme. Detta skiljer sig från OOMkiller (mördare utom minnet), men det är ett helt annat ämne.

Poängen är att en enhet med till exempel 1 GB RAM aldrig kan nå de nödvändiga prestandadata i ett swap, och så swap behövs absolut inte i Android. Dess genomförande är helt enkelt full av fördröjning och leder till en degradering i prestanda, snarare än att optimera det.

zRAM - Föråldrad och inte längre effektiv

zRAM är en beprövad och effektiv metod för enhetsoptimering för äldre enheter - tänk KitKat-baserade enheter som bara fungerar på cirka 512 MB RAM-minne. Det faktum att vissa fortfarande inkluderar zRAM-tweaks i optimeringsskript, eller rekommenderar zRAM som någon form av modern optimering, är ett exempel på att människor i allmänhet inte följer de senaste operativa protokollen.

zRAM var tänkt för budgetkomponenter med flera kärnor, så som enheter som använder MTK-chipsets och 512 MB RAM-minne. Mycket billiga kinesiska telefoner, i grund och botten. Vad zRAM i princip gör är att separera kärnan via krypteringsströmmen.

När zRAM används på äldre enheter med en enda kärna , även om zRAM rekommenderas på sådana enheter, tenderar stora mängder fördröjningar att dyka upp. Detta händer också med KSM-tekniken ( Kärna Samma sida sammanslagning) som kombinerar identiska minnessidor i ett försök att frigöra utrymme. Detta rekommenderas faktiskt av Google, men leder till större fördröjningar på äldre enheter, eftersom de ständigt aktiva kärnhuvudena körs kontinuerligt från minnet för att söka efter dubbla sidor. I grund och botten försöker enheten köra optimeringsjusteringen enheten ytterligare, ironiskt nog.

Seeder - Föråldrad sedan Android 3.0

En av de mest debatterade optimeringstipsen för Android-utvecklare är ceder , och vi är säkra på att någon kan försöka bevisa att vi har fel om detta ämne - men först måste vi granska såmaskinens historia.

Såmaskin-app för Android

Ja, det finns ett stort antal rapporter som förklarar bättre Android-prestanda efter installationen på mycket äldre Android-enheter . Men människor oavsett anledning tror att det betyder att det också är en tillämplig optimering för moderna Android-enheter , vilket är helt absurt. Att Seeder fortfarande upprätthålls och erbjuds som ett ” modern' lagreduktionsverktyg är ett exempel på felinformation - även om detta inte är Seeders utvecklares fel, eftersom även deras Play Store-sida noterar att Seeder är mindre effektiv efter Android 4.0+. Men oavsett anledning dyker Seeder fortfarande upp i optimeringsdiskussioner för moderna Android-system.

Vad Seeder i grund och botten gör för Android 3.0 är att ta itu med ett fel där Android-körning aktivt skulle använda / dev / random / filen för att skaffa entropi. / Dev / slumpmässig / buffert skulle bli instabil och systemet skulle blockeras tills det fyllde den erforderliga mängden data - tänk på små saker som de olika sensorerna och knapparna på Android-enheten.

Seeders författare tog Linux-demonen rngd , och sammanställts för Androids inastroil så att det tog slumpmässiga data från en mycket snabbare och mer förutsägbar / dev / urandom-väg, och slår samman dem till dev / random / varje sekund, utan att tillåta / dev / random / att bli uttömda. Detta resulterade i ett Android-system som inte upplevde brist på entropi, och utförde mycket mjukare.

Google krossade detta fel efter Android 3.0, men av någon anledning dyker Seeder fortfarande upp “Rekommenderade tweaks” listor för optimering av Android-prestanda. Dessutom har Seeder-appen några analoger som sEFix som inkluderar Seeders funktionalitet, oavsett om de använder samma rngd eller alternativet har tagit , eller till och med bara en symlänk mellan / dev / urandom och / dev / random. Detta är helt meningslöst för moderna Android-system.

Anledningen till att det är meningslöst är att nyare Android-versioner använder / dev / random / i tre huvudkomponenter - libcrypto , för kryptering av SSL-anslutningar, generering av SSH-nycklar, etc. WPA_supplication / hostapd som genererar WEP / WPA-nycklar, och slutligen, en handfull bibliotek för att generera ID för att skapa EXT2 / EXT3 / EXT4-filsystem.

Så när Såmaskin eller såmaskinbaserade förbättringar ingår i moderna Android-optimeringsskript, det som slutar hända är ett degradering i enhetsprestanda, för rngd kommer att ständigt väcka enheten och orsaka en ökning av CPU-frekvensen, vilket naturligtvis påverkar batteriförbrukningen negativt.

Odex

Lager firmware på Android-enheter odex nästan alltid. Detta innebär att bredvid standardpaketet för Android-appar i APK-format, som finns i / system / app / och / system / priv-app /, har samma filnamn med .odex-tillägget. Odex-filerna innehåller optimerade bytecode-applikationer som redan har passerat den virtuella validerings- och optimeringsmaskinen och sedan spelats in i en separat fil med något som dexopt verktyg.

Så odex-filer är avsedda att ladda ner virtuell maskin och erbjuda en snabbare lansering av odexed-applikationen - på nackdelen förhindrar ODEX-filer ändringar av firmware och skapar problem med uppdateringar, så av denna anledning distribueras många anpassade ROM-skivor som LineageOS utan ODEX .

Att generera ODEX-filer görs på ett antal sätt, som att använda Odexer Tool - problemet är att det bara är en placeboeffekt. När moderna Android-system inte hittar odex-filer i / systemkatalogen skapar systemet dem och placerar dem i katalogen / system / dalvik-cache /. Det är precis vad som händer när du till exempel blinkar en ny Android-version och det ger meddelandet ”Upptagen, optimering av applikationer” ett tag.

Lågmemorykiller tweaks

Multitasking i Android skiljer sig från andra mobila operativsystem i den meningen att det bygger på en klassisk modell där applikationer fungerar tyst i bakgrunden, och det finns inga begränsningar för antalet bakgrundsappar ( om inte en anges i Developer Options, men detta rekommenderas i allmänhet mot) - dessutom stoppas inte funktionaliteten för övergång till en bakgrundskörning, även om systemet förbehåller sig rätten att döda bakgrundsappar i situationer med lågt minne ( se var vi pratade om lowmemorykiller och out-of-memory killer tidigare i den här guiden) .

För att gå tillbaka till lowmemorykiller Android kan fortsätta att fungera med en begränsad mängd minne och brist på bytespartition. Användaren kan fortsätta att starta applikationer och växla mellan dem, och systemet dödar tyst outnyttjade bakgrundsappar för att försöka frigöra minne för aktiva uppgifter.

Detta var mycket användbart för Android under de tidiga dagarna, men av någon anledning har det blivit populärt i form av task-killer-appar, som i allmänhet är mer skadliga än fördelaktiga. Uppgiftsdödande appar vaknar antingen med bestämda intervall eller körs av användaren och verkar frigöra stora mängder RAM, vilket ses som ett positivt - mer gratis RAM betyder en snabbare enhet, eller hur? Detta är dock inte exakt fallet med Android.

Att ha en stor mängd gratis RAM kan faktiskt vara skadligt för enhetens prestanda och batteritid. När appar lagras i Androids RAM är det mycket lättare att ringa upp dem, starta dem etc. Android-systemet behöver inte ägna mycket resurser åt att byta till appen, eftersom det redan finns i minnet.

På grund av detta är task-killers inte riktigt lika populära som de en gång var, även om Android-nybörjare fortfarande brukar lita på dem av någon anledning ( brist på information, tyvärr) . Tyvärr har en ny trend ersatt uppgiftsdödande, trenden med lowmemorykiller mekanismavstämningar. Detta skulle vara till exempel MinFreeManager app, och huvudidén är att öka RAM-omkostnaderna innan systemet börjar döda bakgrundsappar.

Så till exempel fungerar standard-RAM vid gränser - 4, 8, 12, 24, 32 och 40 Mb, och när det fria lagringsutrymmet på 40 MB fylls, laddas en av de cachade apparna som laddas in i minnet men inte igång kommer att avslutas.

Så i grund och botten kommer Android alltid att ha minst 40 MB tillgängligt minne, vilket räcker för att rymma ytterligare en applikation tidigare lowmemorykiller börjar sin rengöringsprocess - vilket innebär att Android alltid kommer att göra sitt bästa för att använda den maximala mängden tillgängligt RAM-minne utan att störa användarupplevelsen.

Tyvärr rekommenderas det som vissa homebrew-entusiaster rekommenderar att värdet höjs till exempelvis 100 MB innan LMK sparkar in. Nu kommer användaren faktiskt förlora RAM (100 - 40 = 60), så istället för att använda detta utrymme för att lagra backend-appar kommer systemet att behålla denna mängd minne fri , med absolut inget syfte för det.

LKM-inställning kan vara användbart för mycket äldre enheter med 512 RAM, men vem äger dem längre? 2 GB är det moderna 'budgetområdet', till och med 4 GB RAM-enheter ser ut som 'mellanklass' i dessa dagar, så LMK-justeringar är verkligen föråldrade och värdelösa.

I / O-justeringar

I många optimeringsskript för Android hittar du ofta tweaks som adresserar I / O-delsystemet. Låt oss till exempel ta en titt på Blixt! Skript, som innehåller dessa rader:

echo 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests;

Den första raden ger I / O-schemaläggningsinstruktioner för att hantera en SSD, och den andra ökar den maximala storleken på kön I / O från 128 till 1024 - eftersom $ i-variabeln innehåller en sökväg till trädet för blockenheter i / sys, och manuset körs i en slinga.

Efter det hittar du en rad relaterad till CFQ-schemaläggaren:

echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;

Detta följs av fler linjer som tillhör andra planerare, men i slutändan är de två första kommandona meningslösa eftersom:

En modern Linux-kärna kan förstå vilken typ av lagringsmedium den arbetar med som standard.

En lång input-output-kö ( såsom 1024) är värdelös på en modern Android-enhet, i själva verket är den meningslös även på skrivbordet - det rekommenderas verkligen bara den tunga servrar . Din telefon är inte en tung Linux-server.

För en Android-enhet finns det praktiskt taget inga applikationer som prioriteras i ingångsutgången och ingen mekanisk drivrutin, så den bästa planeraren är noop / FIFO-kön, så den här typen av schemaläggare “ Modifiera' gör inte något speciellt eller meningsfullt för I / O-delsystemet. Faktum är att alla dessa kommandon med flera skärmlistor bättre ersätts av en enkel cykel:

för i in / sys / block / mmc *; gör echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done

Detta skulle möjliggöra noop-schemaläggaren för alla enheter från ackumulering av I / O-statistik, vilket borde ha en positiv inverkan på prestanda, även om den är mycket liten och nästan helt försumbar.

En annan värdelös I / O-tweak som ofta finns i prestandaskript är de ökade läsvärdena för SD-kort upp till 2 MB. Read-ahead-mekanism är för tidig dataläsning från media innan appen begär åtkomst till den informationen. Så i grund och botten kommer kärnan att försöka ta reda på vilken data som kommer att behövas i framtiden och förladdar den i RAM-minnet, vilket därmed borde minska returtiden. Det låter bra på papper, men den läsbara algoritmen är oftare fel , vilket leder till helt onödiga operationer av input-output, för att inte tala om en hög RAM-förbrukning.

Höga läsvärden på mellan 1 - 8 MB rekommenderas i RAID-arrays, men för Android-enheter är det bäst att bara lämna standardvärdet på 128 KB.

Systemjusteringar för virtuellt minneshantering

En annan vanlig 'optimering' -teknik är att ställa in det virtuella minneshanteringsundersystemet. Detta riktar sig vanligtvis endast mot två kärnvariabler, vm.dirty_background_ratio och vm.dirty_ratio, som är för att justera buffertens storlek för lagring av 'smutsiga' data. Smutsig data är vanligtvis data som har skrivits till disken, men det finns mer i minnet och väntar på att bli skrivet till disken.

Typiska justeringsvärden i både Linux-distributioner och Androis till delsystemet VM-hantering skulle vara som:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Så vad detta försöker göra är att när den smutsiga databufferten är 10% av den totala mängden RAM, vaknar den pdflush flöde och börjar skriva data till disken - om funktionen för inspelning av data på disken kommer att ske för intensiv , kommer bufferten att fortsätta växa, och när den når 20% av tillgängligt RAM kommer systemet att växla till den efterföljande skrivoperationen i synkron läge - utan förbuffert. Detta innebär att arbetet med att skriva till diskapplikationen kommer att vara blockeras tills data skrivs till disk (AKA 'lag').

Vad du bör förstå är att även om buffertstorleken når inte 10% startar systemet automatiskt pdflush efter 30 sekunder. En kombination av 10/20 är ganska rimlig, till exempel på en enhet med 1 GB RAM skulle detta motsvara 100/200 MB RAM, vilket är mer än tillräckligt när det gäller burst-poster där hastigheten ofta är under hastighetsregistret i systemet NAND -minne eller SD-kort, till exempel när du installerar appar eller kopierar filer från en dator.

Av någon anledning försöker manusförfattare att driva detta värde ännu högre till absurda priser. Till exempel kan vi hitta i Xplix optimeringsskript så högt som 50/90.

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

På en enhet med 1 GB minne sätter detta gränsen för en smutsig buffert till 500/900 MB, vilket är helt värdelöst för en Android-enhet, eftersom det bara skulle fungera under konstant inspelning på skivan - något som bara händer på en tung Linux-server.

Blixt! Script använder ett mer rimligt värde, men totalt sett är det fortfarande ganska meningslöst:

om ['$ mem' -lt 524288]; då sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; sedan sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; annars sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;

De två första kommandona körs på smartphones med 512 MB RAM, den andra - med 1 GB och andra - med mer än 1 GB. Men faktiskt finns det bara en anledning att ändra standardinställningarna - en enhet med ett mycket långsamt internt minne eller minneskort. I det här fallet är det rimligt att sprida värdena på variablerna, det vill säga göra något så här:

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

Då, när ett överspänningssystem skriver operationer utan att behöva spela in data på skivan, växlar upp till det sista inte till synkront läge, vilket gör att applikationer kan minska fördröjningen vid inspelning.

Ytterligare värdelösa tweaks och Performance Tunings

Det finns mycket mer 'optimeringar' där ute som verkligen inte gör någonting. De flesta av dem har helt enkelt ingen effekt alls, medan andra kan förbättras några aspekt av prestanda, samtidigt som enheten försämras på andra sätt ( brukar det koka ner till prestanda vs batteriladdning) .

Här är några ytterligare populära optimeringar som kan eller inte kan vara användbara, beroende på Android-systemet och enheten.

• Acceleration - Den lilla accelerationen för att förbättra prestanda och underspänning - sparar lite batteri.
• Databasoptimering - I teorin detta skall ger en förbättring av enhetens prestanda, men det är tveksamt.
• Zipalign - Ironiskt nog, trots den inbyggda Android SDK-funktionens innehållsinriktning i APK-filen i butiken kan du hitta att mycket programvara inte överförs via zipalign.
• Inaktivera onödiga systemtjänster, ta bort oanvänt system och sällan använda tredjepartsapplikationer. I grund och botten avinstallerar du bloatware.
• Anpassad kärna med optimeringar för en specifik enhet (igen, inte alla kärnor är lika bra).
• Har redan beskrivit I / O schemaläggaren noop.
• Mättnadsalgoritm TCP Westwood - Används mer effektivt i standard Android Cubic för trådlösa nätverk, tillgängligt i anpassade kärnor.

Användbara inställningar build.prop

LaraCraft304 från XDA Developers forum har genomfört en studie och visat att ett imponerande antal /system/build.prop-inställningar som rekommenderas för användning av 'experter' inte finns i källan AOSP och CyanogenMod. Här är listan:

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_velocity ro. kärna.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.Home