Performansı değerlendirme

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

Performansla ilgili kullanıcı tarafından görülebilen iki gösterge vardır:

  • Öngörülebilir ve algılanabilir performans. Kullanıcı arayüzü (UI) kare düşürüyor mu veya sürekli olarak 60 FPS'de mi oluşturuyor? Ses, yapılar veya patlama olmadan oynatılıyor mu? Kullanıcının ekrana dokunması ile efektin ekranda görünmesi arasında ne kadar gecikme var?
  • Daha uzun süren işlemler için gereken süre (ör. uygulamaları açma).

Birincisi, ikincisinden daha belirgindir. Kullanıcılar genellikle duraklamayı fark eder ancak iki cihazı yan yana incelemedikleri sürece 500 ms ile 600 ms arasındaki uygulama başlatma süresini ayırt edemezler. Dokunma gecikmesi hemen fark edilir ve cihaz algısına önemli ölçüde katkıda bulunur.

Sonuç olarak, hızlı bir cihazda kullanıcı arayüzü işlem hattının işlevsel kalması için gerekenler dışında sistemdeki en önemli şey kullanıcı arayüzü işlem hattıdır. 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ı geçici olarak kesmesi gerektiği anlamına gelir. Akıcı bir kullanıcı arayüzü sağlamak için kullanıcı arayüzü çalışması yürütülebiliyorsa arka plan senkronizasyonu, bildirim teslimi ve benzeri işlemlerin tümü ertelenmelidir. Akıcı bir kullanıcı arayüzü sağlamak için daha uzun işlemlerin (HDR+ çalışma zamanı, uygulama başlatma vb.) performansını düşürmek kabul edilebilir.

Kapasite ve titreşim karşılaştırması

Cihaz performansını değerlendirirken kapasite ve titreme iki anlamlı metriktir.

Kapasite

Kapasite, cihazın belirli bir süre boyunca sahip olduğu 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. Tüm sistemin performansını incelerken tek tek bileşenleri soyutlamak ve performansı belirleyen tek bir metrik olduğunu varsaymak faydalı olabilir (özellikle yeni bir cihazı ayarlarken, çünkü bu cihazda çalıştırılan iş yükleri muhtemelen sabittir).

Bir sistemin kapasitesi, online işlem kaynaklarına göre değişir. Kapasiteyi değiştirmenin temel yolu CPU/GPU frekansını değiştirmektir ancak CPU çekirdeği sayısını online olarak değiştirmek gibi başka yollar da vardır. Dolayısıyla, bir sistemin kapasitesi güç tüketimiyle orantılıdır. Kapasitenin değiştirilmesi 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 uygulamaya göre belirlenir. Sonuç olarak platform, belirli bir iş yükü için gereken kapasiteyi ayarlamak konusunda çok az şey yapabilir ve bunu yapmanın yolları, çalışma zamanı iyileştirmeleriyle (Android çerçevesi, ART, Bionic, GPU derleyicisi/sürücüleri, çekirdek) sınırlıdır.

Titreşim

Bir iş yükü için gereken kapasiteyi görmek kolay olsa da titreşim 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 (Eksik Süper Bilgisayar Performansı: ASCI Q'nun 8.192 İşlemcisinde Optimum Performansı Elde Etme) başlıklı makaleyi okumanızı öneririz. (ASCI Q süper bilgisayarının neden beklenen performansı göstermediğiyle ilgili bir araştırmadır ve büyük sistemleri optimize etme konusunda harika bir giriş niteliğindedir.)

Bu sayfada, ASCI Q makalesinde gürültü olarak adlandırılan durumu tanımlamak için titreşim terimi kullanılmaktadır. Titreşim, algılanabilir çalışmanın yürütülmesini engelleyen rastgele sistem davranışıdır. Bu tür işler genellikle çalıştırılması gereken işlerdir ancak belirli bir zamanda çalıştırılmasını gerektiren katı zamanlama koşulları olmayabilir. Rastgele olduğundan belirli bir iş yükü için titreşimin varlığını kanıtlamak son derece zordur. Ayrıca bilinen bir titreşim kaynağının belirli bir performans sorununa neden olduğunu kanıtlamak da son derece zordur. Titreşimin nedenlerini teşhis etmek için en sık kullanılan araçlar (ör. izleme veya günlük kaydı) kendi titreşimlerini oluşturabilir.

Android'in gerçek dünyadaki uygulamalarında yaşanan titremenin kaynakları şunlardır:

  • Zamanlayıcı gecikmesi
  • Kesme işleyicileri
  • Öncelik veya kesintiler devre dışı bırakılmışken sürücü kodu çok uzun süre çalışıyor
  • Uzun süreli 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 bir dosyadaki kilidi tutarak yüksek öncelikli bir iş parçacığının çalışmasını engellediği dosya tanımlayıcı çekişmesi
  • Kullanıcı arayüzü için kritik öneme sahip kodun, gecikebileceği iş kuyruklarında çalıştırılması
  • CPU boşta kalma geçişleri
  • Günlük Kaydı
  • G/Ç gecikmeleri
  • Gereksiz işlem oluşturma (örneğin, CONNECTIVITY_CHANGE yayınları)
  • Yetersiz boş bellek nedeniyle sayfa önbelleği aşırı bellek kullanımı

Belirli bir titreşim dönemi için gereken süre, kapasite arttıkça azalabilir veya azalmayabilir. Örneğin, bir sürücü i2c veri yolu üzerinden okuma beklerken kesmeleri devre dışı bırakırsa CPU'nun 384 MHz veya 2 GHz olup olmadığına bakılmaksızın sabit bir süre geçer. Titreşim 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 titreşimle sınırlı durumlarda performansı artırmaz.

Son olarak, kapasitenin aksine ses dalgalanması neredeyse tamamen sistem tedarikçisinin sorumluluğundadır.

Bellek tüketimi

Geleneksel olarak, düşük performansın nedeni bellek tüketimi olarak gösterilir. Tüketimin kendisi bir performans sorunu olmasa da düşük bellek kapatıcı ek yükü, hizmetin yeniden başlatılması ve sayfa önbelleğinin aşırı bellek kullanımı yoluyla titreşime neden olabilir. Bellek tüketimini azaltmak, düşük performansın doğrudan nedenlerini önleyebilir ancak bu nedenleri önleyen başka hedefli iyileştirmeler de olabilir (örneğin, kısa süre sonra sayfalandırılacak olan çerçevenin sayfalandırılmasını önlemek için çerçeveyi sabitleme).

İlk cihaz performansını analiz etme

İşlevsel ancak kötü performans gösteren bir sistemden başlayıp sistemin davranışını, kullanıcı tarafından görülebilen kötü performansın tek tek örneklerine bakarak düzeltmeye çalışmak iyi bir strateji değildir. Düşük performans genellikle kolayca yeniden üretilemediği (ör. titreşim) veya bir uygulama sorunu olduğu için tam sistemdeki çok fazla değişken bu stratejinin etkili olmasını engeller. Bu nedenle, nedenleri yanlış tanımlamak ve sistem genelinde performansı düzeltmeye yönelik sistematik fırsatları kaçırırken küçük iyileştirmeler yapmak çok kolaydır.

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

  1. Sistemin, tüm sürücüler çalışır durumdayken ve bazı temel frekans yöneticisi ayarlarıyla (frekans yöneticisi ayarlarını değiştirirseniz aşağıdaki tüm adımları tekrarlayın) kullanıcı arayüzüne önyüklenmesini sağlayın.
  2. Çekirdeğin, sched_blocked_reason izleme noktasının yanı sıra ekran hattındaki diğer izleme noktalarını da desteklediğinden emin olun. Bu izleme noktaları, karenin ekrana ne zaman teslim edildiğini gösterir.
  3. Hafif ve tutarlı bir iş yükü (örneğin, UiBench veya TouchLatency'deki top testi) çalıştırırken tüm kullanıcı arayüzü ardışık düzeninin (IRQ aracılığıyla giriş almaktan nihai taramaya kadar) uzun izlerini alın.
  4. Hafif ve tutarlı iş yükünde tespit edilen kare düşmelerini düzeltin.
  5. Tek seferde 20 saniyeden uzun süre boyunca hiç kare düşürmeden çalıştırana kadar 3-4 arasındaki adımları tekrarlayın.
  6. Kullanıcı tarafından görülebilen diğer duraklama kaynaklarına geçin.

Cihazı başlatma sürecinin başlarında yapabileceğiniz diğer basit işlemler şunlardır:

  • Çekirdeğinizde sched_blocked_reason izleme noktası yamasının bulunduğundan emin olun. Bu izleme noktası, systrace'te sched izleme kategorisiyle etkinleştirilir ve iş parçacığı kesintiye uğratılamayan uykuya girdiğinde uyumaktan sorumlu işlevi sağlar. Kesintisiz uyku, titremenin çok yaygın bir göstergesi olduğundan performans analizi için kritik öneme sahiptir.
  • GPU ve ekran işlem hatları için yeterli izleme olduğundan emin olun. Yakın zamanda piyasaya sürülen Qualcomm SOC'lerde izleme noktaları şu şekilde etkinleştirilir:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Bu etkinlikler, Systrace'i çalıştırdığınızda etkin kalır. Böylece, izlemede mdss_fb0 bölümündeki ekran ardışık düzeni (MDSS) hakkında ek bilgiler görebilirsiniz. Qualcomm SOC'lerde, 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 Understanding systrace (Systrace'i Anlama) başlıklı makaleyi inceleyin).

    Bu tür bir görüntü izlemeden istediğiniz, bir karenin ekrana teslim edildiğini doğrudan gösteren tek bir etkinliktir. Buradan, kare sürenize başarıyla ulaşıp ulaşmadığınızı belirleyebilirsiniz.Xn etkinliği, Xn-1 etkinliğinden 16,7 ms'den daha kısa bir süre sonra gerçekleşirse (60 Hz ekran olduğu varsayılarak) jank yapmadığınızı anlarsınız. SOC'niz bu tür sinyaller sağlamıyorsa bunları almak için satıcınızla birlikte çalışın. Kare tamamlama sinyali olmadan titreşimi ayıklamak son derece zordur.

Sentetik karşılaştırma testleri kullanma

Sentetik karşılaştırmalar, bir cihazın temel işlevselliğinin mevcut olduğundan emin olmak için yararlıdır. Ancak karşılaştırmaları algılanan cihaz performansının yerine kullanmak yararlı değildir.

SOC'lerle ilgili deneyimlere göre, SOC'ler arasındaki sentetik karşılaştırma testi performansındaki farklılıklar, algılanabilir kullanıcı arayüzü performansındaki (bırakılan kare sayısı, kare süresinin 99. yüzdelik dilimi vb.) benzer bir farklılıkla ilişkili değildir. Yapay karşılaştırma testleri yalnızca kapasite karşılaştırma testleridir. Titreme, bu karşılaştırma testlerinin ölçülen performansını yalnızca karşılaştırma testinin 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.

Kullanıcı arayüzünün 1.000 karesini oluşturup toplam oluşturma süresini bildiren (düşük puan daha iyidir) Benchmark X'i çalıştıran iki çip üzerinde sistemi ele alalım.

  • SOC 1,Benchmark X'in 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, önemli ölçüde 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ı varsayıldığında SOC 2, 1,5 saniyelik çalışma süresinde bir kare atlar. Bu arada, SOC 1 (Benchmark X'e göre daha yavaş olan SOC) mükemmel şekilde akıcı olacaktır.

Hata raporlarını kullanma

Hata raporları bazen performans analizi için yararlı olsa da çok ağır olduklarından aralıklı olarak yaşanan takılma sorunlarının hata ayıklanması için nadiren yararlıdır. Sistem, belirli bir zamanda ne yapıyordu? Özellikle de duraklama, uygulama geçişi sırasında meydana geliyorsa (hata raporuna kaydedilir) bu konuda bazı ipuçları verebilir. Hata raporları, sistemde daha genel bir sorun olduğunda da bunu belirtebilir. Bu sorun, sistemin etkin kapasitesini düşürebilir (ör. termal kısma veya bellek parçalanması).

Use TouchLatency

Kötü davranışa ilişkin çeşitli örnekler, Pixel ve Pixel XL için tercih edilen periyodik iş yükü olan TouchLatency'den alınmıştır. frameworks/base/tests/TouchLatency adresinde kullanılabilir 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).

Seksek topu testi, göründüğü kadar basittir: Kullanıcı girişinden bağımsız olarak top, ekranda sürekli olarak seker. Bu test, genellikle çok daha zor bir şekilde mükemmel çalışır. Ancak test, kare düşürmeden çalışmaya ne kadar yakın olursa cihazınız o kadar iyi olur. Zıplayan top testi, önemsiz ancak tamamen tutarlı bir iş yükü olduğu ve çok düşük bir saat hızında çalıştığı için zordur (bu, cihazda frekans yöneticisi olduğu varsayımına dayanır. Cihaz bunun yerine sabit saatlerle çalışıyorsa zıplayan top testini ilk kez çalıştırırken CPU/GPU'nun saat hızını minimuma yakın bir değere düşürün). Sistem sessizleşip saatler boşta kalmaya yaklaştıkça kare başına gereken CPU/GPU süresi artar. Topu izleyebilir ve görüntüdeki duraklamaları görebilirsiniz. Ayrıca, systrace'te kaçırılan kareleri de görebilirsiniz.

İş yükü çok tutarlı olduğundan, kullanıcı arayüzü işlem hattı yerine her kaçırılan kare sırasında sistemde tam olarak neyin çalıştığını izleyerek çoğu kullanıcı tarafından görülebilen iş yüküne kıyasla titreşimin çoğu kaynağını çok daha kolay belirleyebilirsiniz. Daha düşük saat hızları, titreşimin etkilerini artırarak titreşimin kare düşmesine neden olma olasılığını yükseltir. Bu nedenle, TouchLatency değeri 60 FPS'ye ne kadar yakın olursa büyük uygulamalarda aralıklı ve yeniden üretilmesi zor olan duraklamalara neden olan kötü sistem davranışlarıyla karşılaşma olasılığınız o kadar düşüktür.

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

  • Tüm titreşimler saat hızıyla değişmez. Birçok kaynak yalnızca CPU süresini tüketir.
  • Yönetici, saat hızını düşürerek ortalama kare süresini son tarihe yaklaştırmalıdır. Böylece, kullanıcı arayüzü dışındaki işlerin yürütülmesi için harcanan süre, kare düşürme sınırını aşabilir.