Performans değerlendirme

Tekliflerinizi otomatikleştirmek ve optimize etmek için Basit performans cihazlarınızın performansını değerlendirebilirsiniz. Simpleperf, hem yerel işlemler için de geçerlidir. Tekliflerinizi otomatikleştirmek ve optimize etmek için CPU Profil Aracı uygulama CPU kullanımını ve iş parçacığı etkinliğini gerçek zamanlı olarak inceleyin.

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

  • Tahmin edilebilir, algılanabilir performans. Kullanıcı arayüzünde kareler atlanıyor mu yoksa tutarlı bir şekilde 60 FPS'de mi oluşturuluyor? Ses çalıyor mu yok mu? Kullanıcının dokunmadan önce ne kadar süre ve efekt ekranda gösteriliyor mu?
  • Daha uzun işlemler için gereken süre (ör. (uygulamaları açabilirsiniz).

İlki, ikincisinden daha dikkat çekicidir. Kullanıcılar genellikle olumsuzlukları fark eder Ancak 500 ms ve 600 ms uygulama başlatma süresini söyleyemezler. yan yana iki cihaza bakıyorlar. Dokunma gecikmesi hemen fark edilebilir ve bir cihaz algılanmasına önemli ölçüde katkıda bulunur.

Sonuç olarak hızlı bir cihazda, kullanıcı arayüzü ardışık düzeni, hızlı bir dışında bir sisteme ihtiyacınız vardır. Bu kullanıcı arayüzü ardışık düzeninin gerekli olmayan diğer işleri önceden ayırması gerektiği anlamına gelir. akışkan kullanıcı arayüzü için. Değişken bir kullanıcı arayüzü, arka plan senkronizasyonu, bildirim teslimi ve ve kullanıcı arayüzü çalışmaları yürütülebiliyorsa benzer çalışmaların tümü gecikmelidir. Evet ve daha uzun işlemlerin (HDR+ çalışma zamanı, uygulama başlatma vb.) esnek bir kullanıcı arayüzü sağlar.

Kapasite ve ses dalgalanması

Cihaz performansı değerlendirilirken kapasite ve ses dalgalanması iki anlamlı metriktir.

Kapasite

Kapasite, cihazın sahip olduğu kaynakların toplam miktarıdır. devam etmesi gerekir. Bunlar CPU kaynakları, GPU kaynakları, G/Ç kaynakları, ağ kaynakları, bellek bant genişliği veya benzer bir metrik İnceleme sırasında her şeyi tek tek soyutlamak yararlı olabilir. performansı belirleyen tek bir metrik varsayabilirsiniz (özellikle çü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 yöntemidir ancak Örneğin, çevrimiçi CPU çekirdeği sayısını değiştirebilirsiniz. Buna göre bir sistemin kapasitesi güç tüketimine karşılık gelir; değişiyor kapasitesi, güç tüketiminde her zaman benzer bir değişikliğe neden olur.

Belli bir zaman için gereken kapasite büyük ölçüde çalışan bir uygulamadır. Sonuç olarak, platform, performans verilerini belirli bir iş yükü için gereken kapasite ve bunu yapma araçları çalışma zamanı iyileştirmeleri (Android çerçevesi, ART, Bionic, GPU derleyici/sürücüleri, çekirdeği) kaldırın.

Gecikme dalgalanması

Bir iş yükü için gereken kapasite kolayca görülebilirken ses dalgalanması daha harika bir konsept. Platformun hızlı çalışmasının önünde bir engel olarak titremeye iyi bir giriş için için, SÜPER BÜTÇE PERFORMANSINI KAZANILAN ÖRNEK: ASCl Q'nun 8.192 İŞLEYİCİSİ. (Bu, ASCI'nın neden bu şekilde Q süper bilgisayarı beklenen performansına ulaşamadı ve harika bir büyük sistemleri optimize etmeye giriş.)

Bu sayfada ASCI Q makalesindeki çağrılarını açıklamak için ses dalgalanması terimi kullanılmaktadır. gürültü değerleridir. Ses dalgalanması, bir kullanıcının marka tarafından algılanmasını engelleyen rastgele sistem davranışıdır çalışmasını önler. Genellikle çalıştırılması gereken bir çalışmadır ancak katı kurallı olmayabilir. belirli bir zamanda çalıştırılmasına neden olan zamanlama gereksinimleridir. Çünkü için titremenin varlığını kanıtlamak son derece zordur. yardımcı olabilir. Bilinen bir kaynağın yanlış kullanım olduğunu kanıtlamak da ses dalgalanması, belirli bir performans sorununun nedeniydi. Araçların en yaygın ses dalgalanmasının nedenlerini (takip etme veya günlüğe kaydetme gibi) teşhis etmek için kullanılan ses dalgaları var.

Android'in gerçek uygulama uygulamalarında karşılaşılan ses dalgalanmalarının kaynakları şunlardır:

  • Planlayıcı gecikmesi
  • Kesme işleyiciler
  • Önleme veya kesmeler devre dışıyken çok uzun süre çalışan sürücü kodu
  • Köklü softirq'lar
  • Kilit anlaşmazlığı (uygulama, çerçeve, çekirdek sürücüsü, bağlayıcı kilidi, mmap) kilit)
  • Düşük öncelikli bir iş parçacığının kilidi bir yüksek öncelikli iş parçacığının çalışmasını engelliyorsa
  • Gecikmeli olabileceği iş sıralarında kullanıcı arayüzü açısından kritik kodun ç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ın)
  • Yetersiz boş bellek nedeniyle sayfa önbelleği taşması

Belirli bir ses dalgalanması süresi için gereken süre değişebilir veya olmayabilir azalabilir. Örneğin, bir sürücü kesintiye uğrarsa i2c veri yolundan okuma beklenirken devre dışı bırakıldıysa sabit bir CPU'nun 384 MHz veya 2 GHz'ten bağımsız olarak işlem süresi Artan titreme olduğunda kapasitenin performansı artırmak uygun bir çözüm değildir dahil edilir. Sonuç olarak, daha hızlı işleyenler genellikle daha yüksek performans gösterir.

Son olarak, kapasitenin aksine ses dalgalanması neredeyse tamamen sistem tedarikçisi:

Bellek tüketimi

Bellek tüketimi, geleneksel olarak düşük performanstan kaynaklanmaktadır. Bu sırada tüketimi bir performans sorunu değildir, düşükmemorykiller ek yükü, hizmet yeniden başlatılması ve sayfa önbelleğinin aşırı yüklenmesi. Azalan Bellek tüketimi, düşük performansın doğrudan nedenlerinden kaçınabilir, ancak bu nedenlerin önüne geçen diğer hedeflenmiş iyileştirmeler olabilir (örneğin, sayfalanacak şekilde sayfa dışında bırakılmasını önlemek için çerçeveyi sabitleme ) gerekir.

İlk cihaz performansını analiz etme

Çalışır durumdaki ancak kötü performans gösteren bir sistemle başlamak ve sorunları düzeltmeye çalışmak kullanıcının görebildiği zayıf reklam durumları, ayrı ayrı değerlendirerek, iyi bir strateji değildir. Düşük performans genellikle kolayca tekrarlanabilir (yani titreme) veya uygulama ile ilgili bir sorun değildir tüm sistemde bulunan birçok değişken bu stratejinin etkili olmasını engeller. Farklı ortaya çıkarsa, hataları ortaya çıkarmak ve küçük iyileştirmeler yapmak çok sistem genelinde performansı düzeltmeye yönelik sistematik fırsatları kaçırıyordur.

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

  1. Tüm sürücüler çalışırken ve bazı temel özelliklerde, sistemde kullanıcı arayüzünde önyükleme yapın frekans düzenleyici ayarları (sıklık 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ı desteklediğinden emin olun ve ekrana getirilir.
  3. Tüm UI ardışık düzeninin uzun izlerini alın (IRQ aracılığıyla giriş alımından) son taramaya) kadar) ve hafif ve tutarlı bir iş yükü (örneğin, UiBench veya TouchLatency'daki top testi.
  4. Hafif ve tutarlı modda algılanan kare düşüşlerini düzeltin yardımcı olabilir.
  5. 20'den fazla saniye boyunca sıfır atlanmış kareyle koşana kadar 3-4. adımları tekrarlayın oluşturabilirsiniz.
  6. Kullanıcıların görebildiği diğer olumsuzluk kaynaklarına geçin.

Cihaz büyütmenin ilk aşamalarında yapabileceğiniz diğer basit şeyler şunlardır:

  • Çekirdeğinizde planlanan_engellenmiş_neden izleme noktası düzeltmesi hakkında daha fazla bilgi edinin. Bu izleme noktası, planlı iz kategorisiyle etkinleştirilmiş sistem izlemede çalışır ve bu sırada uykudan sorumlu işlevi kesintisiz bir uykuya girer. Performans analizi açısından son derece önemlidir. çünkü kesintisiz uyku, titremenin en yaygın göstergelerinden biridir.
  • GPU ve ekran ardışık düzenleri için yeterli izlemeye sahip olduğunuzdan emin olun. Şu tarihte: İzleme noktaları, şunlar kullanılarak etkinleştirilir:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Sistem izlemeyi çalıştırdığınızda bu etkinlikler etkin kalır. Böylece, görüntüleme ardışık düzeni (MDSS) ile ilgili izin bilgilerini mdss_fb0 bölümü. Qualcomm SOC'lerde ek genel systrace görünümünde GPU hakkında bilgi var, ancak sonuçlar izinde mevcuttur (ayrıntılar için bkz. Anlama systrace) kaldırın.

    Bu tür görüntüleme izlemeden istediğiniz şey, doğrudan bir karenin ekrana iletildiğini gösterir. Bu noktadan sonra kare sürenize başarıyla ulaşıp ulaşmadığınızı belirleyebilirsiniz. Xn etkinliği Xn-1 olayından sonra 16,7 ms'den az gerçekleşir (ekranın 60 Hz olduğu varsayılır), mahsur bırakmadığınızı anlarsınız. SOC'niz bu tür sinyaller sağlamıyorsa onlarla iletişime geçin. gösteren net bir sinyaldir.

Sentetik karşılaştırmaları kullanma

Sentetik karşılaştırmalar, cihazların temel işlevlerini yerine getirmesini sağlamak için yararlıdır. olduğundan emin olun. Ancak, karşılaştırmaları algılanan cihaz için bir proxy olarak değerlendirmek faydalı olmaz.

SOC'lerle ilgili deneyimlere dayanır, sentetik karşılaştırmadaki farklılıklar SOC'ler arasındaki performans, 212 veya 24 saat civarındaki benzer bir farkla algılanabilir kullanıcı arayüzü performansı (atlanan kare sayısı, 99. yüzdelik dilim karesi) vb.) belirtin. Yapay karşılaştırmalar, yalnızca kapasiteyle ilgili karşılaştırmalardır; ses dalgalanması etkileri Bu karşılaştırmaların ölçülen performansını yalnızca, toplu satın alımlar için zaman çalarak üzerine konuşacağız. Sonuç olarak, sentetik karşılaştırma puanları Algılanan performans metriği olarak alakasız.

1.000 kullanıcı arayüzü karesi oluşturan ve Karşılaştırma X'i çalıştıran iki SOC'yi düşünün. toplam oluşturma süresini bildirir (düşük puan daha iyi olur).

  • SOC 1,Karşılaştırma X'in her karesini 10 ms'de oluşturur ve 10.000 puana sahip olur.
  • SOC 2, karelerin% 99'unu 1 ms.de, %1'ini ise 100 ms.de ve puanlarda oluşturur 19.900, çok daha iyi bir puan.

Karşılaştırma gerçek kullanıcı arayüzü performansını gösteriyorsa SOC 2 bir şablon görevi görür. 60 Hz yenileme hızının 60 Hz olduğunu varsaydığımızda SOC 2'de her zaman yavaş bir kare olacaktır. 1,5 sn.çalışma. Bu arada SOC 1 (Karşılaştırma X'e göre daha yavaş olan SOC) son derece esnek olur.

Hata raporlarını kullanma

Hata raporları bazen performans analizi için yararlı olur, ancak o kadar ağırdır ki, düzensiz geçici sorunları gidermek için nadiren faydalı olurlar. Sistemin belli bir zamanda ne yaptığıyla ilgili ipuçları verebilirler. özellikle olumsuzluk, bir uygulama geçişiyle ilgiliyse (kullanıcının daha fazla bilgi edinip başvurabilirsiniz. Hata raporları, bir öğenin daha genel olduğu durumları da gösterebilir verimli kapasitesini azaltabilecek (ör. termal kısıtlama veya bellek bölünmesi).

Dokunma Gecikmesini kullan

Kötü davranış örneklerinin birkaç örneği olarak, tercih edilen periyodik iş yüküne bakalım. Şu adreste sunulmaktadır: frameworks/base/tests/TouchLatency ve iki modu vardır: dokunma gecikmesi ve zıplayan top (modlar arasında geçiş yapmak için sağ üstteki düğmeyi tıklayın .

Zıplayan top testi tam da göründüğü kadar basit: Top zıplıyor kullanıcı girişlerinden bağımsız olarak sonsuza kadar ekranda kalır. Ayrıca genellikle açıkça mükemmel sonuç veren en zor testtir ama o kadar teste yaklaşırsınız hiçbir kare atılmadan çalışıyorsa cihazınız o kadar iyi olacaktır. İlgili içeriği oluşturmak için kullanılan zıplayan top testi yapmak zor çünkü basit ama son derece tutarlı bir oyun. çok düşük bir saatte çalışan iş yükü (bu durumda, cihazın belirli bir frekansta vali; Cihaz bunun yerine sabit saatlerle çalışıyorsa zıplayan top testini ilk kez çalıştırırken CPU/GPU neredeyse minimuma). Sistem durup saatler boşta kalmaya yaklaştıkça, gereken CPU/GPU kare başına süre artar. Topu izleyip berbat şeyler görebilirsiniz. eksik kareleri de görebiliriz.

İş yükü çok tutarlı olduğundan, çoğu kaynaktaki iş yükünü belirleyebilirsiniz. çoğu iş yüküne kıyasla çok daha kolay bir şekilde titremelerini her eksik karede kullanıcı arayüzü yerine sistemde tam olarak çalışıyor ardışık düzendir. Düşük saatler, titreşimin etkisini artırarak ses dalgalanması karenin düşmesine neden olma ihtimalini artırır. Sonuç olarak Dokunma gecikmesi 60 FPS'ye yaklaşırsa sisteminizin kötü durumda olma olasılığı da o kadar azalır. ve daha büyük gruplarda düzensiz, çoğalması zor olumsuzluklara neden olan davranışlar

Ses dalgalanması genellikle (ancak her zaman değil) saat hızı-değişmez olduğundan, aşağıdaki nedenlerden dolayı titremeyi teşhis etmek için çok düşük saatlerde çalışır:

  • Tüm ses dalgalanmaları saat hızıyla değişken değildir; pek çok kaynak yalnızca CPU gerekir.
  • Yönetici, ortalama kare süresini son tarihe kadar teslim tarihine yaklaşırsa Böylece, kullanıcı arayüzü harici işleri çalıştırmak için harcanan süre, ilerlemeyi kare atıyor.