systrace, Android cihaz performansını analiz etmek için kullanılan birincil araçtır. Ancak bu, diğer araçları kapsayan bir pakettir. Bu, ana makine tarafı sarmalayıcıdır kullanıcı alanını kontrol eden, cihaz tarafında yürütülebilir dosya atrace etrafındaki izleme ve ftrace'i ve Linux'taki birincil izleme mekanizmasını kurar. kernel'e gidin. systrace, izlemeyi etkinleştirmek için aiz kullanır, ardından ftrace arabelleğini okur ve bunları bağımsız bir HTML görüntüleyicide birleştirir. (Yeni çekirdeklerde ise Linux Enhanced Berkeley Paket Filtresi (eBPF) için aşağıdaki dokümanlar Pixel/Pixel telefonda kullanılan 3.18 çekirdeğiyle (eFPF yoktur) ilgilidir XL)
systrace, Google Android ve Google Chrome ekiplerine ait olup Çevik’in bir parçası olarak Catapult projesi. İçinde Catapult, systrace'e ek olarak başka faydalı programlar da içerir. Örneğin, ftrace, systrace veya atrace ile doğrudan etkinleştirilebileceklerinden daha fazla özelliğe sahiptir ve Hata ayıklama performansında kritik öneme sahip bazı gelişmiş işlevler içerir neden olabilir. (Bu özellikler, kök erişimi ve genellikle yeni bir çekirdek gerektirir.)
Sistem izlemeyi çalıştır
Pixel/Pixel XL'de ses dalgalanmalarını ayıklarken aşağıdakilerden başlayın: komut:
./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000
GPU ve ekran için gerekli olan ek izleme noktalarıyla birleştirildiğinde Bu, kullanıcı girişinden çerçeveye kadar izleme yapabilmenizi sağlar. ekranda görüntülenir. Kaybetmemek için tampon boyutunu büyük bir değere ayarlayın. etkinlikler (çünkü büyük bir arabellek olmadan bazı CPU'lar izin verilen ara hedefler) belirleyebilirsiniz.
Sistem izlemeden geçerken, her etkinliğin CPU'daki bir şey tarafından tetiklenir.
Sistem izleme ftrace üzerine inşa edildiği ve ftrace'in CPU üzerinde çalıştığı için bir şey, donanım değişikliklerini günlüğe kaydeden ftrace arabelleğine yazmalıdır. Bu, bir ekran çitinin durumunun neden değiştiğini merak ediyorsanız tam geçiş noktasında CPU'da neyin çalıştığını görebilir (CPU'da çalışan bir şey, günlükteki değişikliği tetiklemiştir). Bu temel kavram, systrace kullanarak performans analizi yapmanın
Örnek: Çalışma çerçevesi
Bu örnekte, normal bir kullanıcı arayüzü ardışık düzeni için bir sistem izleme açıklanmaktadır. Takip etmek için
Örneğin, izlerin ZIP dosyasını indirin.
(bu bölümde bahsedilen diğer izleri de içerir) dosyayı açın,
ve systrace_tutorial.html dosyasını tarayıcınızda açın. Uyarı alın
bu sistem izlemenin büyük bir dosya olduğunu; günlük işlerinizde systrace kullanmıyorsanız
ve bu durum, muhtemelen çok daha fazla bilgi içeren ve burada
tek bir izde hiç görülmemişti.
TouchLatency gibi tutarlı ve düzenli bir iş yükü için kullanıcı arayüzü ardışık düzeni şunları içerir:
- SurfaceFlinger'daki EventThread, uygulama kullanıcı arayüzü iş parçacığını uyandırarak zamanının geldiğini belirtir yeni bir kare oluşturun.
- Uygulama, CPU ve yapılandırma kullanarak UI iş parçacığı, RenderThread ve hwuiTasks içinde bir çerçeve oluşturur. GPU kaynakları. Bu, kullanıcı arayüzü için harcanan kapasitenin büyük kısmıdır.
- Uygulama, oluşturulan kareyi bir bağlayıcı kullanarak SurfaceFlinger'a gönderir, ardından SurfaceFlinger uyku moduna geçiyor.
- SurfaceFlinger'daki ikinci bir EventThread, SurfaceFlinger'ı uyandırmak için bileşim ve görüntü çıktısı. SurfaceFlinger, Google'ın açık kaynaklı iş biter, tekrar uyku moduna geçer.
- SurfaceFlinger, besteyi Donanım Oluşturucu (HWC)/Donanım kullanarak işler. Composer 2 (HWC2) veya GL. HWC/HWC2 bileşimi daha hızlı ve daha düşük güç tüketimi ancak çip üzerindeki sisteme bağlı olarak sınırlamalar vardır (SoC). Bu işlem genellikle yaklaşık 4-6 ms. sürer ancak Android nedeniyle 2. adımla çakışabilir. uygulamalar her zaman üç kez arabelleğe alınır. (Uygulamalar her zaman üç kez arabelleğe alınmış olsa da SurfaceFlinger'da bekleyen yalnızca bir bekleyen kare olabilir ve bu nedenle çift arabelleğe alma ile aynıdır.)
- SurfaceFlinger nihai çıktıyı bir tedarikçi firma sürücüsüyle görüntülenmek üzere gönderir ve uykuya geri dönmesi, EventThread'in uyanması bekleniyor.
15.409 ms'den başlayan karenin üzerinden geçelim:
Şekil 1, normal çerçevelerle çevrili normal bir çerçevedir, bu nedenle işleyişini anlamaya yönelik bir başlangıç noktası olarak düşünebilirsiniz. Kullanıcı arayüzü iş parçacığı satırı TouchLatency için farklı zamanlarda farklı renkler kullanabilirsiniz. Çubuklar ileti dizisi için farklı durumlar:
- Gri. Uyuyun.
- Mavi. Çalıştırılabilir (çalışabilir ancak planlayıcı çalışmadı) henüz yayınlanmaya başlamamıştır).
- Yeşil. Aktif olarak çalışıyor (planlayıcı, çalışır).
- Kırmızı. Kesintisiz uyku (genellikle kilitsiz bir şekilde uyumak) . G/Ç yükünün göstergesi olabilir. Hata ayıklama için son derece faydalı performans sorunları var.
- Turuncu. G/Ç yükü nedeniyle kesintisiz uyku.
Kesintisiz uyku nedenini görüntülemek için (
sched_blocked_reason izleme noktası) kırmızı kesintisiz izlemeyi seçin
bir uyku dilimi.
EventThread çalışırken TouchLatency için kullanıcı arayüzü iş parçacığı çalıştırılabilir. Neyi uyandırdığını görmek için mavi bölümü tıklayın.
Şekil 2'de, EventThread'e karşılık gelir. Kullanıcı arayüzü iş parçacığı uyanır, bir kare oluşturur ve sıraya koyar emin olmanız gerekir.
binder_driver etiketi bir izlemede etkinleştirildiyse
tüm süreçlerle ilgili bilgileri görüntülemek için bağlayıcı işlemin
belirtir.
Şekil 4'te, SurfaceFlinger'da 15.423,65 ms Binder:6832_1 olduğunda TouchLatency'ın RenderThread'i olan cid 9579 nedeniyle çalıştırılabilir. Ayrıca transkriptinizi sıranın, bağlayıcı işleminin her iki tarafında da görünmesini sağlar.
SurfaceFlinger tarafındaki merchantBuffer sırasında bekleyen TouchLatency'daki karelerin değeri 1'den 2'ye çıkıyor.
Şekil 5'te, tamamlanmış iki karenin bulunduğu ve üçte birini oluşturmaya başlamak üzere. Bunun nedeni, Bu yüzden uygulama bir yerine iki bekleyen kare tutuyor. Böylece, bu karelerden kaçınmaya kare daha fazla atlandı.
Kısa süre sonra, SurfaceFlinger'ın ana iş parçacığı ikinci bir EventThread tarafından uyandırılır. ekranda bekleyen eski karenin çıktısını alabilir:
SurfaceFlinger önce beklemedeki eski arabelleği kilitler ve bu da 2'den 1'e düşürülmesi bekleniyor.
Tamponu kilitledikten sonra, SurfaceFlinger kompozisyonu ayarlar ve
ekrana sığdırır. (Bu bölümlerin bazıları
mdss izleme noktası olduğundan SoC'nize dahil edilmeyebilir.)
Ardından mdss_fb0, CPU 0'da uyanır. mdss_fb0
Ardışık düzenin çekirdek iş parçacığını göstererek oluşturulan bir çerçeveyi ekranda oluşturur.
mdss_fb0, izde kendi satırı olarak görülebilir (aşağı kaydırın
görünümü) tıklayın.
mdss_fb0 uyanır, kısa süre koşar, kesintisiz uykuya girer,
sonra tekrar uyanır.
Örnek: Çalışmayan çerçeve
Bu örnekte Pixel/Pixel XL ses dalgalanmasında hata ayıklamak için kullanılan bir sistem izleme açıklanmaktadır. Alıcı:
örnektekini takip edin, ZIP dosyasını
iz dosyasını (bu belgede atıfta bulunulan diğer izleri içerir)
bölümünde), dosyanın sıkıştırmasını açın ve systrace_tutorial.html dosyasını
emin olun.
Sistem izlemeyi açtığınızda şuna benzer bir şey görürsünüz:
Titremeyi ararken SurfaceFlinger'ın altındaki FrameMissed satırını kontrol edin.
FrameMissed, HWC2 tarafından sağlanan bir yaşam kalitesi iyileştirmesidir. Görüntülerken
systrace'i kullanıyorsanız cihaz
HWC2 kullanmaz. İkisinden birinde
FrameMissed'in, SurfaceFlinger'da şunlardan birinin eksik olmasıyla ilişkilidir:
son derece normal çalışma zamanları ve uygulama için değişmeyen bekleyen arabellek sayısı
Bir vsync'de (com.prefabulated.touchlatency).
Şekil 11'de 15.598,29&nb/sn.de eksik bir kare gösterilmektedir. SurfaceFlinger, şu saatte kısa bir süre uyandı: ve hiçbir çalışma yapmadan uyku moduna geçti. Bu, SurfaceFlinger, ekrana bir kare göndermeyi denemenin tekrar. Neden?
Ardışık düzenin bu çerçeve için nasıl ayrıldığını anlamak amacıyla önce çalışma çerçevesi örneğini yukarıdaki çalışma çerçevesiyle birlikte izleyebilirsiniz. Hazır olduğunuzda eksik kareye dönün ve geriye doğru ilerleyin. Not: SurfaceFlinger uyanır ve hemen uyku moduna geçer. Telefondaki TouchLatency'dan bekleyen kareler varsa iki kare var (bu, fotoğraf makinelerine ne olduğunu anlamaya çalışın).
SurfaceFlinger'da karelerimiz olduğundan bu bir uygulama sorunu değildir. Ayrıca, SurfaceFlinger doğru saatte uyandığı için bir SurfaceFlinger değil . Hem SurfaceFlinger hem de uygulama normal görünüyorsa muhtemelen bu bir sürücü sorunudur.
mdss ve sync izleme noktaları etkinleştirildiği için
çitler hakkında bilgi alabiliriz (ekran sürücüsü ile
SurfaceFlinger) içerir.
Bu çitler mdss_fb0_retire altında listelenmektedir.
ekranda bir kare bulunduğunu belirtir. Bu çitler,
sync iz kategorisinin bir parçasıdır. Hangi çitler karşılık geliyor?
SurfaceFlinger'daki belirli etkinlikler SOC ve sürücü yığınınıza bağlıdır. Bu nedenle,
SOC tedarikçinizle birlikte çalışarak, işletmenizdeki sınır kategorilerinin anlamını öğrenebilirsiniz.
izler.
Şekil 13'te, beklendiği gibi 16,7 ms değil, 33 ms boyunca görüntülenen bir kare gösterilmektedir. Bu dilimin yarısında, söz konusu kare yeni bir kareyle değiştirilmiş olmalıdır. ama olmadı. Önceki kareyi görüntüleyin ve bir şey arayın.
Şekil 14'te, bir kare 14,482 ms'de gösterilmektedir. İki kareli bozuk segment 33,6 ms'ydi. Bu, iki kare için beklediğimiz gibidir (60 Hz, 16,7 ms kare başına ortalama değer). Ancak 14,482 ms, 16,7 ms'ye hiç yakın değildir. Bu da görüntüleme borusunda bir şeylerin yanlış olduğunu gösteriyor.
Çitin tam olarak nerede bittiğini araştırarak neyin kontrol ettiğini belirleyin.
Bir çalışma sırası, __vsync_retire_work_handler değerini içeriyor.
nasıl çalışması gerektiğini öğreneceğiz. Çekirdek kaynağına baktığınızda
ekran sürücüsünün bir parçasıdır. Kritik öneme sahip olduğu anlaşılıyor.
yolunu belirtmek için kullanıldığından emin olun. İnsanların
yaklaşık 70 süre çalıştırılabilir (planlamada uzun bir gecikme olmaz), ancak
zaman çizelgesi doğru şekilde olmayabilir.
Önceki kareyi kontrol ederek bu durumun etkili olup olmadığını belirleyin. bazen titrer ve nihayetinde teslim tarihinin kaçırılmasına neden olabilir.
İzleyici döndüğünden kworker'daki çalıştırılabilir çizgi görünmüyor
seçildiğinde beyaz listeye alınır, ancak istatistikler hikayeyi anlatır: planlayıcının 2,3 ms.
görüntüleme ardışık düzeni kritik yolunun bir parçası için gecikmenin kötü olması gerekir.
Devam etmeden önce gecikmeyi, e-postanın bu kısmını taşıyarak
ardışık düzendeki kritik yolunu gösterir.
SCHED_OTHER CFS iş parçacığı) özel bir SCHED_FIFO öğesine
kthread. Bu işlevin, iş kuyruklarının gösterilmeyeceği (ve gösterilmeyeceği)
sağlamak amaçlanır.
Sorunun nedeni bu mu? Sonuç olarak kesin bir şey söylemek zor. Şu yerlerin dışında: görüntüleme açısından kritik öneme sahip çekirdek kilidi anlaşmazlığı gibi teşhis edilmesi kolay durumlar olduğu için izler genellikle sorunu belirtmez. Karenin düşmesinin nedeni bu titreme olabilir mi? Kesinlikle evet. İlgili içeriği oluşturmak için kullanılan çit süreleri 16,7 ms olmalıdır, ancak çerçevelerde bu süreye hiç yakın değiller belirir. Ekran ardışık düzeninin ne kadar sıkı bağlı zaman çizelgesinin etrafındaki titremenin, özellikle çerçeve.
Bu örnekte, çözüm, kullanıcılara
__vsync_retire_work_handler, iş sırasından özel bir sıraya alındı
kthread. Bu durum, ses dalgalanması fark edilir düzeyde iyileşmeye ve
zıplayan top testi. Sonraki izler, çok yakın olan sınır zamanlarını gösterir
16,7 ms.