Android DDMS: Ein Leitfaden zur ultimativen Android-Konsole

Entwicklung ist eine heikle Angelegenheit. Das Ziel bewegt sich ständig, neue Technologien und Domänen werden regelmäßig zum Leben erweckt, hin und wieder tauchen neue Tools auf, und Sprachen ändern sich in scheinbar bewältigtem Chaos.

Trotz all dieser Änderungen bleiben die Grundregeln gleich. Eine der wichtigsten dieser zugrunde liegenden Regeln besagt, dass Sie, um wirklich großartige Software zu erstellen, eine tiefe, kontinuierliche und detaillierte Selbstbeobachtung Ihres ausführenden Systems erhalten müssen. Diagnose , Debugging und Profilerstellung sind Begriffe, die manchmal in diesem Zusammenhang verwendet werden, aber die Regel geht tiefer. Ein erstklassiger Entwickler „fühlt“ sein System buchstäblich. Er weiß, was dazu führen wird, dass Chunk auf die Freigabe von mehr Speicher wartet, was seine Threads in CPU-Hunger führt, welche Aktionen zu umfangreichen E/A- oder Netzwerkzugriffen führen und somit den gesamten Betrieb verlangsamen.

Daran führt wirklich kein Weg vorbei. Sie könnten ein sehr kluger Entwickler sein, der großartigen Code schreibt, aber solange Sie nicht über die oben genannten Fähigkeiten verfügen, nämlich in der Lage sind, die Details des Laufzeitverhaltens Ihres Systems zu überwachen und zu studieren, werden Sie immer noch hinterherhinken, wenn es darum geht, wirklich erstklassige Ergebnisse zu liefern Anwendungen.

Tatsächlich werden Sie nach einiger Erfahrung eine ganze Kategorie von „Code-Krankheiten“ entdecken, die auf die Vernachlässigung der Regel der Introspektion zurückzuführen sind: Kurz gesagt, das Schreiben von Code (manchmal Smart Code) ohne kontinuierliche Überwachung seiner Auswirkungen auf die eigentliche Plattform .

DDMS in Android: Meine bevorzugte Waffe für die Selbstbeobachtung

Zum Glück für uns war es der Android-Community gelungen, so viele erstklassige Selbstbeobachtungstools bereitzustellen. Facebooks Stetho gehört zu den besten, AT&Ts ARO („Application Resource Optimizer“) ist etwas älter, aber immer noch erstklassig, mit wahrscheinlich der besten Netzwerküberwachungskonsole da draußen, während LeakCanary einen viel eingeschränkteren Ansatz verfolgt, sich zu konzentrieren (und darin großartig zu sein). it) in der Bibliothek zur Erkennung von Speicherlecks zur Laufzeit. Um es kurz zu machen, es gibt keinen Mangel an Android-Debugging-Tools.

Dennoch ist der Diamant in der Krone, das Introspektion-Tool, dem Sie vertrauen können, wenn entscheidende, genaue und gut formatierte Daten zum Laufzeitverhalten Ihrer App extrahiert werden müssen, immer noch der gute alte Dalvik Debug Monitor Server (DDMS) in Android Studio, der ist seit den Tagen des Eclipse-Android-Plugins bei uns (leider von so vielen Teams zu wenig genutzt).

Wie wichtig ist DDMS in der Android-Entwicklung? Nun, zu wissen, was ich heute über DDMS und die Überwachung mobiler Apps im Allgemeinen vor 5-6 Jahren als weniger erfahrener Android-Entwickler weiß, hätte mir viele Kopfschmerzen und Nächte des Debuggens erspart.

Und die Sache ist, dass DDMS so einfach zu beherrschen ist!

Natürlich hängt ein großer Teil der korrekten Verwendung wie bei jedem anderen Software-Tool von der Erfahrung ab. Sie müssen Ihre beruflichen Fähigkeiten einige Zeit verfeinern, bis Sie im Laufzeit-Performance-Monitoring richtig gut werden. Aber selbst innerhalb weniger Stunden, sagen wir nach dem Lesen dieses Artikels, wenn Sie meinen Vorschlägen folgen und sie auf Ihre nächste App anwenden, werden die Ergebnisse erstaunlich sein! Das Profiling und Tuning selbst komplexer Systeme ist nicht so schwer. Es kann auch Spaß machen!

Oft wird eine Frage bezüglich des Unterschieds zwischen Mobilentwicklern auf Anfänger- und Master-Niveau gestellt. Die Beherrschung von DDMS in Android – oder allgemein ausgedrückt, Anwendungsprofilerstellung und Selbstprüfungsfunktionen – ist einer dieser großen Unterschiede.

Hinweis: Ein großer Teil davon, ein erstklassiger Entwickler zu werden, besteht darin, die besten Bibliotheken zu verwenden, die in Ihrer Domäne verfügbar sind. In einem früheren Toptal-Artikel habe ich einige der besten verfügbaren Entwicklerbibliotheken für Android aufgelistet. In gewisser Weise ist dieser Artikel eine Fortsetzung des Artikels „Bibliothek“ und behandelt eines von vielen Android-Tools. Wenn Sie Ihre Fähigkeiten als Android-Entwickler verbessern möchten, sollten Sie es natürlich jetzt lesen!

Eine Kurzanleitung zu DDMS in Android Studio

Lassen Sie uns nun ohne weiteres in die Beschreibung von DDMS eintauchen, eines der ultimativen Android-Entwicklertools.

Wenn Sie den Aufwand gegen den Nutzen abwägen, kann wahrscheinlich kein anderes Tool die Qualität Ihrer App verbessern und Ihnen dabei helfen, die wirklich chaotischen und schwer fassbaren Fehler zu lokalisieren, die sie möglicherweise enthält. Aber aus irgendeinem Grund (Faulheit, irgendjemand?) scheitern so viele Teams daran, DDMS zu verwenden.

Beginnen wir mit einem Crashkurs in DDMS:

Auf DDMS kann über Studio > Tools > Android > Android Device Monitor und durch Klicken auf die DDMS-Schaltfläche im Menü zugegriffen werden. Sie können es auch als Verknüpfungssymbol (ich tue) in Ihrem oberen Bedienfeld platzieren.

Nach dem Öffnen sehen Sie Folgendes:

Der linke Bereich ermöglicht die Geräte-/App-Auswahl und die rechte Konsole bietet Ihnen mehrere Ansichten, jede auf einer eigenen Registerkarte, die jeweils eine bestimmte Ansicht Ihrer App zeigen.

Die wichtigsten Dienste, die von Dalvik Debug Monitor Server bereitgestellt werden, sind:

• Statistiken zur App-Speichernutzung (Gesamtheap- und Objektzuweisungsstatistiken)
• App-Thread-Statistiken
• Bildschirmaufnahme des Geräts
• Gerätedatei-Explorer
• Eingehende Anrufe und SMS-Spoofing
• Spoofing von Standortdaten
• Logcat

Um den aktuellen Heap-Speicherwert zu erhalten, der von Ihrer App verwendet wird, gehen Sie einfach wie folgt vor:

• Verbinden Sie das Gerät, auf dem Ihre App ausgeführt wird
• Klicken Sie auf die Schaltfläche Heap aktualisieren, um das Sammeln von Heap-Statistiken zu aktivieren
• Öffnen Sie die Registerkarte Heap
• Klicken Sie auf „GC verursachen“, um einen GC-Lauf zu erzwingen. Erst nach einem solchen Durchlauf beginnt die Heap-Datensammlung
• Lassen Sie die Registerkarte geöffnet, arbeiten Sie weiter an Ihrer App und klicken Sie regelmäßig erneut auf „Cause GC“, um die Heap-Statistikdaten zu aktualisieren

Diese letzte Zeile bedarf wahrscheinlich einer zusätzlichen Erklärung. Die Speichernutzung ist einer dieser Analysewerte, bei denen ihre Dynamik viel wichtiger ist als der Ausgangswert. Bei den meisten Apps kümmern wir uns nicht sehr um den anfänglichen Wert der Heap-Nutzung. Wir werden uns sehr um die Entwicklung dieses Werts kümmern, da er uns einen klaren Hinweis auf einen der wahren Alpträume geben wird, die auf mobile Entwickler warten – Android-Speicherlecks:

Meine Verwendung des Heap-Statistikmoduls ist einfach; Als Teil des Lebenszyklus der Entwicklung der App werde ich nach der Einführung von Änderungen, die sich auf die Heap-Nutzung auswirken sollten, das Modul „Cause GC“ aktivieren, um das Sammeln von Statistiken zu initieren und (normalerweise mehr als einmal) die heap-intensiven Positionen meiner App zu aktivieren. und regelmäßig „GC veranlassen“, sich zu aktualisieren. Wenn die Heap-Nutzung weiter zunimmt, habe ich ein Speicherleck an meinen Händen und ich muss es lösen (Details dazu – unten). Wenn nicht, und unabhängig von der tatsächlichen Haufengröße, geht es mir gut.

Wenn ein Speicherleck erkannt wird, ist das nächste Tool, das ich verwenden werde, der Object Allocation Tracker. Mal sehen, was es für die Speicherverwaltung in Android tun kann.

Objektzuweisungs-Tracker

Der Allocation Tracker liefert Ihnen, einfach ausgedrückt, die Informationen, die Sie benötigen, um herauszufinden, wer die „Schuld“ für die aktuelle Heap-Größe trägt. Dieses Modul teilt Ihnen in Echtzeit mit, aus welchen Threads und Methoden die Zuweisungsbefehle stammen, was es für die Speicheranalyse in Android von unschätzbarem Wert macht.

Gehen Sie wie folgt vor, um mit der Verfolgung zu beginnen:

• Wählen Sie wie zuvor das entsprechende Gerät/den Prozess aus
• Wechseln Sie zur Registerkarte Allocation Tracker und klicken Sie auf Tracking starten, um zu beginnen.
• Ab hier werden alle Neuzuweisungen nachverfolgt
• Klicken Sie auf „Get Allocations“, um eine Listenansicht aller letzten Allokationen zu erhalten (neueste seit dem letzten „Beginn“)
• Um herauszufinden, wer die Zuweisungsbehörde ist, klicken Sie auf eine bestimmte Zeile in der Liste

Aus meiner eigenen Erfahrung heraus sollte Sie das Durchführen von zuweisungsintensiven Aktionen in Ihrer App, gefolgt von einem Klick auf „Zuweisungen abrufen“, um die Zuweisungszähler anzuzeigen, normalerweise auf einfache Weise zum Leck führen; manchmal, entweder wenn das Leck nicht linear ist (d. h. hin und wieder vorkommt) ODER wenn Ihre App mehrere Lecks enthält, die möglicherweise nicht funktionieren. In solchen Fällen, und ich bin nicht vielen davon begegnet, müssen Sie darauf zurückgreifen, manuell eine HPROF-Dump-Datei zu erstellen und zu analysieren. Speicheranalyse und Android-Speicherverwaltung werden in diesem Artikel nicht ausführlich behandelt. Sehen Sie hier für einige Hinweise.

Thread-Info-Konsole: Android-CPU-Auslastung leicht gemacht

Jedem Entwickler wohlbekannt, sind synchrone Pfade der Ausführungslogik in Threads gruppiert, die jeweils einen seriellen Ausführungsfluss innerhalb Ihrer App bilden. Buchstäblich alle Apps verwenden mehr als einen einzigen Ausführungsthread. Einige von ihnen verwenden Dutzende.

Eine allgemeine Untersuchung potenzieller Probleme bei der Verwendung von Threads würde den Rahmen dieses Artikels sprengen. Konzentrieren wir uns also auf ein einziges, nämlich Thread-Hunger, das das Hauptproblem ist, für das Sie die Thread-Info-Konsole besuchen würden.

In allen mobilen Anwendungen konkurrieren verschiedene Threads um CPU-Zeit. Davon gibt es einfach nicht genug. Was passiert, wenn aus irgendeinem Grund einer oder mehrere dieser Threads nicht die Ausführungszeit erhalten, die sie benötigen? Normalerweise schlechte Dinge. Das System verhält sich nicht so, wie Sie es geplant haben, was immer eine schlechte Idee ist. Mögliche Gründe für dieses Problem könnten das Festlegen einer niedrigen Priorität sein, andere Threads, die gleichzeitig ausgeführt werden, sich selbst mit einer zu hohen Priorität festlegen, viel Zeit mit Synchronisierungsmonitoren verbringen und vieles mehr. Alles notorisch schwer allein durch Code-Review zu erkennen.

Android DDMS-Thread-Konsole zur Rettung!

Wenn Sie die Thread-Ansicht aufrufen, sehen Sie eine Liste aus Thread-Datensätzen, die jeweils den Namen und die ID des Threads enthalten, sowie zwei zusätzliche Zähler namens utime und stime. Utime misst die Gesamtzeit, die der Thread mit der Ausführung von Benutzercode verbringt (denken Sie an Ihre Funktionen und Bibliotheken von Drittanbietern), während stime die Gesamtzeit misst, die für Systemcode aufgewendet wird (Sleep, Synchronize, Systemaufrufe – das Los). Der erste – utime – wird normalerweise für uns interessanter sein, obwohl ich mir Probleme vorstellen kann, die sich hauptsächlich durch den stime-Zähler manifestieren.

OK, wir haben unseren Code ausgeführt, einschließlich mehrerer Threads, und wir möchten sicherstellen, dass alle unsere Threads ihren Anteil an CPU-Zeit erhalten. Dazu lassen wir unser System zunächst eine Weile laufen, öffnen dann den Thread-Tab und suchen nach „eigenartigen“ utime-Werten. Zero kann sicherlich ein Problem darstellen – der Thread hat buchstäblich keine CPU-Zeit und keine CPU-Auslastung. Aber zu hohe Werte könnten einen anderen Aspekt desselben Problems darstellen: nämlich Threads, deren Priorität so hoch ist, dass sie andere verhungern lassen.

Beachten Sie, dass für einen Thread-Typ ein Utime-Wert von null oder nahe null nicht auf ein echtes Problem hinweist. Dies sind die E/A-gebundenen Threads, Threads, die hauptsächlich Netzwerk- oder Festplattenzugriffe (oder Datenbankzugriffe) ausführen. Diese Threads sollten die meiste Zeit damit verbringen, entweder auf das Eintreffen von Daten zu warten oder anstehende Systemaufrufe zu blockieren, keine dieser Aktionen erhöht den utime-Zähler. Kenne deine Fäden!

Tipp: Verwenden Sie niemals den Standardnamen des Threads. Es bedeutet nichts und Sie werden es normalerweise in den DDMS-Ansichten nicht erkennen. Starten Sie Ihre Interaktion stattdessen jedes Mal, wenn Sie einen Thread erstellen oder aus einem Thread-Pool abrufen, indem Sie ihm einen selbsterklärenden Namen zuweisen. Dies wird Ihr Leben viel einfacher machen, als Ihr System zu debuggen/profilieren. Normalerweise stelle ich den Namen der App voran, um zwischen von Android generierten Threads und denen zu unterscheiden, die von meinem eigenen Code erzeugt wurden, Beispiel: MyApp-Server-Connector, MyApp-DB-Interactor usw.

Tipp: Die Priorität eines Threads gibt (grob gesagt) die Menge an CPU-Zeit an, die ihm vom Scheduler gewährt wird. Die Ihren Worker-Threads zugewiesene Priorität ist von entscheidender Bedeutung für die Gesamtleistung und „Ruhefähigkeit“ Ihrer App und kann in vielen Fällen den Unterschied zwischen einem glatten, schnellen Verhalten und einem holprigen, langsamen Verhalten ausmachen. Die Regel hier ist einfach: Die von Android zugewiesene Standardpriorität, die NORMAL=5 ist, ist fast immer nicht die, die Sie verwenden möchten. Stattdessen möchten Sie für die meisten Worker-Threads eine viel geringere Auswirkung auf die gesamte CPU-Auslastung haben. Um dies zu tun, setzen Sie beim Start eines Threads seine Priorität auf einen niedrigeren Wert, ich gehe normalerweise mit Priorität = 3.

Netzwerkstatistikkonsole

Bei Netzwerkstatistiken geht es darum, Ihnen zu ermöglichen, sowohl eingehende als auch ausgehende Kommunikationskanäle zu Ihrer App in einer vernünftig lesbaren Weise zu überwachen.

Die y-Achse im Netzwerkdiagramm stellt die Übertragungsgeschwindigkeit der Übertragung dar, gemessen in KB/Sekunde, während die x-Achse die verstrichene Zeit in Sekunden darstellt. Um eine schnelle Schätzung der Größe der Übertragung zu erhalten, versuchen Sie daher, die Fläche der relevanten Spitze zu schätzen. Nach einer Weile wird dies ziemlich einfach.

Beachten Sie, dass Sie nach dem Aufrufen dieser Konsole auf die obere Schaltfläche „Aktivieren“ klicken müssen, damit die Netzwerkmessungen angezeigt werden.

Bevor die Netzwerkkonsole zu ihrem heutigen Stand ausgereift war, mussten Entwickler normalerweise auf Sniffer-Apps zurückgreifen (einige tun dies immer noch), um ähnliche Informationen zu erhalten.

Das Tolle an dieser Konsole ist die Art und Weise, wie sie eines der wichtigsten Batterieverbrauchsverhalten visualisiert – das der fortlaufenden Kommunikation in kleinen Paketen. Wie viele von Ihnen wissen, ist es nicht das fünfminütige intensive Netzwerken, das Ihre App zu einem Batteriefresser macht, sondern die langen Perioden des kurzen, sich wiederholenden Netzwerkens, z. B. für Keep-alive-, Diagnose- oder Status-Updates.

Sobald ein solches Muster erkannt wird und die visuelle Paketanzeige der Netzwerkkonsole es so einfach macht, denken Sie sofort an Batching. Kann ich mehrere kleine Übertragungen zu einer einzigen großen zusammenfassen? Die Auswirkungen dieser Änderung auf den Akku werden zwangsläufig Apps von einem Akku-Drainer in eine Kategorie mit gutem Benehmen verschieben!

Tipp: Laden Sie ein Bild niemals unverändert in den Speicher. Dies ist ein Out-of-Memory-Crash, der darauf wartet, passiert zu werden. Führen Sie stattdessen ein herunterskaliertes Laden durch oder verwenden Sie, noch besser, eine Bibliothek eines Drittanbieters, um die Skalierung für Sie zu verwalten.

Obwohl Sie diese Informationen selten verwenden werden, beachten Sie, dass das DDMS auf dem Stack Android Debug Bridge (ADB) basiert, um Daten zurück/vom Gerät zu übertragen. Wenn das DDMS Ihre App nicht anzeigt oder mitten in einer DDMS-Sitzung einfriert, öffnen Sie am besten eine Konsole und geben Sie Folgendes ein:

 adb devices

um sicherzustellen, dass Ihr Gerät mit ADB zugänglich und autorisiert ist. Wenn dies nicht der Fall ist, sollte in vielen Fällen ein Neustart Ihres lokalen ADB-Servers das Problem lösen:

 adb kill-server adb devices # restarts the adb server and displays all detected devices

Wenn Sie weiterhin Probleme haben und Ihre App auf einem physischen Gerät installiert ist, versuchen Sie, alle Emulatorinstanzen zu trennen. Warum? Da sich DDMS sowohl mit physischen Geräten als auch mit Emulatorinstanzen verbindet, ist letztere standardmäßig der Fall.

Beispiel für die DDMS-Nutzung im wirklichen Leben: Eine App hält an (stürzt nicht ab, hält nur an). Der Benutzer eilt sofort zur nahe gelegenen Workstation, stellt eine Verbindung zu USB her und öffnet DDMS in der Thread-Ansicht, um den Thread-Stack » fehlgeschlagener Thread » Stack-Trace herauszufinden – in meinem Fall aufgrund eines Synchronisations-Deadlocks, der, sobald er erkannt wurde, einfach durch Wechseln gelöst werden konnte.

Tipp: Wenn der Standard-RAM-Speicher, der Ihrer App von Android zugewiesen wird, nicht ausreicht, was beispielsweise bei medienintensiven Apps der Fall sein kann, beachten Sie, dass Sie auf den meisten Geräten etwa 15-20 % zusätzlichen Speicher gewinnen können, indem Sie das Manifest-Flag _ largeHeap setzen : https://developer.android.com/guide/topics/manifest/application-element.html_

Emulation des Gerätestatus in Android DDMS

Mobile Apps sind in der Regel keine linearen Konstrukte. Stattdessen setzen sie Sensibilisierungsstrategien ein, die es ihnen ermöglichen, Änderungen des Gerätezustands zu überwachen und darauf zu reagieren. Eine App kann beispielsweise eingehende Anrufe oder Textnachrichten abhören, ihren Status an den Netzwerkstatus anpassen und Änderungen am Standort des Geräts verfolgen und darauf reagieren.

Ein triviales Beispiel für Letzteres wäre eine GPS-App. Die meisten von uns entwickeln solche Apps nicht (leider ist der Markt nicht groß genug …), aber dennoch setzen wir in vielen Fällen eine standortabhängige Logik ein, sei es eine einfache Kartenansicht der aktuellen Position des Benutzers oder eine Routenverfolgung , oder eine ortsabhängige Datenanzeige.

Das Testen auf solche zustandsabhängigen Bedingungen ist notorisch komplex, manchmal mehr als das Schreiben des eigentlichen Codes. Wenn Sie ein physisches Gerät mit SIM haben, können Sie natürlich Anrufe und SMS senden und empfangen. Das Ändern des Telefonstatus Ihres Geräts ist viel schwieriger, aber dennoch möglich. Der Wechsel des Testorts könnte kniffliger sein, obwohl es eine Option ist, mit Ihrem Laptop durch die Stadt zu schlendern …

Aber trotzdem – wie würden wir mit Emulatorinstanzen umgehen? Wie können wir sie auf diese Änderungen testen?

DDMS zur Rettung, wieder einmal. Eine der stärkeren, aber oft übersehenen Funktionen des DDMS ist seine Fähigkeit, Mock-Ereignisse in eine laufende Emulatorinstanz auszugeben („Spoof“). DDMS kann einen Anruf von einer bestimmten Nummer an den Emulator senden, eine SMS senden, Telefonstatusdaten ändern und vieles mehr.

Sobald sie im Emulator angekommen sind, sind all diese gefälschten Ereignisse nicht mehr von „echten“ Ereignissen zu unterscheiden, dh als würden sie von den zugrunde liegenden Hardwaresensoren empfangen. Insbesondere werden alle Empfänger Ihrer relevanten App auf die gleiche Weise aktiviert, wie sie es beim Empfang eines echten Anrufs/einer echten SMS-Nachricht tun würden.

Die Aktivierung des Telefoniestatus und der Aktionen ist ziemlich einfach:

Um Ihre App auf Fälle mit geringer Netzwerkkonnektivität zu testen (was Sie in jeder netzwerkzentrierten App tun sollten), gehen Sie zum Abschnitt Telefoniestatus und stellen Sie die Geschwindigkeits- und Latenzwerte auf die gewünschten Werte ein. Normalerweise nehme ich den GPRS-Wert für beide, um eine geringe Konnektivität effektiv zu emulieren, aber Sie können gerne Ihre eigenen Werte festlegen.

Um Telefonanrufe oder SMS zu simulieren, gehen Sie zum Abschnitt Telefonieaktion, legen Sie die Ursprungstelefonnummer fest, fügen Sie bei Bedarf eine Textnachricht hinzu und schießen Sie los. Dieses Tool ist besonders effektiv, wenn Sie eine dedizierte Coderoute für Anrufe aus dem Ausland eingerichtet haben und diese auf Kosten des Budgets testen möchten.

Interessanter wird es, wenn es darum geht, einen neuen Standort zu verspotten.

Wenn Sie nur einen neuen Standort für Ihre Emulatorinstanz festlegen möchten, wählen Sie Manuell, stellen Sie die gewünschten Breiten-/Längengrade ein und klicken Sie auf Senden.

Aber was ist, wenn Sie möchten, dass Ihre App nicht einen festen Standort festlegt, sondern eine voreingestellte Route durchläuft – beispielsweise ihr Verhalten untersucht, wenn der Benutzer von einer Stadt in eine andere reist? Ein solcher Test kann für jede kartengestützte App sowie für andere ortsbezogene Apps, die ihr Datenfenster pro Benutzerstandort festlegen, von großem Wert sein. Hier möchten Sie sicher sehen, dass Standortverschiebungen mit unterschiedlicher Geschwindigkeit das angezeigte Datenfenster auf dem neuesten Stand halten.

Dazu verwenden wir ein spezielles Format namens KML, das speziell für die Verwendung mit Google Earth entwickelt wurde und Routen oder Pfade als eine Reihe verbundener Punkte im Raum darstellt, die von GPS-fähigen Geräten erfasst werden können.

GPX ist ein alternatives Pfadformat, das von DDMS unterstützt wird. Für alle praktischen Zwecke sollten diese beiden als austauschbar betrachtet werden, wenn sie für mobiles Standort-Spoofing verwendet werden.

Lassen Sie uns nun durch die Phasen des Festlegens einer Scheinroute in den Emulator gehen.

1. Erstellen Sie eine Route. Der bei weitem einfachste Weg wäre die Verwendung der Richtungsoption von Google Maps, die den entsprechenden Start- und Zielort einstellt.

1. Sobald die Route über der Karte angezeigt wird, gehen Sie in die Adresszeile und kopieren Sie die URL

2. Gehen Sie mit der URL in der Zwischenablage zum GPS Visualizer, fügen Sie sie in das Textfeld „URL bereitstellen“ ein und klicken Sie auf die Schaltfläche Konvertieren:

und klicken Sie, um die resultierende GPX-Datei herunterzuladen (mit einem etwas chaotischen Namen, z. B. 20170520030103-22192-data.gpx)

1. Kehren Sie zur DDMS Location Control zurück, öffnen Sie die Registerkarte GPX, klicken Sie auf Load GPX und wählen Sie die neu heruntergeladene Datei aus

1. Wir sind fertig! Sie können jetzt zwischen den verschiedenen Routenorten navigieren, indem Sie auf die Schaltflächen „Zurück“ und „Vorwärts“ klicken oder auf die Schaltfläche „Wiedergabe“ klicken, um die Route automatisch mit einer festgelegten Geschwindigkeit zu durchlaufen.

Sie müssen keine eigene Route erstellen. Viele Routen zum Herunterladen von Websites wie OpenStreetMap (siehe Abschnitt „GPS-Spuren“).

Beachten Sie schließlich, dass im Gegensatz zu älteren DDMS-Versionen, bei denen das Laden von Routendateien ein Kinderspiel war, neuere Versionen beim Laden einer bestimmten Route möglicherweise einige Versuche und Irrtümer erfordern.

Beispielsweise scheint nur GPX 1.1 von DDMS unterstützt zu werden. Neue GPX-Versionen erfordern möglicherweise einige manuelle Anpassungen.

Außerdem wird das GPX-Wegpunktformat nicht mehr unterstützt. Verwenden Sie stattdessen das GPX-Track-Format:

 <trk> <name /> <cmt /> <trkseg> <trkpt lat="27.0512" lon="-80.4324"> <ele>0</ele> <time>2017-02-02T08:01:41Z</time> </trkpt> </trkseg> </trk>

Android debuggen: Eine Stunde pro Woche macht einen Unterschied!

Genug Theorie! Es ist jetzt Zeit für etwas Übung. Ich schlage vor, vorausgesetzt, Sie sind ein Android-Entwickler, dass Sie ab Ihrem nächsten Projekt nur eine Stunde pro Woche dafür aufwenden, sich über DDMS einen Einblick in die Leistung Ihrer App zu verschaffen.

Sie werden von der Menge an Qualitätsinformationen überrascht sein (dh Informationen, die verwendet werden können, um den Zustand Ihrer App sofort zu verbessern), die Sie dadurch erhalten!

Wie ich bei unerfahrenen Entwicklern immer wieder erlebt habe, ist Android DDMS ein Tool, das die Fähigkeiten eines Entwicklers erheblich verbessern kann, vorausgesetzt, es wird beherrscht und richtig eingesetzt. Die Fähigkeit eines Android-Entwicklers, erstklassige Systeme zu liefern, wird buchstäblich um ein oder zwei Stufen steigen, sobald er das volle Potenzial von DDMS in der Android-Entwicklung ausschöpft. Daher klingt es nach einer cleveren Investition, sich ein paar Stunden Zeit zu nehmen, um DDMS sinnvoll zu nutzen, da es die Leistung und Effizienz von Android erheblich verbessern kann.

Seien Sie einer der schlauen Jungs. Benutze es.