Profil GPU Oluşturma aracı, oluşturma ardışık düzeninin her aşamasının önceki kareyi oluşturmak için gereken göreli süreyi belirtir. Bu bilgi, ardışık düzendeki performans sorunlarını tanımlamanıza yardımcı olabilir. Böylece, uygulamanızın oluşturma performansını iyileştirmek için neleri optimize etmeniz gerektiğini bilirsiniz.
Bu sayfada, ardışık düzen aşamalarında neler olduğu kısaca açıklanmakta ve burada performans sorunlarına neden olabilecek sorunlar açıklanmaktadır. Bu sayfayı okumadan önce, Profil GPU oluşturma bölümünde sunulan bilgileri öğrenmeniz gerekir. Ayrıca, tüm aşamaların nasıl bir araya geldiğini anlamak için oluşturma ardışık düzeninin nasıl çalıştığını incelemeniz faydalı olabilir.
Görsel temsil
Profil GPU Oluşturma aracı, aşamaları ve göreli zamanlarını grafik biçiminde, yani renk kodlu bir histogram gösterir. Şekil 1'de böyle bir ekran örneği gösterilmektedir.
![](https://developer.android.com/static/topic/performance/images/bars.png?authuser=5&hl=tr)
Şekil 1. Profil GPU Oluşturma Grafiği
Profil GPU Oluşturma grafiğinde görüntülenen her bir dikey çubuğun her bir segmenti, ardışık düzenin bir aşamasını temsil eder ve çubuk grafikte belirli bir renk kullanılarak vurgulanır. Şekil 2'de, görüntülenen her bir rengin anlamını belirten bir anahtar gösterilmektedir.
![](https://developer.android.com/static/topic/performance/images/s-profiler-legend.png?authuser=5&hl=tr)
2. Şekil. Profil GPU Oluşturma Grafiği Açıklaması
Her bir rengin neyi belirttiğini anladığınızda, oluşturma performansını optimize etmek için uygulamanızın belirli yönlerini hedefleyebilirsiniz.
Aşamalar ve anlamları
Bu bölümde, Şekil 2'deki bir renge karşılık gelen her aşamada neler olduğu ve dikkat edilmesi gereken performans sorunu nedenleri açıklanmaktadır.
Giriş işleme
Ardışık düzenin giriş işleme aşaması, uygulamanın giriş etkinliklerini ne kadar süreyle işlediğini ölçer. Bu metrik, uygulamanın giriş etkinliği geri çağırmalarının sonucu olarak çağrılan kodu yürütmek için ne kadar süre harcadığını gösterir.
Bu segment büyük olduğunda
Bu alandaki yüksek değerler genellikle giriş işleyici etkinlik geri çağırmaları içinde gerçekleşen çok fazla iş veya çok karmaşık iş nedeniyle ortaya çıkar. Bu geri çağırmalar her zaman ana iş parçacığında meydana geldiği için bu sorunun çözümleri, doğrudan işi optimize etmeye veya işi farklı bir iş parçacığına yüklemeye odaklanır.
RecyclerView
kaydırma özelliğinin bu aşamada görünebileceğini de unutmamak gerekir.
RecyclerView
, dokunma etkinliğini kullandığında hemen kaydırır. Sonuç olarak,
yeni öğe görünümlerini artırabilir veya doldurabilir. Bu nedenle bu işlemi mümkün
olduğunca hızlı yapmak önemlidir. Traceview veya Systrace gibi profil oluşturma
araçları, daha ayrıntılı araştırma yapmanıza yardımcı olabilir.
Animasyonlar
Animasyonlar aşaması, o karede çalışan tüm animatörleri değerlendirmenin ne kadar sürdüğünü gösterir. En yaygın animatörler ObjectAnimator
, ViewPropertyAnimator
ve Geçişler'dir.
Bu segment büyük olduğunda
Bu alandaki yüksek değerler genellikle animasyonun bazı özellik değişiklikleri nedeniyle yürütülen işin bir sonucudur. Örneğin, ListView
veya RecyclerView
sayfanızı kaydıran bir hızlıca kaydırma animasyonu, görüntüleme sayısında bir artışa ve nüfusa neden olur.
Ölçüm/düzen
Android, görünüm öğelerinizi ekrana çizmek için görünüm hiyerarşinizdeki düzenlerde ve görünümlerde iki özel işlem gerçekleştirir.
İlk olarak, sistem görüntüleme öğelerini ölçer. Her görünüm ve düzende, ekrandaki nesnenin boyutunu açıklayan belirli veriler bulunur. Bazı görünümlerin belirli bir boyutu olabilir, bazılarının ise üst düzen kapsayıcısının boyutuna uyum sağlayan bir boyutu vardır.
İkinci olarak, sistem görünüm öğelerini ortaya koyar. Sistem, alt öğelerin görüntülemelerinin boyutlarını hesapladıktan sonra ekrandaki görünümlerin boyutunu ve konumlandırmasını öğrenerek düzene devam edebilir.
Sistem, yalnızca çizilecek görünümler için değil, aynı zamanda kök görünüme kadar bu görünümlerin üst hiyerarşileri için de ölçüm ve düzen gerçekleştirir.
Bu segment büyük olduğunda
Uygulamanız bu alanda kare başına çok fazla zaman harcıyorsa bunun nedeni genellikle düzenlenmesi gereken görüntüleme sayısının çok yüksek olması veya hiyerarşinizde yanlış noktada çift vergilendirme gibi sorunlardır. Her iki durumda da, performansın ele alınması görünüm hiyerarşilerinizin performansını iyileştirmeyi içerir.
onLayout(boolean, int, int, int, int)
veya onMeasure(int, int)
öğelerine eklediğiniz kod da performans sorunlarına neden olabilir. Traceview ve Systrace, kodunuzun sahip olabileceği sorunları tespit etmek için çağrı yığınlarını incelemenize yardımcı olabilir.
Çiz
Çizim sahnesi, bir görünümün oluşturma işlemlerini (ör. arka plan çizme veya metin çizme) bir yerel çizim komutları dizisine dönüştürür. Sistem bu komutları bir görüntüleme listesine kaydeder.
Çizim çubuğu, bu karede ekranda güncellenmesi gereken tüm görünümler için komutların görüntüleme listesine alınmasının ne kadar sürdüğünü kaydeder. Ölçülen süre, uygulamanızdaki kullanıcı arayüzü nesnelerine eklediğiniz tüm kodlar için geçerlidir. Bu tür kodlara örnek olarak onDraw()
, dispatchDraw()
ve Drawable
sınıfının alt sınıflarına ait çeşitli draw ()methods
verilebilir.
Bu segment büyük olduğunda
Basitçe açıklamak gerekirse bu metriği, geçersiz kılınan her görünüm için tüm onDraw()
çağrılarının ne kadar sürdüğünü göstererek anlayabilirsiniz. Bu ölçüm, çocuklara çizim komutları göndermek için harcanan tüm süreyi ve mevcut olabilecek çizimleri içerir. Bu nedenle, bu çubuğun ani bir şekilde yükseldiğini gördüğünüzde birçok görüntülemenin
aniden geçersiz hale gelmesinin nedeni olabilir. Geçersiz kılma işlemi, görünümlerin görüntüleme listelerinin yeniden oluşturulmasını gerektirir. onDraw()
yöntemlerinde son derece karmaşık mantık bulunan birkaç özel görünüm de uzamaya devam edebilir.
Senkronize et/yükle
Senkronize Et ve Yükle metriği, geçerli kare sırasında bit eşlem nesnelerinin CPU belleğinden GPU belleğine aktarılması için geçen süreyi gösterir.
Farklı işlemciler olarak CPU ve GPU'nun işlemeye ayrılmış farklı RAM alanları vardır. Android'de bir bit eşlem çizdiğinizde, GPU'nun ekranı oluşturabilmesi için sistem bit eşlemi GPU belleğine aktarır. Daha sonra GPU, bit eşlemi önbelleğe alır. Böylece, doku GPU doku önbelleğinden çıkarılmadığı sürece sistemin verileri tekrar aktarmasına gerek kalmaz.
Not: Lollipop cihazlarda bu aşama mordur.
Bu segment büyük olduğunda
Bir karenin tüm kaynaklarının, kare çizmek için kullanılmadan önce GPU belleğinde bulunması gerekir. Yani bu metrik için yüksek bir değer, çok sayıda küçük kaynak yükü veya az sayıda çok büyük kaynak anlamına gelebilir. Yaygın bir durum, bir uygulamanın ekran boyutuna yakın tek bir bit eşlem görüntülemesidir. Başka bir durum da bir uygulamanın çok sayıda küçük resim görüntülemesidir.
Bu çubuğu küçültmek için, aşağıdaki gibi teknikleri kullanabilirsiniz:
- Bit eşlem çözünürlüklerinizin, görüntülenecekleri boyuttan çok daha büyük olmadığından emin olun. Örneğin, uygulamanız 48x48 boyutunda bir resim olarak 1024x1024 bir resim görüntülemekten kaçınmalıdır.
-
Bir sonraki senkronizasyon aşamasından önce bir bit eşlemi eşzamansız olarak önceden yüklemek için
prepareToDraw()
özelliğinden yararlanın.
Sorun komutları
Sorun Komutları segmenti, görüntü listelerini ekrana çizmek için gereken tüm komutların yayınlanması için geçen süreyi temsil eder.
Sistemin ekran listelerini ekrana çizmesi için gerekli komutları GPU'ya gönderir. Genellikle bu işlemi OpenGL ES API üzerinden gerçekleştirir.
Sistem, komutu GPU'ya göndermeden önce her komut için son dönüştürme ve kırpma işlemleri yaptığından bu işlem biraz zaman alır. Daha sonra GPU tarafında ek yük oluşur ve bu işlem son komutları hesaplar. Bu komutlar, son dönüşümleri ve ek kırpma işlemlerini içerir.
Bu segment büyük olduğunda
Bu aşamada harcanan süre, sistemin belirli bir çerçevede oluşturduğu görüntülü reklam listelerinin karmaşıklığının ve miktarının doğrudan ölçüsüdür. Örneğin, çok sayıda çizim işleminin olması, özellikle de her temel çizimin doğal maliyetinin küçük olduğu durumlarda bu süreyi uzatabilir. Örneğin:
Kotlin
for (i in 0 until 1000) { canvas.drawPoint() }
Java
for (int i = 0; i < 1000; i++) { canvas.drawPoint() }
Bu yöntem, aşağıdakilerden çok daha pahalıdır:
Kotlin
canvas.drawPoints(thousandPointArray)
Java
canvas.drawPoints(thousandPointArray);
Komut verme ile gerçekte görüntüleme listesi oluşturma arasında her zaman bire bir bağlantı yoktur. Çizim komutlarının GPU'ya gönderilmesi için gereken süreyi yakalayan Sorun Komutlarının aksine Çizim metriği, yayınlanan komutların görüntü listesine alınması için geçen süreyi gösterir.
Bu farkın nedeni, mümkün olduğunda görüntüleme listelerinin sistem tarafından önbelleğe alınmasıdır. Sonuç olarak, kaydırma, dönüştürme veya animasyon için sistemin bir görüntüleme listesini yeniden göndermesini gerektiren, ancak listeyi gerçekten yeniden oluşturmak (çizim komutlarını tekrar almak) zorunda bırakmadığı durumlar vardır. Bunun sonucunda, yüksek bir Çizim komutları çubuğu olmadan yüksek bir "Sorun komutları" çubuğu görebilirsiniz.
Tamponları işleme/değiştirme
Android tüm görüntüleme listesini GPU'ya göndermeyi bitirdikten sonra, sistem grafik sürücüsüne işlemin geçerli kareyle yapıldığını bildirmek için son bir komut verir. Bu noktada, sürücü nihayet ekranda güncellenmiş görüntüyü sunabilir.
Bu segment büyük olduğunda
GPU'nun CPU'ya paralel olarak iş yürüttüğünü anlamanız önemlidir. Android sistemi, GPU'ya çizim komutları yayınlar ve ardından bir sonraki göreve geçer. GPU bu çizim komutlarını bir sıradan okur ve işler.
CPU'nun komutları GPU'nun tükettiğinden daha hızlı yayınladığı durumlarda işlemciler arasındaki iletişim sırası dolu olabilir. Böyle bir durumda CPU engellenir ve sonraki komutu yerleştirmek için sırada boş yer kalana kadar bekler. Bu tam sıra durumu, genellikle Arabellekleri Değiştirme aşamasında ortaya çıkar, çünkü bu noktada, karenin değeri kadar komut gönderilmiş olur.
Bu sorunu hafifletmenin anahtarı, "Sorun Komutları" aşamasında yapacağınıza benzer şekilde GPU'da gerçekleşen işin karmaşıklığını azaltmaktır.
Diğer
Oluşturma sisteminin işini yapması için gereken süreye ek olarak, ana iş parçacığında gerçekleşen ek bir dizi çalışma vardır ve oluşturma ile hiçbir ilgisi yoktur. Bu çalışmanın harcadığı süre yanlış zaman olarak raporlanır. Çeşitli süre, genellikle iki ardışık oluşturma çerçevesi arasında kullanıcı arayüzü iş parçacığında gerçekleşebilecek işleri temsil eder.
Bu segment büyük olduğunda
Bu değer yüksekse uygulamanızın başka bir iş parçacığında gerçekleşmesi gereken geri çağırmalar, amaçlar veya başka çalışmalar olabilir. Yöntem izleme veya Systrace gibi araçlar, ana iş parçacığında çalışan görevlere görünürlük sağlar. Bu bilgiler, performans iyileştirmelerini hedeflemenize yardımcı olabilir.