Android DDMS: Ultimate Android Konsolu Kılavuzu

Geliştirmek zor bir iştir. Hedef hareket etmeye devam ediyor, yeni teknolojiler ve alanlar periyodik olarak hayat buluyor, ara sıra yeni araçlar ortaya çıkıyor ve yönetilen tahribatta diller değişiyor.

Yine de, tüm bu değişikliklere rağmen, temel kurallar aynı kalıyor. Bu temel kuralların en önemlilerinden biri, gerçekten harika bir yazılım oluşturmak için, yürütme sisteminizde derin, sürekli ve ayrıntılı bir iç gözlem kazanmanız gerektiğini belirtir. Tanılama , hata ayıklama ve profil oluşturma bazen bu bağlamda kullanılan terimlerdir, ancak kural daha derinlere iner. Birinci sınıf bir geliştirici, sistemini kelimenin tam anlamıyla "hissediyor". Neyin daha fazla belleğin serbest bırakılmasını beklemeye neden olacağını, iş parçacıklarını CPU açlığına neyin götüreceğini, hangi eylemlerin kapsamlı G/Ç veya ağ erişimi ile sonuçlanacağını ve dolayısıyla tüm çalışmasını yavaşlatacağını biliyor.

Etrafında gerçekten bir yol yok. Harika kod yazan çok akıllı bir geliştirici olabilirsiniz, ancak yukarıdaki beceriye, yani sisteminizin çalışma zamanı davranışının ayrıntılarını izleyip inceleyemeyecek olana kadar, gerçekten birinci sınıf teslim söz konusu olduğunda yine de geride kalacaksınız. uygulamalar.

Aslında, biraz deneyim kazandıktan sonra, iç gözlem kuralını ihmal etmeye kadar izlenebilecek bütün bir “kod hastalıkları” kategorisini tespit edeceksiniz: Kısaca, gerçek platform üzerindeki etkilerini sürekli izlemeden kod yazmak (bazen akıllı kod) .

Android'de DDMS: İç Gözlem için Seçtiğim Silahım

Neyse ki bizim için Android topluluğu çok sayıda birinci sınıf iç gözlem aracı sunmayı başardı. Facebook'un Stetho'su en iyiler arasında, AT&T'nin ARO'su (“Uygulama Kaynak Optimize Edici”) biraz daha eski ama yine de muhtemelen en iyi ağ izleme konsolu ile birinci sınıf, LeakCanary ise konsantre olmak için çok daha sınırlı bir yaklaşım benimsiyor (ve bu konuda harika gidiyor). it) çalışma zamanı bellek sızıntısı algılama kitaplığında. Uzun lafın kısası, orada Android hata ayıklama araçları sıkıntısı yok.

Yine de, taçtaki elmas, uygulamanızın çalışma zamanı davranışıyla ilgili önemli, doğru ve iyi biçimlendirilmiş verilerin çıkarılması gerektiğinde güvenilecek iç gözlem aracı, hala Android Studio'daki eski güzel Dalvik Hata Ayıklama İzleme Sunucusu'dur (DDMS). Eclipse Android eklentisi günlerinden beri bizimle (ne yazık ki pek çok ekip tarafından yeterince kullanılmamaktadır).

Android geliştirmede DDMS ne kadar önemlidir? Pekala, 5-6 yıl önce, daha az deneyimli bir Android geliştiricisi olarak, DDMS ve genel olarak mobil uygulama izleme hakkında şu anda bildiklerimi bilmek, beni birçok baş ağrısından ve hata ayıklama gecelerinden kurtarırdı.

Ve mesele şu ki, DDMS'de ustalaşmak çok basit!

Elbette her yazılım aracında olduğu gibi onu doğru şekilde kullanmanın büyük bir kısmı deneyimle gelir. Çalışma zamanı performans izlemede gerçekten iyi olana kadar bir süre profesyonel becerilerinizi geliştirmeniz gerekir. Ancak birkaç saat içinde bile, bu makaleyi okuduktan sonra, önerilerimi takip edip bir sonraki uygulamanızda uygularsanız, sonuçların harika olacağını söyleyin! Karmaşık sistemleri bile profillemek ve ayarlamak o kadar da zor değil. Aynı zamanda eğlenceli olabilir!

Acemi ve usta düzeyinde mobil geliştiriciler arasındaki farkla ilgili sık sık bir soru sorulur. Android'de DDMS'de uzmanlaşmak - veya genel olarak, uygulama profili oluşturma ve iç gözlem yetenekleri - böyle büyük bir farktır.

Not: Birinci sınıf bir geliştirici olmanın büyük bir kısmı, alanınızda mevcut olan en iyi kitaplıkları kullanmaktır. Önceki bir Toptal makalesinde, Android için mevcut olan en iyi geliştirici kitaplıklarından bazılarını listelemiştim. Bu makale bir bakıma “kütüphane” makalesinin devamı niteliğindedir ve birçok Android aracından birini kapsar. Söylemeye gerek yok, Android geliştirici becerilerinizi geliştirmeyi hedefliyorsanız, şimdi okuyun!

Android Studio'da DDMS için Hızlı Kılavuz

Ve şimdi lafı daha fazla uzatmadan, en iyi Android geliştirici araçlarından biri olan DDMS'nin açıklamasına geçelim.

Çabayı faydaya karşı tartarken, muhtemelen başka hiçbir araç uygulamanızın kalitesini iyileştiremez ve içerebileceği gerçekten dağınık ve anlaşılması zor hataları bulmanıza yardımcı olamaz. Ama yine de, bir nedenden dolayı (tembellik, kimse?), Pek çok takım DDMS'yi kullanamıyor.

DDMS'de hızlandırılmış bir kursla başlayalım:

DDMS'ye Studio > Araçlar > Android > Android Device Monitor üzerinden ve menüdeki DDMS düğmesine tıklayarak erişilebilir. Ayrıca, üst panelinize kısayol simgesi (Yaparım) olarak da yerleştirebilirsiniz.

Açıldığında, göreceğiniz şey şudur:

Sol panel, cihaz/uygulama seçimine izin verir ve sağ konsol, her biri kendi sekmesinde, her biri uygulamanızın belirli bir görünümünü sergileyen birden çok görünüm sağlar.

Dalvik Debug Monitor Server tarafından sağlanan başlıca hizmetler şunlardır:

• Uygulama belleği kullanım istatistikleri (toplam yığın ve nesne ayırma istatistikleri)
• Uygulama dizisi istatistikleri
• Cihaz ekran görüntüsü
• Cihaz dosyası gezgini
• Gelen arama ve SMS sahtekarlığı
• Konum verileri sahtekarlığı
• kütük kedi

Uygulamanız tarafından kullanılan mevcut yığın bellek değerini elde etmek için aşağıdakileri yapmanız yeterlidir:

• Uygulamanızın üzerinde çalıştığı cihazı bağlayın
• Yığın istatistik toplamayı etkinleştirmek için Yığını Güncelle düğmesini tıklayın
• Yığın sekmesini açın
• Bir GC çalıştırmasını zorlamak için "GC'ye Neden Ol"a tıklayın. Yığın veri toplama işlemi ancak böyle bir çalıştırmadan sonra başlayacaktır.
• Sekmeyi açık tutun, uygulamanız üzerinde çalışmaya devam edin ve yığın istatistik verilerini yenilemek için periyodik olarak "GC'ye Neden"i yeniden tıklayın.

Bu son satır muhtemelen ek açıklama gerektirir. Bellek kullanımı, dinamiklerinin başlangıç ​​değerinden çok daha önemli olduğu analitik değerlerden biridir. Çoğu uygulama için, ilk yığın kullanım değerini pek umursamayacağız. Mobil geliştiricileri bekleyen gerçek kabuslardan biri olan Android bellek sızıntılarının net bir göstergesini sağlayacağından, bu değerin ilerlemesini çok önemseyeceğiz:

Heap stat modülünü kullanımım basit; Uygulamayı geliştirme yaşam döngüsünün bir parçası olarak, yığın kullanımını etkilemesi gereken değişiklikleri uyguladıktan sonra, istatistik toplamayı başlatmak için "GC'ye Neden" modülünü etkinleştireceğim, uygulamamın yığın yoğun konumlarını etkinleştireceğim (genellikle bir kereden fazla), ve periyodik olarak "GC'nin yenilenmesine neden olun". Yığın kullanımı artmaya devam ederse, elimde bir bellek sızıntısı var ve bunu çözmem gerekiyor (nasıl ile ilgili ayrıntılar - aşağıda). Değilse ve gerçek yığın boyutundan bağımsız olarak, ben iyiyim.

Bir bellek sızıntısı tespit edilirse, kullanacağım sonraki araç Object Allocation Tracker'dır. Android'de bellek yönetimi için neler yapabileceğini görelim.

Nesne Ayırma İzleyici

Basitçe söylemek gerekirse, ayırma izleyicisi, mevcut yığın boyutu için "suçlanacak" tarafın kim olduğunu bulmak için gereken bilgileri size sağlayacaktır. Bu modül, ayırma komutlarının gerçek zamanlı olarak hangi iş parçacıklarından ve yöntemlerden geldiğini size söyleyecek ve Android'de bellek analizi için paha biçilmez hale getirecektir.

İzlemeye başlamak için aşağıdakileri yapın:

• İlgili cihazı/prosesi önceden olduğu gibi seçin
• Tahsis İzleyici sekmesine geçin ve başlamak için İzlemeyi Başlat'a tıklayın.
• Buradan itibaren tüm yeni tahsisler izlenecek
• En son tahsislerin (son "başlangıcından" beri en son) bir liste görünümünü almak için "Ayırmaları Al"ı tıklayın.
• Tahsis yetkilisinin kim olduğunu öğrenmek için listedeki belirli bir satırı tıklayın.

Şimdi, kendi deneyimlerime göre, uygulamanızda ayırma yoğun eylemler gerçekleştirdikten sonra ayırma sayaçlarını görüntülemek için "Ayırma Al"ı tıkladığınızda, genellikle sizi basit bir şekilde sızıntıya yönlendirir; bazen, sızıntı doğrusal olmadığında (yani, ara sıra meydana geldiğinde) VEYA uygulamanız çalışmayabilecek birden fazla sızıntı içerdiğinde. Bu gibi durumlarda ve ben bunların çoğuyla karşılaşmadım, manuel olarak bir dump HPROF dosyası oluşturmaya ve onu analiz etmeye başvurmanız gerekecek. Bellek analizi ve Android bellek yönetimi bu makalede derinlemesine ele alınmayacaktır. Bazı potansiyel müşteriler için buraya bakın.

Konu Bilgi Konsolu: Android CPU Kullanımı Kolaylaştırıldı

Herhangi bir geliştirici tarafından iyi bilinen, eşzamanlı mantık yürütme yolları, her biri uygulamanız içinde bir seri yürütme akışı oluşturan iş parçacıkları halinde gruplandırılmıştır. Kelimenin tam anlamıyla tüm uygulamalar, tek bir yürütme iş parçacığından fazlasını kullanır. Bazıları düzinelerce kullanıyor.

Konuları kullanırken olası sorunların genel bir incelemesi bu makalenin kapsamı dışındadır. O halde tek bir soruna odaklanalım, yani iş parçacığı bilgi konsolunu ziyaret edeceğiniz ana sorun olan iş parçacığı açlığı.

Tüm mobil uygulamalarda farklı iş parçacıkları CPU zamanı için rekabet edecek. Etrafta dolaşmak için bunlardan yeterince yok. Herhangi bir nedenle, bir veya daha fazla iş parçacığı ihtiyaç duydukları yürütme süresini alamazsa ne olur? Genellikle kötü şeyler. Sistem, planladığınız gibi davranmayacaktır, ki bu her zaman kötü bir fikirdir. Bu sorunun olası nedenleri düşük önceliği ayarlamak, diğer iş parçacıklarının kendilerini aşırı yüksek önceliğe sahip olarak aynı anda yürütmesi, senkronizasyon monitörlerinde uzun zaman harcaması ve daha fazlası olabilir. Hepsinin yalnızca kod incelemesiyle tespit edilmesi çok zor .

Android DDMS iş parçacığı konsolu kurtarmaya!

İş parçacığı görünümüne girerken, her biri iş parçacığının adını ve kimliğini ve utime ve stime adlı iki ek sayacı içeren iş parçacığı kayıtlarından oluşan bir liste göreceksiniz. Utime, kullanıcı kodunu yürüten iş parçacığı tarafından harcanan toplam süreyi ölçer (işlevlerinizi ve üçüncü taraf kitaplıklarınızı düşünün), stime ise sistem kodunda (uyku, senkronizasyon, sistem çağrıları - parti) harcanan toplam süreyi ölçer. İlki - utime - genellikle bizim için daha ilginç olacak, ancak çoğunlukla zaman sayacı tarafından ortaya çıkacak sorunları düşünebiliyorum.

Tamam, birkaç iş parçacığı dahil olmak üzere kodumuzu çalıştırıyoruz ve tüm iş parçacıklarımızın CPU zamanından paylarını aldığından emin olmak istiyoruz. Bunun için önce sistemimizin bir süre çalışmasına izin verdikten sonra thread sekmesini açıp “tuhaf” utime değerlerini aramaya başlıyoruz. Sıfır kesinlikle bir sorunu temsil edebilir - iş parçacığının tam anlamıyla CPU zamanı ve CPU kullanımı yok. Ancak aşırı yüksek değerler aynı sorunun farklı bir yönünü temsil edebilir: yani, diğerlerinin aç kalmasına neden olacak kadar önceliği olan iş parçacıkları.

Bir tür iş parçacığı için sıfır veya sıfıra yakın kullanım süresi değerinin gerçek bir sorunu göstermeyeceğine dikkat edin. Bunlar, çoğunlukla ağ veya disk (veya veritabanı) erişimi yapan G/Ç bağlantılı iş parçacıklarıdır. Bu iş parçacıkları zamanlarının çoğunu ya verilerin gelmesini bekleyerek ya da bekleyen sistem çağrılarını engelleyerek geçirmelidir, bu eylemlerin hiçbiri kullanım süresi sayacını artırmaz. Konularınızı bilin!

İpucu: Asla iş parçacığının varsayılan adını kullanmayın. Bu hiçbir şey ifade etmez ve genellikle DDMS görünümlerinde bunu tespit etmekte başarısız olursunuz. bunun yerine, bir iş parçacığı oluşturduğunuzda veya bir iş parçacığı havuzundan getirdiğinizde, ona açıklayıcı bir ad atayarak etkileşiminizi başlatın. Bu, hayatınızı sisteminizde hata ayıklamak/profil oluşturmaktan çok daha kolay hale getirecektir. Android tarafından oluşturulan iş parçacığı ile kendi kodum tarafından oluşturulanlar arasında ayrım yapmak için genellikle uygulamanın adını başına koyarım, örneğin: MyApp-server-connector, MyApp-db-interactor, vb.

İpucu: Bir iş parçacığının önceliği, zamanlayıcı tarafından verilecek CPU zamanı miktarını (gevşek bir ifadeyle) belirtir. Çalışan iş parçacıklarınıza atanan öncelik, uygulamanızın genel performansı ve "pürüzsüzlüğü" için kritik öneme sahiptir ve çoğu durumda kaygan hızlı davranış ile inişli çıkışlı yavaş davranış arasındaki fark olabilir. Buradaki kural basittir: Android tarafından atanan NORMAL=5 olan varsayılan öncelik, neredeyse her zaman kullanmak istediğiniz öncelik değildir. Bunun yerine, çoğu çalışan iş parçacığı için genel CPU kullanımı üzerinde çok daha küçük bir etki istiyorsunuz. Bunu yapmak için, bir iş parçacığının başlangıcında önceliğini daha düşük bir değere ayarlayın, genellikle öncelik=3 ile giderim.

Ağ İstatistikleri Konsolu

Ağ istatistikleri, uygulamanıza hem gelen hem de giden iletişim kanallarını makul ölçüde insan tarafından okunabilir bir şekilde izlemenize olanak tanımakla ilgilidir.

Ağ grafiğindeki y ekseni, iletimin KB/saniye cinsinden ölçülen aktarım hızını temsil ederken, x ekseni, saniye cinsinden geçen süreyi temsil eder. Bu nedenle, iletimin boyutunun hızlı bir tahminini elde etmek için ilgili ani yükselme alanını tahmin etmeye çalışın. Bir süre sonra bu oldukça kolay hale geliyor.

Bu konsola girildikten sonra, ağ ölçümlerinin görünmeye başlaması için üstteki “etkinleştir” düğmesine tıklamanız gerekeceğini unutmayın.

Ağ konsolu şu anki seviyeye olgunlaşmadan önce, geliştiriciler genellikle benzer bilgileri elde etmek için sniffer uygulamaları kullanmaya başvurmak zorunda kaldılar (bazıları hala kullanıyor).

Bu konsolla ilgili harika olan şey, pili boşaltmanın en önemli davranışlarından birini, yani devam eden küçük paket boyutundaki iletişimi görselleştirme şeklidir. Birçoğunuzun bildiği gibi, uygulamanızı pil tüketen yapan şey, yaptığı beş dakikalık yoğun ağ iletişimi değil, daha çok, örneğin canlı tutma, tanılama veya durum güncellemeleri için uzun, kısa, tekrar eden ağ süreleridir.

Böyle bir model algılandığında ve ağ konsolunun görsel paket ekranı bunu çok kolay hale getirdiğinde, hemen toplulaştırmayı düşünün. Birden fazla küçük iletimi tek bir büyük iletimde toplayabilir miyim? Bu değişikliğin pil etkisi, uygulamaları pil tüketen bir kategoriden iyi niyetli bir kategoriye taşımak zorunda!

İpucu: Bir görüntüyü asla belleğe olduğu gibi yüklemeyin. Bu, gerçekleşmeyi bekleyen bellek yetersiz bir çökmedir. Bunun yerine, ölçeği küçültülmüş yükleme gerçekleştirin veya daha da iyisi, sizin için ölçeklendirmeyi yönetmek için bir üçüncü taraf kitaplığı kullanın.

Bu bilgiyi nadiren kullanacak olsanız da, DDMS'nin verileri cihazdan geri/cihazdan iletmek için Android Hata Ayıklama Köprüsü (ADB) yığınına dayandığını unutmayın. DDMS uygulamanızı gösteremezse veya bir DDMS oturumunun ortasında donarsa, en iyi seçeneğiniz bir konsol açıp şunu yazmak olacaktır:

 adb devices

cihazınızın ADB ile erişilebilir ve yetkilendirilmiş olduğundan emin olmak için. Durum böyle değilse, çoğu durumda yerel ADB sunucunuzu yeniden başlatmak sorunu çözmelidir:

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

Hâlâ sorun yaşıyorsanız ve uygulamanız fiziksel bir cihaza yüklenmişse, tüm öykünücü örneklerinin bağlantısını kesmeyi deneyin. Niye ya? DDMS kendisini hem fiziksel aygıt aygıtına hem de öykünücü örneklerine bağladığından, varsayılan ikincisidir.

Gerçek hayattan DDMS Kullanımı örneği: Bir uygulama durur (çökmez, sadece durur). Kullanıcı hemen yakındaki iş istasyonuna koşar, USB'ye bağlanır ve iş parçacığı yığını » başarısız iş parçacığı » yığın izini bulmak için iş parçacığı görünümünde DDMS'yi açar - benim durumumda, senkronizasyon kilitlenmesi nedeniyle, bir kez algılandığında geçiş yapılarak kolayca çözülür.

İpucu: Android tarafından uygulamanıza ayrılan standart RAM belleği, örneğin medya yoğun uygulamalarda olabileceği gibi yeterli değilse, _ LargeHeap bildirim bayrağını yükselterek çoğu cihazda %15-20 ek bellek kazanabileceğinizi unutmayın. : https://developer.android.com/guide/topics/manifest/application-element.html_

Android DDMS'de Cihaz Durumu Öykünmesi

Kural olarak, mobil uygulamalar doğrusal yapılar değildir. Bunun yerine, cihazın durumundaki değişiklikleri izlemelerine ve bunlara tepki vermelerine olanak tanıyan farkındalık stratejileri uygularlar. Bir uygulama, örneğin, gelen aramayı veya metin mesajlarını dinleyebilir, durumunu ağ durumuna göre yeniden ayarlayabilir ve cihazın konumundaki değişiklikleri izleyebilir ve bunlara tepki verebilir.

İkincisi için önemsiz bir örnek, bir GPS uygulaması olacaktır. Çoğumuz bu tür uygulamalar geliştirmiyoruz (ne yazık ki, pazar yeterince büyük değil…) ama yine de, çoğu durumda, kullanıcının mevcut konumunun basit bir harita görünümü olsun, rota takibi olsun, konuma bağlı olan mantığı devreye sokarız. veya konuma duyarlı bir veri ekranı.

Duruma duyarlı bu tür koşulları test etmek, bazen gerçek kodu yazmaktan çok daha karmaşıktır. SIM'li fiziksel bir cihazınız varsa, elbette arama ve SMS gönderip alabilirsiniz. Cihazınızın telefon durumunu değiştirmek çok daha zordur ama yine de yapılabilir. Dizüstü bilgisayarınızla şehirde dolaşmak bir seçenek olsa da, test konumu değişiklikleri daha zor olabilir…

Ama yine de, öykünücü örneklerini nasıl ele alırdık? Bunları bu değişiklikler için nasıl test edebiliriz?

DDMS bir kez daha kurtarmaya geldi. DDMS'nin daha güçlü, ancak sıklıkla gözden kaçan özelliklerinden biri, çalışan bir öykünücü örneğine sahte olaylar ("sahte") yayınlama yeteneğidir. DDMS, belirli bir numaradan öykünücüye arama yapabilir, SMS gönderebilir, telefon durumu verilerini değiştirebilir ve daha fazlasını yapabilir.

Öykünücüye ulaştıktan sonra, tüm bu sahte olaylar artık "gerçek" olaylardan ayırt edilemez, yani temeldeki donanım sensörleri tarafından alınmış gibi. Spesifik olarak, ilgili uygulamanızın tüm alıcıları, gerçek bir arama/SMS mesajı aldıklarında yapacakları şekilde etkinleştirilecektir.

Telefon durumunu ve eylemleri etkinleştirmek oldukça basittir:

Uygulamanızı düşük ağ bağlantısı durumlarına karşı test etmek için (herhangi bir ağ merkezli uygulamada yapmanız gereken) Telefon Durumu bölümüne gidin ve hız ve gecikme değerlerini istediğiniz değerlere ayarlayın. Düşük bağlanabilirliği taklit etmenin etkili bir yolu olarak genellikle GPRS değerini kullanırım, ancak kendi değerlerinizi ayarlamaktan çekinmeyin.

Telefon aramalarını veya SMS'leri simüle etmek için Telefon İşlemi bölümüne gidin, kaynak telefon numarasını ayarlayın, gerekirse bir metin mesajı ekleyin ve ateş edin. Bu araç, özellikle yurt dışından gelen aramalar için özel bir kod rotası belirlediğinizde ve bunu bütçe dahilinde test etmek istediğinizde etkilidir.

Yeni bir yerle alay etmeye gelince işler daha da ilginçleşiyor.

Tek amacınız öykünücü örneğiniz için yeni bir konum belirlemekse, El İle'yi seçin, istediğiniz enlem/boylam değerlerini ayarlayın ve Gönder'e basın.

Ancak, sabit bir konum belirlemek yerine uygulamanızın önceden belirlenmiş bir rotadan geçmesini istiyorsanız, örneğin kullanıcı bir şehirden diğerine seyahat ederken davranışını inceleyin? Böyle bir test, herhangi bir harita destekli uygulama ve ayrıca veri pencerelerini kullanıcı konumuna göre ayarlayan diğer konuma duyarlı uygulamalar için büyük değere sahip olabilir. Burada, farklı hızlarda yer değiştirmenin görüntülenen veri penceresini güncel tutacağını görmek isteyeceksiniz.

Bunun için, Google Earth ile kullanılmak üzere özel olarak geliştirilmiş ve GPS özellikli cihazlarla olabilen, uzaydaki bir dizi bağlantılı nokta olarak rotaları veya yolları temsil eden KML adlı özel bir format kullanacağız.

GPX, DDMS tarafından desteklenen alternatif bir yol biçimidir. Tüm pratik amaçlar için, bu ikisinin mobil konum sahtekarlığı için kullanıldığında birbirinin yerine kullanılabilir olduğu düşünülmelidir.

Şimdi öykünücüye sahte bir rota belirleme aşamalarını geçelim.

1. Bir rota oluşturun. Şimdiye kadarki en basit yol, uygun başlangıç ​​ve varış yerini ayarlayan Google Haritalar yön seçeneğini kullanmak olacaktır.

1. Rota harita üzerinde görüntülendiğinde, adres satırına gidin ve URL'yi kopyalayın

2. Panodaki URL ile GPS Görüntüleyiciye gidin, URL'yi Sağla metin kutusuna yapıştırın ve Dönüştür düğmesini tıklayın:

ve ortaya çıkan GPX dosyasını indirmek için tıklayın (biraz karışık bir adla, örneğin, 20170520030103-22192-data.gpx)

1. DDMS Konum Kontrolüne geri dönün, GPX sekmesini açın, GPX Yükle'ye tıklayın ve yeni indirilen dosyayı seçin

1. Yapılmıştı! Artık geri ve ileri düğmelerini tıklatarak veya rotada otomatik olarak belirli bir hızda gezinmek için Oynat düğmesini tıklatarak farklı rota konumları arasında gezinebilirsiniz.

Kendi rotanızı oluşturmanıza gerek yoktur. OpenStreetMap gibi sitelerden indirilebilecek çok sayıda rota (bkz. 'GPS İzleri' bölümü).

Son olarak, rota dosyası yüklemenin çok kolay olduğu eski DDMS sürümlerinden farklı olarak, yeni sürümlerin belirli bir rota yüklerken biraz deneme yanılma gerektirebileceğini lütfen unutmayın.

Örneğin, DDMS tarafından yalnızca GPX 1.1'in desteklendiği görülüyor. Yeni GPX sürümleri bazı manuel ayarlamalar gerektirebilir.

Ek olarak, GPX yol noktası formatı artık desteklenmemektedir. Bunun yerine GPX Track biçimini kullanın:

 <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'de Hata Ayıklama: Haftada Bir Saat Fark Yaratır!

Yeter teori! Şimdi biraz pratik yapma zamanı. Bir Android geliştiricisi olduğunuzu varsayarsak, bir sonraki projenize başlayarak, DDMS aracılığıyla uygulamanızın performansına ilişkin iç gözlem kazanmak için haftada yalnızca bir saat ayırmanızı öneririm.

Bunun size sağlayacağı kaliteli bilgi miktarına (yani uygulamanızın durumunu hemen iyileştirmek için kullanılabilecek bilgiler) şaşıracaksınız!

Acemi geliştiricilerde defalarca tanık olduğum gibi, Android DDMS, ustalaşılması ve uygun şekilde kullanılması koşuluyla geliştiricinin yeteneklerini büyük ölçüde artırabilecek bir araçtır. Bir Android geliştiricisinin birinci sınıf sistemler sunma yeteneği, Android geliştirmede DDMS'nin tüm potansiyelinden yararlandığında kelimenin tam anlamıyla bir veya iki çentik artacaktır. Bu nedenle, Android performansını ve verimliliğini büyük ölçüde artırabileceğinden, DDMS'den iyi bir şekilde yararlanmak için birkaç saat ayırmak akıllıca bir yatırım gibi görünüyor.

Akıllı adamlardan biri olun. Kullanın.