Entwickeln ist ein kniffliges Geschäft. Das Ziel bleibt in Bewegung, neue Technologien und Domänen werden regelmäßig zum Leben erweckt, hin und wieder tauchen neue Tools auf und Sprachen Veränderung in dem, was als Chaos zu bewältigen scheint.

Trotz all dieser Änderungen bleiben die Grundregeln gleich. Eine der wichtigsten dieser zugrunde liegenden Regeln besagt, dass Sie tiefgreifende, fortlaufende und detaillierte Informationen erhalten müssen, um wirklich großartige Software zu erstellen Selbstbeobachtung in Ihr ausführendes System. Diagnose , Debuggen , 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 er darauf wartet, dass mehr Speicher freigegeben wird, was seine Threads in einen CPU-Mangel 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 bis Sie nicht über die oben genannten Fähigkeiten verfügen, nämlich die Details des Laufzeitverhaltens Ihres Systems zu überwachen und zu studieren, werden Sie immer noch hinterherhinken, wenn es darum geht, wirklich erstklassigen Code zu liefern Anwendungen.

In der Tat werden Sie nach einigen Erfahrungen eine ganze Kategorie von „Code-Krankheiten“ entdecken, die darauf zurückzuführen ist, dass die Regel der Selbstbeobachtung vernachlässigt wird: Kurz gesagt, Schreiben von Code (manchmal intelligenter Code) ohne kontinuierliche Überwachung seiner Auswirkungen auf die tatsächliche Plattform .

DDMS in Android: Meine Waffe der Wahl für die Selbstbeobachtung

Zum Glück war es der Android-Community gelungen, so viele erstklassige Introspection-Tools bereitzustellen. Facebooks Stetho gehört zu den besten von AT & T. ARO („Application Resource Optimizer“) ist etwas älter, aber immer noch erstklassig, mit der wahrscheinlich besten Netzwerküberwachungskonsole auf dem Markt LeakCanary geht viel eingeschränkter vor und konzentriert sich (und macht es großartig) auf die Bibliothek zur Erkennung von Laufzeitspeicherlecks. Kurz gesagt, es gibt keinen Mangel an Android-Debugging-Tools.

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

Wie wichtig ist DDMS in der Android-Entwicklung? Wenn ich wüsste, was ich jetzt über DDMS und die Überwachung mobiler Apps im Allgemeinen weiß, hätte ich mich vor 5 bis 6 Jahren als weniger erfahrener Android-Entwickler einen gespart Menge von Kopfschmerzen und Nächten des Debuggens.

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

Natürlich ist ein großer Teil der korrekten Verwendung, wie bei jedem anderen Software-Tool, mit Erfahrung verbunden. Sie müssen Ihre beruflichen Fähigkeiten für einige Zeit verbessern, bis Sie wirklich gut in der Überwachung der Laufzeitleistung sind. Aber selbst in wenigen Stunden, sagen Sie 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 Profilieren und Optimieren selbst komplexer Systeme ist nicht so schwierig. Es kann auch Spaß machen!

Oft wird eine Frage zum Unterschied zwischen unerfahrenen und Master-Entwicklern von Mobilgeräten gestellt. Das Beherrschen von DDMS in Android - oder allgemein gesagt, Funktionen zur Erstellung von Anwendungsprofilen und zur Selbstbeobachtung - ist ein solcher Hauptunterschied.

Hinweis: Ein wesentlicher Teil der Entwicklung zu einem erstklassigen Entwickler besteht darin, die besten in Ihrer Domain verfügbaren Bibliotheken zu verwenden. In einem früheren ApeeScape-Artikel Ich habe einige der besten 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, lesen Sie es jetzt!

Eine Kurzanleitung zu DDMS in Android Studio

Lassen Sie uns nun ohne weiteres auf die Beschreibung von DDMS eingehen, einem 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 bei der Suche nach dem helfen Ja wirklich unordentliche und schwer fassbare Fehler, die es enthalten kann. Aber aus irgendeinem Grund (Faulheit, irgendjemand?) Verwenden so viele Teams DDMS nicht.

Beginnen wir mit einem Crashkurs in DDMS:

DDMS ist über erreichbar Studio> Extras> Android> Android-Gerätemonitor und klicken Sie im Menü auf die Schaltfläche DDMS. Sie können es auch als Verknüpfungssymbol (ich tue es) in Ihrem oberen Bereich platzieren.

Nach dem Öffnen sehen Sie Folgendes:

Das linke Feld ermöglicht die Auswahl von Geräten / Apps und die rechte Konsole bietet Ihnen mehrere Ansichten, jede auf einer eigenen Registerkarte, die jeweils eine bestimmte Ansicht Ihrer App anzeigen.

Die Hauptdienste von Dalvik Debug Monitor Server sind:

• Statistiken zur App-Speichernutzung (Statistik der gesamten Heap- und Objektzuordnung)
• App-Thread-Statistiken
• Bildschirmaufnahme des Geräts
• Gerätedateie-Explorer
• Spoofing für eingehende Anrufe und SMS
• Spoofing von Standortdaten
• Logcat

Gehen Sie wie folgt vor, um den aktuellen Heap-Speicherwert zu erhalten, der von Ihrer App verwendet wird:

• Schließen Sie das Gerät an, 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 'Cause GC', um einen GC-Lauf zu erzwingen. Erst nach einem solchen Lauf beginnt die Heap-Datenerfassung
• 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 Erläuterung. Die Speichernutzung ist einer dieser analytischen Werte Dynamik sind viel wichtiger als der Anfangswert. Bei den meisten Apps ist der anfängliche Heap-Nutzungswert nicht besonders wichtig. Wir werden uns sehr um den Fortschritt dieses Wertes kümmern, da er uns einen klaren Hinweis auf einen der wahren Albträume geben wird, die auf Entwickler von Mobilgeräten warten - Android-Speicherlecks:

Meine Verwendung des Heap-Stat-Moduls 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 initiieren und (normalerweise mehr als einmal) die Heap-intensiven Positionen meiner App zu aktivieren. und regelmäßig 'Cause GC' aktualisieren. Wenn die Heap-Nutzung weiter zunimmt, habe ich ein Speicherleck in den Händen und muss es beheben (Details dazu, wie - unten). Wenn nicht, und unabhängig von der tatsächlichen Heap-Größe, bin ich gut.

Wenn ein Speicherverlust festgestellt 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.

Objektzuordnungs-Tracker

Der Allokations-Tracker liefert Ihnen, einfach ausgedrückt, die Informationen, die erforderlich sind, um herauszufinden, wer für die aktuelle Heap-Größe verantwortlich ist. In diesem Modul erfahren Sie in Echtzeit, von welchen Threads und Methoden die Zuweisungsbefehle stammen, sodass es für die Speicheranalyse in Android von unschätzbarem Wert ist.

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

• Wählen Sie das entsprechende Gerät / Verfahren wie zuvor aus
• Wechseln Sie zur Registerkarte Allocation Tracker und klicken Sie auf Start Tracking, um zu beginnen.
• Ab hier werden alle neuen Zuordnungen nachverfolgt
• Klicken Sie auf 'Zuordnungen abrufen', um eine Listenansicht aller neuesten Zuordnungen zu erhalten (spätestens seit dem letzten 'Beginn').
• Klicken Sie auf eine bestimmte Zeile in der Liste, um herauszufinden, wer die Zuweisungsberechtigung ist

Nach meiner eigenen Erfahrung sollten Sie nun in der Regel auf unkomplizierte Weise zu allokationsintensiven Aktionen in Ihrer App führen und anschließend auf 'Allokationen abrufen' klicken, um die Allokationszähler anzuzeigen. manchmal, entweder wenn das Leck nicht linear ist (d. h. ab und zu auftritt) oder wenn Ihre App mehrere Lecks enthält, die möglicherweise nicht funktionieren. In solchen Fällen, und ich habe nicht viele davon festgestellt, müssen Sie manuell eine HPROF-Dump-Datei erstellen und analysieren. Die Speicheranalyse und die Android-Speicherverwaltung werden in diesem Artikel nicht ausführlich behandelt. Sehen Hier für einige führt.

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

Jedem Entwickler bekannt, werden synchrone Pfade zum Ausführen von Logik 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 ist nicht Gegenstand dieses Artikels. Konzentrieren wir uns dann auf einen einzigen, nämlich den Thread-Mangel, der das Hauptproblem darstellt, für das Sie die Thread-Info-Konsole besuchen würden.

In allen mobilen Anwendungen konkurrieren verschiedene Threads um die CPU-Zeit. Es gibt einfach nicht genug davon, um herumzugehen. Was passiert, wenn aus irgendeinem Grund einer oder mehrere Threads nicht die erforderliche Ausführungszeit erhalten? 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 sein, dass eine niedrige Priorität festgelegt wird, andere Threads gleichzeitig eine Einstellung mit zu hoher Priorität ausführen, viel Zeit für Synchronisationsmonitore aufwenden und vieles mehr. Alle notorisch allein durch Codeüberprüfung schwer zu erkennen.

Android DDMS Thread Konsole zur Rettung!

Wenn Sie die Thread-Ansicht aufrufen, wird eine Liste mit Thread-Datensätzen angezeigt, die jeweils den Namen und die ID des Threads sowie zwei zusätzliche Zähler mit den Namen utime und stime enthalten. Utime misst die Gesamtzeit, die der Thread für die Ausführung von Benutzercode benötigt (denken Sie an Ihre Funktionen und Bibliotheken von Drittanbietern), während stime die Gesamtzeit misst, die für Systemcode aufgewendet wird (Ruhezustand, Synchronisierung, Systemaufrufe - das Los). Das erste - utime - wird normalerweise für uns interessanter sein, obwohl ich mir Probleme vorstellen kann, die sich meistens am 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 der CPU-Zeit erhalten. Dazu lassen wir unser System zunächst eine Weile laufen, öffnen dann die Registerkarte 'Thread' und suchen nach 'besonderen' Utime-Werten. Null kann sicherlich ein Problem darstellen - der Thread hat buchstäblich keine CPU-Zeit und keine CPU-Auslastung. Zu hohe Werte können jedoch einen anderen Aspekt desselben Problems darstellen: Threads, deren Priorität so hoch ist, dass andere verhungern.

Beachten Sie, dass für einen Thread-Typ ein Utime-Wert von Null oder nahe Null kein echtes Problem anzeigt. Dies sind die E / A-gebundenen Threads, Threads, die hauptsächlich Netzwerk- oder Festplattenzugriff (oder Datenbankzugriff) ausführen. Diese Threads sollte Verbringen Sie die meiste Zeit damit, entweder auf das Eintreffen von Daten zu warten oder ausstehende Systemaufrufe zu blockieren. Keine dieser Aktionen erhöht den Zeitzähler. Kenne deine Fäden!

Trinkgeld: Verwenden Sie niemals den Standardnamen des Threads. Es bedeutet nichts und Sie werden es normalerweise in den DDMS-Ansichten nicht erkennen. Beginnen Sie Ihre Interaktion stattdessen mit, wenn Sie einen Thread erstellen oder aus einem Thread-Pool abrufen Zuweisen mit einem selbsterklärenden Namen . Dies erleichtert Ihnen das Leben als das Debuggen / Profilieren Ihres Systems. Normalerweise stelle ich den Namen der App voran, um zwischen von Android generierten Threads und solchen zu unterscheiden, die durch meinen eigenen Code erzeugt wurden. Beispiel: MyApp-Server-Connector, MyApp-DB-Interaktor usw.

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

Netzwerkstatistikkonsole

In der Netzwerkstatistik geht es darum, dass Sie sowohl eingehende als auch ausgehende Kommunikationskanäle zu Ihrer App auf eine für Menschen lesbare Weise überwachen können.

Die y-Achse im Netzwerkdiagramm repräsentiert die Übertragungsgeschwindigkeit der Übertragung, gemessen in KB / Sekunde, während die x-Achse die verstrichene Zeit in Sekunden darstellt. Um eine schnelle Schätzung der Übertragungsgröße 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 Netzwerkmessungen angezeigt werden.

Bevor die Netzwerkkonsole auf das derzeitige Niveau gereift 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 Verhaltensweisen beim Entladen des Akkus darstellt - das der laufenden Kommunikation mit kleinen Paketen. Wie viele von Ihnen wissen, sind es nicht die fünf Minuten intensiven Netzwerks, die Ihre App zu einem Batterieentleerer macht, sondern die langen Zeiträume kurzer, sich wiederholender Netzwerke, z. B. um Keepalive, Diagnose oder Statusaktualisierungen zu ermöglichen.

Sobald ein solches Muster erkannt wurde und die visuelle Paketanzeige der Netzwerkkonsole es so einfach macht, denken Sie sofort nach Dosierung . Kann ich mehrere kleine Übertragungen zu einer einzigen großen übertragen? Die Auswirkungen dieser Änderung auf die Batterie werden Apps zwangsläufig von einem Batterieentleerer in eine gut erzogene Kategorie verschieben!

Trinkgeld: Laden Sie niemals ein Bild so wie es ist in den Speicher. Dies ist ein Absturz aufgrund von Speichermangel, der darauf wartet, passiert zu werden. Führen Sie stattdessen durch verkleinertes Laden oder noch besser, verwenden Sie a Drittanbieter-Bibliothek um die Skalierung für Sie zu verwalten.

Obwohl Sie diese Informationen selten verwenden, beachten Sie, dass das DDMS auf den ADB-Stapel (Android Debug Bridge) angewiesen ist, um Daten vom Gerät zurückzuleiten. Wenn das DDMS Ihre App nicht anzeigt oder während 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. Ist dies in vielen Fällen nicht der Fall, sollte das Problem durch einen Neustart des lokalen ADB-Servers behoben werden:

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 Geräte- als auch mit Emulatorinstanzen physischer Geräte verbindet, ist die Standardeinstellung letztere.

Beispiel für die Verwendung von DDMS im realen Leben: Eine App wird angehalten (nicht abstürzt, nur angehalten). Der Benutzer eilt sofort zur nahe gelegenen Workstation, stellt eine Verbindung zu USB her und öffnet DDMS in der Thread-Ansicht, um die Stapelverfolgung des Thread-Stapels »fehlgeschlagener Thread» herauszufinden - in meinem Fall aufgrund eines Synchronisations-Deadlocks, der nach dem Erkennen leicht durch Umschalten behoben werden konnte.

Trinkgeld: Wenn der von Android Ihrer App zugewiesene Standard-RAM-Speicher nicht ausreicht, wie dies beispielsweise bei medienintensiven Apps der Fall sein kann, können Sie auf den meisten Geräten durch Erhöhen von _ 15 bis 20% zusätzlichen Speicher gewinnen largeHeap Manifest-Flag: https://developer.android.com/guide/topics/manifest/application-element.html_

Gerätezustandsemulation in Android DDMS

Mobile Apps sind in der Regel keine linearen Konstrukte. Stattdessen setzen sie Sensibilisierungsstrategien ein, mit denen sie Änderungen im Gerätezustand überwachen und darauf reagieren können. Eine App kann beispielsweise eingehende Anrufe oder Textnachrichten abhören, ihren Status entsprechend dem Netzwerkstatus neu ausrichten 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 in vielen Fällen setzen wir dennoch eine ortsabhängige Logik ein, unabhängig davon, ob es sich um eine einfache Kartenansicht der aktuellen Position des Benutzers oder um die Routenverfolgung handelt oder eine ortsabhängige Datenanzeige.

Das Testen auf solche zustandsempfindlichen 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 ausgeben und empfangen. Das Ändern des Telefoniestatus Ihres Geräts ist viel schwieriger, kann aber dennoch durchgeführt werden. Änderungen am Teststandort könnten schwieriger sein, obwohl ein Spaziergang mit Ihrem Laptop durch die Stadt eine Option ist…

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

DDMS zur Rettung noch einmal. Eine der stärkeren, jedoch häufig übersehenen Funktionen des DDMS ist seine Fähigkeit, Scheinereignisse in eine laufende Emulatorinstanz auszugeben ('fälschen'). DDMS kann einen Anruf von einer bestimmten Nummer an den Emulator senden, eine SMS senden, Telefoniestatusdaten ändern und vieles mehr.

Sobald sie im Emulator angekommen sind, können alle diese gefälschten Ereignisse nicht mehr von 'realen' Ereignissen unterschieden werden, d. H. Als ob sie von den zugrunde liegenden Hardwaresensoren empfangen würden. Insbesondere werden alle Empfänger Ihrer relevanten App auf dieselbe Weise aktiviert, wie sie es beim Empfang einer echten Anruf- / SMS-Nachricht tun würden.

Das Aktivieren des Telefoniestatus und der Aktionen ist recht einfach:

Um Ihre App auf Fälle geringer Netzwerkkonnektivität zu testen (die Sie in jeder netzwerkzentrierten App verwenden sollten), gehen Sie zum Abschnitt Telefoniestatus und stellen Sie die Geschwindigkeits- und Latenzwerte auf die gewünschten Werte ein. Normalerweise verwende ich den GPRS-Wert für beide als effektive Methode zur Emulation geringer Konnektivität, kann aber auch Ihre eigenen Werte festlegen.

Um Telefonanrufe oder SMS zu simulieren, gehen Sie zum Abschnitt Telefonieaktion, legen Sie die ursprüngliche Telefonnummer fest, fügen Sie bei Bedarf eine Textnachricht hinzu und feuern Sie ab. Dieses Tool ist besonders effektiv, wenn Sie eine dedizierte Coderoute für Anrufe aus dem Ausland festgelegt haben und diese im Rahmen des Budgets testen möchten.

Interessanter wird es, wenn man sich über einen neuen Ort lustig macht.

Wenn Sie lediglich einen neuen Speicherort 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.

Was aber, wenn Ihre App anstelle eines festen Standorts eine voreingestellte Route durchlaufen soll, z. B. das Verhalten des Benutzers beim Reisen von einer Stadt in eine andere untersuchen soll? Ein solcher Test kann für jede kartengestützte App sowie für andere standortbezogene Apps, die ihr Datenfenster pro Benutzerstandort festlegen, von großem Wert sein. Hier möchten Sie sehen, dass eine Standortverschiebung mit unterschiedlicher Geschwindigkeit das angezeigte Datenfenster auf dem neuesten Stand hält.

Zu diesem Zweck 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 Weltraum darstellt, die von GPS-fähigen Geräten verwendet werden können.

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

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

1. Erstellen Sie eine Route. Bei weitem am einfachsten wäre es, die Richtungsoption von Google Maps zu verwenden und den entsprechenden Ursprung und das entsprechende Ziel festzulegen.

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

2. Gehen Sie mit der URL in der Zwischenablage zu GPS Visualizer Fügen Sie es 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 unordentlichen Namen, z. B. 20170520030103-22192-data.gpx).

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

1. Wir sind fertig! Sie können jetzt zwischen den verschiedenen Routenpositionen 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 ‘GPS-Spuren’ Sektion).

Beachten Sie abschließend, 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 wird nur GPX 1.1 von DDMS unterstützt. Neue GPX-Versionen erfordern möglicherweise einige manuelle Anpassungen.

Darüber hinaus wird das GPX-Wegpunktformat nicht mehr unterstützt. Verwenden Sie stattdessen das GPX-Track-Format:

0 2017-02-02T08:01:41Z

Debuggen von Android: Eine Stunde pro Woche macht den 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 widmen nur eine Stunde pro Woche um über DDMS einen Einblick in die Leistung Ihrer App zu erhalten.

Sie werden von der Menge überrascht sein Qualitätsinformationen (d. h. Informationen, die verwendet werden können, um den Status Ihrer App sofort zu verbessern) Sie erhalten damit!

Android DDMS ist, wie ich immer wieder bei unerfahrenen Entwicklern gesehen habe, ein Tool, das die Fähigkeiten eines Entwicklers erheblich verbessern kann, sofern es beherrscht und ordnungsgemäß eingesetzt wird. Die Fähigkeit eines Android-Entwicklers, erstklassige Systeme bereitzustellen, wird buchstäblich um ein oder zwei Stufen steigen, sobald er das volle Potenzial von DDMS in der Android-Entwicklung ausgeschöpft hat. Daher klingt es nach einer cleveren Investition, ein paar Stunden Zeit zu lassen, um DDMS optimal zu nutzen, da dies die Leistung und Effizienz von Android erheblich verbessern kann.

Sei einer der Schlauen. Benutze es.

Grundlagen verstehen

Was ist die Verwendung von DDMS in Android?

Als Teil von Android Studio ist DDMS eines der wichtigsten Introspection-Tools, die Android-Entwicklern zur Verfügung stehen. Es wird zum Debuggen, Diagnostizieren und Profilieren verwendet.

Was ist Android Device Monitor?

Der Android-Gerätemonitor bietet eine Benutzeroberfläche für mehrere Debugging-Tools. Es ist ein leichtes, eigenständiges Tool, sodass Benutzer weder Android Studio noch eine andere IDE installieren müssen.

Was ist Android Debug Bridge?

Android Debug Bridge (adb) ist ein Befehlszeilenprogramm, das die Kommunikation mit einem Android-Gerät erleichtert. Es wird zum Debuggen, Installieren von Apps und Zugreifen auf eine Unix-Shell verwendet, um Befehle auf dem Gerät auszuführen.

Wofür wird der Android-Geräte-Manager verwendet?

Mit ADM können Sie Ihr Gerät über eine Webkonsole suchen, klingeln oder löschen.

Was ist ein Logcat in Android?

Logcat ist das interne Protokollsystem von Android für Apps und Systemmodule.