Meest voorkomende Android-optimalisatie mythen ontkracht

Er zijn veel instructiegidsen die zijn gewijd aan het verbeteren van Android-prestaties en algemene optimalisatietips. Sommigen van hen zijn legitiem, en anderen zijn alleen gebaseerd op theorie, of verouderde operationele methoden in het Android-systeem, of zijn gewoon onzin. Dit omvat aanbevelingen om te ruilen, waarden toegevoegd aan build.prop en variabele wijzigingen in de Linux-kernel.

Er zijn zelfs talloze "optimalisatiescripts" beschikbaar, alles-in-één flashbare .zips die beloven de prestaties, batterijduur en andere dingen aanzienlijk te verbeteren. Sommige tweaks kunnen echt werken, maar de meeste zijn gewoon een placebo-effect, of erger, hebben zelfs een negatieve invloed op uw apparaat.

Dat wil niet zeggen dat mensen opzettelijk snode scripts vrijgeven - er zijn absoluut nep betaalde apps in de Play Store, maar optimalisatiescripts die op Android-forums zijn uitgebracht, zijn over het algemeen goedbedoeld, het is gewoon zo dat de ontwikkelaar mogelijk verkeerd is geïnformeerd, of gewoon experimenteren met verschillende optimalisatie-aanpassingen. Helaas treedt er meestal een soort sneeuwbaleffect op, vooral in "alles-in-één" optimalisatiescripts. Een klein handje van de tweaks kan echt iets doen, terwijl een andere set tweaks in een script helemaal niets kan doen - maar deze scripts worden doorgegeven als magische kogels, zonder echt onderzoek naar wat werkt en wat niet .

Veel all-in-one optimalisatiescripts gebruiken dus dezelfde methoden, waarvan sommige op de lange termijn volledig verouderd of schadelijk zijn. Samenvattend zijn de meeste "alles-in-één" optimalisatiescripts niets anders dan het samenvoegen van aanbevolen afstemmingen, zonder een duidelijk idee van hoe of waarom deze optimalisaties "werken - gebruikers flitsen dan de scripts en beweren dat hun prestaties plotseling sneller zijn ( terwijl in feite het zeer waarschijnlijk de zeer eenvoudige handeling was om hun apparaat opnieuw op te starten, wat een prestatieverhoging veroorzaakte, omdat alles in het RAM van het apparaat wordt opgeruimd) .

In dit exclusieve artikel van Appuals belichten we enkele van de meest voorkomende aanbevelingen voor het " optimaliseren" van Android-prestaties, en of ze gewoon een mythe zijn, of een legitieme aanpassing voor apparaatprestaties.

ruil

Bovenaan de mythelijst staat de Android-swap - wat vrij absurd is in termen van te worden beschouwd als een Android-optimalisatie. Het hoofddoel van Swaps is het maken en verbinden van het wisselbestand, waardoor opslagruimte in het geheugen wordt vrijgemaakt. Dit klinkt verstandig op papier, maar het is echt van toepassing op een server, die bijna geen interactiviteit heeft.

Wanneer u de swap van uw Android-telefoon regelmatig gebruikt, leidt dit tot ernstige vertragingen die voortkomen uit dingen die langs de cache glijden. Stel je bijvoorbeeld voor dat een toepassing een afbeelding probeert weer te geven, die is opgeslagen in de swap, die nu de schijf opnieuw moet laden nadat er ruimte is vrijgemaakt door gegevensruil te plaatsen met een andere toepassing. Het is echt rommelig.

Sommige optimalisatie-enthousiastelingen kunnen zeggen dat swap geen problemen bood, maar het is geen swap die de prestaties verhoogt - het is het ingebouwde Android-mechanisme lowmemorykiller, dat regelmatig opgeblazen processen met hoge prioriteit doodt die niet worden gebruikt. LMK is specifiek ontworpen voor het omgaan met weinig geheugen, wordt aangeroepen door het kswapd- proces en doodt in het algemeen processen voor gebruikersruimte. Dit is anders dan OOMkiller (geheugenloze moordenaar), maar dat is een heel ander onderwerp.

Het punt is dat een apparaat met bijvoorbeeld 1 GB RAM nooit de benodigde prestatiegegevens in een swap kan bereiken, en swap is dus absoluut niet nodig in Android. De implementatie ervan is gewoon beladen met vertraging en leidt tot een verslechtering van de prestaties in plaats van deze te optimaliseren.

zRAM - Verouderd en niet langer efficiënt

zRAM is een beproefde en effectieve methode voor apparaatoptimalisatie voor oudere apparaten - denk aan KitKat-gebaseerde apparaten die op slechts ongeveer 512 MB RAM werken. Het feit dat sommige mensen nog steeds zRAM-tweaks opnemen in optimalisatiescripts, of zRAM aanbevelen als een soort moderne optimalisatie-tweak, is een voorbeeld van mensen die over het algemeen de nieuwste operationele protocollen niet volgen.

zRAM was bedoeld voor multi-core SoC's op instapniveau, zoals apparaten met MTK-chipsets en 512 MB RAM. Heel goedkope Chinese telefoons, eigenlijk. Wat zRAM in principe doet, is de kernel scheiden via de coderingsstroom.

Wanneer zRAM wordt gebruikt op oudere apparaten met een enkele kern, zelfs als zRAM wordt aanbevolen op dergelijke apparaten, neigen grote hoeveelheden vertragingen op te duiken. Dit gebeurt ook met de KSM-technologie ( Kernel Same Page Merging) die identieke geheugenpagina's combineert in een poging om ruimte vrij te maken. Dit wordt in feite door Google aanbevolen, maar leidt tot grotere vertragingen op oudere apparaten, omdat de constant actieve kernthreads continu vanuit het geheugen worden uitgevoerd om te zoeken naar dubbele pagina's. Kortom, het proberen om de optimalisatie tweak uit te voeren vertraagt ​​het apparaat nog verder, ironisch genoeg.

Seeder - verouderd sinds Android 3.0

Een van de meest besproken optimalisatietips onder Android-ontwikkelaars is seeder, en we zijn er zeker van dat iemand kan proberen ons te bewijzen wat dit betreft, maar eerst moeten we de geschiedenis van seeder onderzoeken.

Ja, er is een groot aantal rapporten die betere Android-prestaties aangeven na installatie op veel oudere Android-apparaten . Mensen, om welke reden dan ook, geloven dat dit betekent dat het ook een toepasselijke optimalisatie is voor moderne Android-apparaten, wat absoluut absurd is. Het feit dat Seeder nog steeds wordt onderhouden en aangeboden als een ' moderne' tool voor lagreductie is een voorbeeld van verkeerde informatie - hoewel dit niet de schuld is van de ontwikkelaar van Seeder, omdat zelfs hun Play Store-pagina opmerkt dat Seeder minder effectief is na Android 4.0+. Maar om welke reden dan ook, Seeder duikt nog steeds op in optimalisatiediscussies voor moderne Android-systemen.

Wat Seeder eigenlijk voor Android 3.0 doet, is een bug aanpakken waarbij Android-runtime het / dev / random / file actief zou gebruiken om entropie te verwerven. De / dev / random / buffer zou onstabiel worden en het systeem zou worden geblokkeerd totdat het de vereiste hoeveelheid gegevens had gevuld - denk aan kleine dingen zoals de verschillende sensoren en knoppen op het Android-apparaat.

De auteur van Seeder nam de Linux-demon rngd, en compileerde voor de inastroil van Android, zodat het willekeurige gegevens van een veel snellere en voorspelbaardere / dev / urandom-route nam en deze samenvoegt met dev / random / elke seconde, zonder / dev / random toe te staan / uitgeput raken. Dit resulteerde in een Android-systeem dat geen gebrek aan entropie had en veel soepeler presteerde.

Google heeft deze bug ingeslagen na Android 3.0, maar om een ​​of andere reden verschijnt Seeder nog steeds op de lijst met "aanbevolen aanpassingen" voor optimalisatie van Android-prestaties. Verder heeft de Seeder-app een paar analogen zoals sEFix die de functionaliteit van Seeder bevatten, of het nu dezelfde rngd is of het alternatieve haveged, of zelfs alleen een symlink tussen / dev / urandom en / dev / random. Dit is absoluut zinloos voor moderne Android-systemen.

De reden waarom het zinloos is, is omdat nieuwere Android-versies / dev / random / in drie hoofdcomponenten gebruiken - libcrypto, voor codering van SSL-verbindingen, het genereren van SSH-sleutels, enz. WPA_supplication / hostapd die WEP / WPA-sleutels genereert, en ten slotte een handvol bibliotheken voor het genereren van ID bij het maken van EXT2 / EXT3 / EXT4-bestandssystemen.

Dus wanneer op Seeder of op Seeder gebaseerde verbeteringen zijn opgenomen in moderne Android-optimalisatiescripts, is er uiteindelijk sprake van een verslechtering van de apparaatprestaties, omdat rngd het apparaat constant zal ontwaken en een toename van de CPU-frequentie zal veroorzaken, wat natuurlijk een negatief effect heeft op het batterijverbruik .

Odex

De stock-firmware op Android-apparaten is vrijwel altijd odex. Dit betekent dat naast het standaardpakket voor Android-apps in APK-indeling, te vinden in / system / app / en / system / priv-app /, dezelfde bestandsnamen met de extensie .odex hebben. De odex-bestanden bevatten geoptimaliseerde bytecode-toepassingen die al door de validator en de virtuele optimalisatiemachine zijn gepasseerd en vervolgens zijn opgenomen in een afzonderlijk bestand met zoiets als dexopt- tool.

Dus odex-bestanden zijn bedoeld om de virtuele machine te ontladen en bieden een snellere lancering van de odexed-applicatie - aan de andere kant, ODEX-bestanden voorkomen wijzigingen in de firmware en creëren problemen met updates, dus om deze reden worden veel aangepaste ROM's zoals LineageOS gedistribueerd zonder ODEX .

Het genereren van ODEX-bestanden gebeurt op een aantal manieren, zoals het gebruik van Odexer Tool - het probleem is dat het puur een placebo-effect is. Wanneer het moderne Android-systeem geen odex-bestanden vindt in de map / system, maakt het systeem ze daadwerkelijk en plaatst ze in de map / system / dalvik-cache /. Dit is precies wat er gebeurt als je bijvoorbeeld een nieuwe Android-versie flasht en het geeft een tijdje het bericht 'Bezig, applicaties optimaliseren'.

Tweaks met weinig geheugen

Multitasking in Android verschilt van andere mobiele besturingssystemen in die zin dat het gebaseerd is op een klassiek model waarbij applicaties stil op de achtergrond werken en er geen beperkingen zijn aan het aantal achtergrond-apps ( tenzij er een is ingesteld in Opties voor ontwikkelaars, maar dit is algemeen aanbevolen tegen) - bovendien wordt de functionaliteit van de overgang naar een achtergronduitvoering niet gestopt, hoewel het systeem zich het recht voorbehoudt om achtergrondapps in situaties met weinig geheugen te doden ( zie eerder in dit hoofdstuk over lowmemorykiller en geheugenloze moordenaar) gids) .

Om terug te gaan naar het lowmemorykiller- mechanisme, kan Android blijven werken met een beperkte hoeveelheid geheugen en een gebrek aan swap-partitie. De gebruiker kan applicaties blijven starten en ertussen schakelen, en het systeem doodt stilletjes ongebruikte achtergrond-apps om te proberen geheugen vrij te maken voor actieve taken.

Dit was in het begin erg handig voor Android, maar om de een of andere reden is het populair geworden in de vorm van task-killer-apps, die over het algemeen schadelijker dan gunstig zijn. Taakmoordenaar-apps worden met vaste intervallen wakker of worden door de gebruiker uitgevoerd en lijken grote hoeveelheden RAM vrij te maken, wat als positief wordt beschouwd - meer vrij RAM betekent een sneller apparaat, toch? Dit is echter niet precies het geval met Android.

Het hebben van een grote hoeveelheid gratis RAM-geheugen kan zelfs schadelijk zijn voor de prestaties van uw apparaat en de levensduur van de batterij. Wanneer apps worden opgeslagen in het RAM-geheugen van Android, is het veel gemakkelijker om ze op te roepen, te starten, enz. Het Android-systeem hoeft niet veel middelen te besteden aan het overschakelen naar de app, omdat het al in het geheugen staat.

Hierdoor zijn taakmoordenaars niet zo populair meer als vroeger, hoewel Android-beginners er om een ​​of andere reden toch op vertrouwen ( gebrek aan informatie helaas) . Helaas heeft een nieuwe trend taak-killers vervangen, de trend van het afstemmen van mechanismen met een laag geheugen . Dit zou bijvoorbeeld de MinFreeManager- app zijn, en het belangrijkste idee is om de RAM-overhead te vergroten voordat het systeem achtergrondapps begint te doden.

Dus het standaard RAM werkt bijvoorbeeld aan grenzen - 4, 8, 12, 24, 32 en 40 Mb, en wanneer de vrije opslagruimte van 40 MB vol is, een van de in de cache opgeslagen apps die in het geheugen is geladen maar niet actief is zal worden beëindigd.

Dus in principe zal Android altijd minstens 40 MB beschikbaar geheugen hebben, wat voldoende is om nog een applicatie te accommoderen voordat lowmemorykiller begint met het opruimproces - wat betekent dat Android altijd zijn best zal doen om de maximale hoeveelheid beschikbaar RAM te gebruiken zonder de gebruikerservaring.

Helaas is wat sommige liefhebbers van homebrew zijn begonnen aan te bevelen dat de waarde wordt verhoogd tot bijvoorbeeld 100 MB voordat LMK begint. Nu verliest de gebruiker RAM (100 - 40 = 60), dus in plaats van deze ruimte te gebruiken om terug te slaan- einde apps, zal het systeem deze hoeveelheid geheugen vrij houden, zonder enig doel.

LKM-afstemming kan nuttig zijn voor veel oudere apparaten met 512 RAM, maar wie bezit die nog meer? 2 GB is het moderne "budgetbereik", tegenwoordig worden zelfs 4 GB RAM-apparaten als "middelmatig" beschouwd, dus LMK-aanpassingen zijn echt verouderd en nutteloos.

I / O-aanpassingen

In veel optimalisatiescripts voor Android vindt u vaak tweaks die betrekking hebben op het I / O-subsysteem. Laten we bijvoorbeeld eens kijken naar de ThunderBolt! Script, dat deze regels bevat:

 echo 0> $ i / wachtrij / rotatie; echo 1024> $ i / queue / nr_requests; 

De eerste regel geeft de I / O-plannerinstructies voor het omgaan met een SSD en de tweede verhoogt de maximale grootte van de wachtrij-I / O van 128 tot 1024 - omdat de variabele $ i een pad bevat naar de boom met blokapparaten in / sys en het script wordt in een lus uitgevoerd.

Hierna vindt u een regel met betrekking tot de CFQ-planner:

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

Dit wordt gevolgd door meer regels die bij andere planners horen, maar uiteindelijk zijn de eerste twee opdrachten zinloos omdat:

Een moderne Linux-kernel kan standaard begrijpen met welk type opslagmedium het werkt.

Een lange invoer-uitvoerwachtrij ( zoals 1024) is nutteloos op een modern Android-apparaat, in feite is het zelfs op desktop zinloos - het wordt echt alleen aanbevolen op zware servers . Uw telefoon is geen zware Linux-server.

Voor een Android-apparaat zijn er vrijwel geen toepassingen geprioriteerd in de input-output en geen mechanische driver, dus de beste planner is de noop / FIFO-wachtrij, dus dit type ' tweak' van de planner doet niets bijzonders of betekenisvol aan de I / O-subsysteem. Al deze lijstopdrachten op meerdere schermen kunnen zelfs beter worden vervangen door een eenvoudige cyclus:

 voor i in / sys / block / mmc *; do echo noop> $ i / wachtrij / planner echo 0> $ i / wachtrij / iostats klaar 

Dit zou de noop-planner voor alle schijven mogelijk maken door de accumulatie van I / O-statistieken, wat een positief effect op de prestaties zou moeten hebben, hoewel een zeer kleine en bijna volledig te verwaarlozen.

Een andere nutteloze I / O-tweak die vaak in prestatiescripts wordt aangetroffen, zijn de verhoogde read-ahead-waarden voor SD-kaarten tot 2 MB. Voorleesmechanisme is bedoeld voor vroege gegevensuitlezingen van de media, voordat de app toegang tot die gegevens vraagt. Dus in feite zal de kernel proberen te achterhalen welke gegevens in de toekomst nodig zullen zijn, en laadt deze vooraf in het RAM-geheugen, wat de retourtijd zou moeten verminderen. Dit klinkt geweldig op papier, maar het read-ahead-algoritme is vaker verkeerd, wat leidt tot totaal onnodige bewerkingen van input-output en niet te vergeten een hoog RAM-verbruik.

Hoge read-ahead waarden tussen 1 - 8 MB worden aanbevolen in RAID-arrays, maar voor Android-apparaten is het het beste om de standaardwaarde van 128 KB te laten.

Virtual Memory Management systeem tweaks

Een andere veel voorkomende 'optimalisatie'-techniek is het afstemmen van het subsysteem voor virtueel geheugenbeheer. Dit richt zich doorgaans op slechts twee kernelvariabelen, vm.dirty_background_ratio en vm.dirty_ratio, die bedoeld zijn om de buffer aan te passen voor het opslaan van "vuile" gegevens. Vuile gegevens zijn meestal gegevens die naar schijf zijn geschreven, maar er is nog meer in het geheugen en wacht om naar schijf te worden geschreven.

Typische tweakwaarden in zowel Linux-distro's als Androis voor het VM-beheersubsysteem zouden zijn:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Dus wat dit probeert te doen is dat wanneer de vuile gegevensbuffer 10% van de totale hoeveelheid RAM is, deze de pdflush- stroom wakker maakt en gegevens naar de schijf begint te schrijven - als de bewerking van het opnemen van gegevens op de schijf te intensief zal zijn, de buffer blijft groeien en wanneer het 20% van het beschikbare RAM-geheugen bereikt, schakelt het systeem over naar de volgende schrijfbewerking in synchrone modus - zonder pre-buffer. Dit betekent dat het schrijven naar schijftoepassing wordt geblokkeerd totdat de gegevens naar schijf worden geschreven ('lag' van AKA).

Wat u moet begrijpen, is dat zelfs als de buffergrootte niet 10% bereikt, het systeem na 30 seconden automatisch pdflush inschakelt. Een combinatie van 10/20 is redelijk, bijvoorbeeld op een apparaat met 1 GB RAM zou dit gelijk zijn aan 100 / 200MB RAM, wat meer dan genoeg is in termen van burst-records waarbij de snelheid vaak lager is dan het snelheidsrecord in systeem NAND -geheugen of SD-kaart, zoals bij het installeren van apps of het kopiëren van bestanden van een computer.

Om de een of andere reden proberen scriptschrijvers deze waarde zelfs nog hoger te zetten, tot absurde cijfers. We kunnen bijvoorbeeld in het Xplix- optimalisatiescript een snelheid van maximaal 50/90 vinden.

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

Op een apparaat met 1 GB geheugen stelt dit de limiet voor een vuile buffer in op 500/900 MB, wat volledig nutteloos is voor een Android-apparaat, omdat het alleen zou werken onder constante opname op de schijf - iets dat alleen gebeurt op een zware Linux-server.

Thunderbolt! Script gebruikt een redelijkere waarde, maar over het algemeen is het nog redelijk zinloos:

 if ["$ mem" -lt 524288]; dan sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; vervolgens sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; anders sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

De eerste twee opdrachten worden uitgevoerd op smartphones met 512 MB RAM, de tweede - met 1 GB en andere - met meer dan 1 GB. Maar er is eigenlijk maar één reden om de standaardinstellingen te wijzigen - een apparaat met een zeer traag intern geheugen of een geheugenkaart. In dit geval is het redelijk om de waarden van de variabelen te spreiden, dat wil zeggen om zoiets te maken:

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

Dan, wanneer een pieksysteem operaties schrijft, zonder gegevens op de schijf op te nemen, zal tot het laatst niet overschakelen naar de synchrone modus, waardoor applicaties de vertraging kunnen verminderen tijdens het opnemen.

Extra nutteloze tweaks en performance-afstemmingen

Er zijn veel meer "optimalisaties" die echt niets doen. De meeste hebben gewoon geen enkel effect, terwijl anderen een bepaald aspect van de prestaties kunnen verbeteren, terwijl ze het apparaat op andere manieren verslechteren ( meestal komt het neer op prestaties versus batterijverbruik) .

Hier zijn enkele aanvullende populaire optimalisaties die al dan niet nuttig kunnen zijn, afhankelijk van het Android-systeem en het apparaat.

• Versnelling - De kleine versnelling om de prestaties en onderbelasting te verbeteren - bespaart een beetje batterij.
• Databaseoptimalisatie - In theorie zou dit een verbetering van de apparaatprestaties moeten geven, maar het is twijfelachtig.
• Zipalign - Ironisch genoeg, ondanks de ingebouwde Android SDK-functie-inhoudsuitlijning in het APK-bestand in de winkel, kun je zien dat veel software niet wordt verzonden via zipalign.
• Schakel onnodige systeemservices uit, verwijder ongebruikte systemen en zelden gebruikte applicaties van derden. Kortom, bloatware verwijderen.
• Aangepaste kernel met optimalisaties voor een specifiek apparaat (nogmaals, niet alle kernen zijn even goed).
• Reeds beschreven I / O-planner noop.
• Verzadigingsalgoritme TCP Westwood - Efficiënter gebruikt in de standaard Android Cubic voor draadloze netwerken, beschikbaar in aangepaste kernels.

Nutteloze instellingen build.prop

LaraCraft304 van het XDA Developers-forum heeft een onderzoek uitgevoerd en geconstateerd dat een indrukwekkend aantal /system/build.prop-instellingen die worden aanbevolen voor gebruik "experts" niet bestaan ​​in de bron AOSP en CyanogenMod. Hier is de lijst:

 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. 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_D.HOME