Performansın Değerlendirilmesi

Bir cihazın performansını değerlendirmek için Simpleperf kullanın. Simpleperf, Android'de hem uygulamalar hem de yerel işlemler için yerel bir profil oluşturma aracıdır. Uygulama CPU kullanımını ve iş parçacığı etkinliğini gerçek zamanlı olarak incelemek için CPU Profiler'ı kullanın.

Kullanıcı tarafından görülebilen iki performans göstergesi vardır:

  • Öngörülebilir, algılanabilir performans . Kullanıcı arabirimi (UI) kareleri düşürüyor mu veya sürekli olarak 60FPS'de mi işleniyor? Ses, artefakt veya patlama olmadan çalıyor mu? Kullanıcının ekrana dokunması ile ekranda gösterilen efekt arasındaki gecikme ne kadardır?
  • Daha uzun işlemler için gereken süre (uygulamaların açılması gibi).

Birincisi, ikincisinden daha belirgindir. Kullanıcılar genellikle çöpü fark eder, ancak yan yana iki cihaza bakmadıkları sürece 500ms ile 600ms uygulama başlangıç ​​zamanını ayırt edemezler. Dokunma gecikmesi hemen fark edilir ve bir cihazın algılanmasına önemli ölçüde katkıda bulunur.

Sonuç olarak, hızlı bir cihazda, UI işlem hattı, UI işlem hattını işlevsel tutmak için gerekli olanın dışında sistemdeki en önemli şeydir. Bu, kullanıcı arabirimi ardışık düzeninin, akışkan kullanıcı arabirimi için gerekli olmayan diğer işleri engellemesi gerektiği anlamına gelir. Kullanıcı arabirimi çalışması çalıştırılabilirse, akıcı bir kullanıcı arabirimi sağlamak için arka plan senkronizasyonu, bildirim teslimi ve benzer çalışmaların tümü ertelenmelidir. Akışkan bir kullanıcı arabirimi sağlamak için daha uzun işlemlerin (HDR+ çalışma zamanı, uygulama başlatma vb.) performansının takas edilmesi kabul edilebilir.

Kapasite ve titreşim

Cihaz performansı göz önüne alındığında, kapasite ve titreşim iki anlamlı ölçümdür.

Kapasite

Kapasite, cihazın belirli bir süre boyunca sahip olduğu kaynakların toplam miktarıdır. Bu, CPU kaynakları, GPU kaynakları, G/Ç kaynakları, ağ kaynakları, bellek bant genişliği veya benzer herhangi bir ölçü olabilir. Tüm sistem performansını incelerken, tek tek bileşenleri soyutlamak ve performansı belirleyen tek bir metrik varsaymak yararlı olabilir (özellikle yeni bir cihazı ayarlarken, çünkü o cihazda çalışan iş yükleri muhtemelen sabittir).

Bir sistemin kapasitesi, çevrimiçi bilgi işlem kaynaklarına göre değişir. CPU/GPU frekansını değiştirmek, kapasiteyi değiştirmenin birincil yoludur, 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üketimine karşılık gelir; değişen kapasite her zaman güç tüketiminde benzer bir değişiklikle sonuçlanır.

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 için çok az şey yapabilir ve bunu yapmanın yolları, çalışma zamanı iyileştirmeleriyle sınırlıdır (Android çerçevesi, ART, Bionic, GPU derleyici/sürücüler, çekirdek).

titreme

Bir iş yükü için gereken kapasiteyi görmek kolay olsa da, titreşim daha belirsiz bir kavramdır. Hızlı sistemlere bir engel olarak titreşime iyi bir giriş için, EKSİK SÜPER BİLGİSAYAR PERFORMANSI ÖRNEĞİ: 8.192 ASCI Q İŞLEMCİSİ ÜZERİNDE OPTİMAL PERFORMANS ELDE ETMESİ bölümüne bakın . (ASCI Q süper bilgisayarının neden beklenen performansı elde edemediğinin araştırılması ve büyük sistemlerin optimize edilmesi için harika bir giriş.)

Bu sayfa, ASCI Q belgesinin gürültü olarak adlandırdığı şeyi açıklamak için titreşim terimini kullanır. Titreşim, algılanabilir işin çalışmasını engelleyen rastgele sistem davranışıdır. Genellikle çalıştırılması gereken iştir, ancak belirli bir zamanda çalışmasına neden olan katı zamanlama gereksinimleri olmayabilir. Rastgele olduğundan, belirli bir iş yükü için titreşimin varlığını çürütmek son derece zordur. Bilinen bir titreşim kaynağının belirli bir performans sorununun nedeni olduğunu kanıtlamak da son derece zordur. Titremenin nedenlerini teşhis etmek için en yaygın olarak kullanılan araçlar (izleme veya günlüğe kaydetme gibi) kendi titreşimlerini ortaya çıkarabilir.

Android'in gerçek dünya uygulamalarında yaşanan titreşim kaynakları şunları içerir:

  • Zamanlayıcı gecikmesi
  • Kesinti işleyicileri
  • Sürücü kodu, ön alım veya kesintiler devre dışı bırakılarak çok uzun süre çalışıyor
  • Uzun süredir devam eden softirq'ler
  • Kilit çekişmesi (uygulama, çerçeve, çekirdek sürücüsü, cilt kilidi, mmap kilidi)
  • Düşük öncelikli bir iş parçacığının bir dosyadaki kilidi tuttuğu ve yüksek öncelikli bir iş parçacığının çalışmasını engellediği dosya tanımlayıcı çekişmesi
  • Kullanıcı arabirimi açısından kritik kodun gecikebileceği çalışma sıralarında çalıştırılması
  • CPU boşta geçişleri
  • Kerestecilik
  • G/Ç gecikmeleri
  • Gereksiz süreç oluşturma (örneğin, CONNECTIVITY_CHANGE yayınları)
  • Yetersiz boş bellekten kaynaklanan sayfa önbelleği çökmesi

Belirli bir titreşim periyodu için gereken süre, kapasite arttıkça azalabilir veya azalmayabilir. Örneğin, bir sürücü bir i2c veri yolundan bir okuma beklerken kesintileri devre dışı bırakırsa, CPU'nun 384 MHz veya 2 GHz'de olmasına bakılmaksızın sabit bir süre alacaktır. Titreşim söz konusu olduğunda, kapasiteyi artırmak performansı artırmak için uygun bir çözüm değildir. Sonuç olarak, daha hızlı işlemciler genellikle titreşim kısıtlı durumlarda performansı iyileştirmeyecektir.

Son olarak, kapasiteden farklı olarak, titreşim neredeyse tamamen sistem satıcısının etki alanı içindedir.

Bellek tüketimi

Bellek tüketimi geleneksel olarak düşük performans için suçlanır. Tüketimin kendisi bir performans sorunu olmasa da, düşük bellek öldürücü ek yükü, hizmetin yeniden başlatılması ve sayfa önbelleği thrashing yoluyla titreşime neden olabilir. Bellek tüketimini azaltmak, düşük performansın doğrudan nedenlerini önleyebilir, ancak bu nedenleri de önleyen hedeflenen başka iyileştirmeler de olabilir (örneğin, kısa süre sonra disk belleğine alınacağı zaman çerçevenin disk belleğinden çıkarılmasını önlemek için çerçeveyi sabitleme).

İlk cihaz performansını analiz etme

İşlevsel ancak düşük performans gösteren bir sistemden yola çıkmak ve kullanıcı tarafından görülebilen düşük performans durumlarına bakarak sistemin davranışını düzeltmeye çalışmak sağlam bir strateji değildir . Düşük performans genellikle kolayca yeniden üretilemediğinden (yani titreme) veya bir uygulama sorunu olduğundan, tam sistemdeki çok fazla değişken bu stratejinin etkili olmasını engeller. Sonuç olarak, sistem genelinde performansı düzeltmek için sistemik fırsatları kaçırırken nedenleri yanlış belirlemek ve küçük iyileştirmeler yapmak çok kolaydır.

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

  1. Sistemin tüm sürücüler çalışır durumda ve bazı temel frekans düzenleyici ayarlarıyla kullanıcı arabirimine önyükleme yapmasını sağlayın (frekans düzenleyici ayarlarını değiştirirseniz aşağıdaki tüm adımları tekrarlayın).
  2. Çekirdeğin sched_blocked_reason noktasını ve ayrıca çerçevenin ekrana ne zaman teslim edildiğini gösteren görüntü ardışık düzenindeki diğer izleme noktalarını desteklediğinden emin olun.
  3. Hafif ve tutarlı bir iş yükü çalıştırırken (örneğin, UiBench veya TouchLatency'de top testi) tüm UI işlem hattının (bir IRQ aracılığıyla girdi alınmasından son taramaya kadar) uzun izlerini alın.
  4. Hafif ve tutarlı iş yükünde algılanan çerçeve düşüşlerini düzeltin.
  5. Bir seferde 20+ saniye boyunca sıfır atılan karelerle koşabilene kadar 3-4 arasındaki adımları tekrarlayın.
  6. Kullanıcı tarafından görülebilen diğer jank kaynaklarına geçin.

Cihaz açılırken erken yapabileceğiniz diğer basit şeyler şunlardır:

  • Çekirdeğinizin sched_blocked_reason izleme noktası yamasına sahip olduğundan emin olun. Bu izleme noktası, systrace'deki şema izleme kategorisiyle etkinleştirilir ve bu iş parçacığı kesintisiz uykuya girdiğinde uyumaktan sorumlu işlevi sağlar. Kesintisiz uyku, titreşimin çok yaygın bir göstergesi olduğundan performans analizi için kritiktir.
  • GPU ve görüntü işlem hatları için yeterli izlemeye sahip olduğunuzdan emin olun. En son Qualcomm SOC'lerinde 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"

    Bu olaylar, systrace'i çalıştırdığınızda etkin kalır, böylece mdss_fb0 bölümündeki görüntüleme ardışık düzeni (MDSS) hakkındaki izlemede ek bilgiler görebilirsiniz. Qualcomm SOC'lerde, standart systrace görünümünde GPU hakkında herhangi bir ek bilgi görmezsiniz, ancak sonuçlar izlemenin kendisinde bulunur (ayrıntılar için bkz. systrace'i anlama ).

    Bu tür bir görüntü izlemeden istediğiniz şey, ekrana doğrudan bir çerçevenin teslim edildiğini gösteren tek bir olaydır. Oradan, kare sürenizi başarılı bir şekilde vurup vurmadığınızı belirleyebilirsiniz; X n olayı, X n-1 olayından (60 Hz'lik bir ekran varsayılarak) 16.7 ms'den daha kısa bir süre sonra meydana gelirse, o zaman jank yapmadığınızı bilirsiniz. SOC'niz bu tür sinyalleri sağlamıyorsa, bunları almak için satıcınızla birlikte çalışın. Kesin bir çerçeve tamamlama sinyali olmadan hata ayıklama titreşimi son derece zordur.

Sentetik karşılaştırma ölçütlerini kullanma

Sentetik kıyaslamalar, bir cihazın temel işlevlerinin mevcut olduğundan emin olmak için kullanışlıdır. Ancak, kıyaslamaları algılanan cihaz performansı için bir vekil olarak ele almak yararlı değildir.

SOC'lerle ilgili deneyimlere dayanarak, SOC'ler arasındaki sentetik kıyaslama performansındaki farklılıklar, algılanabilir UI performansındaki benzer bir farkla (düşürülmüş kare sayısı, 99. yüzdelik dilim kare süresi vb.) ilişkili değildir. Sentetik karşılaştırma ölçütleri, yalnızca kapasite ölçütleridir; jitter, bu kıyaslamaların ölçülen performansını yalnızca kıyaslamanın toplu çalışmasından zaman çalarak etkiler. Sonuç olarak, sentetik kıyaslama puanları, kullanıcı tarafından algılanan performansın bir ölçüsü olarak çoğunlukla ilgisizdir.

1000 kare kullanıcı arabirimi oluşturan ve toplam oluşturma süresini bildiren Benchmark X çalıştıran iki SOC düşünün (düşük puan daha iyidir).

  • SOC 1, Benchmark X'in her karesini 10 ms'de işler ve 10.000 puan alır.
  • SOC 2, karelerin %99'unu 1ms'de, karelerin %1'ini 100ms'de işler ve 19.900 puan verir, bu çok daha iyi bir puandır.

Kıyaslama gerçek UI performansının göstergesiyse, SOC 2 kullanılamaz olacaktır. 60 Hz yenileme hızı varsayıldığında, SOC 2 her 1,5 saniyede bir sarsıntılı bir çerçeveye sahip olacaktır. Bu arada, SOC 1 (Benchmark X'e göre daha yavaş olan SOC) tamamen akıcı olacaktır.

Hata raporlarını kullanma

Hata raporları bazen performans analizi için kullanışlıdır, ancak çok ağır olduklarından, ara sıra çöplük sorunlarının hatalarını ayıklamak için nadiren faydalıdırlar. Belirli bir zamanda sistemin ne yaptığına dair bazı ipuçları sağlayabilirler, özellikle de çöp bir uygulama geçişi (bir hata raporunda günlüğe kaydedilir) civarındaysa. Hata raporları, sistemde etkin kapasitesini azaltabilecek (termal kısma veya bellek parçalanması gibi) daha genel olarak yanlış bir şeyler olduğunda da gösterebilir.

TouchLatency'yi kullanma

Pixel ve Pixel XL için tercih edilen periyodik iş yükü olan TouchLatency'den birkaç kötü davranış örneği gelir. frameworks/base/tests/TouchLatency mevcuttur ve 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).

Sıçrayan top testi göründüğü kadar basittir: Bir top, kullanıcı girişinden bağımsız olarak ekranda sonsuza kadar seker. Ayrıca, genellikle kusursuz çalışması en zor testtir, ancak herhangi bir kare atlamadan çalışmaya ne kadar yaklaşırsa, cihazınız o kadar iyi olur. Sıçrayan top testi zordur çünkü çok düşük bir saatte çalışan önemsiz fakat mükemmel derecede tutarlı bir iş yüküdür (bu, cihazın bir frekans düzenleyicisine sahip olduğunu varsayar; cihaz bunun yerine sabit saatlerle çalışıyorsa, CPU/GPU'yu minimuma yakın bir seviyeye düşürün zıplayan top testini ilk kez çalıştırırken). Sistem sessizleştikçe ve saatler boşta kalmaya yaklaştıkça, çerçeve başına gerekli CPU/GPU süresi artar. Topu izleyebilir ve bir şeylerin sarsıldığını görebilir ve ayrıca systrace'de kaçırılan kareleri de görebileceksiniz.

İş yükü çok tutarlı olduğu için, kullanıcı arabirimi ardışık düzeni yerine her kaçırılan çerçeve sırasında sistemde tam olarak neyin çalıştığını izleyerek, çoğu titreşim kaynağını, kullanıcı tarafından görülebilen çoğu iş yükünden çok daha kolay bir şekilde tanımlayabilirsiniz. Daha düşük saatler, herhangi bir titreşimin çerçevenin düşmesine neden olma olasılığını artırarak titreşimin etkilerini güçlendirir. Sonuç olarak, TouchLatency 60FPS'ye ne kadar yakınsa, daha büyük uygulamalarda ara sıra, yeniden üretilmesi zor olan aksaklığa neden olan kötü sistem davranışlarına sahip olma olasılığınız o kadar düşük olur.

Titreşim genellikle (ancak her zaman değil) saat hızında değişmez olduğundan, aşağıdaki nedenlerle titreşimi teşhis etmek için çok düşük saatlerde çalışan bir test kullanın:

  • Tüm titreşimler saat hızında değişmez değildir; birçok kaynak sadece CPU zamanını tüketir.
  • Yönetici, saati azaltarak ortalama kare süresini son tarihe yakın tutmalıdır, böylece UI dışı çalışma için harcanan zaman, bir kareyi düşürmeye kadar onu zorlayabilir.