Android DDMS: Panduan untuk Konsol Android Terbaik

Mengembangkan adalah bisnis yang rumit. Target terus bergerak, teknologi dan domain baru muncul secara berkala, alat baru bermunculan setiap saat, dan bahasa berubah dalam apa yang tampaknya dikelola sebagai malapetaka.

Namun, bahkan dengan semua perubahan ini, aturan dasarnya tetap sama. Salah satu yang paling penting dari aturan dasar ini menyatakan bahwa untuk membuat perangkat lunak yang benar-benar hebat, Anda harus mendapatkan introspeksi yang mendalam, berkelanjutan, dan terperinci ke dalam sistem pelaksana Anda. Diagnostik , debugging , dan pembuatan profil adalah istilah yang terkadang digunakan dalam konteks ini, tetapi aturannya lebih dalam. Pengembang terkemuka benar-benar "merasakan" sistemnya. Dia tahu apa yang akan menyebabkan chunk menunggu lebih banyak memori untuk dilepaskan, apa yang akan menjalankan utasnya ke kelaparan CPU, tindakan mana yang akan menghasilkan I/O atau akses jaringan yang luas sehingga akan memperlambat seluruh operasinya.

Benar-benar tidak ada jalan lain. Anda bisa menjadi pengembang yang sangat pintar menulis kode yang luar biasa, tetapi, sampai Anda tidak memiliki keterampilan di atas, yaitu mampu memantau dan mempelajari detail perilaku runtime sistem Anda, Anda masih akan gagal dalam hal memberikan yang benar-benar terbaik. aplikasi.

Faktanya, setelah mendapatkan beberapa pengalaman, Anda akan mendeteksi seluruh kategori "penyakit kode" yang dapat ditelusuri dengan mengabaikan aturan introspeksi: Secara singkat, menulis kode (terkadang kode pintar) tanpa pemantauan terus menerus dari efeknya pada platform yang sebenarnya .

DDMS di Android: Senjata Pilihan Saya untuk Introspeksi

Untungnya bagi kami, komunitas Android telah berhasil memberikan begitu banyak alat introspeksi terbaik. Stetho Facebook adalah salah satu yang terbaik, AT&T's ARO ("Application Resource Optimizer") agak lebih tua tetapi masih top-notch, dengan mungkin konsol pemantauan jaringan terbaik di luar sana, sementara LeakCanary mengambil pendekatan konsentrasi yang jauh lebih terbatas (dan melakukan yang terbaik di it) pada perpustakaan deteksi kebocoran memori runtime. Singkat cerita, tidak ada kekurangan alat debugging Android di luar sana.

Namun, berlian di mahkota, alat introspeksi untuk dipercaya ketika data penting, akurat, dan diformat dengan baik perlu diekstraksi mengenai perilaku runtime aplikasi Anda masih merupakan Dalvik Debug Monitor Server (DDMS) lama yang baik di Android Studio, yang telah bersama kami (sayangnya kurang dimanfaatkan oleh begitu banyak tim) sejak zaman plugin Eclipse Android.

Seberapa penting DDMS dalam pengembangan Android? Nah, mengetahui apa yang saya ketahui sekarang tentang DDMS dan pemantauan aplikasi seluler secara umum katakanlah 5-6 tahun yang lalu, sebagai pengembang Android yang kurang berpengalaman, akan menyelamatkan saya dari banyak sakit kepala dan malam debugging.

Dan masalahnya adalah DDMS sangat mudah untuk dikuasai!

Tentu saja, sebagian besar penggunaannya dengan benar, seperti halnya alat perangkat lunak lainnya, disertai dengan pengalaman. Anda perlu mengasah keterampilan profesional Anda untuk beberapa waktu sampai Anda benar-benar mahir dalam pemantauan kinerja runtime. Tetapi bahkan dalam hitungan jam, katakanlah setelah membaca artikel ini, jika Anda mengikuti saran saya dan menerapkannya di aplikasi Anda berikutnya, hasilnya akan luar biasa! Membuat profil dan menyetel sistem yang rumit sekalipun tidak terlalu sulit. Ini bisa menyenangkan juga!

Sebuah pertanyaan sering diajukan mengenai perbedaan antara pengembang seluler tingkat pemula dan master. Menguasai DDMS di Android—atau secara umum, profil aplikasi dan kemampuan introspeksi—adalah salah satu perbedaan utama.

Catatan: Sebagian besar menjadi pengembang kedudukan tertinggi menggunakan perpustakaan terbaik yang tersedia di domain Anda. Dalam artikel Toptal sebelumnya, saya mencantumkan beberapa perpustakaan pengembang terbaik yang tersedia untuk Android. Dalam arti tertentu, artikel ini adalah sekuel dari artikel "perpustakaan" dan mencakup salah satu dari banyak alat Android. Tak perlu dikatakan, jika Anda bertujuan untuk meningkatkan keterampilan pengembang Android Anda, bacalah sekarang!

Panduan Cepat untuk DDMS di Android Studio

Dan sekarang, tanpa basa-basi lagi, mari kita selidiki deskripsi DDMS, salah satu alat pengembang Android terbaik.

Saat menimbang upaya dengan manfaat, mungkin tidak ada alat lain yang dapat meningkatkan kualitas aplikasi Anda dan membantu Anda menemukan bug yang benar- benar berantakan dan sulit dipahami yang mungkin ada di dalamnya. Tapi tetap saja, untuk beberapa alasan (malas, siapa saja?), begitu banyak tim gagal menggunakan DDMS.

Mari kita mulai dengan kursus kilat di DDMS:

DDMS dapat diakses melalui Studio > Tools > Android > Android Device Monitor dan mengklik tombol DDMS pada menu. Anda juga dapat menempatkannya sebagai ikon pintasan (saya lakukan) di panel atas Anda.

Setelah dibuka, inilah yang akan Anda lihat:

Panel kiri memungkinkan pemilihan perangkat/aplikasi dan konsol kanan memberi Anda beberapa tampilan, masing-masing di tabnya sendiri, masing-masing menampilkan tampilan spesifik aplikasi Anda.

Layanan utama yang disediakan oleh Dalvik Debug Monitor Server adalah:

• Statistik penggunaan memori aplikasi (statistik tumpukan total dan alokasi objek)
• Statistik utas aplikasi
• Tangkapan layar perangkat
• Penjelajah file perangkat
• Panggilan masuk dan SMS spoofing
• Pemalsuan data lokasi
• Logcat

Untuk mendapatkan nilai memori heap saat ini yang digunakan oleh aplikasi Anda, cukup lakukan hal berikut:

• Hubungkan perangkat tempat aplikasi Anda berjalan
• Klik tombol Perbarui Heap untuk mengaktifkan pengumpulan statistik heap
• Buka tab Tumpukan
• Klik "Sebab GC" untuk memaksa menjalankan GC. Hanya setelah proses tersebut, pengumpulan data heap akan dimulai
• Biarkan tab tetap terbuka, lanjutkan mengerjakan aplikasi Anda, dan klik ulang "Sebab GC" secara berkala untuk menyegarkan data statistik tumpukan

Baris terakhir ini mungkin membutuhkan penjelasan tambahan. Penggunaan memori adalah salah satu nilai analitik di mana dinamikanya jauh lebih penting daripada nilai awal. Untuk sebagian besar aplikasi, kami tidak akan terlalu peduli dengan nilai penggunaan heap awal. Kami akan sangat peduli dengan kemajuan nilai ini, karena ini akan memberi kami indikasi yang jelas tentang salah satu mimpi buruk yang menunggu pengembang seluler—kebocoran memori Android:

Penggunaan modul heap stat saya sederhana; sebagai bagian dari siklus pengembangan aplikasi, setelah memperkenalkan perubahan yang akan berdampak pada penggunaan heap, saya akan mengaktifkan modul, "Penyebab GC" untuk memulai pengumpulan statistik, mengaktifkan (biasanya lebih dari sekali) posisi heap-intensif aplikasi saya, dan secara berkala "Menyebabkan GC" untuk menyegarkan. Jika penggunaan heap terus bertambah, saya mengalami kebocoran memori di tangan saya dan saya harus menyelesaikannya (detail tentang caranya - di bawah). Jika tidak, dan terlepas dari ukuran tumpukan sebenarnya, saya baik-baik saja.

Jika kebocoran memori terdeteksi, alat selanjutnya yang akan saya gunakan adalah Object Allocation Tracker. Mari kita lihat apa yang dapat dilakukannya untuk manajemen memori di Android.

Pelacak Alokasi Objek

Pelacak alokasi, sederhananya, akan memberi Anda informasi yang diperlukan untuk mencari tahu siapa pihak yang "disalahkan" untuk ukuran tumpukan saat ini. Modul ini akan memberi tahu Anda dari utas dan metode mana perintah alokasi berasal secara real-time, membuatnya sangat berharga untuk analisis memori di Android.

Untuk memulai pelacakan, lakukan hal berikut:

• Pilih perangkat/proses yang relevan seperti sebelumnya
• Beralih ke tab Pelacak Alokasi dan klik Mulai Pelacakan untuk memulai.
• Dari sini semua alokasi baru akan dilacak
• Klik "Dapatkan Alokasi" untuk mendapatkan tampilan daftar semua alokasi terbaru (terbaru sejak "mulai" terakhir)
• Untuk mengetahui siapa otoritas alokasi, klik baris tertentu dalam daftar

Sekarang, dari pengalaman saya sendiri, melakukan tindakan alokasi intensif pada aplikasi Anda diikuti dengan mengklik "Dapatkan Alokasi" untuk melihat penghitung alokasi biasanya akan mengarahkan Anda ke kebocoran secara langsung; terkadang, baik saat kebocoran non-linier (yaitu, terjadi sesekali) ATAU saat aplikasi Anda berisi beberapa kebocoran yang mungkin tidak berfungsi. Dalam kasus seperti itu, dan saya belum menemukan banyak dari ini, Anda harus menggunakan secara manual membuat file HPROF dump dan menganalisisnya. Analisis memori dan manajemen memori Android tidak akan dibahas secara mendalam dalam artikel ini. Lihat di sini untuk beberapa petunjuk.

Konsol Info Utas: Penggunaan CPU Android Menjadi Mudah

Dikenal baik oleh pengembang mana pun, jalur sinkron untuk mengeksekusi logika dikelompokkan ke dalam utas, masing-masing membentuk satu aliran serial eksekusi dalam aplikasi Anda. Secara harfiah semua aplikasi menggunakan lebih dari satu utas eksekusi. Beberapa dari mereka menggunakan lusinan.

Pemeriksaan menyeluruh terhadap potensi masalah saat menggunakan utas jauh di luar cakupan artikel ini. Mari kita berkonsentrasi kemudian pada satu, yaitu kelaparan utas, yang merupakan masalah utama Anda akan mengunjungi konsol info utas.

Di semua aplikasi seluler, utas yang berbeda akan bersaing untuk waktu CPU. Ada tidak cukup dari mereka untuk pergi sekitar. Apa yang terjadi jika, karena alasan apa pun, satu atau lebih utas ini tidak mendapatkan waktu eksekusi yang mereka butuhkan? Biasanya hal-hal buruk. Sistem tidak akan berperilaku seperti yang Anda rencanakan, yang selalu merupakan ide yang buruk. Alasan potensial untuk masalah ini dapat berupa pengaturan prioritas rendah, utas lain secara bersamaan menjalankan pengaturan sendiri dengan prioritas yang terlalu tinggi, menghabiskan waktu lama pada monitor sinkronisasi, dan banyak lagi. Semua sangat sulit dideteksi hanya dengan tinjauan kode.

Konsol utas Android DDMS untuk menyelamatkan!

Saat Anda memasuki tampilan utas, Anda akan melihat daftar yang terdiri dari catatan utas, masing-masing berisi nama dan ID utas, dan dua penghitung tambahan yang disebut utime dan stime. Utime mengukur total waktu yang dihabiskan oleh utas yang mengeksekusi kode pengguna (pikirkan fungsi Anda dan perpustakaan pihak ketiga), sementara stime mengukur total waktu yang dihabiskan untuk kode sistem (tidur, sinkronisasi, panggilan sistem—banyak). Yang pertama—utime—biasanya akan lebih menarik bagi kita, meskipun saya bisa memikirkan masalah yang sebagian besar akan muncul dengan sendirinya melalui penghitung waktu.

OK, kami menjalankan kode kami, termasuk beberapa utas, dan kami ingin memastikan semua utas kami mendapatkan bagian waktu CPU mereka. Untuk ini, pertama-tama kita biarkan sistem kita berjalan sebentar, lalu buka tab utas dan mulai mencari nilai utime "aneh". Nol tentu saja dapat mewakili masalah—utas benar-benar tidak memiliki waktu CPU dan tidak ada penggunaan CPU. Tetapi nilai yang terlalu tinggi mungkin mewakili aspek berbeda dari masalah yang sama: yaitu, utas yang prioritasnya sangat tinggi sehingga menyebabkan orang lain kelaparan.

Perhatikan bahwa untuk satu jenis utas, nilai utime nol atau mendekati nol tidak akan menunjukkan masalah nyata. Ini adalah utas terikat I/O, utas yang sebagian besar melakukan akses jaringan atau disk (atau basis data). Utas ini harus menghabiskan sebagian besar waktunya menunggu data tiba atau memblokir panggilan sistem yang tertunda, tidak satu pun dari tindakan ini yang meningkatkan penghitung utime. Ketahui utas Anda!

Tip: Jangan pernah menggunakan nama default thread. Itu tidak berarti apa-apa dan Anda biasanya akan gagal mendeteksinya dalam tampilan DDMS. sebagai gantinya, setiap kali membuat utas atau mengambilnya dari kumpulan utas, mulailah interaksi Anda dengan menetapkannya dengan nama yang cukup jelas. Ini akan membuat hidup Anda lebih mudah daripada men-debug/membuat profil sistem Anda. Saya biasanya menambahkan nama aplikasi untuk membedakan antara utas yang dihasilkan Android dan yang dihasilkan oleh kode saya sendiri, contoh: konektor-server-MyApp,-interaktor-db-Saya, dll.

Tip: Prioritas utas menunjukkan (secara longgar berbicara) jumlah waktu CPU yang akan diberikan oleh penjadwal. Prioritas yang ditetapkan ke utas pekerja Anda sangat penting untuk kinerja keseluruhan dan "kelancaran" aplikasi Anda, dan dalam banyak kasus dapat menjadi perbedaan antara perilaku cepat licin dan perilaku lambat bergelombang. Aturannya sederhana: Prioritas default yang ditetapkan oleh Android, yaitu NORMAL=5, hampir selalu bukan prioritas yang ingin Anda gunakan. Sebagai gantinya, untuk sebagian besar utas pekerja, Anda menginginkan dampak yang jauh lebih kecil pada penggunaan CPU secara keseluruhan. Untuk melakukan ini, saat memulai utas, tetapkan prioritasnya ke nilai yang lebih rendah, saya biasanya menggunakan prioritas=3.

Konsol Statistik Jaringan

Statistik jaringan memungkinkan Anda memantau saluran komunikasi masuk dan keluar ke aplikasi Anda dengan cara yang cukup dapat dibaca manusia.

Sumbu y dalam bagan jaringan mewakili kecepatan transfer transmisi yang diukur dalam KB/detik, sedangkan sumbu x mewakili waktu yang telah berlalu dalam detik. Oleh karena itu, untuk mendapatkan perkiraan cepat dari ukuran transmisi, cobalah untuk memperkirakan area lonjakan yang relevan. Setelah beberapa saat, ini menjadi agak mudah.

Perhatikan bahwa, setelah konsol ini dimasukkan, Anda harus mengklik tombol "aktifkan" atas agar pengukuran jaringan mulai muncul.

Sebelum konsol jaringan matang ke level seperti sekarang, pengembang biasanya harus menggunakan aplikasi sniffer (beberapa masih melakukannya) untuk mendapatkan informasi serupa.

Hal yang hebat tentang konsol ini adalah caranya memvisualisasikan salah satu perilaku pengurasan baterai utama—yaitu komunikasi ukuran paket kecil yang sedang berlangsung. Seperti yang Anda ketahui, apa yang akan membuat aplikasi Anda menjadi penguras baterai bukanlah jaringan intensif selama lima menit seperti yang dilakukannya, melainkan jangka waktu yang lama dari jaringan yang berulang-ulang, misalnya, untuk kepentingan keepalive, diagnostik, atau pembaruan status.

Setelah pola seperti itu terdeteksi, dan tampilan paket visual dari konsol jaringan membuatnya sangat mudah, segera pikirkan batching. Bisakah saya mengelompokkan beberapa transmisi kecil menjadi satu transmisi besar? Dampak baterai dari perubahan ini pasti akan memindahkan aplikasi dari penguras baterai ke kategori berperilaku baik!

Tip: Jangan pernah memuat gambar ke dalam memori apa adanya. Ini adalah kecelakaan kehabisan memori yang menunggu untuk terjadi. Sebagai gantinya, lakukan pemuatan yang diperkecil, atau bahkan lebih baik, gunakan perpustakaan pihak ketiga untuk mengelola penskalaan untuk Anda.

Meskipun Anda jarang menggunakan informasi ini, perhatikan bahwa DDMS bergantung pada tumpukan Android Debug Bridge (ADB) untuk meneruskan data kembali/dari perangkat. Jika DDMS gagal menampilkan aplikasi Anda, atau berhenti di tengah sesi DDMS, pilihan terbaik Anda adalah membuka konsol dan mengetik:

 adb devices

untuk memastikan perangkat Anda dapat diakses dan disahkan dengan ADB. Jika tidak demikian, dalam banyak kasus, memulai ulang server ADB lokal Anda akan menyelesaikan masalah:

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

Jika Anda masih mengalami masalah dan aplikasi Anda diinstal pada perangkat fisik, coba putuskan sambungan semua instance emulator. Mengapa? Karena DDMS menghubungkan dirinya sendiri ke perangkat perangkat fisik dan instance emulator, defaultnya adalah yang terakhir.

Contoh Penggunaan DDMS di kehidupan nyata: Aplikasi berhenti (tidak mogok, hanya berhenti). Pengguna segera bergegas ke stasiun kerja terdekat, menghubungkan ke USB, dan membuka DDMS dalam tampilan utas untuk mengetahui tumpukan utas » utas gagal » jejak tumpukan—dalam kasus saya, karena kebuntuan sinkronisasi yang, setelah terdeteksi, mudah diselesaikan dengan beralih.

Tip: Jika memori RAM standar yang dialokasikan untuk aplikasi Anda oleh Android tidak cukup, seperti yang mungkin terjadi untuk, misalnya, aplikasi intensif media, perhatikan bahwa Anda dapat memperoleh sekitar 15-20% memori tambahan di sebagian besar perangkat dengan menaikkan _ tanda manifes Heap besar : https://developer.android.com/guide/topics/manifest/application-element.html_

Emulasi Status Perangkat di Android DDMS

Sebagai aturan, aplikasi seluler bukanlah konstruksi linier. Sebaliknya, mereka menerapkan strategi kesadaran yang memungkinkan mereka untuk memantau dan bereaksi terhadap perubahan status perangkat. Aplikasi dapat, misalnya, mendengarkan panggilan masuk atau pesan teks, dapat menyelaraskan kembali statusnya sesuai dengan status jaringan, dan dapat melacak dan bereaksi terhadap perubahan di lokasi perangkat.

Contoh sepele untuk yang terakhir adalah aplikasi GPS. Sebagian besar dari kita tidak mengembangkan aplikasi semacam itu (sayangnya, pasarnya tidak cukup besar…) tetapi tetap saja, dalam banyak kasus, kita menerapkan logika, yang bergantung pada lokasi, apakah itu tampilan peta sederhana dari posisi pengguna saat ini, pelacakan rute , atau tampilan data sensitif lokasi.

Pengujian untuk kondisi sensitif keadaan seperti itu sangat rumit, terkadang lebih rumit daripada menulis kode yang sebenarnya. Jika Anda memiliki perangkat fisik dengan SIM, Anda tentu saja dapat mengeluarkan dan menerima panggilan dan SMS. Mengubah status telepon perangkat Anda jauh lebih sulit tetapi masih bisa dilakukan. Perubahan lokasi pengujian bisa lebih rumit, meskipun berjalan-jalan di kota dengan laptop Anda adalah pilihan…

Tapi tetap saja—bagaimana kita menangani instance emulator? Bagaimana kita bisa menguji mereka untuk perubahan ini?

DDMS untuk menyelamatkan, sekali lagi. Salah satu fitur DDMS yang lebih kuat namun sering diabaikan adalah kemampuannya untuk mengeluarkan kejadian tiruan ("spoof") ke dalam instance emulator yang sedang berjalan. DDMS dapat melakukan panggilan dari nomor tertentu ke emulator, mengirim SMS, mengubah data status telepon, dan banyak lagi.

Setelah masuk ke emulator, semua peristiwa palsu ini tidak lagi dapat dibedakan dari peristiwa "nyata", yaitu, seolah-olah diterima oleh sensor perangkat keras yang mendasarinya. Secara khusus, semua penerima aplikasi Anda yang relevan akan diaktifkan dengan cara yang sama seperti saat menerima panggilan/pesan SMS yang sebenarnya.

Mengaktifkan status dan tindakan telepon cukup mudah:

Untuk menguji aplikasi Anda untuk kasus konektivitas jaringan yang rendah (yang seharusnya Anda lakukan di aplikasi yang berpusat pada jaringan) buka bagian Status Telepon dan atur nilai kecepatan dan latensi ke nilai yang diinginkan. Saya biasanya menggunakan nilai GPRS untuk keduanya sebagai cara yang efektif untuk meniru konektivitas rendah, tetapi jangan ragu untuk menetapkan nilai Anda sendiri.

Untuk mensimulasikan panggilan telepon atau SMS, buka bagian Telephony Action, atur nomor telepon asal, tambahkan pesan tekstual jika diperlukan, dan tembak. Alat ini sangat efektif ketika Anda telah menetapkan rute kode khusus untuk panggilan dari luar negeri dan ingin mengujinya dengan anggaran terbatas.

Hal-hal menjadi lebih menarik ketika harus mengejek lokasi baru.

Jika semua yang Anda tuju adalah menyetel lokasi baru untuk instance emulator Anda, pilih Manual, atur nilai lintang/bujur yang diinginkan, dan tekan Kirim.

Namun bagaimana jika, alih-alih menyetel satu lokasi tetap, Anda ingin aplikasi melewati rute yang telah ditentukan sebelumnya—misalnya, memeriksa perilakunya saat pengguna bepergian dari satu kota ke kota lain? Pengujian semacam itu dapat memiliki nilai yang besar untuk aplikasi yang didukung peta serta aplikasi sensitif lokasi lainnya yang menyetel jendela datanya per lokasi pengguna. Di sini, Anda akan ingin melihat bahwa lokasi yang bergeser pada kecepatan yang berbeda akan membuat jendela data yang ditampilkan selalu terbarui.

Untuk ini, kami akan menggunakan format khusus yang disebut KML, yang secara khusus dikembangkan untuk digunakan dengan Google Earth, dan yang mewakili rute, atau jalur, sebagai kumpulan titik yang terhubung di ruang angkasa, yang dapat dilakukan oleh perangkat berkemampuan GPS.

GPX adalah format jalur alternatif yang didukung oleh DDMS. Untuk semua tujuan praktis, keduanya harus dianggap dapat dipertukarkan saat digunakan untuk spoofing lokasi seluler.

Sekarang mari kita berjalan melalui tahapan pengaturan rute tiruan ke dalam emulator.

1. Buat rute. Sejauh ini cara paling sederhana adalah dengan menggunakan opsi arah Google Maps yang mengatur asal dan tujuan yang sesuai.

1. Setelah rute ditampilkan di atas peta, pergi ke baris alamat dan salin URL

2. Dengan URL di clipboard, buka GPS Visualizer, rekatkan ke dalam kotak teks “Provide URL”, dan klik tombol Convert:

dan klik untuk mengunduh file GPX yang dihasilkan (dengan nama yang agak berantakan misalnya 20170520030103-22192-data.gpx)

1. Kembali ke Kontrol Lokasi DDMS, buka tab GPX, klik Muat GPX dan pilih file yang baru diunduh

1. Dilakukan! Anda sekarang dapat menavigasi di antara lokasi rute yang berbeda dengan mengklik tombol mundur dan maju, atau dengan mengklik tombol Putar untuk secara otomatis melalui rute dengan kecepatan yang ditentukan.

Anda tidak perlu membuat rute sendiri. Banyak rute untuk diunduh dari situs seperti OpenStreetMap (lihat bagian 'Jejak GPS').

Terakhir, harap perhatikan bahwa tidak seperti versi DDMS yang lebih lama, di mana pemuatan file rute sangat mudah, versi yang lebih baru mungkin memerlukan beberapa percobaan dan kesalahan saat memuat rute tertentu.

Misalnya tampaknya hanya GPX 1.1 yang didukung oleh DDMS. Versi GPX baru mungkin memerlukan beberapa penyesuaian manual.

Selain itu, format titik jalan GPX tidak lagi didukung. Sebagai gantinya, gunakan format GPX Track:

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

Debugging Android: Satu Jam Seminggu Membuat Perbedaan!

Cukup teori! Sekarang saatnya untuk beberapa latihan. Saya menyarankan, dengan asumsi Anda adalah pengembang Android, bahwa mulai proyek Anda berikutnya, Anda akan mendedikasikan hanya satu jam seminggu untuk mendapatkan introspeksi kinerja aplikasi Anda melalui DDMS.

Anda akan terkejut dengan banyaknya informasi berkualitas (yaitu, informasi yang dapat digunakan untuk segera meningkatkan status aplikasi Anda) yang akan diberikan kepada Anda!

Android DDMS, seperti yang telah saya saksikan berkali-kali dengan pengembang pemula, adalah alat yang dapat sangat meningkatkan kemampuan pengembang, asalkan dikuasai dan digunakan dengan benar. Kemampuan pengembang Android untuk menghadirkan sistem terbaik akan benar-benar naik satu atau dua tingkat setelah mereka memanfaatkan potensi penuh DDMS dalam pengembangan Android. Oleh karena itu, menyisihkan beberapa jam untuk memanfaatkan DDMS dengan baik terdengar seperti investasi yang cerdas, karena dapat sangat meningkatkan kinerja dan efisiensi Android.

Jadilah salah satu orang pintar. Gunakan.