Häufigste Mythen zur Android-Optimierung entlarvt

Advise: Klicken Sie Hier, Windows-Fehler Und Optimiert Die Systemleistung Zu Beheben

Es gibt viele Anleitungen, die sich mit der Steigerung der Android-Leistung befassen, und allgemeine Optimierungstipps. Einige von ihnen sind legitim und andere basieren nur auf theoretischen oder veralteten Betriebsmethoden im Android-System oder sind einfach Unsinn. Dies umfasst Empfehlungen zum Austauschen, Werte, die zu build.prop hinzugefügt wurden, und Variablenänderungen im Linux-Kernel.

Es gibt sogar eine Menge „Optimierungsskripte“, all-in-one-flashbare .zips, die versprechen, die Leistung, die Akkulaufzeit und andere Dinge erheblich zu verbessern. Einige der Optimierungen können tatsächlich funktionieren, aber die meisten sind lediglich ein Placebo-Effekt oder wirken sich sogar negativ auf Ihr Gerät aus.

Das soll nicht heißen, dass Leute absichtlich schändliche Skripte veröffentlichen - es gibt definitiv gefälschte bezahlte Apps im Play Store, aber Optimierungsskripte, die in Android-Foren veröffentlicht wurden, sind im Allgemeinen gut gemeint. oder einfach mit verschiedenen Optimierungsänderungen experimentieren. Unglücklicherweise tritt eine Art Schneeballeffekt auf, insbesondere in "All-in-One" -Optimierungsskripten. Eine kleine Handvoll der Optimierungen kann tatsächlich etwas bewirken, während eine andere Reihe von Optimierungen in einem Skript möglicherweise überhaupt nichts bewirkt. Diese Skripten werden jedoch als Wundermittel angesehen, ohne dass wirklich untersucht wird, was funktioniert und was nicht .

Daher verwenden viele All-in-One-Optimierungsskripte dieselben Methoden, von denen einige auf lange Sicht völlig veraltet oder schädlich sind. Zusammenfassend ist festzuhalten, dass die meisten "All-in-One" -Optimierungsskripte nichts anderes sind, als die empfohlenen Optimierungen zusammenzufassen, ohne eine klare Vorstellung davon zu haben, wie oder warum diese Optimierungen funktionieren. Die Benutzer lassen dann die Skripte flashen und behaupten, dass ihre Leistung plötzlich schneller ist ( In der Tat war es höchstwahrscheinlich der sehr einfache Vorgang des Neustarts des Geräts, der zu einer Leistungssteigerung führte, da alles im RAM des Geräts bereinigt wurde.)

In diesem exklusiven Artikel von Appuals werden einige der häufigsten Empfehlungen zur „ Optimierung“ der Android-Leistung hervorgehoben, und ob es sich lediglich um einen Mythos oder eine legitime Optimierung der Geräteleistung handelt.

Wechsel

Ganz oben auf der Mythenliste steht der Android-Tausch - was ziemlich absurd ist, wenn man ihn als Android-Optimierung ansieht. Der Hauptzweck von Swaps ist das Erstellen und Verbinden der Auslagerungsdatei, wodurch Speicherplatz im Speicher frei wird. Das klingt auf dem Papier vernünftig, ist aber auf einen Server anwendbar, der fast keine Interaktivität aufweist.

Wenn Sie den Swap Ihres Android-Telefons regelmäßig verwenden, kommt es zu erheblichen Verzögerungen, die von Dingen herrühren, die am Cache vorbeigleiten. Stellen Sie sich zum Beispiel vor, eine Anwendung versucht, eine Grafik anzuzeigen, die im Swap gespeichert ist, und muss die Disc nach der Freigabe von Speicherplatz neu laden, indem sie einen Datenaustausch mit einer anderen Anwendung vornimmt. 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, der regelmäßig aufgeblähte Prozesse mit hoher Priorität tötet, die nicht verwendet werden. LMK wurde speziell für den Umgang mit Bedingungen mit geringem Arbeitsspeicher entwickelt, wird vom kswapd- Prozess aufgerufen und bricht im Allgemeinen Benutzerbereichsprozesse ab. Dies unterscheidet sich von 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 in Android absolut nicht benötigt wird. Die Implementierung ist lediglich mit Verzögerungen behaftet und führt eher zu einer Verschlechterung der Leistung als zu deren Optimierung.

zRAM - veraltet und nicht mehr effizient

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

zRAM war für Multi-Core-SoCs der Einstiegsklasse im Budgetbereich vorgesehen, z. B. für Geräte, die MTK-Chipsätze und 512 MB RAM verwenden. Im Grunde genommen sehr billige chinesische Telefone. Grundsätzlich trennt zRAM den Kernel über den Verschlüsselungsstrom.

Wenn zRAM auf älteren Geräten mit einem einzigen Kern verwendet wird, können große Mengen an Verzögerungen auftreten, auch wenn zRAM auf solchen Geräten empfohlen wird. Dies geschieht auch mit der KSM-Technologie ( Kernel Same Page Merging), bei der identische Speicherseiten kombiniert werden, um Speicherplatz freizugeben. Dies wird in der Tat von Google empfohlen, führt jedoch zu größeren Verzögerungen bei älteren Geräten, da die ständig aktiven Core-Threads kontinuierlich vom Arbeitsspeicher ausgeführt werden, um nach doppelten Seiten zu suchen. Grundsätzlich verlangsamt der Versuch, den Optimierungs-Tweak auszuführen, das Gerät ironischerweise noch weiter.

Seeder - Veraltet seit Android 3.0

Einer der umstrittensten Optimierungstipps unter Android-Entwicklern ist Seeder, und wir sind sicher, dass jemand versuchen könnte, uns in diesem Thema das Gegenteil zu beweisen - aber zuerst müssen wir die Geschichte von Seeder untersuchen.

Sämaschine App für Android

Ja, es gibt eine große Anzahl von Berichten, die nach der Installation auf viel älteren Android-Geräten eine bessere Android-Leistung ausweisen . Die Leute aus irgendeinem Grund glauben jedoch, dass dies auch eine anwendbare Optimierung für moderne Android-Geräte ist, was absolut absurd ist. Die Tatsache, dass Seeder weiterhin als „ modernes“ Tool zur Reduzierung von Verzögerungen gepflegt und angeboten wird, ist ein Beispiel für Fehlinformationen - obwohl dies nicht die Schuld des Entwicklers von Seeder ist, da selbst die Play Store-Seite feststellt, dass Seeder nach Android 4.0+ weniger effektiv ist. Aus welchem ​​Grund auch immer, Seeder nimmt immer noch an Optimierungsdiskussionen für moderne Android-Systeme teil.

Was Seeder im Grunde für Android 3.0 tut, ist die Behebung eines Fehlers, bei dem Android Runtime aktiv die Datei / dev / random / verwendet, um Entropie zu erhalten. Das / dev / random / buffer wird instabil und das System wird blockiert, bis die erforderliche Datenmenge erreicht ist. Denken Sie an Kleinigkeiten wie die verschiedenen Sensoren und Tasten auf dem Android-Gerät.

Der Autor von Seeder nahm den Linux-Dämon rngd und kompilierte ihn für das Inastroil von Android, so dass er zufällige Daten von einem viel schnelleren und vorhersehbareren / dev / urandom-Pfad nahm und sie in dev / random / jede Sekunde zusammenführt, ohne / dev / random zuzulassen erschöpft sein. Dies führte zu einem Android-System, das keinen Mangel an Entropie aufwies und viel flüssiger lief.

Google hat diesen Fehler nach Android 3.0 beseitigt, doch aus irgendeinem Grund wird Seeder immer noch in den empfohlenen Optimierungslisten für die Leistungsoptimierung von Android angezeigt. Darüber hinaus verfügt die Seeder-App über einige Analoga wie sEFix, die die Funktionalität von Seeder umfassen, unabhängig davon, ob Sie dasselbe rngd oder die Alternative haveged verwenden oder nur einen Symlink 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, um SSL-Verbindungen zu verschlüsseln, SSH-Schlüssel zu generieren usw. WPA_supplication / hostapd, das WEP / WPA-Schlüssel generiert, und schließlich eine Handvoll Bibliotheken zur ID-Generierung beim Erstellen von EXT2 / EXT3 / EXT4-Dateisystemen.

Wenn Seeder- oder Seeder-basierte Verbesserungen in modernen Android-Optimierungsskripten enthalten sind, führt dies zu einer Verschlechterung der Geräteleistung, da rngd das Gerät ständig aufweckt und die CPU-Frequenz erhöht, was sich natürlich negativ auf den Batterieverbrauch auswirkt .

Odex

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

Daher sollen ODEX-Dateien die virtuelle Maschine auslagern und einen beschleunigten Start der ODEX-Anwendung ermöglichen. Auf der anderen Seite verhindern ODEX-Dateien Änderungen an der Firmware und verursachen Probleme mit Aktualisierungen. Aus diesem Grund werden viele benutzerdefinierte ROMs wie LineageOS ohne diese verteilt ODEX .

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

Lowmemorykiller zwickt

Multitasking in Android unterscheidet sich von anderen mobilen Betriebssystemen darin, dass es auf einem klassischen Modell basiert, bei dem Anwendungen im Hintergrund leise arbeiten und es keine Einschränkungen für die Anzahl der Hintergrund-Apps gibt (es sei denn, in den Entwickleroptionen ist eine festgelegt, dies ist jedoch der Fall) Allgemein empfohlen dagegen) - Die Funktionalität des Übergangs zu einer Hintergrundausführung wird nicht angehalten, obwohl sich das System das Recht vorbehält, Hintergrund-Apps in Situationen mit wenig Arbeitsspeicher zu beenden ( siehe oben, wo von Lowmemorykiller und Out-of-Memory-Killer gesprochen wurde) Führer) .

Um auf den Lowmemorykiller- Mechanismus zurückzukommen, kann Android mit einer begrenzten Menge an Speicher und einem Mangel an Swap-Partition weiterarbeiten. Der Benutzer kann weiterhin Anwendungen starten und zwischen diesen wechseln, und das System beendet stillschweigend nicht verwendete Hintergrundanwendungen, um zu versuchen, Speicher für aktive Aufgaben freizugeben.

Dies war in den Anfängen 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 setzen offenbar große Mengen an RAM frei, was positiv zu bewerten ist - mehr freier RAM bedeutet ein schnelleres Gerät, oder? Dies ist jedoch bei Android nicht 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 das Umschalten auf die App aufwenden, da sie bereits im Speicher vorhanden ist.

Aus diesem Grund sind Task-Killers nicht mehr so ​​beliebt wie früher, obwohl Android-Neulinge aus irgendeinem Grund immer noch dazu neigen, sich auf sie zu verlassen ( leider mangelnde Informationen) . Leider hat ein neuer Trend die Task-Killer abgelöst, den Trend der Abstimmung von Mechanismen mit niedrigem Speicherbedarf . Dies ist beispielsweise die MinFreeManager- App. Die Hauptidee besteht darin, den RAM-Overhead zu erhöhen, bevor das System Hintergrund-Apps beendet.

So arbeitet beispielsweise der Standard-RAM an den Rändern 4, 8, 12, 24, 32 und 40 MB. Wenn der freie Speicherplatz von 40 MB voll ist, wird eine der zwischengespeicherten Apps in den Speicher geladen, aber nicht ausgeführt wird erloschen sein.

Grundsätzlich hat Android also immer mindestens 40 MB verfügbaren Speicher, was ausreicht, um eine weitere Anwendung aufzunehmen, bevor lowmemorykiller mit der Bereinigung beginnt. Dies bedeutet, dass Android stets sein Bestes tut, um den maximal verfügbaren Arbeitsspeicher zu nutzen, ohne den Arbeitsspeicher zu beeinträchtigen Benutzererfahrung.

Leider wurde von einigen Homebrew-Enthusiasten empfohlen, den Wert auf beispielsweise 100 MB zu erhöhen, bevor LMK einsetzt. Jetzt verliert der Benutzer tatsächlich RAM (100 - 40 = 60). End-Apps, wird das System diese Menge an Speicher frei halten, ohne jeden Zweck dafür.

LKM-Tuning kann für viel ältere Geräte mit 512 RAM nützlich sein, aber wem gehören diese Geräte noch? 2 GB sind der moderne „Budgetbereich“, selbst 4 GB-RAM-Geräte gelten heutzutage als „Mittelklasse“, sodass LMK-Optimierungen wirklich veraltet und unbrauchbar 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 den ThunderBolt an! 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 zum Umgang mit einer SSD angezeigt, 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 in enthält / sys, und das Skript wird in einer Schleife ausgeführt.

Im Anschluss 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; 

Es 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 ( z. B. 1024) ist auf einem modernen Android-Gerät nutzlos, sogar auf einem Desktop ist sie bedeutungslos. Sie wird wirklich nur auf Hochleistungsservern empfohlen. Ihr Telefon ist kein Hochleistungs-Linux-Server.

Für ein Android-Gerät gibt es praktisch keine Anwendungen mit Priorität für die Eingabe / Ausgabe und keinen mechanischen Treiber. Der beste Planer ist also die Noop / FIFO-Warteschlange. Diese Art von Scheduler- Optimierung hat also keine besonderen oder bedeutungsvollen Auswirkungen auf die E / A-Subsystem. Tatsächlich werden alle diese Listenbefehle mit mehreren Bildschirmen besser durch einen einfachen Zyklus ersetzt:

 für i in / sys / block / mmc *; Geben Sie noop> $ i / queue / scheduler als Echo aus. echo 0> $ i / queue / iostats done 

Dies würde den Noop-Scheduler für alle Laufwerke von der Ansammlung von E / A-Statistiken befreien, was sich positiv auf die Leistung auswirken sollte, obwohl es sich um eine sehr kleine und nahezu vernachlässigbare handelt.

Eine weitere nutzlose E / A-Optimierung, die in Leistungsskripten häufig zu finden ist, sind die erhöhten Vorauslesewerte für SD-Karten bis zu 2 MB. Der Read-Ahead-Mechanismus 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 diese vorab in den RAM laden, was die Rückkehrzeit verkürzen dürfte. Auf dem Papier hört sich das gut an, aber der Vorauslesealgorithmus ist häufiger falsch, was zu völlig unnötigen Eingaben und Ausgaben führt, ganz zu schweigen von einem hohen RAM-Verbrauch.

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

Optimierungen am Virtual Memory Management-System

Eine andere übliche „Optimierungstechnik“ ist das Optimieren des virtuellen Speicherverwaltungssubsystems. Dies zielt normalerweise nur auf zwei Kernelvariablen ab, vm.dirty_background_ratio und vm.dirty_ratio, mit denen die Größe des Puffers zum Speichern von "schmutzigen" Daten angepasst wird. Bei unsauberen Daten handelt es sich normalerweise um Daten, die auf die Festplatte geschrieben wurden, sich jedoch noch mehr im Speicher befinden und darauf warten, auf die Festplatte geschrieben zu werden.

Typische Optimierungswerte in Linux-Distributionen und Androis für das VM-Verwaltungssubsystem lauten wie folgt:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Wenn der Puffer für verschmutzte Daten 10% des gesamten Arbeitsspeichers ausmacht, wird der pdflush- Fluss aktiviert, und es werden Daten auf die Festplatte geschrieben - wenn das Aufzeichnen von Daten auf der Festplatte zu intensiv ist. Der Puffer wächst weiter und wenn er 20% des verfügbaren Arbeitsspeichers erreicht, wechselt das System im synchronen Modus zum nachfolgenden Schreibvorgang - ohne Vorpuffer. Dies bedeutet, dass das Schreiben auf eine Festplattenanwendung blockiert wird, bis die Daten auf die Festplatte geschrieben wurden (AKA 'lag').

Was Sie verstehen sollten ist, dass das System nach 30 Sekunden automatisch pdflush startet, auch wenn die Puffergröße nicht 10% erreicht. Eine Kombination von 10/20 ist ziemlich vernünftig, zum Beispiel würde dies auf einem Gerät mit 1 GB RAM 100/200 MB RAM entsprechen, was mehr als genug für Burst-Datensätze ist, bei denen die Geschwindigkeit häufig unter der Geschwindigkeitsaufzeichnung in System-NAND 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 können wir im Xplix- Optimierungsskript eine Rate von bis zu 50/90 finden.

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

Auf einem Gerät mit 1 GB Arbeitsspeicher ist ein Dirty-Buffer auf 500/900 MB beschränkt, was für ein Android-Gerät völlig nutzlos ist, da es nur bei ständiger Aufnahme auf der Disc funktioniert - etwas, das nur auf einem schweren Datenträger auftritt Linux Server.

Blitz! 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 Speicherkarte. In diesem Fall ist es vernünftig, die Werte der Variablen zu verteilen, dh etwa so 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 Vorgang nicht in den synchronen Modus umgeschaltet, wodurch Anwendungen Verzögerungen beim Aufzeichnen verringern können.

Zusätzliche nutzlose Optimierungen und Leistungsoptimierungen

Es gibt noch viel mehr "Optimierungen", die wirklich nichts bewirken. Die meisten von ihnen haben einfach keinerlei Auswirkungen, während andere die Leistung verbessern und das Gerät auf andere Weise verschlechtern können ( normalerweise läuft es auf die Leistung im Vergleich zum Batterieverbrauch hinaus) .

Im Folgenden sind einige weitere beliebte Optimierungen aufgeführt, die je nach Android-System und -Gerät möglicherweise hilfreich sind oder nicht.

  • Beschleunigung - Die geringe Beschleunigung zur Verbesserung der Leistung und zum Unterspannen - spart etwas Batterie.
  • Datenbankoptimierung - Theoretisch sollte dies zu einer Verbesserung der Geräteleistung führen, was jedoch zweifelhaft ist.
  • Zipalign - Ironischerweise wird trotz der integrierten Ausrichtung der Inhalte des Android SDK in der APK-Datei im Store nicht viel Software über Zipalign übertragen.
  • Deaktivieren Sie nicht benötigte Systemdienste, und entfernen Sie nicht verwendete System- 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 I / O Scheduler noop.
  • Sättigungsalgorithmus TCP Westwood - Effizientere Verwendung im standardmäßigen 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. 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_rptersist.sys.shutdown.mode_ro 

Interessante Artikel