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 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.
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, yapaylıklar veya patlamalar 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 (ör. uygulamaları açma) için gereken süre.
Birincisi ikincisinden daha belirgindir. Kullanıcılar genellikle takılmayı 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ü işlem hattının, akıcı kullanıcı arayüzü için gerekli olmayan diğer tüm çalışmaları önceliklendirmesi gerektiği anlamına gelir. Akıcı bir kullanıcı arayüzü sağlamak için kullanıcı arayüzü işi çalıştırılabiliyorsa arka plan senkronizasyonu, bildirim teslimi ve benzeri işlerin tümü ertelenmelidir. Akıcı bir kullanıcı arayüzü sağlamak için daha uzun süren 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 önemli iki 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 çekirdeklerinin sayısını çevrimiçi 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 framework, ART, Bionic, GPU derleyici/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 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 şeyi 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ı çürütmek 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 olan 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_CHANGEyayınları) - Yetersiz boş bellek nedeniyle sayfa önbelleği thrashing'i
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 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. Bu nedenle, daha hızlı işlemciler genellikle titreme kısıtlamalı durumlarda performansı artırmaz.
Son olarak, kapasitenin aksine ses dalgalanması neredeyse tamamen sistem tedarikçisinin alanındadı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 bellekli sonlandırıcı ek yükü, hizmetin yeniden başlatılması ve sayfa önbelleğinin aşırı kullanılması nedeniyle titremeye 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, çerçeveyi kısa süre sonra sayfalandırılacakken sayfalandırılmasını önlemek için sabitleme).
İlk cihaz performansını analiz etme
İşlevsel ancak kötü performans gösteren bir sistemden başlayıp kullanıcının görebileceği kötü performansın tek tek örneklerine bakarak sistemin davranışını düzeltmeye çalışmak doğru bir strateji değildir. Düşük performans genellikle kolayca yeniden üretilemediği (yani titreme) veya bir uygulama sorunu olmadığı 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 sistemik 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:
- Sistemin, tüm sürücüler çalışır durumdayken ve bazı temel frekans yöneticisi ayarlarıyla kullanıcı arayüzüne önyüklenmesini sağlayın (frekans yöneticisi ayarlarını değiştirirseniz aşağıdaki tüm adımları tekrarlayın).
- Çekirdeğin,
sched_blocked_reasonizleme 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. - Hafif ve tutarlı bir iş yükü (ör. UiBench veya TouchLatency'deki top testi) çalıştırırken tüm kullanıcı arayüzü işlem hattının (IRQ aracılığıyla giriş almaktan son taramaya kadar) uzun izlerini alın.
- Hafif ve tutarlı iş yükünde tespit edilen kare düşmelerini düzeltin.
- Tek seferde 20 saniyeden uzun süre boyunca hiç kare düşürmeden çalışana kadar 3-4 arasındaki adımları tekrarlayın.
- Kullanıcı tarafından görülebilen diğer takılma 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ı olduğ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, jitter'ın ç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, mdss_fb0 bölümündeki izlemede ekran işlem hattı (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 izleme dosyasında 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 sonra 16,7 ms'den daha kısa bir sürede gerçekleşirse (60 Hz ekran olduğu varsayılır) 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 tamamlanmasıyla ilgili kesin bir sinyal olmadan titreme sorununu ayıklamak son derece zordur.
Sentetik karşılaştırma testleri kullanma
Sentetik karşılaştırmalar, bir cihazın temel işlevlerinin 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 kez titrek kareye sahip olur. Bu sırada 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. Bu günlükler, sistemin belirli bir zamanda ne yaptığı hakkında bazı ipuçları verebilir. Özellikle de takılma, uygulama geçişi sırasında meydana geliyorsa (bu durum bir hata raporuna kaydedilir) bu ipuçları faydalı olabilir. Hata raporları, sistemde daha geniş kapsamlı bir sorun olduğunda da bunu belirtebilir. Bu sorun, sistemin etkin kapasitesini düşürebilir (ör. termal kısıtlama veya bellek parçalanması).
TouchLatency'yi kullanma
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).
Zıplayan top testi, göründüğü kadar basittir: Kullanıcı girişinden bağımsız olarak top, ekranda sürekli zıplar. 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 saat hızlarıyla çalışıyorsa zıplayan top testi ilk kez çalıştırılı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 titremeleri 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ı, titremenin etkilerini artırarak titremenin 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 zor tekrarlanabilen takılmalara 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.
- Vali, saat hızını düşürerek ortalama kare süresini son tarihe yaklaştırmalıdır. Bu nedenle, kullanıcı arayüzü dışındaki işleri çalıştırmak için harcanan süre, kare düşürme sınırını aşabilir.