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).
İlki 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ı çalıştırılabilirse kullanıcı arayüzünün akıcılığını korumak için 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 oranda ç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 mükemmel 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ş olsa da 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ı reddetmek 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ü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 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_CHANGEyayınları) - Yeterli boş bellek olmadığından sayfa önbelleği aşırı hareketli
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 örneklerine bakarak 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:
- Sistemin, tüm sürücülerin çalıştığı ve bazı temel sıklık denetleyicisi ayarlarının bulunduğu kullanıcı arayüzünde başlatılmasını sağlayın (sıklık denetleyicisi 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 ardışık düzenindeki, karenin ekrana ne zaman teslim edildiğini belirten diğer izleme noktalarını desteklediğinden emin olun. - 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.
- Hafif ve tutarlı iş yükünde algılanan kare düşüşlerini düzeltin.
- Bir seferde 20 saniyeden uzun süre boyunca sıfır kare atlamayla çalıştırabilene kadar 3-4. adımları tekrarlayın.
- 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 uyku moduna geçmekten 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ı için bir proxy olarak kullanmak 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 (hata raporuna kaydedilir) gerçekleştiyse 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 kısıtlama veya bellek parçalanması) da gösterilebilir.
TouchLatency'i kullanma
Kötü davranış örnekleri arasında Pixel ve Pixel XL için tercih edilen dönemsel iş yükü olan TouchLatency'ten alınan örnekler de vardı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 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'nun saat hızını minimuma yakın bir değere düşürün). Sistem sessizleştikçe ve saatler boşta çalışma durumuna 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 titremenin çoğu 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, titremenin kare atlamasına neden olma olasılığını artırarak titremenin etkilerini artırır. Sonuç olarak, TouchLatency değeri 60 FPS'ye ne kadar yakınsa büyük uygulamalarda ara sıra tekrarlanamayan takılmalara neden olan kötü sistem davranışları yaşama olasılığınız o kadar düşük olur.
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 ötesine itebilir.