Die häufigsten Mythen zur Android-Optimierung werden entlarvt

Daher verwenden viele All-in-One-Optimierungsskripte dieselben Methoden, von denen einige auf lange Sicht völlig veraltet oder schädlich sind. Zusammenfassend lässt sich sagen, dass die meisten „All-in-One“ -Optimierungsskripte nichts anderes als zusammengeschlagene empfohlene Optimierungen sind, ohne eine klare Vorstellung davon zu haben, wie oder warum diese Optimierungen funktionieren. Benutzer flashen dann die Skripte und behaupten, ihre Leistung sei plötzlich schneller (( Tatsächlich war es höchstwahrscheinlich der sehr einfache Neustart des Geräts, der zu einer Leistungssteigerung führte , da alles im RAM des Geräts bereinigt wird) .

In diesem exklusiven Appuals-Artikel werden einige der häufigsten Empfehlungen für ' optimieren “ Android-Leistung und ob es sich lediglich um einen Mythos oder um eine legitime Optimierung der Geräteleistung handelt.

Tauschen

Ganz oben auf der Mythenliste steht der Android-Tausch - was ziemlich absurd ist, wenn man ihn als Android-Optimierung betrachtet. Der Hauptzweck von Swaps besteht darin, die Auslagerungsdatei zu erstellen und zu verbinden, wodurch Speicherplatz im Speicher frei wird. Das klingt vernünftig auf Papier , aber es ist wirklich anwendbar auf a Server , die fast keine Interaktivität hat.

Wenn Sie den Tausch Ihres Android-Telefons regelmäßig verwenden, führt dies zu starken Verzögerungen, die darauf zurückzuführen sind, dass Dinge über den Cache rutschen. Stellen Sie sich zum Beispiel vor, eine Anwendung versucht, eine Grafik anzuzeigen, die im Swap gespeichert ist. Diese muss nun die Disc neu laden, nachdem Speicherplatz freigegeben wurde, indem der Datenaustausch mit einer anderen Anwendung durchgeführt wird. Es ist wirklich chaotisch.

Einige Optimierungsbegeisterte können sagen, dass Swap keine Probleme bot, aber es ist kein Swap, der die Leistung steigert - es ist der integrierte Android-Mechanismus Lowmemorykiller Dies tötet regelmäßig aufgeblähte Prozesse mit hoher Priorität ab, die nicht verwendet werden. LMK wurde speziell für den Umgang mit Bedingungen mit wenig Speicher entwickelt und wird von der aufgerufen kswapd Prozess und beendet im Allgemeinen User Space-Prozesse. Das ist anders als OOMkiller (Out-of-Memory-Killer), Aber das ist ein ganz anderes Thema.

Der Punkt ist, dass ein Gerät mit beispielsweise 1 GB RAM niemals die erforderlichen Leistungsdaten in einem Swap erreichen kann und daher ein Swap in Android absolut nicht erforderlich ist. Seine Umsetzung ist einfach mit Verzögerungen behaftet und führt zu a Degradierung in der Leistung, anstatt es zu optimieren.

zRAM - veraltet und nicht mehr effizient

zRAM ist eine bewährte und effektive Methode zur Geräteoptimierung, z ältere Geräte - Denken Sie an KitKat-basierte Geräte, die nur mit etwa 512 MB RAM betrieben werden. Die Tatsache, dass einige Leute immer noch zRAM-Optimierungen in Optimierungsskripten einfügen oder zRAM als eine Art moderne Optimierungsoptimierung empfehlen, ist ein Beispiel für Leute, die im Allgemeinen nicht die neuesten Betriebsprotokolle befolgen.

zRAM war für Multi-Core-SoCs der Einstiegsklasse mit Budgetbereich gedacht, z. B. Geräte mit MTK-Chipsätzen und 512 MB RAM. Im Grunde genommen sehr billige chinesische Telefone. Grundsätzlich trennt zRAM den Kernel über den Verschlüsselungsdatenstrom.

Wenn zRAM auf älteren Geräten mit a verwendet wird Einzelprozessor Selbst wenn zRAM für solche Geräte empfohlen wird, treten häufig große Mengen von Verzögerungen auf. Dies geschieht auch mit der KSM-Technologie ( Kernel Same Page Merging) Hier werden identische Speicherseiten kombiniert, um Speicherplatz freizugeben. Dies wird zwar von Google empfohlen, führt jedoch bei älteren Geräten zu größeren Verzögerungen, da die ständig aktiven Core-Theads kontinuierlich vom Speicher ausgeführt werden, um nach doppelten Seiten zu suchen. Grundsätzlich verlangsamt der Versuch, die Optimierungsoptimierung auszuführen, das Gerät ironischerweise noch weiter.

Seeder - veraltet seit Android 3.0

Einer der am meisten diskutierten Optimierungstipps unter Android-Entwicklern ist Zeder und wir sind sicher, dass jemand versuchen könnte, uns in diesem Thema das Gegenteil zu beweisen - aber zuerst müssen wir die Geschichte der Sämaschine untersuchen.

Seeder App für Android

Ja, es gibt eine große Anzahl von Berichten, die nach der Installation eine bessere Android-Leistung deklarieren viel ältere Android-Geräte . Menschen, aus welchen Gründen auch immer, glauben jedoch, dass dies auch eine anwendbare Optimierung für ist moderne Android-Geräte , was absolut absurd ist. Die Tatsache, dass Seeder weiterhin gepflegt und als „ modern' Das Tool zur Reduzierung von Verzögerungen ist ein Beispiel für Fehlinformationen - obwohl dies nicht die Schuld des Entwicklers von Seeder ist, da selbst auf der Play Store-Seite festgestellt wird, dass Seeder nach Android 4.0+ weniger effektiv ist. Aus welchem ​​Grund auch immer, Seeder taucht immer noch in Optimierungsdiskussionen für moderne Android-Systeme auf.

Was Seeder für Android 3.0 im Grunde tut, ist die Behebung eines Fehlers, bei dem die Android-Laufzeit aktiv die Datei / dev / random / verwendet, um Entropie zu erhalten. Der / dev / random / buffer würde instabil und das System würde blockiert, bis es die erforderliche Datenmenge gefüllt hat - denken Sie an kleine Dinge wie die verschiedenen Sensoren und Tasten auf dem Android-Gerät.

Seeders Autor nahm den Linux-Dämon rngd und für das Inastroil von Android kompiliert, sodass zufällige Daten aus einem viel schnelleren und vorhersehbareren / dev / urandom-Pfad entnommen und jede Sekunde in dev / random / zusammengeführt werden, ohne dass / dev / random / erschöpft wird. Dies führte zu einem Android-System, bei dem es nicht an Entropie mangelte und das viel flüssiger lief.

Google hat diesen Fehler nach Android 3.0 behoben, doch aus irgendeinem Grund taucht Seeder immer noch auf 'Empfohlene Optimierungen' Listen zur Optimierung der Android-Leistung. Darüber hinaus verfügt die Seeder-App über einige Analoga wie sEFix, die die Seeder-Funktionalität enthalten, unabhängig davon, ob diese verwendet wird rngd oder die Alternative hasged oder auch nur eine Verknüpfung zwischen / dev / urandom und / dev / random. Dies ist für moderne Android-Systeme absolut sinnlos.

Der Grund dafür ist, dass neuere Android-Versionen / dev / random / in drei Hauptkomponenten verwenden - libcrypto , zur Verschlüsselung von SSL-Verbindungen, zum Generieren von SSH-Schlüsseln usw. WPA_supplication / hostapd, das WEP / WPA-Schlüssel generiert, und schließlich eine Handvoll Bibliotheken zum Generieren von IDs beim Erstellen von EXT2 / EXT3 / EXT4-Dateisystemen.

Also wann Sämaschine oder Seeder-basierte Verbesserungen sind in modernen Android-Optimierungsskripten enthalten Degradierung in der Geräteleistung, weil rngd wird das Gerät ständig aufwecken und eine Erhöhung der CPU-Frequenz verursachen, was sich natürlich negativ auf den Batterieverbrauch auswirkt.

Odex

Die Standard-Firmware auf Android-Geräten ist so ziemlich immer Odex. Dies bedeutet, dass neben dem Standardpaket für Android-Apps im APK-Format, das in / system / app / und / system / priv-app / zu finden ist, dieselben Dateinamen mit der Erweiterung .odex verwendet werden. Die Odex-Dateien enthalten optimierte Bytecode-Anwendungen, die bereits die virtuelle Maschine des Validators und Optimierers durchlaufen haben und dann in einer separaten Datei mit so etwas wie aufgezeichnet werden dexopt Werkzeug.

Odex-Dateien sollen also die virtuelle Maschine auslagern und einen beschleunigten Start der Odex-Anwendung ermöglichen. ODEX-Dateien verhindern jedoch Änderungen an der Firmware und verursachen Probleme mit Updates. Aus diesem Grund werden viele benutzerdefinierte ROMs wie LineageOS verteilt ohne ODEX .

Das Generieren von ODEX-Dateien erfolgt auf verschiedene Arten, beispielsweise mit dem Odexer Tool. Das Problem besteht darin, dass es sich lediglich um einen Placebo-Effekt handelt. Wenn ein modernes Android-System keine Odex-Dateien im Verzeichnis / system findet, erstellt das System diese tatsächlich und legt sie im Verzeichnis / system / dalvik-cache / ab. Genau dies geschieht, wenn Sie beispielsweise eine neue Android-Version flashen und für eine Weile die Meldung 'Beschäftigt, Anwendungen optimieren' angezeigt wird.

Lowmemorykiller-Optimierungen

Multitasking in Android unterscheidet sich von anderen mobilen Betriebssystemen darin, dass es auf einem klassischen Modell basiert, bei dem Anwendungen leise im Hintergrund arbeiten und die Anzahl der Hintergrund-Apps nicht eingeschränkt ist ( es sei denn, man ist in den Entwickleroptionen festgelegt, aber dies wird im Allgemeinen gegen empfohlen.) - Darüber hinaus wird die Funktionalität des Übergangs zu einer Hintergrundausführung nicht gestoppt, obwohl sich das System das Recht vorbehält, Hintergrund-Apps in Situationen mit wenig Arbeitsspeicher zu beenden ( Sehen Sie, wo wir weiter oben in diesem Handbuch über Lowmemorykiller und Out-of-Memory-Killer gesprochen haben. .

Zurück zum Lowmemorykiller Mechanismus kann Android weiterhin mit einer begrenzten Menge an Speicher und einem Mangel an Swap-Partition arbeiten. Der Benutzer kann weiterhin Anwendungen starten und zwischen ihnen wechseln. Das System beendet nicht verwendete Hintergrund-Apps stillschweigend, um Speicher für aktive Aufgaben freizugeben.

Dies war in den frühen Tagen für Android sehr nützlich, obwohl es aus irgendeinem Grund in Form von Task-Killer-Apps populär geworden ist, die im Allgemeinen eher schädlich als nützlich sind. Task-Killer-Apps werden entweder in festgelegten Intervallen aktiviert oder vom Benutzer ausgeführt und scheinen große Mengen an RAM freizugeben, was als positiv angesehen wird. Mehr freies RAM bedeutet ein schnelleres Gerät, oder? Dies ist jedoch bei Android nicht genau der Fall.

Tatsächlich kann eine große Menge an freiem RAM die Leistung und die Akkulaufzeit Ihres Geräts beeinträchtigen. Wenn Apps im RAM von Android gespeichert sind, ist es viel einfacher, sie aufzurufen, zu starten usw. Das Android-System muss nicht viel Ressourcen für den Wechsel zur App aufwenden, da es bereits im Speicher vorhanden ist.

Aus diesem Grund sind Task-Killer nicht mehr so ​​beliebt wie früher, obwohl Android-Neulinge aus irgendeinem Grund immer noch auf sie angewiesen sind ( Mangel an Informationen, leider) . Leider hat ein neuer Trend Task-Killer ersetzt, der Trend von Lowmemorykiller Mechanismusabstimmungen. Dies wäre zum Beispiel MinFreeManager Die Hauptidee besteht darin, den RAM-Overhead zu erhöhen, bevor das System Hintergrund-Apps beendet.

So arbeitet der Standard-RAM beispielsweise an den Grenzen 4, 8, 12, 24, 32 und 40 MB. Wenn der freie Speicherplatz von 40 MB belegt ist, wird eine der zwischengespeicherten Apps in den Speicher geladen aber nicht laufen wird erloschen sein.

Grundsätzlich verfügt Android immer über mindestens 40 MB verfügbaren Speicher, was ausreicht, um zuvor eine weitere Anwendung aufzunehmen Lowmemorykiller beginnt mit dem Bereinigungsprozess - was bedeutet, dass Android immer sein Bestes tut, um die maximale Menge an verfügbarem RAM zu nutzen, ohne die Benutzererfahrung zu beeinträchtigen.

Leider haben einige Homebrew-Enthusiasten empfohlen, den Wert vor dem Start von LMK auf beispielsweise 100 MB zu erhöhen. Jetzt wird der Benutzer dies tatsächlich tun verlieren RAM (100 - 40 = 60). Anstatt diesen Speicherplatz zum Speichern von Back-End-Apps zu verwenden, behält das System diese Speichermenge bei kostenlos , mit absolut keinem Zweck dafür.

LKM-Abstimmung kann nützlich sein für viel ältere Geräte mit 512 RAM, aber wem gehören diese noch? 2 GB sind der moderne „Budgetbereich“, selbst 4 GB RAM-Geräte werden heutzutage als „Mittelklasse“ angesehen, sodass LMK-Optimierungen wirklich veraltet und nutzlos sind.

I / O-Optimierungen

In vielen Optimierungsskripten für Android finden Sie häufig Optimierungen, die sich auf das E / A-Subsystem beziehen. Schauen wir uns zum Beispiel die an Blitz! Skript, das folgende Zeilen enthält:

Echo 0> $ i / Warteschlange / Rotation; echo 1024> $ i / queue / nr_requests;

In der ersten Zeile werden die Anweisungen des E / A-Schedulers für den Umgang mit einer SSD angegeben, und in der zweiten Zeile wird die maximale Größe der Warteschlangen-E / A von 128 auf 1024 erhöht, da die Variable $ i einen Pfad zum Baum der Blockgeräte enthält / sys, und das Skript wird in einer Schleife ausgeführt.

Anschließend finden Sie eine Zeile zum CFQ-Scheduler:

Echo 1> $ i / queue / iosched / back_seek_penalty; Echo 1> $ i / queue / iosched / low_latency; Echo 1> $ i / queue / iosched / Slice_idle;

Darauf folgen weitere Zeilen, die anderen Planern gehören, aber letztendlich sind die ersten beiden Befehle sinnlos, weil:

Ein moderner Linux-Kernel kann verstehen, mit welcher Art von Speichermedium er standardmäßig arbeitet.

Eine lange Eingabe-Ausgabe-Warteschlange ( wie 1024) ist auf einem modernen Android-Gerät nutzlos, sogar auf dem Desktop bedeutungslos - es wird wirklich nur auf empfohlen Hochleistungsserver . Ihr Telefon ist kein Hochleistungs-Linux-Server.

Für ein Android-Gerät gibt es praktisch keine Anwendungen, die in der Eingabe / Ausgabe priorisiert sind, und keinen mechanischen Treiber. Der beste Planer ist also die Noop / FIFO-Warteschlange. Diese Art von Scheduler “ optimieren ” tut dem E / A-Subsystem nichts Besonderes oder Sinnvolles. Tatsächlich werden alle diese Listenbefehle mit mehreren Bildschirmen besser durch einen einfachen Zyklus ersetzt:

für i in / sys / block / mmc *; Echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats erledigt

Dies würde den Noop-Scheduler für alle Laufwerke aus der Anhäufung von E / A-Statistiken aktivieren, was sich positiv auf die Leistung auswirken sollte, wenn auch ein sehr winziger und fast völlig vernachlässigbarer.

Eine weitere nutzlose E / A-Optimierung, die häufig in Leistungsskripten zu finden ist, sind die erhöhten Vorauslesewerte für SD-Karten bis zu 2 MB. Der Vorauslesemechanismus dient zum frühen Lesen von Daten von den Medien, bevor die App den Zugriff auf diese Daten anfordert. Im Grunde wird der Kernel versuchen, herauszufinden, welche Daten in Zukunft benötigt werden, und sie vorab in den RAM laden, wodurch sich die Rückgabezeit verkürzen sollte. Auf dem Papier klingt das großartig, aber der Vorauslesealgorithmus ist häufiger falsch Dies führt zu völlig unnötigen Operationen der Eingabe / Ausgabe, ganz zu schweigen von einem hohen RAM-Verbrauch.

In RAID-Arrays werden hohe Vorauslesewerte zwischen 1 und 8 MB empfohlen. Für Android-Geräte empfiehlt es sich jedoch, nur den Standardwert von 128 KB beizubehalten.

Optimierungen des Virtual Memory Management-Systems

Eine weitere gängige Optimierungstechnik ist die Optimierung des Subsystems für die Verwaltung des virtuellen Speichers. Dies zielt normalerweise nur auf zwei Kernelvariablen ab, vm.dirty_background_ratio und vm.dirty_ratio, die zum Anpassen der Größe des Puffers zum Speichern von 'schmutzigen' Daten dienen. Dreckig Daten sind normalerweise Daten, die auf die Festplatte geschrieben wurden, aber noch mehr im Speicher sind und darauf warten, auf die Festplatte geschrieben zu werden.

Typische Optimierungswerte sowohl in Linux-Distributionen als auch in Androis für das VM-Verwaltungssubsystem sind:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Dies versucht also, dass der verschmutzte Datenpuffer, wenn er 10% der Gesamtmenge an RAM ausmacht, erwacht pdflush fließen und beginnt, Daten auf die Festplatte zu schreiben - wenn der Vorgang des Aufzeichnens von Daten auf der Festplatte ausgeführt wird zu intensiv Der Puffer wächst weiter und wenn er 20% des verfügbaren RAM erreicht, schaltet das System im synchronen Modus auf den nachfolgenden Schreibvorgang um - ohne Vorpuffer. Dies bedeutet, dass das Schreiben auf die Festplattenanwendung erledigt sein wird blockiert, bis die Daten auf die Festplatte geschrieben sind (AKA ‘lag’).

Was Sie verstehen sollten ist, dass auch wenn die Puffergröße erreicht nicht 10% Das System schaltet nach 30 Sekunden automatisch pdflush ein. Eine Kombination von 10/20 ist ziemlich vernünftig. Auf einem Gerät mit 1 GB RAM entspricht dies beispielsweise 100/200 MB RAM. Dies ist mehr als ausreichend für Burst-Datensätze, bei denen die Geschwindigkeit im System-NAND häufig unter dem Geschwindigkeitsrekord liegt -speicher oder SD-Karte, z. B. beim Installieren von Apps oder beim Kopieren von Dateien von einem Computer.

Aus irgendeinem Grund versuchen Drehbuchautoren, diesen Wert noch weiter zu erhöhen, zu absurden Raten. Zum Beispiel finden wir in der Xplix Optimierungsskript eine Rate von bis zu 50/90.

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

Auf einem Gerät mit 1 GB Arbeitsspeicher wird dadurch die Beschränkung für einen verschmutzten Puffer auf 500/900 MB festgelegt, was für ein Android-Gerät völlig nutzlos ist, da es nur unter funktioniert ständige Aufnahme auf der Disc - etwas, das nur auf einem schweren Linux-Server passiert.

Blitz! Das Skript verwendet einen vernünftigeren Wert, aber insgesamt ist es immer noch ziemlich bedeutungslos:

wenn ['$ mem' -lt 524288]; dann sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; dann sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; sonst sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;

Die ersten beiden Befehle werden auf Smartphones mit 512 MB RAM ausgeführt, der zweite mit 1 GB und andere mit mehr als 1 GB. Tatsächlich gibt es jedoch nur einen Grund, die Standardeinstellungen zu ändern - ein Gerät mit einem sehr langsamen internen Speicher oder einer sehr langsamen Speicherkarte. In diesem Fall ist es sinnvoll, die Werte der Variablen zu verteilen, dh so etwas zu machen:

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

Wenn ein Überspannungssystem Vorgänge schreibt, ohne Daten auf der Disc aufzeichnen zu müssen, wird bis zum letzten nicht in den synchronen Modus gewechselt, wodurch Anwendungen die Verzögerung beim Aufzeichnen verringern können.

Zusätzliche nutzlose Optimierungen und Leistungsoptimierungen

Es gibt viel mehr 'Optimierungen', die wirklich nichts bewirken. Die meisten von ihnen haben einfach keinerlei Wirkung, während andere sich verbessern können etwas Leistungsaspekt, während das Gerät auf andere Weise beeinträchtigt wird ( Normalerweise läuft es auf Leistung im Vergleich zum Batterieverbrauch hinaus. .

Im Folgenden finden Sie einige weitere beliebte Optimierungen, die je nach Android-System und -Gerät nützlich sein können oder nicht.

• Beschleunigung - Die geringe Beschleunigung zur Verbesserung der Leistung und der Unterspannung spart ein wenig Batterie.
• Datenbankoptimierung - Theoretisch ist dies sollte geben eine Verbesserung der Geräteleistung, aber es ist zweifelhaft.
• Zipalign - Ironischerweise wird trotz der integrierten Inhaltsausrichtung für Android SDK-Funktionen in der APK-Datei im Store festgestellt, dass viele Softwareprogramme nicht über zipalign übertragen werden.
• Deaktivieren Sie unnötige Systemdienste und entfernen Sie nicht verwendete Systeme und selten verwendete Anwendungen von Drittanbietern. Grundsätzlich Deinstallation von Bloatware.
• Benutzerdefinierter Kernel mit Optimierungen für ein bestimmtes Gerät (auch hier sind nicht alle Kerne gleich gut).
• Bereits beschriebener E / A-Scheduler noop.
• Sättigungsalgorithmus TCP Westwood - Effizientere Verwendung im Standard-Android Cubic für drahtlose Netzwerke, verfügbar in benutzerdefinierten Kerneln.

Nutzlose Einstellungen build.prop

LaraCraft304 vom XDA Developers Forum hat eine Studie durchgeführt und festgestellt, dass eine beeindruckende Anzahl von /system/build.prop-Einstellungen, die für die Verwendung von „Experten“ empfohlen werden, in den Quellen AOSP und CyanogenMod nicht vorhanden sind. Hier ist die Liste:

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_ode.