Uygulama performansını ölçmeye genel bakış

Bu belge, uygulamanızdaki önemli performans sorunlarını belirleyip düzeltmenize yardımcı olur.

Temel performans sorunları

Uygulamaların kötü performans göstermesine yol açabilecek birçok sorun vardır, ancak uygulamanızda dikkat etmeniz gereken bazı yaygın sorunlar şunlardır:

Başlatma gecikmesi

Başlatma gecikmesi, uygulama simgesine, bildirime veya başka bir giriş noktasına dokunma ile kullanıcı verilerinin ekranda gösterilmesi arasında geçen süredir.

Uygulamalarınızda aşağıdaki başlangıç hedeflerini hedefleyin:

  • 500 ms'den kısa sürede baştan başlatma. Başlatılan uygulama, çalıştırılmakta olan uygulama sistemin belleğinde olmadığında gerçekleşir. Bu durum, uygulama yeniden başlatmadan sonra ilk başlatıldığında veya uygulama işlemi kullanıcı ya da sistem tarafından durdurulduğunda gerçekleşir.

    Buna karşılık, uygulama arka planda çalışırken hazır başlatma gerçekleşir. Soğuk başlatma, depolama alanındaki her şeyi yükleyip uygulamanın başlatılması gerektiğinden sistem üzerinde en fazla çalışma yapılmasını gerektirir. Baştan başlatmanın 500 ms veya daha kısa sürmesini deneyin.

  • P95 ve P99 gecikmeleri ortanca değere çok yakındır. Uygulamanın başlatılması uzun sürerse kullanıcı deneyimini olumsuz etkiler. Uygulama başlatmanın kritik yolu sırasında işlemler arası iletişimler (IPC'ler) ve gereksiz G/Ç, kilit anlaşmazlığıyla karşılaşabilir ve tutarsızlıklara yol açabilir.

Kaydırma engeli

Jank, sistem tarafından istenen 60 Hz veya daha yüksek kadansta çerçeveler oluşturamadığında ve kareler sağlayamadığında ortaya çıkan görsel kesintiyi tanımlayan terimdir. Jank'ı en çok kaydırma sırasında görünürken, akıcı bir şekilde animasyonlu bir akış yerine hızlanmalar yaşanır. Uygulamanın içeriği oluşturması, sistemdeki bir karenin süresinden daha uzun sürdüğü için Jank, hareket boyunca bir veya daha fazla kare boyunca hareket durakladığında görünür.

Uygulamalar 90 Hz yenileme hızlarını hedeflemelidir. Geleneksel oluşturma hızları 60 Hz'dir ancak yeni çoğu cihaz, kaydırma gibi kullanıcı etkileşimleri sırasında 90 Hz modunda çalışır. Bazı cihazlar 120 Hz'e kadar olan daha yüksek hızları destekler.

Bir cihazın belirli bir zamanda hangi yenileme hızını kullandığını görmek için Hata Ayıklama bölümünde Geliştirici Seçenekleri > Yenileme hızını göster'i kullanarak bir yer paylaşımı etkinleştirin.

Düzgün olmayan geçişler

Bu durum, sekmeler arasında geçiş yapma veya yeni bir etkinlik yükleme gibi etkileşimler sırasında belirgindir. Bu tür geçişler, akıcı animasyonlar olmalı ve gecikme veya görsel titreme içermemelidir.

Güç verimsizlikleri

İş yapmak pil şarjını azaltır ve gereksiz işler yapmak pil ömrünü kısaltır.

Kodda yeni nesneler oluşturulmasından kaynaklanan bellek ayırmaları, sistemde önemli işler yapılmasının nedeni olabilir. Bunun nedeni, ayırma işlemlerinin yalnızca Android Çalışma Zamanı (ART) tarafından çaba gerektirmesi değil, bu nesnelerin daha sonra boşaltılması (çöp toplama) için de zaman ve çaba gerektirmesidir. Hem ayırma hem de toplama, özellikle geçici nesneler için çok daha hızlı ve daha verimlidir. Eskiden mümkün olduğunca nesne ayırmaktan kaçınmak en iyi uygulamaydı ancak uygulamanız ve mimariniz için en mantıklı olanı yapmanızı öneririz. ART'ın yapabildiği şeyler göz önünde bulundurulduğunda, tahsislerden tasarruf edilmesinin sağlanamayacak kod riski altında olması en iyi uygulama değildir.

Bununla birlikte, bu işlem çaba gerektirir. Bu nedenle, iç döngünüzde çok sayıda nesne ayırırsanız performans sorunlarına katkıda bulunabileceğini unutmayın.

Sorunları belirleme

Performans sorunlarını belirlemek ve düzeltmek için aşağıdaki iş akışını öneririz:

  1. Aşağıdaki kritik kullanıcı yolculuklarını belirleyin ve inceleyin:
    • Başlatıcı ve bildirimler de dahil olmak üzere yaygın başlatma akışları.
    • Kullanıcının veriler arasında gezindiği ekranlar.
    • Ekranlar arasındaki geçişler.
    • Gezinme veya müzik çalma gibi uzun süreli akışlar.
  2. Aşağıdaki hata ayıklama araçlarını kullanarak önceki akışlar sırasında neler olduğunu inceleyin:
    • Perfetto: Hassas zamanlama verileriyle cihaz genelinde neler olduğunu görmenize olanak tanır.
    • Bellek Profil Aracı: Yığında hangi bellek ayırmalarının gerçekleştiğini görmenize olanak tanır.
    • Simpleperf: Hangi işlev çağrılarının belirli bir süre boyunca en fazla CPU'yu kullandığını gösteren bir alev grafiği. Systrace'te uzun sürecek bir şey tespit ettiğinizde ama nedenini bilmediğinizde Simpleperf size ek bilgiler sağlayabilir.

Bu performans sorunlarını anlamak ve hata ayıklamak için her bir test çalıştırmasında manuel olarak hata ayıklamak büyük önem taşır. Birleştirilmiş verileri analiz ederek önceki adımları değiştiremezsiniz. Bununla birlikte, kullanıcıların gerçekte ne gördüğünü anlamak ve regresyonların ne zaman olabileceğini belirlemek için otomatik testlerde ve sahada metrik toplamayı ayarlamak önemlidir:

  • Başlatma akışları
  • Jank
    • Alan metrikleri
      • Play Console çerçeve verileri: Play Console'da metrikleri belirli bir kullanıcı yolculuğuna indirgeyemezsiniz. Yalnızca uygulama genelindeki genel olumsuzlukları raporlar.
      • FrameMetricsAggregator ile özel ölçüm: Belirli bir iş akışı sırasında jank metriklerini kaydetmek için FrameMetricsAggregator kullanabilirsiniz.
    • Laboratuvar testleri
      • Macrobenchmark ile kaydırma.
      • Macrobenchmark, tek bir kullanıcı yolculuğunu temsil eden dumpsys gfxinfo komutlarını kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğundaki olumsuzlukları anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü gösteren RenderTime metrikleri, regresyonları veya iyileştirmeleri tanımlamak için hatalı karelerin sayısından daha önemlidir.

Uygulama Bağlantıları, web sitenize ait olduğu doğrulanan web sitenizin URL'sini temel alan derin bağlantılardır. Aşağıda, App Link doğrulamalarının başarısız olmasına yol açabilecek nedenler belirtilmiştir.

  • Intent filtresi kapsamları: Yalnızca uygulamanızın yanıt verebileceği URL'ler için intent filtrelerine autoVerify ekleyin.
  • Doğrulanmamış protokol anahtarları: Doğrulanmamış sunucu tarafı ve alt alan adı yönlendirmeleri, güvenlik riski olarak kabul edilir ve doğrulamada başarısız olur. Tüm autoVerify bağlantılarının başarısız olmasına neden olurlar. Örneğin, HTTPS bağlantılarını doğrulamadan HTTP'den HTTPS'ye (ör. example.com'dan www.example.com'a) yönlendirmek doğrulama işleminin başarısız olmasına neden olabilir. Amaç filtreleri ekleyerek Uygulama Bağlantılarını doğruladığınızdan emin olun.
  • Doğrulanamayan bağlantılar: Test amacıyla doğrulanamayan bağlantılar eklemek, sistemin uygulamanızın uygulama bağlantılarını doğrulamamasına neden olabilir.
  • Güvenilir olmayan sunucular: Sunucularınızın, istemci uygulamalarınıza bağlanabildiğinden emin olun.

Uygulamanızı performans analizi için ayarlama

Bir uygulamadan doğru, tekrarlanabilir ve işlem yapılabilir karşılaştırmalar elde etmek için ayarları doğru şekilde yapmak önemlidir. Gürültü kaynaklarını bastırarak, üretime olabildiğince yakın bir sistemde test yapın. Aşağıdaki bölümlerde, bir test kurulumu hazırlamak için uygulayabileceğiniz, APK'ya ve sisteme özgü bazı adımlar gösterilmektedir. Bu adımlardan bazıları kullanım alanına özgüdür.

İzleme noktaları

Uygulamalar, kodları için özel izleme etkinlikleri kullanabilir.

İzler yakalanırken izleme işlemi, bölüm başına yaklaşık 5 μs'lik küçük bir ek yük oluşturur. Bu nedenle, izlemeyi her yöntemin yanına koymayın. 0,1 ms'den büyük iş parçalarının takibi, performans sorunları hakkında önemli bilgiler sağlayabilir.

APK ile ilgili dikkat edilmesi gereken noktalar

Hata ayıklama varyantları, yığın örnekleriyle ilgili sorunların giderilmesi ve yığın örneklerinin simgeselleştirilmesi açısından faydalı olabilir ancak performansı ciddi şekilde etkiler. Android 10 (API Düzeyi 29) ve sonraki sürümleri çalıştıran cihazlar, sürüm derlemelerinde profil oluşturmayı etkinleştirmek için manifestlerinde profileable android:shell="true"'i kullanabilir.

Üretim düzeyindeki kod küçültme yapılandırmanızı kullanın. Uygulamanızın kullandığı kaynaklara bağlı olarak, bu durum performans üzerinde önemli bir etki yaratabilir. Bazı ProGuard yapılandırmaları izleme noktalarını kaldırdığından, üzerinde testleri çalıştırdığınız yapılandırma için bu kuralları kaldırmayı düşünebilirsiniz.

Derleme

Cihazda uygulamanızı bilinen bir durumla (genellikle speed veya speed-profile) derleyin. Arka plan tam zamanında (JIT) etkinlik, performansta önemli ölçüde ek yüke neden olabilir. Test çalıştırmaları arasında APK'yı yeniden yüklüyorsanız bu durumla sık sık karşılaşırsınız. Aşağıda bu işlemi gerçekleştirmek için kullanılabilecek bir komut verilmiştir:

adb shell cmd package compile -m speed -f com.google.packagename

speed derleme modu, uygulamayı tamamen derler. speed-profile modu, uygulamayı, uygulama kullanımı sırasında toplanan, kullanılan kod yollarının profiline göre derler. Profilleri tutarlı ve doğru bir şekilde toplamak zor olabilir. Bu nedenle, profilleri kullanmaya karar verirseniz bunların beklediğiniz bilgileri topladığını doğrulayın. Profiller şu konumda bulunur:

/data/misc/profiles/ref/[package-name]/primary.prof

Macrobenchmark doğrudan derleme modunu belirtmenizi sağlar.

Sistemle ilgili olarak göz önünde bulundurulması gerekenler

Düşük düzey ve yüksek doğrulukta ölçümler için cihazlarınızı kalibre edin. Aynı cihazda ve aynı işletim sistemi sürümünde A/B karşılaştırmaları çalıştırın. Aynı cihaz türünde bile performansta önemli farklılıklar olabilir.

Root erişimli cihazlarda Microbenchmark'lar için bir lockClocks komut dosyası kullanabilirsiniz. Bu komut dosyaları, diğer işlevlerinin yanı sıra şunları yapar:

  • CPU'ları sabit bir frekansa yerleştirin.
  • Küçük çekirdekleri devre dışı bırakın ve GPU'yu yapılandırın.
  • Termal kısıtlamayı devre dışı bırakın.

Uygulama başlatma, DoU testi ve jank testi gibi kullanıcı deneyimi odaklı testler için lockClocks komut dosyası kullanmanızı önermeyiz ancak Mikrobenchmark testlerinde gürültüyü azaltmak için gerekli olabilir.

Mümkün olduğunda, ölçümlerinizdeki gürültüyü azaltabilecek ve ölçümlerin yanlışlığını önleyebilecek Macrobenchmark gibi bir test çerçevesi kullanmayı düşünün.

Yavaş uygulama başlatma: Gereksiz trambolin etkinliği

Trambolin etkinliği, uygulama başlatma süresini gereksiz yere uzatabilir. Bu nedenle, uygulamanızın bunu yapıp yapmadığını bilmeniz önemlidir. Aşağıdaki örnek izlemede gösterildiği gibi bir activityStart hemen ardından başka bir activityStart gelir ve ilk etkinlik hiçbir kare çizmez.

alternatif_metin Şekil 1. Trambolin etkinliğini gösteren bir iz.

Bu durum hem bildirim giriş noktasında hem de normal bir uygulama başlatma giriş noktasında gerçekleşebilir. Genellikle yeniden düzenleme yaparak bu sorunu çözebilirsiniz. Örneğin, bu etkinliği başka bir etkinlik çalıştırılmadan önce kurulumu gerçekleştirmek için kullanıyorsanız bu kodu yeniden kullanılabilir bir bileşene veya kitaplığa dahil edin.

GC'leri sık tetikleyen gereksiz ayırmalar

Çöp toplamaların (GC'ler), Systrace'te beklediğinizden daha sık gerçekleştiğini görebilirsiniz.

Aşağıdaki örnekte, uzun çalışan bir işlem sırasında her 10 saniyede bir, uygulamanın zaman içinde gereksiz ama tutarlı bir şekilde ayırma yapabileceğini gösterir:

alternatif_metin Şekil 2. GC etkinlikleri arasındaki boşluğu gösteren bir iz.

Ayrıca, Bellek Profil Aracı'nı kullanırken ayırmaların büyük çoğunluğunu belirli bir çağrı yığınının oluşturduğunu fark edebilirsiniz. Kodun bakımını zorlaştırabileceği için tüm ayırmaları agresif bir şekilde ortadan kaldırmanız gerekmez. Bunun yerine, tahsislerin hotspot'ları üzerinde çalışarak başlayın.

Janky çerçeveler

Grafik ardışık düzeni nispeten karmaşıktır ve kullanıcının nihayetinde düşen kare görüp görmeyeceğini belirlemede bazı farklılıklar olabilir. Bazı durumlarda platform, arabelleğe alma özelliğini kullanarak bir çerçeveyi "kurtarabilir". Bununla birlikte, sorunlu kareleri uygulamanız açısından tanımlamak için bu nüansların çoğunu göz ardı edebilirsiniz.

Uygulamanın çok az işlem yapması gerekmeden kareler çizildiğinde 60 FPS'lik bir cihazda Choreographer.doFrame() izleme noktaları 16, 7 ms'lik bir kadansta oluşur:

alternatif_metin Şekil 3. Sık hızlı kareleri gösteren bir iz.

Uzaklaştırıp izde gezinirseniz bazen karelerin tamamlanmasının biraz daha uzun sürdüğünü görebilirsiniz. Yine de kendilerine ayrılan 16,7 ms. süreden daha uzun sürmedikleri için sorun olmaz:

alternatif_metin Şekil 4. Periyodik iş patlamaları içeren sık hızlı kareleri gösteren bir iz.

Bu düzenli kadansta bir kesinti olduğunda bu, Şekil 5'te gösterildiği gibi stabil bir karedir:

alternatif_metin Şekil 5. Çirkin bir çerçeveyi gösteren iz.

Bunları tespit ederek alıştırma yapabilirsiniz.

alternatif_metin Şekil 6. Daha hantal kareleri gösteren bir iz.

Bazı durumlarda, hangi görünümlerin şişirildiği veya RecyclerView uygulamasının ne yaptığı hakkında daha fazla bilgi için izleme noktasını yakınlaştırmanız gerekir. Bazı durumlarda ise daha ayrıntılı inceleme yapmanız gerekebilir.

Titreyen çerçeveleri belirleme ve bunların nedenlerini ayıklama hakkında daha fazla bilgi edinmek için Yavaş oluşturma bölümüne bakın.

Yaygın RecyclerView hataları

RecyclerView yedekleme verilerinin tamamının gereksiz yere geçersiz kılınması, uzun kare oluşturma sürelerine ve gecikme yaşanmasına yol açabilir. Bunun yerine, güncellenmesi gereken görüntüleme sayısını en aza indirmek için yalnızca değişen verileri geçersiz kılın.

İçeriğin tamamen değiştirilmesi yerine güncellenmesine neden olan maliyetli notifyDatasetChanged() çağrılarından kaçınmanın yolları için Dinamik verileri sunma konusuna bakın.

İç içe yerleştirilmiş her RecyclerView öğesini düzgün bir şekilde desteklemezseniz dahili RecyclerView her seferinde tamamen yeniden oluşturulabilir. Görünümlerin her bir iç RecyclerView arasında geri dönüştürülebilmesi için iç içe yerleştirilmiş her RecyclerView öğesinde bir RecycledViewPool ayarlanmış olmalıdır.

Yeterli veriyi önceden getirmemek veya zamanında getirmemek, kullanıcının sunucudan daha fazla veri beklemesi gerektiğinde kaydırma listesinin sonuna ulaşmayı sarsabilir. Bu teknik açıdan olumsuz olmasa da hiçbir çerçeve için son tarih kaçırılmadığından, önceden getirme zamanlamasını ve miktarını değiştirerek kullanıcı deneyimini önemli ölçüde iyileştirebilirsiniz. Böylece, kullanıcı verileri beklemek zorunda kalmaz.

Uygulamanızda hata ayıklama

Aşağıda, uygulamanızın performansıyla ilgili hata ayıklama yöntemleri yer almaktadır. Sistem izleme ve Android Studio profil aracını kullanmaya genel bir bakış için aşağıdaki videoyu izleyin.

Systrace ile uygulama başlatmada hata ayıklama

Uygulama başlatma işlemine genel bir bakış için Uygulama başlatma süresi bölümüne ve sistem izlemeye genel bakış için aşağıdaki videoyu izleyin.

Başlangıç türlerini aşağıdaki aşamalarda netleştirebilirsiniz:

  • Sıfırdan başlatma: Kayıtlı durumu olmayan yeni bir işlem oluşturmaya başlayın.
  • Hazır başlatma: İşlemi yeniden kullanırken etkinliği yeniden oluşturur ya da kaydedilen durumda işlemi yeniden oluşturur.
  • Çalışır durumda başlatma: Etkinliği yeniden başlatır ve enflasyon düzeyinde başlar.

Systra'ları Cihazdaki Sistem İzleme uygulamasıyla yakalamanızı öneririz. Android 10 ve sonraki sürümlerde Perfetto'yu kullanın. Android 9 ve önceki sürümlerde Systrace'i kullanın. İzleme dosyalarını web tabanlı Perfetto izleme görüntüleyici ile görüntülemenizi de öneririz. Daha fazla bilgi için Sistem izlemeye genel bakış bölümüne bakın.

Dikkat etmeniz gereken bazı noktalar şunlardır:

  • Çakışmayı izleme: Monitörle korunan kaynaklar için rekabet, uygulamanın başlatılmasında önemli ölçüde gecikmeye neden olabilir.

  • Eşzamanlı bağlayıcı işlemleri: Uygulamanızın kritik yolunda gereksiz işlemleri arayın. Gerekli bir işlem pahalıysa iyileştirmeler yapmak için ilgili platform ekibiyle birlikte çalışmayı düşünün.

  • Eşzamanlı GC: Bu yaygın bir durumdur ve nispeten düşüktür. Ancak bu durumla sık karşılaşıyorsanız Android Studio bellek profil aracını kullanarak konuyu inceleyebilirsiniz.

  • G/Ç: Başlatma sırasında gerçekleştirilen G/Ç'yi kontrol edin ve uzun tezgahlar olup olmadığına bakın.

  • Diğer iş parçacıklarında önemli etkinlik: Bunlar, kullanıcı arayüzü iş parçacığını etkileyebilir. Bu nedenle, başlatma sırasında arka planda çalışmaya dikkat edin.

Daha iyi uygulama başlatma metriği raporlaması için uygulama açısından başlatma tamamlandığında reportFullyDrawn numaralı telefonu çağırmanızı öneririz. reportFullyDrawn kullanımı hakkında daha fazla bilgi için Tam görüntüleme süresi bölümüne bakın. Perfetto iz işlemcisini kullanarak RFD tarafından tanımlanan başlangıç zamanlarını ayıklayabilirsiniz. Bu durumda, kullanıcı tarafından görülebilen bir izleme etkinliği yayınlanır.

Cihazda Sistem İzlemeyi kullan

Bir cihazda sistem izini yakalamak için Sistem İzleme adlı sistem düzeyinde uygulamayı kullanabilirsiniz. Bu uygulama, cihazı takmak veya adb cihazına bağlamak zorunda kalmadan cihazdaki izleri kaydetmenize olanak tanır.

Android Studio Bellek Profili Aracı'nı kullanma

Bellek sızıntılarından veya hatalı kullanım kalıplarından kaynaklanabilecek bellek basıncını incelemek için Android Studio Bellek Profil Aracı'nı kullanabilirsiniz. Nesne ayırmalarının canlı görünümünü sağlar.

GC'lerin neden ve ne sıklıkta gerçekleştiğini izlemek için Bellek Profili Aracı'ndaki bilgileri takip ederek uygulamanızdaki bellek sorunlarını düzeltebilirsiniz.

Uygulama belleğini profillemek için aşağıdaki adımları uygulayın:

  1. Bellek sorunlarını algılama.

    Odaklanmak istediğiniz kullanıcı yolculuğuna ait bellek profili oluşturma oturumunu kaydedin. Şekil 7'de gösterildiği gibi, nesne sayısında artış olup olmadığına bakın. Bu, Şekil 8'de gösterildiği gibi sonunda GC'lere yol açar.

    alternatif_metin Şekil 7. Nesne sayısı artırılıyor.

    alternatif_metin Şekil 8. Çöp toplama.

    Bellek baskısına neden olan kullanıcı yolculuğunu tanımladıktan sonra bellek baskısının temel nedenlerini analiz edin.

  2. Bellekte baskı olan sıcak noktaları teşhis edin.

    Şekil 9'da gösterildiği gibi, hem Ayırma Sayısı'nı hem de Sığ Boyut'u görselleştirmek için zaman çizelgesinde bir aralık seçin.

    alternatif_metin Şekil 9. Allocations ve Shallow Boyut değerleri.

    Bu verileri sıralamanın birden fazla yolu vardır. Aşağıda, her bir görünümün sorunları analiz etmenize nasıl yardımcı olabileceğine ilişkin bazı örnekler verilmiştir.

    • Sınıfa göre düzenle: Önbelleğe alınan veya bir bellek havuzundan yeniden kullanılan nesneler oluşturan sınıfları bulmak istediğinizde kullanışlıdır.

      Örneğin, bir uygulamanın saniyede "Vertex" adlı 2.000 sınıf nesne oluşturduğunu görürseniz Allocations (Ayırma Sayısı) her saniyede 2.000 artar ve bunu sınıfa göre sıralama yaparken görürsünüz. Atık oluşturmamak için bu nesneleri yeniden kullanmak istiyorsanız bellek havuzu uygulayın.

    • Çağrı yığınına göre düzenle: Belleğin ayrıldığı sıcak yolun nerede olduğunu bulmak istediğinizde (ör. bir döngü içinde veya çok fazla ayırma işi yapan belirli bir işlevin içinde) faydalıdır.

    • Sığ Boyut: Yalnızca nesnenin kendisinin belleğini izler. Çoğunlukla yalnızca temel değerlerden oluşan basit sınıfları izlemek için yararlıdır.

    • Tutulan Boyut: Nesneden kaynaklanan toplam belleği ve yalnızca nesnenin başvurduğu referansları gösterir. Karmaşık nesneler nedeniyle bellek basıncını takip etmek açısından yararlıdır. Bu değeri elde etmek için şekil 10'da gösterildiği gibi tam bir bellek dökümünü alın. Ardından, Şekil 11'de gösterildiği gibi Tutulan Boyut sütunu bir sütun olarak eklenir.

      alternatif_metin Şekil 10. Tam bellek dökümü.

      Tutulan Boyut sütunu.
      Şekil 11. Tutulan Boyut sütunu.

  3. Optimizasyonun etkisini ölçün.

    GC'ler daha belirgindir ve bellek optimizasyonlarının etkisini ölçmek daha kolaydır. Optimizasyon, bellek baskısını düşürdüğünde daha az GC görürsünüz.

    Optimizasyonun etkisini ölçmek için profil oluşturucu zaman çizelgesinde GC'ler arasındaki süreyi ölçün. Bu durumda, GC'ler arasında sürenin daha uzun olduğunu görebilirsiniz.

    Bellek iyileştirmelerinin nihai etkileri şunlardır:

    • Uygulama, bellek baskısına sürekli olarak etki etmezse bellek dışı kapanmalar muhtemelen daha az olur.
    • Daha az GC'ye sahip olmak, özellikle P99'da jank metriklerini iyileştirir. Bunun nedeni, GC'lerin CPU anlaşmazlığına yol açarak GC gerçekleşirken oluşturma görevlerinin ertelenmesidir.