Android-Performans Optimizasyonu Deneyim Paylaşımı
Önsöz
Performans optimizasyonu süreci iki bölüme ayrılmıştır:
1. Performans darboğazlarını keşfedin
2. Performans sorunlarını çözmek için bir plan geliştirin
Performans probleminin çözümü, belirli durumların özel analizini gerektirir ve tamamen sabit bir yol yoktur ve daha çok, bu makalede ele alınmayan deneyim birikimine bağlıdır. Ancak performans darboğazlarını bulmanın sabit bir yolu var. Bu makale esas olarak performans darboğazlarının nasıl bulunacağını açıklamaktadır.
Performans darboğazları nasıl bulunur?
Yaygın olarak kullanılan performans test aracı, Android Cihaz İzleyicisi ile entegre olan izleme görüntülemedir. Android Studio 3.0'dan başlayarak, Android Cihaz Monitörü terk edilmiş ve yerine üç ana işlev sunan Android Profiler ile değiştirilmiştir: Bellek Prodiler, CPU Profiler ve Network Prodiler.
Bellek optimizasyonu (bellek sızıntıları dahil) yaygın olarak MAT veya LeakCanary olarak kullanılır ve Memory Profiler, MAT'ın basitleştirilmiş sürümünü AS'ye entegre etmeye eşdeğerdir. Performans optimizasyonu açısından, CPU Profiler izleme işlevini AS'ye entegre etmeye eşdeğerdir.
Bu nedenle, AS3.0'dan önceki sürümü kullanırsanız, izleme görünümünü kullanabilirsiniz ve AS3.0'dan sonraki sürümü kullanırsanız, izleme görünümüne ek olarak CPU Profiler'ı da seçebilirsiniz.
Çerçevelerin neden olduğu arayüz donmaları gibi sorunları çözmek için sistem işleminin detaylı verilerini takip etmek istiyorsanız, bu makalede ele alınmayan systrace'i kullanabilirsiniz.
Ücretsiz yüksek seviyeli Android öğrenme materyalleri ve yüksek çözünürlüklü zihin haritalarını almak için makalenin sonundaki tam metni okuyun!
Traceview nasıl kullanılır
İzleme görünümünü kullanmak için, enstrümantasyon için Debug sınıfını kullanmanız gerekir.Uygulama, enstrümantasyon kodunu çalıştırdığında, cep telefonu sd kartında otomatik olarak bir .trace dosyası oluşturur ve ardından dosyayı açmak için izleme veya AS'yi (sürüm 3.0) kullanır.
1. Enstrümantasyon
Enstrümantasyon, Debug sınıfının kullanılmasını gerektirir ve sdcard'da bir .trace dosyası oluşturur, bu nedenle öncelikle uygulamanızın harici depolamaya (WRITE_EXTERNAL_STORAGE) yazma iznine sahip olduğundan emin olmalısınız.
İzlemek istediğiniz kod mantığının başına ve sonuna saplamalar ekleyin:
// Sağladığınız adla bir izleme günlüğü kaydetmeye başlar. Örneğin, // aşağıdaki kod sisteme bir .trace dosyasını cihaza // "sample.trace" adıyla kaydetmeye başlamasını söyler .Debug.startMethodTracing (" sample "); ... // Uygulamanız stopMethodTracing () 'i çağırıncaya kadar sistem oluşturulan izleme verilerini arabelleğe almaya başlar, bu sırada arabelleğe alınmış verileri çıktı dosyasına // yazar.Debug.stopMethodTracing ();Oluşturulan .trace dosyası, getExternalFilesDir () tarafından döndürülen aynı dizin olan sabit bir dizine, yani / sdcard / Android / data // files altına kaydedilecektir.
Uygulamanız, izleme günlüğünün adını değiştirmeden startMethodTracing () öğesini tekrar çağırırsa, cihaza kaydedilen mevcut günlüğün üzerine yazacağını lütfen unutmayın. Her çalıştırma için farklı bir günlük dosyasına kaydetmek isterseniz, aşağıdaki kodu kullanabilirsiniz:
// Geçerli tarih ve saatle // bir Dize oluşturmak için SimpleDateFormat sınıfını kullanır.SimpleDateFormat date = new SimpleDateFormat ("dd_MM_yyyy_hh_mm_ss"); String logDate = date.format (new Date ()); // Tarih ve saati uygular izleme log.Debug.startMethodTracing ("sample-" + logDate) adına;StopMethodTracing () öğesini çağırmadan önce sistem maksimum arabellek değerine ulaşırsa, izlemeyi durdurur ve yönetim merkezine bir bildirim gönderir. İzlemeyi başlatma ve durdurma işlevleri, başvuru süreciniz boyunca geçerlidir. Başka bir deyişle, etkinliğin onCreate (Paket) özelliğini kullanabilirsiniz.
İşlevde startMethodTracing () öğesini ve Activity öğesinin onDestroy () işlevinde stopMethodTracing () öğesini çağırın.
İkinci olarak, .trace dosyasını görüntüleyin
Saplamayı yerleştirdikten sonra, uygulamayı kurun ve işlevin algılanan bölümünü çalıştırın ve ardından dosyayı AS veya izleme görünümü aracılığıyla görüntüleyebilirsiniz.
Görüntülemek için AS'yi kullanın
Android Dosya Gezgini'ni açmak için AS'de Görünüm Aracı Windows-Android Dosya Gezgini'ne tıklayın:
Oluşturulan .trace dosyasını / sdcard / Android / data // files altında bulabilir ve dosyayı çift tıklayarak açabilirsiniz.
.Trace dosyasını bilgisayarınıza kaydedin ve görünümü doğrudan açmak için doğrudan AS penceresine sürükleyin.
Açılan görünümde, sol üstte görüntülemek istediğiniz diziyi seçebilirsiniz. İzleme süresi boyunca belirtilen iş parçacığının ne kadar süredir çalıştığını, hangi yöntemlerin yürütüldüğünü, her yöntemin ne kadar süreyle çalıştırıldığını vb. Görüntüleyebilirsiniz.
Açıklanması gereken 4 terim vardır:
- Duvar Saati Zamanı: Gerçek geçen zamanı temsil eden duvar saati zamanı, yani iş parçacığının aktif veya hareketsiz olmasına bakılmaksızın, bir yönteme girmeden yöntemden çıkmaya kadar geçen süre.
- İş parçacığı süresi: İş parçacığı süresi, bu, gerçek geçen süre eksi iş parçacığının CPU kaynaklarını tüketmediği süre anlamına gelir (uyku). Herhangi bir işlev için, iş parçacığı süresi her zaman duvar saati süresinden daha küçük veya ona eşittir. İş parçacığı süresinin kullanılması, iş parçacığının gerçek CPU kullanımının belirli bir işlev tarafından tüketildiğini daha iyi anlamanıza olanak tanır.
- Kapsayıcı Süre: Yöntemin kendi kodunu yürütme zamanı + alt yöntemini yürütme zamanı.
- Özel Zaman: Yöntemin kendi kodunu çalıştırma zamanı.
Görüntülemek için izleme görünümünü kullanın
İzleme görünümüyle görüntülemek için önce .trace dosyasını bilgisayarınıza kaydetmeniz gerekir:
adb pull /sdcard/Android/data//files/sample.trace D: \ Documents \ sample.traceAndroid Device Monitor'ü açın. AS3.0'ın önceki sürümü, LogCat'in bulunduğu penceredir ve ardından sekme sayfasını değiştirir. AS3.0'dan sonra android-sdk / tools / yolunu girin ve aşağıdaki komutu çalıştırın:
monitör
Android Device Monitor'ün DDMS'sinde Dosya Gezgini de bulunsa da, yukarıdaki yol köklü olmayan bir cep telefonunda görüntülenemez, bu nedenle .trace dosyasını görüntülemek için yalnızca bilgisayara kaydedebilirsiniz.
Android Cihaz İzleyicisi'nde sırasıyla Dosya Aç'ı tıklayın ve açmak için .trace dosyasının yolunu seçin:
İçerik, AS açıldığında olana benzer, asıl fark, AS'nin Çağrı Grafiğinin sezgisel görüntüsü olmadan simge kısmıdır.
Ayrıca 4 kavram vardır:
1. CPU Süresi: AS'deki İş Parçacığı süresine eşdeğerdir.
2. Gerçek Zaman: AS'deki Duvar Saati Zamanına eşdeğerdir.
3. Kapsayıcı Süre: AS ile aynı.
4. Exclusive Time: AS ile aynı.
Görüntülemek için görüntülemek veya izlemek için AS'yi kullanın
Bu bir görüş meselesi.Kişisel tecrübelerime göre, görüntülemek için AS kullanılması tavsiye edilir. Bunun iki nedeni var:
AS daha basittir. ADM'yi ayrı olarak açmaya gerek yoktur ve .trace dosyasını bilgisayara kaydetmeye gerek yoktur.
AS'nin çağrı şeması daha sezgiseldir ve cpu zamanının tüketimi bir bakışta nettir.
Çağrı Grafiğinin yatay ekseni, işlev çağrısının (veya arayanın) zaman periyodunu ve zamanını temsil eder ve aranan uç, dikey eksen boyunca görüntülenir. Aşağıdaki şekil, bir çağrı grafiği örneğini gösterir ve belirli bir işlev için öz zaman, çocuk zamanı ve toplam süre kavramlarını tasvir eder.
Unutulmaması gereken son bir nokta, izleme ve analiz işlemi sırasında uygulamanın çalışma hızının yavaşlayacağıdır. Bu nedenle, izleme görüntüleme ile elde edilen analiz verileri, gerçek uygulamadaki belirli bir yöntemin mutlak zamanını doğru bir şekilde yansıtmaz. Bu noktayla ilgili olarak son notlarda detaylı bir analiz yapacağız.
Google ayrıca, analizin çalışma zamanı performansı üzerindeki etkisini azaltmak için örnek tabanlı analiz sağlar. Örnek analizini etkinleştirmek için Debug.startMethodTracingSampling () yöntemini çağırın (Debug.startMethodTracing () yöntemini değil). Sistem, stopMethodTracing () çağrılana kadar periyodik olarak örnek toplar.
CPU Profiler nasıl kullanılır
İşlev izleme için CPU Profiler'ı kullanmak, izleme görüntülemeden daha kolaydır. Herhangi bir kod yerleştirmeye gerek yok, işte kısa bir giriş:
İlk geçiş
View-Tool Windows-Android Profiler Android Profiler'ı açın. Telefon bilgisayara bağlandıktan ve uygulamayı çalıştırdıktan sonra, Android Profiler'da aşağıdaki görünümü göreceksiniz:
Sol üst köşede, cihazları ve işlemleri seçebilir ve CPU Profiler görünümüne girmek için CPU alanına tıklayabilirsiniz:
İzleme modu sol üst köşeden seçilebilir:
Örneklenmiş: Uygulamanın çağrı yığınını varsayılan örnekleme hızında yakalayın. Bu modla ilgili doğal sorun, uygulama bir yakalamadan sonra bir işleve girerse ve sonraki yakalamadan önce işlevden çıkarsa, analizörün işlev çağrısını kaydetmemesidir. Bu tür kısa süreli izleme işlevleriyle ilgileniyorsanız, "Aletli" izlemeyi kullanabilirsiniz.
Aletli: Her işlev çağrısının başında ve sonunda zaman damgasını kaydetmek için. İşlev izleme verilerini oluşturmak için zaman damgalarını analiz edin ve karşılaştırın. Bir işlevle ilişkili ek yükün ayarlanmasının çalışma zamanı performansını etkileyeceği ve hatta verileri analiz edeceği unutulmamalıdır.Bu, görece kısa yaşam döngüsüne sahip işlevler için daha açıktır. Ek olarak, uygulama kısa sürede çok sayıda işlevi yürütürse, analizör dosya boyutu sınırını hızla aşabilir ve daha fazla izleme verisi kaydedilemez.
Konfigürasyonları düzenle: Örnekleme oranını özelleştirin. İzleme görünümünde Debug.startMethodTracingSampling () 'e benzer.
.Trace dosyasının boyutu sınırlıdır. Belirli bir kayıt için, analizör bu limite ulaştığında, AS yeni veri toplamayı durdurur (ancak bu, kaydı durdurmaz). "Aletli" izleme gerçekleştirilirken, bu genellikle daha hızlı gerçekleşir çünkü bu tür izleme, "Örneklenmiş" izlemeye göre daha kısa sürede daha fazla veri toplar.
Android 8.0 (API 26) veya daha yüksek bir cihaz kullanıyorsanız, izleme verilerinin dosya boyutunda herhangi bir sınır yoktur ve bu değer göz ardı edilebilir. Ancak, AS'nin büyük izleme dosyalarını ayrıştırmakta güçlük çekebileceğinden, her kayıttan sonra cihazın ne kadar veri topladığına yine de dikkat etmeniz gerekir.
Yukarıdaki "Kaydı Başlat" düğmesini tıklayın ve ardından uygulamada izlenmekte olan işlevi gerçekleştirin ve tamamlandığında "Kaydı Durdur" düğmesini tıklayın. CPU Profiler, verileri analiz etmeye ve oluşturmaya otomatik olarak başlayacaktır.
Yukarıdakiler, CPU Profiler'ın ve izleme görünümünün nasıl kullanılacağıdır. Bir optimizasyon planının nasıl formüle edileceğine gelince, başlamaz ve tamamen sabit bir yol yoktur. Benim durumumdaki onRebuild () yöntemi söz konusu olduğunda, yüzlerce sıralı yapım sürecini eşzamanlı yürütme için 5 iş parçacığına bölen ve ardından verileri sırayla birleştiren, zaman alan Kontak oluşturma süreci için paralel bir süreçtir. Tek iş parçacığında. Sonunda, onRebuild () yürütme hızı 15 saniyeden 2,5 saniyeye çıktı, bu benim için fazlasıyla yeterliydi.
Önemli Not
İşlev izleme için izleme görünümünü veya CPU Profiler'ı kullanıyor olsanız da, dikkat edilmesi gereken bir şey vardır: izleme analizi işlemi sırasında uygulamanın çalışma hızı yavaşlayacaktır. Bu nedenle, analiz verileri, bir yöntemin gerçekten yürütüldüğü mutlak zamanı doğru bir şekilde yansıtmaz. Projede onRebuild (boolean) yöntemini optimize ettiğimde kaydedilen 4 veri kümesi aşağıdadır. Bunları karşılaştıralım:
Gerçek yürütme süresi: Günlüğün, analiz modu etkinleştirilmeden normal işlem altında yazdırılmasıyla elde edilen gerçek yürütme süresi.
Profiler istatistiksel süresi: yürütme süresini analiz etmek için CPU Profiler'ı kullanın.
İzleme istatistiksel süresi: İzleme görüntüleme tarafından oluşturulan .trace dosyası analiz edilerek elde edilen yürütme süresi.
İzleme gerçek süresi: İzleme görüntüleme kullanılması durumunda, günlüğün yazdırılmasıyla elde edilen gerçek yürütme süresi.
İzleme için neden iki kez var? Bunun nedeni, test sırasında, izleme görüntüleme ile otomatik olarak analiz edilen sürenin gerçek yürütme süresinden daha yavaş olmadığı, ancak çok daha hızlı olduğu tespit edilmiştir. Şüpheye göre, izleme etkinleştirildiğinde gerçek zaman aşağıdaki kodla ölçülmüştür. Bu gerçekten daha iyi Gerçek yürütme süresi yavaştır.
Debug.startMethodTracing ("smssdk_onrebuild"); long curr = System.currentTimeMillis (); onRebuild (true); Log.d (TAG, "onRebuild lasts:" + (System.currentTimeMillis () - curr)); Debug.stopMethodTracing ( );
Yukarıdaki tablodaki verilerden, ister CPU Profiler ister izleme olsun, zaman istatistiklerinin gerçek yürütme süresini doğru bir şekilde temsil edemediği görülebilir. Dahası, izleme modunda otomatik olarak analiz edilen veriler ile izleme modundaki gerçek zaman arasında büyük bir fark var.Bu noktada ayrıntılı bir açıklama bulamadım.Birisi biliyorsa, umarım bana bildirebilirsiniz.
İzleme analizi ile elde edilen zaman gerçek zamanı temsil edemeyeceğinden, bu veriler işe yaramaz mı? Tabii ki değil! En az iki yönden değerlidirler:
- Bir test ile elde edilen verilerde, bir iş parçacığındaki her yöntemin yürütülmesi için harcanan zaman, tüm iş parçacığının yürütme zamanındaki belirli bir referans değerini hesaba katar. Yüksek orana sahip yöntem, optimizasyonun temel amacı olmalıdır.
- Optimizasyondan önceki ve sonraki iki incelemeden elde edilen veriler, optimizasyon şemasının gerçekten etkili olup olmadığını doğrulamak için karşılaştırmalı değere sahiptir.
Bu araçlar aracılığıyla izleme işlevleri yalnızca göreceli bir referans olarak kullanılabilir ve işlevin performansını tam olarak yansıtamaz. Örneğin, CPU Profiler aracılığıyla elde ettiğim onRebuild () yönteminin analiz verileri, iletişim oluşturma yönteminin tüm yürütme süreci boyunca yaklaşık% 60'lık bir paya sahip olduğunu ve Contact.toString () yönteminin yaklaşık% 40'lık bir paya sahip olduğunu, ancak aslında onRebuild () yönteminin Tüketilen 15 saniyede, Contact.toString () yalnızca yüz milisaniye tüketir ve zamanın% 90'ından fazlası, yapım yöntemi tarafından tüketilir, bu da CPU Profiler'ın izleme sürecinin Contact.toString'in performansı üzerinde daha büyük bir etkiye sahip olduğunu gösterir. etkiler.
Ancak aynı sorun, izleme incelemesinin analiz sonuçlarında ortaya çıkmadı.
Lütfen CPU Profiler ve traceview'in aynı anda kullanılamayacağını unutmayın.Koda enstrümantasyon kodu implante edilirse, CPU Profiler'ın kaydı normal şekilde başlatmamasına veya durdurmamasına neden olabilir.
İzleme görüntüleme ve CPU Profiler karşılaştırması
Kullanım açısından bakıldığında, izleme görüntüleme CPU Profiler'dan biraz daha karmaşıktır. Önce .hprof yığın dökümü dosyasını edinmesi gereken MAT'a benzer şekilde, izleme görüntülemenin önce .trace dosyasını alması ve ardından dosyayı analiz etmek için izleme görünümünü kullanması gerekir. CPU Profiler, uygulamayı doğrudan analiz edebilir.
Oluşturulan son grafikten yola çıkarak, CPU Profiler tarafından oluşturulan grafikler, iş parçacığında hangi işlevlerin çalıştırıldığını, işlevin yürütme zamanını, çağrı yığınını vb. Bir bakışta ve herhangi bir işlevde çok canlı bir şekilde gösterebilen Çağrı Grafiği ve Alev Grafiğini içerir. Sağ tıklayın, doğrudan ilgili koda atlayabilirsiniz, ki bu çok rahattır.Bu noktada, traceview'den daha iyidir.
[Ekli] Alakalı mimari video materyalleri
Bilgi koleksiyonu
Takip edin + özel mesajı ücretsiz olarak "Android bilgileri" yanıtlayın!
Önceki Android gelişmiş mimari malzemelerine, kaynak koduna, notlarına ve videolarına erişim sağlayın. Gelişmiş UI, performans optimizasyonu, mimarlık kursu, NDK, hibrit geliştirme (ReactNative + Weex) WeChat uygulaması, Flutter çok yönlü Android gelişmiş uygulama teknolojisi
