Performans değerlendirme

Bir cihazın performansını değerlendirmek için Simpleperf'i kullanın. Simpleperf, Android'deki hem uygulamalar hem de yerel süreçler için yerel bir profil oluşturma aracıdır. Uygulamanın CPU kullanımını ve ileti dizisi etkinliğini gerçek zamanlı olarak incelemek için CPU Profiler'ı kullanın.

Kullanıcıların görebildiği iki performans göstergesi vardır:

  • Öngörülebilen, algılanabilir performans. Kullanıcı arayüzü (UI) kareleri düşürüyor mu yoksa 60 FPS'de tutarlı bir şekilde oluşturuluyor mu? Ses, bozulma veya patlama olmadan çalıyor mu? Kullanıcının ekrana dokunması ile efektin ekranda gösterilmesi arasında ne kadar gecikme var?
  • Daha uzun işlemler için gereken süre (ör. uygulamaları açma).

Birincisi ikincisinden daha belirgindir. Kullanıcılar genellikle takılmaları fark eder ancak iki cihazı yan yana görmedikleri sürece uygulama başlatma süresinin 500 milisaniye mi yoksa 600 milisaniye mi olduğunu anlayamaz. Dokunma gecikmesi hemen fark edilir ve cihazın algılanmasına önemli ölçüde katkıda bulunur.

Sonuç olarak, hızlı bir cihazda kullanıcı arayüzü ardışık düzeni, kullanıcı arayüzü ardışık düzeninin çalışır durumda kalması için gerekenler dışında sistemdeki en önemli şeydir. Bu, kullanıcı arayüzü ardışık düzeninin, akıcı kullanıcı arayüzü için gerekli olmayan diğer tüm çalışmaları önceliklendirmesi gerektiği anlamına gelir. Kullanıcı arayüzü çalışmasının çalıştırılabilmesi için kullanıcı arayüzünün akıcılığını korumak amacıyla arka planda senkronizasyon, bildirim yayınlama ve benzer çalışmaların tümü geciktirilmelidir. Akışkan bir kullanıcı arayüzü sağlamak için daha uzun işlemlerin (HDR+ çalışma zamanı, uygulama başlatma vb.) performansını feda etmek kabul edilebilir.

Kapasite ve jitter

Cihaz performansı söz konusu olduğunda kapasite ve jitter iki önemli metriktir.

Kapasite

Kapasite, cihazın belirli bir süre boyunca sahip olduğu belirli bir kaynağın toplam miktarıdır. Bu, CPU kaynakları, GPU kaynakları, G/Ç kaynakları, ağ kaynakları, bellek bant genişliği veya benzer bir metrik olabilir. Sistem genelindeki performansı incelerken bileşenleri ayrı ayrı incelemek ve performansı belirleyen tek bir metrik varsaymak faydalı olabilir (özellikle yeni bir cihazı ayarlama sırasında, bu cihazda çalışan iş yükleri muhtemelen sabit olduğundan).

Bir sistemin kapasitesi, online işlem kaynaklarına bağlı olarak değişir. Kapasiteyi değiştirmenin birincil yolu CPU/GPU frekansını değiştirmektir ancak çevrimiçi CPU çekirdeği sayısını değiştirmek gibi başka yöntemler de vardır. Buna göre, bir sistemin kapasitesi güç tüketimiyle orantılıdır; kapasitenin değişmesi her zaman güç tüketiminde benzer bir değişikliğe neden olur.

Belirli bir zamanda gereken kapasite büyük ölçüde çalışan uygulama tarafından belirlenir. Sonuç olarak platform, belirli bir iş yükü için gereken kapasiteyi ayarlamak üzere çok az şey yapabilir ve bunu yapmanın yolları çalışma zamanındaki iyileştirmelerle (Android çerçevesi, ART, Bionic, GPU derleyicisi/sürücüler, çekirdek) sınırlıdır.

Gecikme dalgalanması

Bir iş yükü için gereken kapasiteyi görmek kolay olsa da jitter daha belirsiz bir kavramdır. Hızlı sistemlerin önündeki bir engel olarak jitter hakkında iyi bir giriş için The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q başlıklı makaleyi okumanızı öneririz. (Bu makale, ASCI Q süper bilgisayarının beklenen performansı neden elde edemediğini araştırıyor ve büyük sistemleri optimize etmeye harika bir giriş niteliğinde.)

Bu sayfada, ASCI Q makalesinde gürültü olarak adlandırılan durumu tanımlamak için jitter terimi kullanılmaktadır. Jitter, algılanabilir çalışmanın yapılmasını engelleyen rastgele sistem davranışıdır. Genellikle çalıştırılması gereken bir iştir ancak belirli bir zamanda çalışmasına neden olacak katı zamanlama koşulları olmayabilir. Rastgele olduğu için belirli bir iş yükü için jitter'in varlığını çürütmek son derece zordur. Ayrıca, belirli bir performans sorununun bilinen bir jitter kaynağından kaynaklandığını kanıtlamak son derece zordur. Jitter nedenlerini teşhis etmek için en yaygın olarak kullanılan araçlar (ör. izleme veya günlük kaydı), kendi jitter'lerini de ekleyebilir.

Android'in gerçek dünyadaki uygulamalarında karşılaşılan titreşim kaynakları şunlardır:

  • Planlayıcı gecikmesi
  • Kesme işleyicileri
  • Önceliklendirme veya kesintiler devre dışıyken sürücü kodunun çok uzun süre çalışması
  • Uzun süre çalışan softirq'ler
  • Kilit anlaşmazlığı (uygulama, çerçeve, çekirdek sürücüsü, bağlayıcı kilidi, mmap kilidi)
  • Düşük öncelikli bir iş parçacığının dosyanın kilidini tutarak yüksek öncelikli bir iş parçacığının çalışmasını engellediği dosya tanımlayıcı anlaşmazlığı
  • Kullanıcı arayüzü açısından kritik kodların gecikebileceği iş sıralarında çalıştırılması
  • CPU boşta geçişleri
  • Günlük kaydı
  • G/Ç gecikmeleri
  • Gereksiz işlem oluşturma (ör. CONNECTIVITY_CHANGE yayınları)
  • Yeterli boş bellek olmadığından sayfa önbelleği aşırı çalışma

Belirli bir jitter dönemi için gereken süre, kapasite arttıkça azalabilir veya azalmayabilir. Örneğin, bir sürücü bir i2c veri yolundan okuma işlemini beklerken kesintileri devre dışı bırakırsa CPU'nun 384 MHz veya 2 GHz'te olup olmadığına bakılmaksızın sabit bir süre geçer. Jitter söz konusu olduğunda kapasiteyi artırmak, performansı iyileştirmek için uygun bir çözüm değildir. Sonuç olarak, daha hızlı işlemciler genellikle jitter sınırlamalı durumlarda performansı artırmaz.

Son olarak, kapasitenin aksine jitter neredeyse tamamen sistem tedarikçisinin alanındadır.

Bellek tüketimi

Düşük performansın nedeni genellikle bellek tüketimidir. Tüketim bir performans sorunu olmasa da lowmemorykiller yükü, hizmetin yeniden başlatılması ve sayfa önbelleği taşması nedeniyle titreşime neden olabilir. Bellek tüketimini azaltmak, düşük performansın doğrudan nedenlerini önleyebilir ancak bu nedenleri önleyen başka hedeflenmiş iyileştirmeler de olabilir (örneğin, çerçevenin kısa süre sonra sayfaya ekleneceğinde sayfadan çıkarılması için çerçeveyi sabitleme).

İlk cihaz performansını analiz etme

İşlevsel ancak düşük performans gösteren bir sistemden başlayıp kullanıcı tarafından görülebilen düşük performans örneklerini tek tek inceleyerek sistemin davranışını düzeltmeye çalışmak doğru bir strateji değildir. Düşük performans genellikle kolayca yeniden üretilemez (yani titreme) veya uygulama sorunu olmadığından, sistemdeki çok fazla değişken bu stratejinin etkili olmasını engeller. Sonuç olarak, sistem genelindeki performansı düzeltmeyle ilgili sistemsel fırsatları kaçırırken nedenleri yanlış tanımlamak ve küçük iyileştirmeler yapmak çok kolaydır.

Bunun yerine, yeni bir cihazı kullanıma sunarken aşağıdaki genel yaklaşımı kullanın:

  1. Sistemin, tüm sürücülerin çalıştığı ve bazı temel sıklık denetleyici ayarlarının bulunduğu kullanıcı arayüzünde başlatılmasını sağlayın (sıklık denetleyici ayarlarını değiştirirseniz aşağıdaki tüm adımları tekrarlayın).
  2. Çekirdeğin, sched_blocked_reason izleme noktasının yanı sıra ekran ardışık düzenindeki, karenin ekrana ne zaman teslim edildiğini belirten diğer izleme noktalarını desteklediğinden emin olun.
  3. Hafif ve tutarlı bir iş yükü (ör. UiBench veya TouchLatency'teki top testi) çalıştırırken kullanıcı arayüzü ardışık düzeninin tamamının (IRQ aracılığıyla giriş almaktan nihai tarama işlemine kadar) uzun izlerini alın.
  4. Hafif ve tutarlı iş yükünde tespit edilen kare düşüşlerini düzeltin.
  5. Bir seferde 20 saniyeden uzun süre boyunca sıfır kare atlamayla çalıştırabilene kadar 3-4. adımları tekrarlayın.
  6. Kullanıcı tarafından görülebilen diğer takılma kaynaklarına geçin.

Cihazın kullanıma sunulmasının ilk aşamalarında yapabileceğiniz diğer basit işlemler şunlardır:

  • Çekirdeğinizin sched_blocked_reason tracepoint yamasının bulunduğundan emin olun. Bu izleme noktası, systrace'teki sched izleme kategorisiyle etkinleştirilir ve ilgili iş parçacığı kesintisiz uykuya girdiğinde uykuya dalmaktan sorumlu işlevi sağlar. Kesintiye uğramayan uyku, jitter'in çok yaygın bir göstergesi olduğundan performans analizi için kritik öneme sahiptir.
  • GPU ve görüntüleme ardışık düzenleri için yeterli izlemeniz olduğundan emin olun. Son Qualcomm SOC'larda, izleme noktaları aşağıdakiler kullanılarak etkinleştirilir:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    systrace'i çalıştırdığınızda bu etkinlikler etkin kalır. Böylece, mdss_fb0 bölümündeki izlemede görüntülü reklam ardışık düzeni (MDSS) hakkında ek bilgiler görebilirsiniz. Qualcomm SOC'larda standart systrace görünümünde GPU hakkında ek bilgi görmezsiniz ancak sonuçlar izlemenin kendisinde bulunur (ayrıntılar için systrace'i anlama başlıklı makaleyi inceleyin).

    Bu tür bir ekran izlemeden, ekrana bir karenin yayınlandığını doğrudan belirten tek bir etkinlik elde etmek istersiniz. Buradan, kare sürenizi başarıyla karşılayıp karşılamadığınızı belirleyebilirsiniz.Xn etkinliği, Xn-1 etkinliğinden 16,7 ms'den kısa bir süre sonra gerçekleşirse (60 Hz ekran olduğu varsayılırsa) takılma olmadığını anlayabilirsiniz. SOC'niz bu tür sinyaller sağlamıyorsa bunları almak için tedarikçinizle birlikte çalışın. Kare tamamlandığına dair kesin bir sinyal olmadan titremeyle ilgili hata ayıklama işlemi son derece zordur.

Sentetik karşılaştırmaları kullanma

Sentetik karşılaştırmalar, cihazın temel işlevlerinin mevcut olduğundan emin olmak için kullanışlıdır. Ancak karşılaştırmaları, algılanan cihaz performansının bir göstergesi olarak değerlendirmek yararlı değildir.

SOC'lerle ilgili deneyimlere göre, SOC'ler arasındaki sentetik karşılaştırma performansındaki farklılıklar, algılanabilir kullanıcı arayüzü performansında (atlanan kare sayısı, 99. yüzdelik dilim kare süresi vb.) benzer bir farkla ilişkili değildir. Sentetik karşılaştırmalar yalnızca kapasite karşılaştırmalarıdır; jitter, bu karşılaştırmaların ölçülen performansını yalnızca karşılaştırmanın toplu işleminden zaman çalarak etkiler. Sonuç olarak, sentetik karşılaştırma puanları, kullanıcı tarafından algılanan performans metriği olarak çoğunlukla alakasızdır.

1.000 kullanıcı arayüzü karesi oluşturan ve toplam oluşturma süresini bildiren (düşük puan daha iyidir) X karşılaştırmasını çalıştıran iki SOC'yi düşünün.

  • SOC 1,X karşılaştırma ölçütünün her karesini 10 ms'de oluşturur ve 10.000 puan alır.
  • SOC 2, karelerin% 99'unu 1 ms'de, %1'ini ise 100 ms'de oluşturur ve 19.900 puan alır. Bu, çok daha iyi bir puandır.

Karşılaştırma, gerçek kullanıcı arayüzü performansını gösteriyorsa SOC 2 kullanılamaz. 60 Hz yenileme hızı varsa SOC 2'de her 1, 5 saniyede bir sarsıntılı kare olur. Bu sırada SOC 1 (X karşılaştırmasına göre daha yavaş SOC), sorunsuz bir şekilde çalışır.

Hata raporlarını kullanma

Hata raporları bazen performans analizi için yararlı olsa da çok ağır olduklarından ara sıra yaşanan takılma sorunlarını düzeltmek için nadiren yararlıdır. Özellikle de takılma, uygulama geçişi sırasında gerçekleşiyorsa (bu durum bir hata raporuna kaydedilir) sistem belirli bir zamanda ne yapıyordu konusunda bazı ipuçları verebilir. Hata raporları, sistemde etkili kapasiteyi azaltabilecek daha genel bir sorun olduğunda (ör. termal sınırlama veya bellek parçalanması) da gösterilebilir.

TouchLatency'i kullanma

Kötü davranışa dair birkaç örnek, Pixel ve Pixel XL için tercih edilen dönemsel iş yükü olan TouchLatency'ten alınmıştır. frameworks/base/tests/TouchLatency sürümünde bulunan bu özelliğin iki modu vardır: dokunma gecikmesi ve zıplayan top (modları değiştirmek için sağ üst köşedeki düğmeyi tıklayın).

Zıplayan top testi tam olarak göründüğü kadar basittir: Bir top, kullanıcı girişinden bağımsız olarak ekranda sonsuza kadar zıplar. Ayrıca, genellikle en mükemmel şekilde çalıştırması en zor testtir. Ancak kare atlamadan çalıştırmaya ne kadar yaklaşırsa cihazınız o kadar iyi olur. Zıplayan top testi, çok düşük bir saat hızında çalışan önemsiz ancak mükemmel şekilde tutarlı bir iş yükü olduğundan zordur (Bu testte cihazın bir frekans denetleyicisi olduğu varsayılır. Cihaz sabit saat hızlarında çalışıyorsa zıplayan top testini ilk kez çalıştırırken CPU/GPU'yu minimuma yakın bir hıza düşürün). Sistem sessizleştikçe ve saatler boşta çalışmaya yaklaştıkça çerçeve başına gereken CPU/GPU süresi artar. Topu izleyip takılmaları görebilir ve systrace'te kaçırılan kareleri de görebilirsiniz.

İş yükü çok tutarlı olduğundan, kullanıcı arayüzü ardışık düzeni yerine her atlanan kare sırasında sistemde tam olarak nelerin çalıştığını izleyerek çoğu titreşim kaynağını kullanıcıların görebildiği çoğu iş yüküne kıyasla çok daha kolay bir şekilde belirleyebilirsiniz. Daha düşük saatler, herhangi bir titremenin kare atlamasına neden olma olasılığını artırarak titremenin etkilerini artırır. Sonuç olarak, TouchLatency'nin 60 FPS'ye ne kadar yakın olduğu, büyük uygulamalarda ara sıra tekrarlanamayan takılmalara neden olan kötü sistem davranışlarının olma olasılığını belirler.

Jitter genellikle (ancak her zaman değil) saat hızına bağlı olmadığından, aşağıdaki nedenlerle jitter'i teşhis etmek için çok düşük saat hızlarında çalışan bir test kullanın:

  • Tüm jitter'ler saat hızına bağlı değildir. Birçok kaynak yalnızca CPU süresini tüketir.
  • Denetleyici, saati yavaşlatarak ortalama kare süresini son tarihe yakın bir değere getirmelidir. Bu nedenle, kullanıcı arayüzü dışındaki işlerin yürütülmesi için harcanan süre, kare atlamasına neden olacak şekilde denetleyiciyi sınırın üzerine itebilir.