GPU Oluşturma Profilini Oluşturma aracı, oluşturma ardışık düzeninin her aşamasının önceki kareyi oluşturmak için geçen göreceli süreyi gösterir. Bu bilgiler, uygulamanızın oluşturma performansını artırmak için optimizasyon yapabilmeniz amacıyla ardışık düzendeki performans sorunlarını belirlemenize yardımcı olabilir.
Bu sayfada, her ardışık düzen aşamasında neler olduğu kısaca açıklanmakta ve performans sorunlarına neden olabilecek sorunlar ele alınmaktadır. Bu sayfayı okumadan önce GPU oluşturma hızını profilleme başlıklı makalede sunulan bilgiler hakkında bilgi sahibi olmanız 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ı incelemek faydalı olabilir.
Görsel gösterim
Profil GPU oluşturma aracı, aşamaları ve göreli sürelerini grafik şeklinde (renk kodlu histogram) gösterir. Şekil 1'de bu tür bir gösterim örneği verilmiştir.
Profil GPU Oluşturma grafiğinde gösterilen her dikey çubuğun her segmenti, işlem hattının bir aşamasını temsil eder ve çubuk grafikte belirli bir renkle vurgulanır. Şekil 2'de, gösterilen her rengin anlamını açıklayan bir anahtar gösterilmektedir.
Her rengin ne anlama geldiğini anladıktan sonra, uygulamanızın belirli yönlerini hedefleyerek oluşturma performansını optimize etmeye çalışabilirsiniz.
Aşamalar ve anlamları
Bu bölümde, her aşamada neler olduğu ve dikkat edilmesi gereken darboğaz nedenleri açıklanmaktadır.
Giriş işleme
İşlem hattının giriş işleme aşaması, uygulamanın giriş olaylarını işlemek için ne kadar süre harcadığını ölçer. Bu metrik, uygulamanın giriş etkinliği geri çağırmaları sonucunda çağrılan kodu yürütmek için ne kadar zaman 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ında çok fazla veya çok karmaşık iş yapılmasından kaynaklanır. Bu geri çağırmalar her zaman ana iş parçacığında gerçekleştiğinden bu sorunun çözümleri, çalışmayı doğrudan optimize etmeye veya çalışmayı farklı bir iş parçacığına aktarmaya odaklanır.
LazyColumn veya LazyRow arasında kaydırma da bu aşamada görünebilir. Bir kullanıcı dokunuşu kaydırma olarak nitelendirildikten sonra, tembel liste, öğeleri dinamik olarak oluşturmak ve yerleştirmek için dokunma etkinliklerini kullanır. Uygulamanız kaydırma konumundaki değişikliklere yanıt veren özel bir işlem gerçekleştiriyorsa kare düşmelerini önlemek için bu işlemi mümkün olduğunca hızlı yapmanız önemlidir. Android Studio'daki CPU Profiler veya Perfetto gibi profil oluşturma araçları, daha ayrıntılı inceleme yapmanıza yardımcı olabilir. Daha fazla bilgi için Sistem izlemeye genel bakış başlıklı makaleyi inceleyin.
Animasyonlar
Animasyonlar aşaması, o karede çalışan tüm animasyon durumlarının değerlendirilmesinin ne kadar sürdüğünü gösterir. Compose'daki bazı yaygın animasyon API'leri animate*AsState, Transition ve Animatable'dır.
Ayrıca, anlık görüntü durumundaki değişiklikleri işlemek ve kompozisyonları güncellemek için bu aşamada Recomposer çalışır. Bu nedenle, yeniden oluşturma ek yükü genellikle doğrudan animasyon aşamasında ortaya çıkar.
Jetpack Compose kullanıcı arayüzleri için sistem etkinliklerinin yanı sıra ayrıntılı kompozisyon izlerini görmek üzere Compose Runtime Tracing kitaplığını ekleyin.
Bu segment büyük olduğunda
Bu alandaki yüksek değerler genellikle animasyonun neden olduğu durum değişiklikleri nedeniyle yürütülen çalışmalardan kaynaklanır. Örneğin, LazyColumn veya LazyRow öğenizi kaydıran bir hızlı kaydırma animasyonu, yeni liste öğelerinin hızlı bir şekilde oluşturulmasına, ölçülmesine ve ayrılmasına neden olur.
Ölçüm
Android, composable'larınızı ekranda çizmek için kullanıcı arayüzü ağacınızdaki düzen düğümlerinde üç aşama yürütür.
İlk olarak sistem, düzen düğümlerini ölçer. Her composable'ın, ekrandaki nesnenin boyut sınırlarını açıklayan belirli kısıtlamaları ve değiştiricileri vardır. Bazı composable'lar belirli ve sabit bir boyuta sahip olabilir. Diğerleri ise üst yerleşim kapsayıcısı tarafından aktarılan kısıtlamalara uyum sağlayan bir boyuta sahiptir.
İkinci olarak, sistem düzen düğümlerini yerleştirir. Compose, ölçüm aşamasında alt düğümlerin boyutlarını hesapladıktan sonra yerleştirme aşamasına geçebilir. Bu aşamada, düzen düğümlerini ekranda boyutlandırır ve konumlandırır.
Sistem, verimlilik için her zaman bu tek geçişli düzeni uygular. Bir composable düzen geçersiz kılındığında Compose, söz konusu düğümü ölçer ve yalnızca alt öğe boyutunu veya kısıtlamalarını değiştirirse düzen güncellemelerini üst hiyerarşilere yayar.
Bu segment büyük olduğunda
Bu alandaki büyük bir segment, uygulamanın düzen aşamasında çok fazla zaman harcadığı anlamına gelir. Bu aşama, düzen düğümlerinin konumlandırılması ve boyutunun belirlenmesinden oluşur. Bu işlemler arasında, düzen ağacı aşırı karmaşıksa kare hazırlığını geciktirebilecek composable'lar için ölçüm ve yerleştirme değiştiricilerinin yürütülmesi yer alır. Bu gibi durumlarda, performansı ele almak için Compose uygulamanızın karşılaştırmasını yapmanız ve performansla ilgili en iyi uygulamaları uygulamanız gerekir.
Düzen geçişlerini incelemek ve darboğazları belirlemek için Android Studio'da CPU Profiler'ı veya Perfetto'yu kullanın. Daha fazla bilgi için Sistem izlemeye genel bakış konusuna bakın.
Çiz
Çizim aşaması, arka plan, şekil veya metin çizme gibi oluşturma işlemlerini yerel çizim komutları dizisine dönüştürür. Sistem, bu komutları GPU yürütmesi için bir görüntüleme listesine alır.
Çizim çubuğu, komutların ekran listesine alınmasının ne kadar sürdüğünü kaydeder. Bu süre, bu kare için ekranda güncellenmesi gereken tüm düzen düğümleri için geçerlidir. Ölçülen süre, çizim değiştiricilerde veya bir Canvas composable'da bulunan özel çizim mantığı için de geçerlidir.
Bu segment büyük olduğunda
Basit bir ifadeyle bu metriğin, geçersiz kılınan her düzen düğümü için tüm çizim komutlarının ne kadar sürede çalıştırıldığını gösterdiğini düşünebilirsiniz.
Bu ölçüm, bu komutların alt düğümlere ve vektör çizilebilir öğelere gönderilmesi için harcanan tüm süreleri içerir. Bu nedenle, bu çubuğun yükseldiğini gördüğünüzde bunun nedeni, birçok composable'ın aniden geçersiz hale gelmesi olabilir. Geçersiz kılma, çizim komutlarının yeniden yürütülmesini ve düzen düğümlerinin görüntüleme listelerinin yeniden oluşturulmasını gerektirir. Alternatif olarak, uzun süre, DrawScope
uygulamalarında son derece karmaşık bir mantığa sahip birkaç özel composable veya canvas'tan kaynaklanabilir.
Ayrıca Compose, dahili ölçü ve düzen geçişlerini genellikle platformun Çizim aşaması olarak kabul ettiği süre içinde gerçekleştirir. Sonuç olarak, yüksek bir çizim çubuğu, yalnızca çizim komutlarından ziyade pahalı veya aşırı dahili ölçü/düzen işlemleri nedeniyle oluşabilir. Şüpheye düştüğünüzde, ek yükün çizim rutinlerinden mi yoksa Compose ölçme ve düzen geçişlerinden mi kaynaklandığını görmek için Perfetto izi yakalayın.
Yükleyin
Yükleme metriği, geçerli kare sırasında bitmap nesnelerinin CPU belleğinden GPU belleğine aktarılması için gereken süreyi gösterir.
CPU ve GPU gibi farklı işlemciler, işlemeye ayrılmış farklı RAM alanlarına sahiptir. Android'de bir bit eşlem çizdiğinizde sistem, GPU'nun bit eşlemi ekrana işlemesinden önce bit eşlemi GPU belleğine aktarır. Ardından, doku GPU doku önbelleğinden çıkarılmadığı sürece sistemin verileri tekrar aktarması gerekmemesi için GPU, bit eşlemi önbelleğe alır.
Not: Lollipop cihazlarda bu aşama mor renktedir.
Bu segment büyük olduğunda
Bir karenin tüm kaynaklarının, kare çizmek için kullanılabilmesi için önce GPU belleğinde bulunması gerekir. Bu nedenle, bu metrik için yüksek bir değer, çok sayıda küçük kaynak yüklemesi veya az sayıda çok büyük kaynak anlamına gelebilir. Uygulamanın, ekran boyutuna yakın tek bir bit eşlem görüntülemesi yaygın bir durumdur. Bir diğer durum da bir uygulamanın çok sayıda küçük resim göstermesidir.
Bu çubuğu küçültmek için aşağıdaki gibi teknikler kullanabilirsiniz:
- Bit eşlem çözünürlüklerinizin, gösterilecekleri boyuttan çok daha büyük olmadığından emin olun. Örneğin, 1024x1024 boyutundaki bir resmi 48x48 boyutunda göstermeyin.
- Bir sonraki senkronizasyon aşamasından önce bit eşlemi eşzamansız olarak önceden yüklemek için Coil gibi modern kitaplıklardan yararlanma.
Komut yayınlama
Komut verme segmenti, ekran listelerinin ekrana çizilmesi için gereken tüm komutların verilmesinin ne kadar sürdüğünü gösterir.
Sistemin, ekran listelerini ekrana çizmesi için gerekli komutları GPU'ya göndermesi gerekir. Bu işlem genellikle OpenGL ES API üzerinden gerçekleştirilir.
Sistem, komutu GPU'ya göndermeden önce her komut için son dönüştürme ve kırpma işlemlerini gerçekleştirdiğinden bu işlem biraz zaman alır. Ardından, son komutları hesaplayan GPU tarafında ek yük oluşur. Bu komutlar, son dönüşümleri ve ek kırpmayı içerir.
Bu segment büyük olduğunda
Bu aşamada harcanan süre, sistemin belirli bir karede oluşturduğu görüntüleme listelerinin karmaşıklığının ve miktarının doğrudan bir ölçüsüdür. Örneğin, özellikle her çizim öğesinin küçük bir maliyeti olduğu durumlarda çok sayıda çizim işlemi yapmak bu süreyi uzatabilir. Örneğin:
for (i in 0 until 1000) { canvas.drawPoint() }
aşağıdakilere kıyasla çok daha pahalıdır:
canvas.drawPoints(thousandPointArray)
Komut verme ile ekran listelerini çizme arasında her zaman bire bir ilişki yoktur. Çizim komutlarını GPU'ya göndermek için gereken süreyi yakalayan sorun komutları çubuğunun aksine, çizim metriği, verilen komutların görüntüleme listesine yakalanması için gereken süreyi gösterir.
Bu farkın nedeni, görüntüleme listelerinin mümkün olduğunda sistem tarafından önbelleğe alınmasıdır. Sonuç olarak, kaydırma, dönüştürme veya animasyonun, sistemin bir görüntü listesini yeniden göndermesini gerektirdiği ancak aslında sıfırdan yeniden oluşturmasını (çizim komutlarını yeniden yakalamasını) gerektirmediği durumlar vardır. Bu nedenle, yüksek sayıda çizim komutu çubuğu görmeden yüksek sayıda sorun komutu çubuğu görebilirsiniz.
Tamponları değiştirme
Android, görüntüleme listesini GPU'ya göndermeyi tamamladığında sistem, grafik sürücüsüne mevcut kareyle işinin bittiğini bildiren son bir komut gönderir. Bu noktada sürücü, güncellenen görüntüyü ekrana sunabilir.
Bu segment büyük olduğunda
GPU'nun, CPU ile paralel olarak çalıştığını anlamak önemlidir. Android sistemi, GPU'ya çizim komutları gönderir 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 bunları kullandığından daha hızlı gönderdiği durumlarda, işlemciler arasındaki iletişim sırası dolabilir. Bu durumda CPU, bir sonraki komutu yerleştirmek için kuyrukta yer açılana kadar engeller ve bekler. Bu tam kuyruk durumu genellikle arabellek değiştirme aşamasında ortaya çıkar. Bunun nedeni, bu noktada bir karenin tamamı kadar komutun gönderilmiş olmasıdır.
Bu sorunu azaltmanın anahtarı, GPU'da gerçekleşen işin karmaşıklığını, sorun komutları aşamasında yapacağınız gibi azaltmaktır.
Çeşitli
Oluşturma sisteminin işini yapması için gereken süreye ek olarak, ana iş parçacığında gerçekleşen ve oluşturmayla ilgisi olmayan ek bir iş grubu vardır. Bu çalışmanın tükettiği süre, çeşitli zaman olarak raporlanır. Çeşitli süre genellikle oluşturmanın iki ardışık karesi arasında kullanıcı arayüzü iş parçacığında gerçekleşen çalışmayı ifade eder.
Bu segment büyük olduğunda
Bu değer yüksekse uygulamanızda geri çağırmalar, amaçlar veya başka bir iş parçacığında gerçekleşmesi gereken başka işlemler olabilir. Android Studio'daki CPU Profiler veya Perfetto gibi araçlar, ana iş parçacığında çalışan görevler hakkında görünürlük sağlayabilir. Bu bilgiler, performans iyileştirmelerini hedeflemenize yardımcı olabilir. Daha fazla bilgi için Sistem izlemeye genel bakış konusuna bakın.