De vanligaste myterna för Android-optimeringsfunktioner

Det finns många instruktionsguider där ute som syftar till att öka Android-prestanda och övergripande optimeringstips. Vissa av dem är legitima, och andra är bara baserade på teori, eller föråldrade operativa metoder i Android-systemet, eller är helt enkelt nonsens. Detta inkluderar rekommendationer för att byta, värden som läggs till build.prop och variabla förändringar i Linux-kärnan.

Det finns till och med massor av "optimeringsskript" där ute, allt-i-ett-blixtabla .zips som lovar att öka prestanda, batteriets livslängd och annat. Några av tweaks kan faktiskt fungera, men en majoritet är helt enkelt en placebo-effekt, eller värre, faktiskt har en negativ inverkan på din enhet.

Det är inte att säga att folk släpper otydliga skript avsiktligt - det finns definitivt falska betalade appar i Play Store, men optimeringsskript som släppts på Android-forum är i allmänhet välmenade, det händer bara så att utvecklaren kan bli felinformerad, eller helt enkelt experimentera med olika optimeringsjusteringar. Tyvärr tenderar en slags snöbolleffekt att inträffa, särskilt i "allt-i-ett" -optimeringsskript. En liten handfull av tweaks kan faktiskt göra någonting, medan en annan uppsättning av tweaks i ett manus kan göra absolut ingenting alls - ändå dessa skript förts som magiska kulor, utan någon verklig undersökning av vad som fungerar och vad som inte .

Således använder många allt-i-ett-optimeringsskript samma metoder, av vilka några är helt föråldrade eller skadliga på lång sikt. Sammanfattningsvis är en majoritet av "allt-i-ett" -optimeringsskript ingenting annat än rekommenderade avstängningar, utan någon klar uppfattning om hur eller varför dessa optimeringar "fungerar - användare blinkar sedan skripten och hävdar att deras prestanda plötsligt är snabbare ( när det faktiskt var troligtvis den mycket enkla handlingen om att starta om deras enhet som orsakade en prestandaförhöjning, eftersom allt i enhetens RAM-minne rensas ut) .

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

Byta

Överst på mytlistan är Android-bytet - vilket är ganska absurd när det gäller att bli tänkt som en Android-optimering. Byter huvudsakligt syfte är att skapa och ansluta sökfilen, vilket kommer att frigöra lagringsutrymme i minnet. Detta låter förnuftigt på papper, men det är verkligen tillämpligt på en server, som har nästan ingen interaktivitet.

När du använder din Android-telefons byte regelbundet kommer det att leda till allvarliga förseningar som härrör från saker som glider förbi cachen. Föreställ dig, till exempel, om ett program försöker visa en grafik, som är lagrad i bytet, som nu måste ladda skivan igen efter att du har frigjorts utrymme genom att placera databyte med ett annat program. Det är verkligen rörigt.

Vissa optimeringsentusiaster kan säga att swap inte erbjöd några problem, men det är inte swap som gör prestandan ökar - det är den inbyggda Android-mekanismen lowmemorykiller, som regelbundet dödar uppblåsta, högprioriterade processer som inte används. LMK designades specifikt för att hantera lågminnesförhållanden, åberopas från kswapd- processen och dödar i allmänhet användarutrymme. Detta skiljer sig från OOMkiller (utanför minnesdödaren), men det är helt annat ett ämne.

Poängen är att en enhet med till exempel 1 GB RAM aldrig kan nå nödvändig prestandadata i en swap, och därför är swap absolut inte nödvändigt i Android. Dess implementering är helt enkelt försenad och leder till en försämring av prestandan snarare än att optimera den.

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. Det faktum att vissa människor fortfarande inkluderar zRAM-justeringar i optimeringsskript, eller rekommenderar zRAM som någon form av modern optimeringsjustering, är ett exempel på att människor i allmänhet inte följer de senaste operativa protokollen.

zRAM var avsett för intrångsnivåer med flera kärnor med flera kärnor, till exempel enheter med MTK-chipset och 512 MB RAM. Mycket billiga kinesiska telefoner, i princip. Vad zRAM egentligen 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 växa upp. Detta händer också med KSM-tekniken ( Kernel Same Page Merging) som kombinerar identiska minnessidor i ett försök att frigöra utrymme. Detta rekommenderas faktiskt av Google, men leder till större förseningar på äldre enheter, eftersom de ständigt aktiva kärntrådarna körs kontinuerligt från minnet för att söka efter dubbla sidor. I grund och botten försöker du köra optimeringsjusteringen enheten ännu längre, ironiskt nog.

Seeder - Föråldrad sedan Android 3.0

Ett av de mest diskuterade optimeringstips bland Android-devs är seeder, och vi är säkra på att någon kan försöka bevisa oss fel om detta ämne - men först måste vi undersöka seederens historia.

Ja, det finns ett stort antal rapporter som förklarar bättre Android-prestanda efter installation på mycket äldre Android-enheter . Men människor oavsett anledning tror att detta betyder att det också är en tillämplig optimering för moderna Android-enheter, vilket är helt absurt. Det faktum att Seeder fortfarande underhålls och erbjuds som ett " modernt" fördröjningsreduceringsverktyg är ett exempel på felinformation - även om detta inte är felet för Seeder's utvecklare, eftersom även deras Play Store-sida konstaterar att Seeder är mindre effektiv efter Android 4.0+. Men av någon anledning dyker Seeder fortfarande upp i optimeringsdiskussioner för moderna Android-system.

Vad Seeder i princip gör för Android 3.0 är att adressera ett fel där Android-runtime aktivt skulle använda / dev / random / filen för att skaffa entropi. / Dev / random / bufferten skulle bli instabil, och systemet skulle blockeras tills det fyllt den mängd data som behövs - tänk små saker som de olika sensorerna och knapparna på Android-enheten.

Seeders författare tog Linux-demon rngd och kompilerade för Android: s inastroil så att det tog slumpmässiga data från en mycket snabbare och mer förutsägbar / dev / urandom-väg, och sammanfogar dem till dev / random / varje sekund utan att tillåta / dev / random / att bli utmattad. Detta resulterade i ett Android-system som inte upplevde brist på entropi och utförde mycket smidigare.

Google krossade detta fel efter Android 3.0, men av någon anledning dyker Seeder fortfarande upp på "rekommenderade tweaks" -listor för optimering av Android-prestanda. Dessutom har Seeder-appen några analoger som sEFix som inkluderar Seeders funktionalitet, oavsett om du använder samma rngd eller alternativet har tagit, eller till och med bara en symlink 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 vid skapande av filsystemen EXT2 / EXT3 / EXT4.

Så när Seeder- eller Seeder-baserade förbättringar ingår i moderna Android-optimeringsskript, är det som slutar att hända en försämring av enhetens prestanda, eftersom rngd ständigt kommer att väcka enheten och orsaka en ökning av CPU-frekvensen, vilket naturligtvis påverkar batteriförbrukningen negativt .

Odex

Aktien firmware på Android-enheter ganska mycket alltid odex. Detta innebär att tillsammans med standardpaketet för Android-appar i APK-format, som finns i / system / app / och / system / priv-app /, har samma filnamn med .odex-förlängningen. Odex-filerna innehåller optimerade bytecode-applikationer som redan har gått igenom den virtuella validatorn och optimeringsapparaten, sedan inspelade i en separat fil med något som dexopt- verktyget.

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

Generering av ODEX-filer görs på flera sätt, som att använda Odexer Tool - problemet är att det enbart är en placeboeffekt. När det moderna Android-systemet inte hittar odexfiler i / systemkatalogen skapar systemet dem faktiskt och placerar dem i / system / dalvik-cache / katalogen. Det här är exakt vad som händer när du till exempel blinkar en ny Android-version och det ger meddelandet "Upptagen, optimera applikationer" ett tag.

Lowmemorykiller tweaks

Multitasking i Android skiljer sig från andra mobila operativsystem i den meningen att det är baserat på en klassisk modell där applikationer fungerar tyst i bakgrunden, och det finns inga begränsningar för antalet bakgrundsappar ( såvida inte en är inställd i Developer Options, men detta är som generellt rekommenderas mot) - dessutom stoppas inte funktionen för övergång till en bakgrundsutförande, ä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-minne killer tidigare i detta guide) .

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

Detta var mycket användbart för Android under de första dagarna, men av någon anledning blev det populärt i form av uppdragsmordar-appar, som i allmänhet är mer skadliga än fördelaktiga. Uppgiftsdödande appar vaknar antingen vid inställda intervaller eller körs av användaren och verkar frigöra stora mängder RAM, vilket ses som ett positivt - mer gratis RAM innebär 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 Android: s RAM, är det mycket lättare att ringa upp dem, starta dem osv. Android-systemet behöver inte ägna mycket resurser åt att byta till appen, eftersom den redan finns i minnet.

På grund av detta är uppdragsmordare egentligen inte så populära som de en gång var, även om Android-nybörjare fortfarande tenderar att lita på dem av någon anledning ( brist på information, tyvärr) . Tyvärr har en ny trend ersatt uppdragsmordare, trenden med lågmemorykiller- mekanismer. Detta skulle till exempel vara MinFreeManager- appen, och huvudtanken är att öka RAM-driften innan systemet börjar döda bakgrundsappar.

Så till exempel fungerar standard-RAM på gränserna - 4, 8, 12, 24, 32 och 40 Mb, och när det fria lagringsutrymmet på 40 MB är fyllt, är en av cachade appar som laddas i minnet men inte körs kommer att avslutas.

Så i princip kommer Android alltid att ha minst 40 MB tillgängligt minne, vilket är tillräckligt för att rymma ytterligare en applikation innan lowmemorykiller påbörjar sin saneringsprocess - 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 utan att störa användarupplevelse.

Det som tyvärr börjat rekommendera är att värdet höjs till exempel 100 MB innan LMK startar. Nu kommer användaren att tappa RAM (100 - 40 = 60), så istället för att använda det här utrymmet för att lagra tillbaka- avsluta appar, kommer systemet att hålla denna mängd minne fritt, med absolut inget syfte för det.

LKM-inställning kan vara användbar för mycket äldre enheter med 512 RAM, men vem äger dem längre? 2 GB är det moderna "budgetområdet", även 4 GB RAM-enheter ser idag som "mellanklass" i dag, så LMK-tweaks ä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 titta på ThunderBolt! Skript som innehåller dessa rader:

 echo 0> $ i / kö / rotation; echo 1024> $ i / kö / nr_requests; 

Den första raden kommer att ge I / O-schemaläggarens instruktioner 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 i blockenheter i / sys, och skriptet körs i en slinga.

Därefter hittar du en rad relaterad till CFQ-schemaläggaren:

 echo 1> $ i / kö / iosched / back_seek_penalty; echo 1> $ i / kö / iosched / low_latency; echo 1> $ i / kö / iosched / slice_idle; 

Detta följs av fler rader 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 inmatningskö (till exempel 1024) är värdelös på en modern Android-enhet, i själva verket meningslös även på skrivbordet - den rekommenderas egentligen bara på tunga servrar . Din telefon är inte en tung server Linux-server.

För en Android-enhet finns det praktiskt taget inga applikationer prioriterade 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 " tweak" gör inte något speciellt eller meningsfullt för I / O-delsystem. Faktum är att alla dessa flerskärmslistekommandon ersätts bättre av en enkel cykel:

 för i in / sys / block / mmc *; gör echo noop> $ i / kö / schemaläggareko 0> $ i / kö / iostats gjort 

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 fullständigt försumbar.

En annan värdelös I / O-finjustering som ofta finns i prestandaskript är de ökade läsningsvärdena för SD-kort upp till 2 MB. Mekanismen för att läsa framåt är för tidig dataläsning från media innan appen begär åtkomst till den informationen. Så i princip kommer kärnan att försöka ta reda på vilka data som kommer att behövas i framtiden, och förinstallerar den i RAM-minnet, vilket således skulle minska returtiden. Detta låter bra på papper, men den läsbara algoritmen är oftare fel, vilket leder till helt onödiga funktioner för input-output, för att inte tala om en hög RAM-förbrukning.

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

Virtuellt minnehanteringssystem justerar

En annan vanlig ”optimering” -teknik är att ställa in det subsystem för virtuellt minnehantering. Detta riktar sig vanligtvis bara till två kärnvariabler, vm.dirty_background_ratio och vm.dirty_ratio, som är för att justera storleken på bufferten för att lagra "smutsiga" data. Smutsiga data är vanligtvis data som har skrivits till disken, men det finns mer i minnet och väntar på att skrivas till disken.

Typiska tweak-värden i både Linux-distros och Androis för VM-hanteringsundersystemet skulle vara som:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Så det här försöker göra är att när den smutsiga databufferten är 10% av den totala mängden RAM, väcker den pdflush- flödet och börjar skriva data till disken - om driften av inspelningsdata på disken blir för intensiv, bufferten fortsätter att växa och när den når 20% av tillgängligt RAM kommer systemet att växla till den efterföljande skrivoperationen i synkronläge - utan förbuffert. Detta innebär att arbetet med att skriva till skivapplikation kommer att blockeras tills data skrivs till skiva (AKA 'lag').

Vad du bör förstå är att även om buffertstorleken inte når 10% kommer systemet automatiskt att sparka in pdflush efter 30 sekunder. En kombination av 10/20 är ganska rimlig, till exempel på en enhet med 1 GB RAM skulle detta vara lika med 100/200 MB RAM, vilket är mer än tillräckligt när det gäller burst-poster där hastigheten ofta ligger under hastighetsposten 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 pressa detta värde ännu högre, till absurde priser. Vi kan till exempel hitta i Xplix- optimeringsskriptet en hastighet så hög 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 på en smutsig buffert till 500/900 MB, vilket är helt värdelöst för en Android-enhet, eftersom den bara fungerar under konstant inspelning på skivan - något som bara händer på en tung Linux-server.

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

 om ["$ mem" -lt 524288]; sedan 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 i själva verket 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 att göra något liknande:

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

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

Ytterligare användbara tweaks och performance Tunings

Det finns mycket fler "optimeringar" där ute som verkligen inte gör någonting. De flesta av dem har helt enkelt ingen effekt, medan andra kan förbättra någon aspekt av prestanda, samtidigt som enheten försämras på andra sätt ( vanligtvis är det en del av prestanda kontra batteriladdning) .

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

• Acceleration - Den lilla accelerationen för att förbättra prestanda och undervoldering - sparar lite batteri.
• Databasoptimering - I teorin bör detta ge en förbättring av enhetens prestanda, men det är tveksamt.
• Zipalign - Ironiskt nog, trots den inbyggda Android SDK-funktionen för innehållsinriktning i APK-filen i butiken kan du hitta mycket programvara som inte överförs via zipalign.
• Inaktivera onödiga systemtjänster, ta bort oanvända system och sällan använda tredjepartsapplikationer. I princip avinstallera bloatware.
• Anpassad kärna med optimeringar för en specifik enhet (igen, inte alla kärnor är lika bra).
• Redan beskrivet I / O-schemaläggare noop.
• Mättnadsalgoritm TCP Westwood - Mer effektivt används i standard Android Cubic för trådlösa nätverk, tillgängliga i anpassade kärnor.

Användbara inställningar build.prop

LaraCraft304 från XDA Developers forum har genomfört en studie och funnit att ett imponerande antal inställningar för system /build.prop 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_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.Hshdowndown.mode