Veel alles-in-één optimalisatiescripts gebruiken dus dezelfde methoden, waarvan sommige op de lange termijn volledig verouderd of schadelijk zijn. Samenvattend, de meeste 'alles-in-één'-optimalisatiescripts zijn niets anders dan bij elkaar geslagen aanbevolen afstemmingen, zonder duidelijk idee van hoe of waarom deze optimalisaties' werken - gebruikers flashen de scripts en beweren dat hun prestaties plotseling sneller zijn ( terwijl het in feite hoogstwaarschijnlijk de zeer simpele handeling van het opnieuw opstarten van hun apparaat was die een prestatieverbetering veroorzaakte , omdat alles in het RAM-geheugen van het apparaat wordt opgeruimd) .
In dit exclusieve artikel van Appuals belichten we enkele van de meest voorkomende aanbevelingen voor ' optimaliseren ” Android-prestaties, en of ze gewoon een mythe zijn, of een legitieme aanpassing aan de apparaatprestaties.
Wissel
Bovenaan de mythe-lijst staat de Android-swap - wat behoorlijk absurd is in termen van te worden beschouwd als een Android-optimalisatie. Het belangrijkste doel van Swaps is het maken en verbinden van het wisselbestand, waardoor opslagruimte in het geheugen wordt vrijgemaakt. Dit klinkt logisch op papier , maar het is echt van toepassing op een server , die bijna geen interactiviteit heeft.
Als u de wisseling van uw Android-telefoon regelmatig gebruikt, leidt dit tot ernstige vertragingen die voortkomen uit dingen die langs de cache glippen. Stel je voor dat een applicatie bijvoorbeeld probeert een afbeelding weer te geven die is opgeslagen in de swap, die nu de schijf opnieuw moet laden nadat hij ruimte heeft vrijgemaakt door een data-swap met een andere applicatie te plaatsen. Het is echt rommelig.
Sommige optimalisatieliefhebbers kunnen zeggen dat swap geen problemen opleverde, maar het is niet swap waardoor de prestaties verbeteren - het is het ingebouwde Android-mechanisme lowmemorykiller , die regelmatig opgeblazen processen met hoge prioriteit die niet worden gebruikt, zullen doden. LMK is speciaal ontworpen voor het omgaan met omstandigheden met weinig geheugen, wordt aangeroepen vanuit de kswapd proces, en doodt in het algemeen gebruikersruimteprocessen. Dit is anders dan OOMkiller (killer met onvoldoende geheugen), maar dat is een heel ander onderwerp.
Het punt is dat een apparaat met bijvoorbeeld 1GB RAM nooit de benodigde prestatiegegevens in een swap kan bereiken, en swap dus absoluut niet nodig is in Android. De implementatie ervan is gewoon beladen met vertraging en leidt tot een degradatie in prestaties, in plaats van deze te optimaliseren.
zRAM - Verouderd en niet meer efficiënt
zRAM is een bewezen en effectieve methode voor apparaatoptimalisatie voor oudere apparaten - denk aan op KitKat gebaseerde apparaten die slechts op 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 niet de nieuwste operationele protocollen volgen.
zRAM was bedoeld voor multi-core SoC's op instapniveau met een budgetbereik, zoals apparaten die MTK-chipsets en 512 MB RAM gebruiken. Eigenlijk heel goedkope Chinese telefoons. Wat zRAM in feite 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, kunnen er grote hoeveelheden vertragingen opduiken. Dit gebeurt ook met de KSM-technologie ( Kernel dezelfde pagina samenvoegen) die identieke geheugenpagina's combineert in een poging om ruimte vrij te maken. Dit wordt in feite aanbevolen door Google, maar leidt tot grotere vertragingen op oudere apparaten, omdat de constant actieve kerntheads continu vanuit het geheugen draaien om te zoeken naar dubbele pagina's. Kortom, het proberen om de optimalisatie-tweak uit te voeren, vertraagt het apparaat zelfs nog verder, ironisch genoeg.
Seeder - verouderd sinds Android 3.0
Een van de meest besproken optimalisatietips onder Android-ontwikkelaars is ceder , en we zijn er zeker van dat iemand kan proberen te bewijzen dat we ongelijk hebben over dit onderwerp - maar eerst moeten we de geschiedenis van seeder onderzoeken.
Seeder-app voor Android
Ja, er is een groot aantal rapporten die betere Android-prestaties aangeven na installatie op veel oudere Android-apparaten . Mensen geloven echter om welke reden dan ook dat dit betekent dat het ook een toepasbare optimalisatie is voor moderne Android-apparaten , wat absoluut absurd is. Het feit dat Seeder nog steeds wordt onderhouden en aangeboden als een “ modern' lag-reductie-tool is een voorbeeld van verkeerde informatie - hoewel dit niet de schuld is van de ontwikkelaar van Seeder, aangezien zelfs hun Play Store-pagina opmerkt dat Seeder minder effectief is na Android 4.0+. Toch duikt Seeder om welke reden dan ook nog steeds op in optimalisatiediscussies voor moderne Android-systemen.
Wat Seeder in feite doet voor Android 3.0, is een bug aanpakken waarbij Android-runtime actief het / dev / random / -bestand zou gebruiken om entropie te verkrijgen. 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 gecompileerd voor Android's inastroil, zodat het willekeurige gegevens van een veel snellere en meer voorspelbare / dev / urandom-route nam en ze samenvoegt tot dev / random / elke seconde, zonder toe te staan dat / dev / random / uitgeput raakt. Dit resulteerde in een Android-systeem dat geen gebrek aan entropie had, en veel soepeler presteerde.
Google heeft deze bug vernietigd na Android 3.0, maar om de een of andere reden duikt Seeder nog steeds op 'Aanbevolen aanpassingen' lijsten voor optimalisatie van Android-prestaties. Bovendien heeft de Seeder-app een paar analogen zoals sEFix die de functionaliteit van Seeder bevatten, ongeacht of ze hetzelfde gebruiken rngd of het alternatief hebben gehad , of zelfs gewoon een symlink tussen / dev / urandom en / dev / random. Dit is absoluut zinloos voor moderne Android-systemen.
De reden dat het zinloos is, is omdat nieuwere Android-versies / dev / random / gebruiken in drie hoofdcomponenten - libcrypto , voor het versleutelen van SSL-verbindingen, het genereren van SSH-sleutels, enz. WPA_supplication / hostapd die WEP / WPA-sleutels genereert, en tot slot een handvol bibliotheken voor het genereren van ID's bij het maken van EXT2 / EXT3 / EXT4-bestandssystemen.
Dus wanneer Zaaimachine of Seeder-gebaseerde verbeteringen zijn opgenomen in moderne Android-optimalisatiescripts, wat uiteindelijk gebeurt is een degradatie in apparaatprestaties, omdat rngd zal het apparaat constant wakker maken en een verhoging van de CPU-frequentie veroorzaken, wat natuurlijk een negatief effect heeft op het batterijverbruik.
Odex
De standaardfirmware op Android-apparaten is vrijwel altijd odex. Dit betekent dat naast het standaardpakket voor Android-apps in APK-formaat, gevonden in / system / app / en / system / priv-app /, dezelfde bestandsnamen zijn met de extensie .odex. De odex-bestanden bevatten geoptimaliseerde bytecode-applicaties die al door de validator en optimizer virtuele machine zijn gegaan en vervolgens zijn opgenomen in een afzonderlijk bestand met behulp van zoiets als dexopt gereedschap.
Dus odex-bestanden zijn bedoeld om de virtuele machine te ontladen en een versnelde start van de odexed-applicatie te bieden - aan de andere kant voorkomen ODEX-bestanden wijzigingen aan de firmware en veroorzaken ze 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 in de / system-directory vindt, zal het systeem deze daadwerkelijk aanmaken en in de / system / dalvik-cache / directory plaatsen. Dit is precies wat er gebeurt als je bijvoorbeeld een nieuwe Android-versie flasht en het een tijdje de melding 'Bezig, applicaties optimaliseren' geeft.
Lowmemorykiller-tweaks
Multitasking in Android verschilt van andere mobiele besturingssystemen in die zin dat het is gebaseerd op een klassiek model waarbij applicaties stil op de achtergrond werken en er geen beperkingen zijn voor het aantal achtergrondapps ( tenzij er een is ingesteld in Developer Options, maar dit wordt over het algemeen afgeraden) - bovendien wordt de functionaliteit van de overgang naar een uitvoering op de achtergrond niet gestopt, hoewel het systeem zich het recht voorbehoudt om achtergrondapps te beëindigen in situaties met weinig geheugen ( zie waar we het eerder in deze handleiding hebben gehad over lowmemorykiller en out-of-memory killer) .
Om terug te gaan naar het lowmemorykiller mechanisme kan Android blijven werken met een beperkte hoeveelheid geheugen en een gebrek aan swappartitie. De gebruiker kan doorgaan met het starten van applicaties en ertussen schakelen, en het systeem zal ongebruikte achtergrond-apps stilletjes doden om te proberen geheugen vrij te maken voor actieve taken.
Dit was in het begin erg handig voor Android, hoewel het om de een of andere reden populair is geworden in de vorm van taakmoordenaar-apps, die over het algemeen meer schadelijk dan nuttig zijn. Task-killer-apps worden ofwel op gezette tijden wakker, of worden uitgevoerd door de gebruiker en lijken grote hoeveelheden RAM vrij te maken, wat wordt gezien als een positief - meer vrij RAM betekent een sneller apparaat, toch? Dit is echter niet precies het geval met Android.
Het hebben van een grote hoeveelheid vrij RAM-geheugen kan zelfs schadelijk zijn voor de prestaties en batterijduur van uw apparaat. Wanneer apps zijn opgeslagen in het RAM 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 deze al in het geheugen staat.
Daarom zijn taakmoordenaars niet zo populair als ze ooit waren, hoewel Android-beginners om de een of andere reden nog steeds op hen vertrouwen ( gebrek aan informatie, helaas) . Helaas heeft een nieuwe trend de plaats ingenomen van taakmoordenaars, de trend van lowmemorykiller mechanisme stemmingen. Dit zou bijvoorbeeld zijn MinFreeManager app, en het belangrijkste idee is om de RAM-overhead te verhogen voordat het systeem achtergrond-apps begint te doden.
Het standaard RAM-geheugen werkt bijvoorbeeld aan de grenzen - 4, 8, 12, 24, 32 en 40 Mb, en wanneer de vrije opslagruimte van 40 MB vol is, wordt een van de cachetoepassingen in het geheugen geladen maar niet rennen wordt beëindigd.
Dus eigenlijk zal Android altijd minimaal 40 MB beschikbaar geheugen hebben, wat genoeg is voor nog een applicatie eerder lowmemorykiller begint met het opruimproces - wat betekent dat Android altijd zijn best zal doen om de maximale hoeveelheid beschikbare RAM te gebruiken zonder de gebruikerservaring te verstoren.
Helaas, wat sommige homebrew-enthousiastelingen begonnen, is dat de waarde wordt verhoogd tot bijvoorbeeld 100 MB voordat LMK begint. Nu zal de gebruiker verliezen RAM (100-40 = 60), dus in plaats van deze ruimte te gebruiken om back-end-apps op te slaan, bewaart het systeem deze hoeveelheid geheugen vrij , met absoluut geen doel voor.
LKM-afstemming kan handig zijn voor veel oudere apparaten met 512 RAM, maar wie bezit die nog? 2GB is het moderne 'budgetbereik', zelfs 4GB RAM-apparaten worden tegenwoordig gezien als 'middenbereik', dus LMK-aanpassingen zijn echt verouderd en nutteloos.
I / O-aanpassingen
In veel optimalisatiescripts voor Android zul je vaak tweaks tegenkomen die betrekking hebben op het I / O-subsysteem. Laten we bijvoorbeeld eens kijken naar het ThunderBolt! Script, dat deze regels bevat:
echo 0> $ i / wachtrij / rotatie; echo 1024> $ i / wachtrij / nr_requests;
De eerste regel geeft de I / O-planner instructies voor het omgaan met een SSD, en de tweede regel verhoogt de maximale grootte van de wachtrij-I / O van 128 naar 1024 - omdat de $ i-variabele een pad bevat naar de boom van 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 / wachtrij / iosched / back_seek_penalty; echo 1> $ i / wachtrij / iosched / low_latency; echo 1> $ i / wachtrij / iosched / slice_idle;
Dit wordt gevolgd door meer regels die tot andere planners behoren, 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 zinloos, zelfs op desktop - het is eigenlijk alleen aanbevolen op zware servers . Je telefoon is geen zware Linux-server.
Voor een Android-apparaat zijn er vrijwel geen applicaties die prioriteit krijgen in de invoer-uitvoer en geen mechanische driver, dus de beste planner is de noop / FIFO-wachtrij, dus dit type planner ' tweak ” doet niets speciaals of zinvols aan het I / O-subsysteem. In feite kunnen al die lijstopdrachten met meerdere schermen beter worden vervangen door een eenvoudige cyclus:
voor i in / sys / block / mmc *; do echo noop> $ i / wachtrij / scheduler echo 0> $ i / wachtrij / iostats klaar
Dit zou de noop-planner voor alle schijven mogelijk maken van de accumulatie van I / O-statistieken, wat een positieve invloed zou moeten hebben op de prestaties, hoewel een zeer kleine en bijna volledig verwaarloosbare.
Een andere nutteloze I / O-aanpassing die vaak wordt aangetroffen in prestatiescripts, zijn de verhoogde read-ahead-waarden voor SD-kaarten tot 2 MB. Read-ahead-mechanisme is bedoeld voor het vroegtijdig lezen van gegevens 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 deze vooraf in het RAM laden, wat de terugkomsttijd zou moeten verkorten. Dit klinkt geweldig op papier, maar het vooruitleesalgoritme komt vaker voor mis , wat leidt tot totaal onnodige bewerkingen van input-output, om nog maar te zwijgen van 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 gewoon de standaardwaarde van 128 KB te behouden.
Systeemaanpassingen voor virtueel geheugenbeheer
Een andere veelgebruikte 'optimalisatietechniek' is het afstemmen van het virtuele geheugenbeheersubsysteem. Dit richt zich doorgaans op slechts twee kernelvariabelen, vm.dirty_background_ratio en vm.dirty_ratio, die bedoeld zijn voor het aanpassen van de grootte van de buffer voor het opslaan van 'vuile' gegevens. Vuil gegevens zijn doorgaans gegevens die naar schijf zijn geschreven, maar er is nog meer in het geheugen dat wacht om naar schijf te worden geschreven.
Typische tweak-waarden in zowel Linux-distributies als Androis voor het VM-beheersubsysteem zouden zijn als:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Dus wat dit probeert te doen, is dat wanneer de vuile databuffer 10% van de totale hoeveelheid RAM is, deze ontwaakt pdflush flow en begint gegevens naar de schijf te schrijven - als het opnemen van gegevens op de schijf zal gebeuren te intens , zal de buffer blijven groeien en wanneer het 20% van de beschikbare RAM bereikt, zal het systeem overschakelen naar de volgende schrijfbewerking in synchrone modus - zonder pre-buffer. Dit betekent dat het schrijven naar de schijftoepassing zal zijn geblokkeerd, totdat de gegevens naar de schijf worden geschreven (AKA ‘lag’).
Wat u moet begrijpen is dat zelfs als de buffergrootte bereikt geen 10% , zal het systeem automatisch pdflush starten na 30 seconden. Een combinatie van 10/20 is redelijk redelijk, bijvoorbeeld op een apparaat met 1GB RAM zou dit gelijk zijn aan 100/200 MB RAM, wat meer dan genoeg is in termen van burst-records waarbij de snelheid vaak onder het snelheidsrecord in systeem NAND ligt -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 nog hoger op te drijven, tot absurde tarieven. We kunnen bijvoorbeeld vinden in de Xplix optimalisatiescript een tarief zo hoog als 50/90.
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 volkomen nutteloos is voor een Android-apparaat, omdat het alleen zou werken onder constant opnemen 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 steeds redelijk zinloos:
if ['$ mem' -lt 524288]; dan sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; dan 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 in feite is er maar één reden om de standaardinstellingen te wijzigen: een apparaat met een erg 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 als dit te maken:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Wanneer een pieksysteem vervolgens bewerkingen schrijft, zonder dat er gegevens op de schijf hoeven te worden opgenomen, zal tot de laatste niet overschakelen naar de synchrone modus, waardoor toepassingen de vertraging bij het opnemen kunnen verminderen.
Extra nutteloze aanpassingen en prestatieafstemmingen
Er zijn nog veel meer 'optimalisaties' die echt niets doen. De meeste hebben simpelweg geen enkel effect, terwijl andere mogelijk verbeteren sommige aspect van de prestaties, terwijl het apparaat op andere manieren wordt verslechterd ( meestal komt het neer op prestaties versus leeglopen van de batterij) .
Hier zijn enkele aanvullende populaire optimalisaties die al dan niet nuttig kunnen zijn, afhankelijk van het Android-systeem en apparaat.
- Versnelling - De kleine versnelling om de prestaties en onderspanning te verbeteren - bespaart een beetje batterij.
- Database-optimalisatie - In theorie dit zou moeten geven een verbetering van de apparaatprestaties, maar het is twijfelachtig.
- Zipalign - Ironisch genoeg, ondanks de ingebouwde Android SDK-functie voor het uitlijnen van inhoud binnen het APK-bestand in de winkel, kun je ontdekken dat veel software niet via zipalign wordt verzonden.
- Schakel onnodige systeemservices uit en verwijder ongebruikt systeem en zelden gebruikte applicaties van derden. Kortom, bloatware verwijderen.
- Aangepaste kernel met optimalisaties voor een specifiek apparaat (nogmaals, niet alle kernen zijn even goed).
- Al 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 studie uitgevoerd en geconstateerd dat een indrukwekkend aantal /system/build.prop instellingen die aanbevolen worden voor gebruik 'experts' niet bestaan in de broncode 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_APP_ADJOME_ADJOMETags android Ontwikkeling 12 minuten gelezen
