Performansın Değerlendirilmesi

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

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

  • Tahmin edilebilir, algılanabilir performans . Kullanıcı arayüzü (UI) kareleri düşürüyor mu yoksa sürekli olarak 60FPS'de mi oluşturuyor? Ses, bozulma veya patlama olmadan çalınıyor mu? Kullanıcının ekrana dokunması ile efektin ekranda görünmesi arasındaki gecikme ne kadardır?
  • Daha uzun işlemler (uygulamaların açılması gibi) için gereken süre .

Birincisi ikinciye göre daha dikkat çekicidir. Kullanıcılar genellikle jank'ı fark ederler ancak iki cihaza yan yana bakmadıkları sürece uygulama başlatma süresinin 500 ms ile 600 ms arasında olduğunu söyleyemezler. Dokunma gecikmesi hemen fark edilir ve cihazın algılanmasına önemli ölçüde katkıda bulunur.

Sonuç olarak, hızlı bir cihazda, UI boru hattı, sistemdeki UI boru hattını işlevsel tutmak için gerekli olanın dışında en önemli şeydir. Bu, UI işlem hattının akıcı UI için gerekli olmayan diğer işleri engellemesi gerektiği anlamına gelir. Akıcı bir kullanıcı arayüzü sağlamak için, kullanıcı arayüzü çalışması çalıştırılabiliyorsa arka planda senkronizasyon, bildirim dağıtımı ve benzeri çalışmaların tümü ertelenmelidir. Akıcı bir kullanıcı arayüzünü korumak için daha uzun işlemlerin (HDR+ çalışma süresi, uygulama başlatma vb.) performansını değiştirmek kabul edilebilir.

Kapasite ve titreşim

Cihaz performansı dikkate alındığında kapasite ve titreşim iki anlamlı ölçümdür.

Kapasite

Kapasite, cihazın belirli bir süre boyunca sahip olduğu bazı 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çüm olabilir. Tüm sistem performansını incelerken, bireysel bileşenleri soyutlamak ve performansı belirleyen tek bir ölçüt varsaymak faydalı 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 CPU çekirdeği sayısını çevrimiçi olarak değiştirmek gibi başka yollar da vardır. Buna göre bir sistemin kapasitesi güç tüketimine karşılık gelir; Kapasite değişimi her zaman güç tüketiminde de benzer bir değişime 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 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 derleyicisi/sürücüleri, çekirdek).

Titreşim

Bir iş yükü için gereken kapasiteyi görmek kolay olsa da titreşim daha belirsiz bir kavramdır. Hızlı sistemlere engel teşkil eden titreşime iyi bir giriş için, KAYIP SÜPER BİLGİSAYAR PERFORMANSI DURUMU: ASCI Q'NUN 8.192 İŞLEMCİSİNDE OPTİMUM PERFORMANSA BAŞLAMAK konusuna bakın. (Bu, ASCI Q süper bilgisayarının neden beklenen performansı elde edemediğine dair bir araştırmadır ve büyük sistemleri optimize etmeye harika bir giriş niteliğindedir.)

Bu sayfada ASCI Q makalesinin gürültü olarak adlandırdığı şeyi tanımlamak için titreşim terimi kullanılmaktadır. Titreşim, algılanabilir işin çalışmasını engelleyen rastgele sistem davranışıdır. Çoğu zaman çalıştırılması gereken iş olur, ancak belirli bir zamanda çalıştırılmasına neden olan katı zamanlama gereklilikleri olmayabilir. Rastgele olduğundan, belirli bir iş yükü için titreşimin varlığını çürütmek son derece zordur. Belirli bir performans sorununun nedeninin bilinen bir titreşim kaynağı olduğunu kanıtlamak da son derece zordur. Titreşimin nedenlerini teşhis etmek için en yaygın olarak kullanılan araçlar (izleme veya kayıt tutma 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
  • Kesme işleyicileri
  • Sürücü kodu, önleme veya kesintiler devre dışı bırakılarak çok uzun süre çalışıyor
  • Uzun süre çalışan 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 dosya üzerindeki kilidi tutarak yüksek öncelikli bir iş parçacığının çalışmasını önlediği dosya tanımlayıcı çekişmesi
  • Kullanıcı arayüzü açısından kritik kodun gecikebileceği çalışma kuyruklarında çalıştırılması
  • CPU boşta geçişleri
  • Kerestecilik
  • G/Ç gecikmeleri
  • Gereksiz süreç oluşturma (örn. CONNECTIVITY_CHANGE yayınları)
  • Yetersiz boş hafızanın neden olduğu sayfa önbelleği bozulması

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

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

Bellek tüketimi

Bellek tüketimi geleneksel olarak düşük performanstan sorumlu tutulur. Tüketimin kendisi bir performans sorunu olmasa da, düşük bellek yükü, hizmetin yeniden başlatılması ve sayfa önbelleğinin bozulması yoluyla titremeye neden olabilir. Bellek tüketimini azaltmak, düşük performansın doğrudan nedenlerini önleyebilir, ancak bu nedenleri de önleyen başka hedefe yönelik iyileştirmeler de olabilir (örneğin, çerçevenin, daha sonra sayfaya aktarılacağı zaman sayfadan çıkarılmasını önlemek için sabitlenmesi).

Başlangıç ​​cihaz performansını analiz etme

İşlevsel ancak düşük performans gösteren bir sistemden başlamak ve kullanıcının görebildiği düşük performansın bireysel durumlarına bakarak sistemin davranışını düzeltmeye çalışmak sağlam bir strateji değildir . Düşük performansın genellikle kolayca tekrarlanamaması (örn. titreşim) veya bir uygulama sorunu olması nedeniyle, sistemin tamamında çok fazla değişken bu stratejinin etkili olmasını engeller. Sonuç olarak, sistem genelinde performansı düzeltmeye yönelik sistemik fırsatları kaçırırken, nedenleri yanlış tanımlamak 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ülerin çalıştığı ve bazı temel frekans düzenleyici ayarlarının çalıştığı kullanıcı arayüzünde önyüklenmesini 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 izleme noktasının yanı sıra ekran ardışık düzeninde çerçevenin ekrana ne zaman teslim edildiğini belirten diğer izleme noktalarını desteklediğinden emin olun.
  3. Hafif ve tutarlı bir iş yükünü çalıştırırken (örneğin, UiBench veya TouchLatency'de top testi) tüm kullanıcı arayüzü hattının uzun izlerini alın (IRQ aracılığıyla girdi alınmasından son taramaya kadar).
  4. Hafif ve tutarlı iş yükünde tespit edilen kare düşüşlerini düzeltin.
  5. Tek seferde 20'den fazla saniye boyunca sıfır atlanan kareyle koşabilene kadar 3-4. adımları tekrarlayın.
  6. Kullanıcıların görebileceği diğer jank kaynaklarına geçin.

Cihaz açılışında erkenden 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ı, sistemdeki zamanlanmış izleme kategorisiyle etkinleştirilir ve iş parçacığı kesintisiz uykuya girdiğinde uykudan sorumlu işlevi sağlar. Performans analizi için kritik öneme sahiptir çünkü kesintisiz uyku, titreşimin çok yaygın bir göstergesidir.
  • GPU ve ekran ardışık düzenleri için yeterli izlemeye sahip olduğunuzdan emin olun. En yeni Qualcomm SOC'lerde 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 olaylar etkin kalır, böylece mdss_fb0 bölümündeki görüntü ardışık düzeni (MDSS) hakkındaki izlemede ek bilgileri 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 mevcuttur (ayrıntılar için bkz . systrace'i anlama).

    Bu tür bir görüntü izlemeden beklediğiniz şey, ekrana bir çerçevenin iletildiğini doğrudan belirten tek bir olaydır. Buradan kare sürenize başarıyla ulaşıp ulaşmadığınızı belirleyebilirsiniz; X n olayı, X n-1 olayından sonra 16,7 ms'den daha kısa bir süre içinde meydana gelirse (60 Hz'lik bir ekran varsayılırsa), o zaman sarsıntı yapmadığınızı bilirsiniz. SOC'niz bu tür sinyalleri sağlamıyorsa bunları almak için satıcınızla birlikte çalışın. Çerçevenin tamamlandığına dair kesin bir sinyal olmadan titreşimde hata ayıklamak son derece zordur.

Sentetik kıyaslamaların kullanılması

Sentetik kıyaslamalar, bir cihazın temel işlevselliğinin mevcut olduğundan emin olmak için kullanışlıdır. Ancak kıyaslamaları algılanan cihaz performansının bir göstergesi 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 kullanıcı arayüzü performansındaki benzer bir farkla (bırakılan kare sayısı, 99'uncu yüzdelik kare süresi vb.) ilişkili değildir. Sentetik kıyaslamalar yalnızca kapasiteye yönelik kıyaslamalardır; titreşim, 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ının algıladığı performansın bir ölçüsü olarak çoğunlukla önemsizdir.

1000 kare kullanıcı arayüzü oluşturan ve toplam oluşturma süresini bildiren Benchmark X çalıştıran iki SOC'yi 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 1 ms'de, ancak karelerin %1'ini 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ın göstergesiyse SOC 2 kullanılamaz. 60 Hz yenileme hızı varsayarsak, SOC 2'de her 1,5 saniyede bir sarsıntılı bir çerçeve 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 faydalıdır, ancak çok ağır oldukları için ara sıra meydana gelen istenmeyen sorunların hatalarını ayıklamak için nadiren faydalıdırlar. Özellikle jank bir uygulama geçişi (hata raporuna kaydedilen) civarındaysa, sistemin belirli bir zamanda ne yaptığına dair bazı ipuçları sağlayabilirler. Hata raporları ayrıca sistemde etkin kapasitesini azaltabilecek bir şeyin (termal kısıtlama veya bellek parçalanması gibi) daha genel bir sorun olduğunu da gösterebilir.

TouchLatency'yi kullanma

Birkaç kötü davranış örneği, Pixel ve Pixel XL için tercih edilen periyodik iş yükü olan TouchLatency'den kaynaklanmaktadır. frameworks/base/tests/TouchLatency adresinde mevcuttur ve iki modu vardır: dokunma gecikmesi ve zıplayan top (modları değiştirmek için sağ üst köşedeki düğmeye tıklayın).

Zıplayan top testi tam olarak göründüğü kadar basittir: Bir top, kullanıcı girdisine bakılmaksızın ekranın etrafında sonsuza kadar zıplar. Genellikle mükemmel şekilde çalıştırılması en zor testtir, ancak herhangi bir kare kaybı olmadan çalışmaya ne kadar yaklaşılırsa cihazınız o kadar iyi olacaktır. Zıplayan top testi zordur çünkü çok düşük bir saatte çalışan önemsiz ama 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'nun saatini neredeyse minimuma düşürün) sıçrayan top testini ilk kez çalıştırırken). Sistem sakinleştikçe ve saatler boşta kalmaya yaklaştıkça, kare başına gereken CPU/GPU süresi artar. Topu izleyebilir ve bazı şeylerin sarsıldığını görebilirsiniz, ayrıca systrace'de kaçırılan kareleri de görebileceksiniz.

İş yükü çok tutarlı olduğu için, kullanıcı arayüzü ardışık düzeni yerine her kaçırılan kare sırasında sistemde tam olarak neyin çalıştığını takip ederek, çoğu kullanıcı tarafından görülebilen iş yükünden çok daha kolay bir şekilde titremenin kaynaklarını 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ın olursa, daha büyük uygulamalarda düzensiz, yeniden üretilmesi zor sarsıntılara neden olan kötü sistem davranışlarına sahip olma olasılığınız o kadar azalır.

Titreşim çoğu zaman (fakat her zaman değil) saat hızıyla değişmez olduğundan, aşağıdaki nedenlerden dolayı titreşimi teşhis etmek için çok düşük saat hızlarında çalışan bir test kullanın:

  • Titreşimin tümü saat hızıyla değişmez değildir; birçok kaynak yalnızca CPU zamanını tüketir.
  • Guvernör, saati azaltarak ortalama kare süresini son teslim tarihine yaklaştırmalıdır, böylece kullanıcı arayüzü olmayan işleri yürütmek için harcanan zaman, bir karenin düşmesine neden olabilir.