Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Android
Code

Erkennung und Lösung von Leistungsproblemen auf Android

by
Difficulty:IntermediateLength:LongLanguages:

German (Deutsch) translation by Władysław Łucyszyn (you can also view the original English article)

Einführung

Egal, wie innovativ und nützlich Ihre Android-App ist, ob sie lückenhaft ist, anfällig für das Einfrieren ist, oder ob sie Ihnen Speichermöglichkeiten bietet, niemand wird sie verwenden wollen.

Die Leistung ist sehr wichtig, aber es ist auch etwas, das Sie leicht vergessen können, wenn Sie damit beschäftigt sind, Ihrer schönen Benutzeroberfläche den letzten Schliff zu geben oder neue und aufregende Funktionen für Ihre App zu entwickeln.

Das heißt, bis die negativen Google Play-Bewertungen ins Rollen kommen.

In diesem Artikel erhalten Sie einen Schnellkurs in den allgemeinen Leistungsproblemen, die jeder Android-Entwickler beachten muss. Sie erfahren, wie Sie testen können, ob diese Probleme in Ihren eigenen Projekten auftreten. Verwenden Sie dazu die Tools des Android SDK sowie ein Tool, das bereits auf Ihrem Android-Gerät installiert ist.

Wenn Sie in Ihrer App ein Leistungsproblem feststellen, sollten Sie es offensichtlich beheben. Währenddessen werden wir uns auch ansehen, wie Sie mit den Android-SDK-Tools mehr Informationen zu den aufgetretenen Leistungsproblemen erhalten. Sobald Sie über diese Informationen verfügen, können Sie besser verstehen, wie Sie die Leistung Ihrer App optimieren und schließlich eine App erstellen können, die von den Nutzern gerne verwendet wird.

1. Überziehung

Schritt 1: Das Problem

Die Benutzeroberfläche Ihrer App ist Ihre Verbindung zum Benutzer, aber etwas, das gut aussieht, ist nur die halbe Miete. Sie müssen auch sicherstellen, dass Ihre Benutzeroberfläche schnell rendert und reibungslos läuft.

Eine der häufigsten Ursachen für ein verzögertes, nicht reagierendes Benutzerinterface ist Overdraw. Überziehung ist, wo Sie GPU-Verarbeitungszeit verschwenden, indem Sie in Pixeln färben, die nur durch etwas anderes wieder eingefärbt werden.

Stellen Sie sich zum Beispiel einen blauen Hintergrund mit etwas Text vor. Android malt nicht nur die für den Benutzer sichtbaren Blaubereiche, sondern zeichnet den gesamten blauen Hintergrund und zeichnet den Text dann oben. Dies bedeutet, dass einige Pixel doppelt eingefärbt sind, was zu einer Überzeichnung führt.

Einige Überzeichnungen, wie im obigen Beispiel, sind unvermeidlich. Zu viel Overdraw kann sich jedoch spürbar auf die Leistung Ihrer App auswirken. Daher sollten Sie die Überziehung möglichst minimieren.

Es ist relativ einfach, deine App auf Überziehung zu überprüfen. Große Overdraw-Beträge können auf ein zugrunde liegendes Problem in der Benutzeroberfläche Ihrer App hinweisen, z. B. auf redundante Ansichten - mehr dazu später. Aus diesen Gründen ist Overdraw ein sinnvoller Startpunkt, wenn Sie Ihre App auf Leistungsprobleme testen.

Schritt 2: Überziehung erkennen

Die gute Nachricht ist, dass Ihr Android-Gerät bereits über eine integrierte Funktion verfügt, mit der Sie den Überziehungsbetrag in einer auf Ihrem Gerät installierten App überprüfen können.

Da diese Funktion auf Ihrem Gerät verfügbar ist, müssen Sie zunächst die App installieren, die Sie auf Ihrem Android-Gerät testen möchten. Um den Überziehungsbetrag zu überprüfen, öffnen Sie einfach die Einstellungen Ihres Geräts, wählen Sie Entwickleroptionen und tippen Sie auf Debug GPU Overdraw gefolgt von Überzeichnungsbereiche anzeigen.

On your device select Settings Developer Options Debug GPU Overdraw Show overdraw area

Dieses Werkzeug verwendet Farbblöcke, um die verschiedenen Überzeichnungsmengen hervorzuheben. Sie müssen nur noch die App starten, die Sie testen möchten, und sehen, was die Überziehungssituation ist.

Launch your app and check the amount of overdraw
  • Keine Farbe: Keine Überzeichnung. Dies bedeutet, dass das Pixel nur einmal gemalt wurde.
  • Blau: Eine Überzeichnung von 1x. Das Pixel wurde zweimal gemalt.
  • Grün. Eine Überziehung von 2x. Dieser Pixel wurde dreimal gemalt. In der Regel sollten Sie eine maximale Überziehung von 2x anstreben.
  • Hellrot: Eine Überziehung von 3x. Abhängig von Ihrer App können kleine Bereiche von hellem Rot unvermeidlich sein, aber wenn Sie mittlere oder große Bereiche von Rot sehen, sollten Sie untersuchen, was zu viel Overdraw verursacht.
  • Dunkelrot: Eine Überzeichnung von 4x. Dieses Pixel wurde 5 Mal oder möglicherweise sogar mehr gemalt. Sie werden definitiv herausfinden wollen, was dunkelrote Bereiche verursacht.

Schritt 3: Überziehung minimieren

Sobald Sie einen Bereich mit signifikanter Überziehung identifiziert haben, ist es am einfachsten, diese Überziehung zu reduzieren, indem Sie die XML-Dateien Ihrer Anwendung öffnen und nach Überlappungsbereichen suchen, insbesondere nach nicht für den Benutzer sichtbaren Zeichenfeldern und allen möglichen Hintergründen übereinander gezogen werden.

Sie sollten auch nach Bereichen suchen, in denen das Hintergrundattribut auf Weiß gesetzt ist, obwohl ein Elternteil bereits einen weißen Hintergrund gezeichnet hat. All diese Dinge können zu erheblichen Überziehungen führen.

Das Android-System kann automatisch einfache Fälle von Überziehung reduzieren, aber es ist erwähnenswert, dass dies nicht für komplexe benutzerdefinierte Ansichten gilt, bei denen Android keinen Einblick in das Zeichnen von Inhalten hat.

Wenn Sie in Ihrer App komplexe benutzerdefinierte Ansichten verwenden, können Sie die ausklappbaren Grenzen für Ihre Ansichten mit der clipRect-Methode definieren. Für weitere Informationen empfehle ich den Besuch der offiziellen Android-Dokumentation.

2. Android-Rendering-Pipeline

Schritt 1: Das Problem

Eine weitere häufige Ursache für Leistungsprobleme ist die Ansichtshierarchie Ihrer App. Um die einzelnen Ansichten zu rendern, durchläuft Android drei Phasen:

  1. messen
  2. Layout
  3. zeichnen

Die Zeit, die Android benötigt, um diese Phasen abzuschließen, ist proportional zur Anzahl der Ansichten in Ihrer Hierarchie. Dies bedeutet, dass eine der einfachsten Möglichkeiten zum Reduzieren der Wiedergabegeschwindigkeit Ihrer App das Erkennen und Entfernen von Ansichten ist, die nicht zum endgültigen Bild beitragen, das der Benutzer auf seinem Gerät sieht.

Auch wenn alle Ansichten in Ihrer Hierarchie erforderlich sind, kann die Art und Weise, in der diese Ansichten angeordnet sind, einen wesentlichen Einfluss auf die Messphase des Renderprozesses haben. Je tiefer Ihre Ansichtshierarchie ist, desto länger dauert es normalerweise, bis die Messung abgeschlossen ist.

Während des Rendervorgangs stellt jede Ansicht ihre Dimensionen der übergeordneten Ansicht zur Verfügung. Wenn die übergeordnete Ansicht ein Problem mit einer dieser Dimensionen entdeckt, kann sie jedes Kind zur erneuten Messung zwingen.

Neumessungen können sogar auftreten, wenn kein Fehler vorliegt. Zum Beispiel müssen relative Layouts oft ihre Kinder zweimal messen, damit alles passt. Lineare Layouts mit Kindern, die den Parameter layout_weight verwenden, messen routinemäßig jedes Kind zweimal.

Abhängig davon, wie Ihre Ansichten angeordnet sind, können Messungen und Neubewertungen ein kostspieliger und zeitraubender Prozess sein, der sich spürbar auf die Rendergeschwindigkeit Ihrer App auswirkt.

Der Schlüssel, um sicherzustellen, dass Ihre Benutzeroberfläche schnell und problemlos gerendert wird, besteht darin, unnötige Ansichten zu entfernen und nach Möglichkeiten zu suchen, um Ihr Layout zu reduzieren.

Das Android SDK enthält ein Tool, den Hierarchie-Viewer, mit dem Sie Ihre gesamte Ansichtshierarchie visualisieren können. Mit diesem Tool können Sie sowohl redundante als auch verschachtelte Layouts erkennen.

Schritt 2: Verwenden des Hierarchie-Viewers

Bevor wir uns das Hierarchy Viewer-Tool genauer ansehen, sollten Sie einige Besonderheiten beachten. Erstens kann Hierarchy Viewer nur mit einer laufenden App kommunizieren, nicht mit dem Quellcode Ihrer Anwendung. Das bedeutet, dass Sie die zu testende App entweder auf Ihrem Android-Gerät installieren oder einen Emulator verwenden müssen.

Es gibt noch einen anderen, größeren Fang. Der Hierarchie-Viewer kann standardmäßig nur mit einem Gerät kommunizieren, auf dem eine Entwicklungsversion des Android-Betriebssystems ausgeführt wird. Wenn Sie kein Entwicklergerät haben, können Sie diese Einschränkung umgehen, indem Sie die ViewServer-Klasse zu Ihrer Anwendung hinzufügen.

Sobald Sie bereit sind, den Hierarchie-Viewer für eine Drehung zu starten, starten Sie Android Studio und wählen Sie Tools in der Symbolleiste, gefolgt von Android und Android Device Monitor.

Select Tools Android Android Device Monitor

Klicken Sie rechts auf die Schaltfläche Hierarchieansicht, wie im folgenden Screenshot gezeigt.

Select the Hierarchy View button from the toolbar

Auf der linken Seite des Bildschirms ist eine Windows-Registerkarte, die alle erkannten Android-Geräte und Emulatoren auflistet. Wählen Sie Ihr Gerät aus, und Sie sehen eine Liste der Prozesse, die auf diesem Gerät ausgeführt werden. Wählen Sie den Prozess, den Sie genauer untersuchen möchten, und drei Bereiche des Hierarchie-Viewers werden automatisch aktualisiert.

Diese drei Fenster bieten drei verschiedene visuelle Darstellungen der Ansichtshierarchie:

  • Baumansicht: Eine Vogelperspektive Ihrer Ansichtshierarchie, wobei jeder Knoten eine einzelne Ansicht darstellt.
  • Tree Overview: Eine Kartendarstellung Ihrer Ansichtshierarchie. Diese Ansicht ist besonders nützlich, wenn Sie Möglichkeiten zum Verflachen Ihres Layouts ermitteln möchten.
  • Layout-Ansicht: Eine Blockdarstellung Ihrer Ansichtshierarchie.

Diese drei Fenster sind miteinander verbunden. Wenn Sie eine Ansicht in einem Fenster auswählen, wird sie in den anderen beiden Fenstern hervorgehoben angezeigt. Sie können alle drei Fenster gleichzeitig verwenden, um alle redundanten Ansichten aufzuspüren, die in der Ansichtshierarchie lauern.

Select a view in one window and itll appear highlighted in the other two

Wenn Sie nicht sicher sind, ob eine Ansicht tatsächlich zum endgültigen Bild beiträgt, gehen Sie einfach zur Strukturansicht und klicken Sie auf den gewünschten Knoten. Sie sehen eine Vorschau, wie diese Ansicht auf dem Bildschirm angezeigt wird, damit Sie genau sehen können, was diese Ansicht zu Ihrer App beiträgt.

Aber nur weil eine Ansicht etwas zum endgültigen gerenderten Bild beiträgt, bedeutet das nicht, dass sie nicht auch zu einem großen Leistungsproblem beiträgt. Sie haben bereits gesehen, wie Sie den Hierarchie-Viewer verwenden können, um offensichtliche verschachtelte Layouts zu erkennen, aber was ist, wenn diese Performance-verschachtelnde Verschachtelung nicht so offensichtlich ist? Oder was, wenn etwas anderes dazu führt, dass eine Ansicht langsam gerendert wird?

Die gute Nachricht ist, dass Sie den Hierarchie-Viewer auch verwenden können, um zu profilieren, wie lange es dauert, bis jede Ansicht die verschiedenen Phasen des Renderprozesses durchläuft. Dies gibt Ihnen eine Möglichkeit, Probleme beim Rendern zu beheben, die auf den ersten Blick nicht offensichtlich sind.

Der nächste Abschnitt zeigt Ihnen, wie Sie den Hierarchie-Viewer verwenden, um die verschiedenen Ansichten in Ihrem Layout zu profilieren, um alle Rendering-Probleme zu erkennen, die möglicherweise unter der Oberfläche lauern.

Schritt 3: Profilerstellung pro Knoten

Der einfachste Weg, um Engpässe in Ihrer Benutzerschnittstelle zu erkennen, besteht darin, Daten darüber zu sammeln, wie lange es dauert, bis jede Ihrer Ansichten die Phasen Messen, Layout und Zeichnen des Renderprozesses abgeschlossen hat.

Mit Hilfe des Hierarchie-Viewers können Sie diese Informationen nicht nur sammeln, sondern diese Daten auch auf leicht verständliche, visuelle Weise anzeigen, so dass Sie auf einen Blick erkennen können, welche Ansichten nicht gut funktionieren.

Der Hierarchie-Viewer zeigt standardmäßig keine Renderzeiten an. Sie können diese Informationen hinzufügen, indem Sie zur Strukturansicht gehen und den Stammknoten des Teils der Struktur auswählen, den Sie testen möchten. Als nächstes rufen Sie die Profiling-Funktion des Hierarchie-Viewers auf, indem Sie auf das grüne, rote und violette Venn-Diagramm-Symbol klicken, wie im folgenden Screenshot gezeigt.

 To invoke Hierarchy Viewers profiling feature click the green red and purple Venn diagram icon

Drei farbige Punkte erscheinen auf jedem Knoten in diesem Teil der Hierarchie. Von links nach rechts repräsentieren diese Punkte:

  • die Zeit, die benötigt wird, um die Ansicht zu messen
  • die Zeit, die für das Layout der Ansicht benötigt wird
  • die Zeit, die es braucht, um die Aussicht zu ziehen

Jeder Punkt hat auch eine zugewiesene Farbe:

  • Grün: Für diesen Teil der Renderzeit ist diese Ansicht schneller als mindestens die Hälfte der profilierten Knoten. Beispiel: Ein grüner Punkt in der Layout-Position bedeutet, dass diese Ansicht eine kürzere Layout-Zeit hat als mindestens 50% der profilierten Knoten.
  • Gelb: Für diesen Teil der Renderzeit befindet sich diese Ansicht in den langsamsten 50% aller profilierten Knoten.
  • Rot: Für diesen Teil der Renderzeit ist diese Ansicht die langsamste aller profilierten Knoten.

Nach dem Sammeln dieser Daten wissen Sie nicht nur die Ansichten, die Sie optimieren müssen, sondern Sie wissen auch genau, welcher Teil des Renderprozesses diese Ansicht langsamer rendern lässt.

Seien Sie sich bewusst, dass Ansichten mit gelben und roten Punkten zwar der logische Ausgangspunkt für Optimierungsbemühungen sein können, diese Leistungsindikatoren jedoch relativ zu den anderen profilierten Knoten in der Ansichtshierarchie sind. Mit anderen Worten, Sie werden immer einige Ansichten haben, die langsamer rendern als andere.

Bevor Sie beginnen, Ihren Code nach Möglichkeiten zur Optimierung einer bestimmten Ansicht zu durchsuchen, sollten Sie sich fragen, ob diese Ansicht einen guten Grund hat, langsamer als die anderen profilierten Knoten zu rendern, oder ob dies wirklich eine Gelegenheit ist, die Renderzeit Ihrer App zu verkürzen.

3. Speicherlecks

Schritt 1: Das Problem

Obwohl Android eine speicherverwaltete Umgebung ist, lassen Sie sich dadurch nicht in ein falsches Gefühl von Sicherheit einhüllen - Speicherlecks können immer noch vorkommen. Dies liegt daran, dass die Garbage Collection (GC) nur Objekte entfernen kann, die als nicht erreichbar erkannt werden. Wenn ein nicht erreichbares Objekt nicht gefunden wird, wird dieses Objekt nicht mit Müll gesammelt.

Diese unerreichbaren Objekte hängen herum, verschmutzen den Haufen und nehmen wertvollen Platz ein. Wenn Ihre App weiterhin Objekte leckt, wird die Menge an nutzbarem Speicherplatz immer kleiner, was wiederum häufigere und längere GC-Ereignisse auslöst.

Das sind aus zwei Gründen schlechte Nachrichten. Erstens haben GC-Ereignisse normalerweise keinen merklichen Einfluss auf die Leistung Ihrer App. Viele GC-Ereignisse, die in einem kurzen Zeitraum auftreten, können jedoch zu einer verzögerten, nicht reagierenden Benutzeroberfläche führen. Das zweite Problem ist, dass mobile Geräte dazu neigen, zu wenig Speicher zu haben, so dass ein Speicherleck schnell zu einem OutOfMemoryError eskalieren kann, was Ihre App zum Absturz bringt.

Speicherlecks können schwierig zu erkennen sein. Sie werden möglicherweise nur feststellen, dass Speicher ein Problem für Ihre App darstellt, wenn sich Ihre Benutzer beschweren. Glücklicherweise verfügt das Android SDK über einige nützliche Tools, mit denen Sie Ihre App nach den manchmal subtilen Anzeichen von Speicherverlusten durchsuchen können.

Schritt 2: Speicherüberwachung

Mit dem Speichermonitor können Sie auf einfache Weise einen Überblick über die Speichernutzung Ihrer App im Zeitverlauf erhalten. Beachten Sie, dass dieses Tool nur eine Verbindung zu einer laufenden App herstellen kann. Stellen Sie daher sicher, dass die zu testende App auf Ihrem Android-Gerät installiert ist und dass Ihr Gerät an Ihren Computer angeschlossen ist.

This tool is built into Android Studio, so you access it by clicking the Memory tab towards the bottom of your IDE. Sobald der Speichermonitor Ihre laufende Anwendung erkennt, wird die Speicherbelegung Ihrer App aufgezeichnet.

Memory Monitor is built into Android Studio you can access it by clicking the Memory tab

Wenn der Speichermonitor die Aufzeichnung nicht startet, überprüfen Sie, ob Ihr Gerät im Dropdown-Menü Geräte ausgewählt ist.

Wenn der Speichermonitor die Meldung Keine debuggierbaren Anwendungen zurückgibt, öffnen Sie das Menü Extras von Android Studio, wählen Sie Android aus, und stellen Sie sicher, dass Adverb-Integration aktivieren ausgewählt ist. Diese Funktion kann temperamentvoll sein, daher müssen Sie möglicherweise die ADB-Integration ein- und ausschalten. Es kann auch helfen, Ihr Android-Gerät zu entfernen und dann erneut zu verbinden.

Sobald der Speichermonitor Ihre ausgeführte Anwendung erkannt hat, zeigt er die Menge an Speicher an, die Ihre App in dunkelblau verwendet, und den nicht zugewiesenen Speicher in hellblau.

Nehmen Sie sich Zeit für die Interaktion mit Ihrem Gerät und achten Sie dabei darauf, wie sich die Speicherbelegung Ihrer App im Speichermonitor ändert. Schließlich wird der zugewiesene Speicher wachsen, bis kein freier Speicher mehr verfügbar ist. An diesem Punkt wird das System Speicher freigeben, indem ein GC-Ereignis ausgelöst wird. Wann immer Sie einen signifikanten Rückgang des zugewiesenen Speichers sehen, ist dies ein Anzeichen dafür, dass ein GC-Ereignis aufgetreten ist.

GC-Ereignisse sind vollkommen normal. Bedenken Sie jedoch, dass Ihre App in kurzer Zeit viel Speicher zuweist oder GC-Ereignisse häufiger auftreten. Dies sind zwei verräterische Anzeichen dafür, dass in Ihrer App ein Speicherverlust auftritt.

Wenn Sie mit Memory Monitor einen vermuteten Speicherverlust über einen längeren Zeitraum verfolgen, können Sie feststellen, dass das Android-System die wachsenden Speicheranforderungen Ihrer App kompensiert, indem Sie Ihrer App eine höhere Speicherobergrenze zuweisen. Danach beginnt der Zyklus erneut.

Möglicherweise sehen Sie sogar, dass Ihre App so viel Speicher verbraucht, dass das System Ihrer App keinen Speicher mehr zur Verfügung stellen kann. Wenn das passiert, ist die Art und Weise, wie Ihre App Speicher verwendet, gravierend falsch.

Schritt 3: Android Gerätemonitor

Ein weiteres Tool, mit dem Sie mehr Informationen zu Speicherverlusten und anderen speicherbezogenen Problemen sammeln können, ist die Registerkarte Heap des Android-Geräte-Monitors.

Die Registerkarte Heap kann Ihnen helfen, Speicherlecks zu diagnostizieren, indem Sie anzeigen, wie viel Speicher das System Ihrer App zugewiesen hat. Wie bereits erwähnt, wenn der zugewiesene Speicher ständig zunimmt, ist dies ein starker Hinweis darauf, dass Ihre App einen Speicherverlust aufweist.

Aber dieses Tool bietet auch viele Daten über die Heap-Nutzung Ihrer App, einschließlich der Art der Objekte, die Ihre App zuweist, der Anzahl der zugewiesenen Objekte und des Speicherplatzes, den diese Objekte einnehmen. Diese zusätzlichen Informationen können von unschätzbarem Wert sein, wenn Sie die Quelle von Speicherverlusten und anderen speicherbezogenen Problemen in Ihrer App ausfindig machen.

Um auf dieses Tool zuzugreifen, starten Sie Android Device Monitor und wählen Sie die Registerkarte DDMS. Wählen Sie im Gerätebedienfeld Ihr Gerät und den Prozess aus, den Sie untersuchen möchten. Wählen Sie dann die Registerkarte Heap (siehe Abbildung unten) und verbringen Sie einige Zeit mit der Interaktion mit Ihrer App.

Launch Android Debug Monitor select DDMS and then click the Heap tab

Die Heap-Ausgabe wird nur nach einem GC-Ereignis angezeigt. Um diese Registerkarte mit Daten zu füllen, müssen Sie entweder warten, bis ein GC-Ereignis eintritt, oder Sie können einen GC erzwingen, indem Sie auf die Schaltfläche Cause GC klicken.

Sobald ein GC-Ereignis eingetreten ist, wird die Registerkarte Heap mit vielen Informationen zur Heap-Nutzung Ihrer App aktualisiert. Diese Daten werden nach jedem GC-Ereignis aktualisiert.

Fazit

In diesem Lernprogramm haben wir einige der häufigsten Leistungsprobleme behandelt, auf die Sie beim Entwickeln von Android-Apps, Überziehungen, Speicherverlusten und langsamem Rendern der Benutzeroberfläche achten sollten.

Sie müssen sich auch mit einigen Tools vertraut machen, mit denen Sie überprüfen können, ob diese Probleme in Ihren eigenen Android-Projekten auftreten, und erfahren haben, wie Sie weitere Informationen zu Leistungsproblemen in Ihren eigenen Apps sammeln können. Je mehr Informationen Sie haben, desto besser können Sie die Ursache des Problems aufspüren und beheben.

Das Android SDK verfügt über viele weitere Tools, mit denen Sie Leistungsprobleme diagnostizieren und beheben können. Wenn Sie mehr erfahren möchten, dann enthalten die offiziellen Android-Dokumentationsseiten zu Traceview und dmtracedump und Allocation Tracker weitere Informationen.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.