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

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

Temel performans sorunları

Bir uygulamadaki kötü performansa yol açabilecek birçok sorun vardır, ancak uygulamanızda bakmanız gereken bazı genel sorunlar aşağıda belirtilmiştir:

Başlatma gecikmesi

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

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

  • 500 ms'den daha kısa sürede baştan başlatma. Sıfırdan başlatma, başlatılmakta olan uygulama sistemin belleğinde bulunmadığında gerçekleşir. Bu durum, uygulama yeniden başlatıldıktan sonra ilk kez başlatıldığında veya uygulama işlemi kullanıcı ya da sistem tarafından durdurulduğunda ortaya çıkar.

    Buna karşılık, hazırda başlatma işlemi, uygulama zaten arka planda çalışırken gerçekleşir. Soğuk başlatma, sistemin depolama alanından her şeyi yükleyip uygulamayı başlatması gerektiğinden sistem üzerinde en fazla çalışmayı gerektirir. Sıfırdan başlatmanın 500 ms veya daha kısa sürmesini sağlamaya çalışın.

  • P95 ve P99 gecikmeleri, ortalama gecikmeye çok yakındır. Başlatılması uzun süren uygulamalar, kötü bir kullanıcı deneyimine neden olur. Uygulama başlatmanın kritik yolunda işlemler arası iletişimler (IPC'ler) ve gereksiz G/Ç, kilit çakışmasıyla karşılaşabilir ve tutarsızlıklara yol açabilir.

Kaydırma sorunu

Jank, sistemin istediğiniz 60 Hz veya daha yüksek kadansta ekrana çerçeveler oluşturabilmesi ve çerçeve sağlayamadığında meydana gelen görsel kesintiyi tanımlayan terimdir. Jank, kaydırma yaparken daha belirgin. Uygulamanın içeriği oluşturması, sistemdeki bir karenin süresinden daha uzun sürdüğünden, bir veya daha fazla kare için hareket durakladığında Jank görünür.

Uygulamalar 90 Hz yenileme hızlarını hedeflemelidir. Geleneksel oluşturma hızları 60 Hz'dir ancak yeni cihazların birçoğu, kaydırma gibi kullanıcı etkileşimleri sırasında 90 Hz modunda çalışır. Bazı cihazlar 120 Hz'e kadar 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ündeki Geliştirici Seçenekleri > Yenileme hızını göster seçeneğini kullanarak bir yer paylaşımını 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 gecikmeler veya görsel titreme içermemelidir.

Güç verimsizlikleri

Çalışma yapmak pil şarjını azaltır ve gereksiz iş yapmak pil ömrünü azaltır.

Kodda yeni nesnelerin oluşturulmasından kaynaklanan bellek ayırmaları, sistemde önemli miktarda iş yapılmasının nedeni olabilir. Bunun nedeni, ayırmaların yalnızca Android Çalışma Zamanı'nın (ART) çalışmasını gerektirmekle kalmaz, aynı zamanda bu nesneleri daha sonra serbest bırakmanın (çöp toplama) da zaman ve çaba gerektirmesidir. Hem ayırma hem de toplama, özellikle geçici nesneler için çok daha hızlı ve verimlidir. Eskiden mümkün olduğunca nesne ayırmaktan kaçınmak en iyi uygulama olsa da uygulamanız ve mimariniz için en mantıklı olanı yapmanızı öneririz. ART'ın yapabildiği şeyler düşünüldüğünde, sürdürülebilir olmayan kod riski nedeniyle yapılan tahsislerden tasarruf etmek en iyi uygulama değildir.

Ancak bunun için çaba sarf etmek gerekir. Bu nedenle, iç döngünüzde çok sayıda nesne ayırıyorsanız bu yöntemin performans sorunlarına yol açabileceğini unutmayın.

Sorunları belirleme

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

  1. Aşağıdaki kritik kullanıcı yolculuklarını belirleyip inceleyin:
    • Başlatıcı ve bildirim dahil olmak üzere genel başlatma akışları.
    • Kullanıcının verileri kaydırdığı ekranlar.
    • Ekranlar arasındaki geçişleri gösterir.
    • Gezinme veya müzik çalma gibi uzun süren akışlar.
  2. Aşağıdaki hata ayıklama araçlarını kullanarak önceki akışlarda neler olduğunu inceleyin:
    • Perfetto: Hassas zamanlama verileriyle cihazın tamamında neler olduğunu görmenize olanak tanır.
    • Bellek Profil Aracı: Yığında hangi bellek ayırmalarının gerçekleştiğini görmenizi sağlar.
    • Simpleperf: Belirli bir süre boyunca hangi işlev çağrılarının en fazla CPU'yu kullandığını gösteren bir grafiği gösterir. Systrace'te uzun süren bir şeyi tanımladığınızda, ancak nedenini bilmediğinizde Simpleperf ek bilgiler sağlayabilir.

Bu performans sorunlarını anlamak ve hata ayıklamak için bağımsız test çalıştırmalarının manuel olarak hatalarını ayıklamak çok önemlidir. 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'daki vitals verileri: Play Console'da metrikleri belirli bir kullanıcı yolculuğuna göre daraltamazsınız. Yalnızca uygulama genelindeki genel olumsuzluğu bildirir.
      • FrameMetricsAggregator ile özel ölçüm: Belirli bir iş akışı sırasında jank metriklerini kaydetmek için FrameMetricsAggregator kullanabilirsiniz.
    • Laboratuvar testleri
      • Makrobenchmark ile kaydırma.
      • Makrobenchmark, tek bir kullanıcı yolculuğunu kapsayan dumpsys gfxinfo komutlarını kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğunda olumsuzluktaki değişimi anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü vurgulayan RenderTime metrikleri, regresyonları veya iyileştirmeleri tanımlamak için kötü 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. Uygulama Bağlantısı doğrulamalarının başarısız olmasına yol açabilecek nedenler aşağıda belirtilmiştir.

  • Amaç filtresi kapsamları: Uygulamanızın yanıt verebileceği URL'lerin amaç filtrelerine yalnızca autoVerify ekleyin.
  • Doğrulanmamış protokol anahtarları: Doğrulanmamış sunucu tarafı ve alt alan 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 olur. Örneğin, HTTPS bağlantılarını doğrulamadan bağlantıları HTTP'den HTTPS'ye (ör. example.com) 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 için Uygulama Bağlantılarını doğrulamamasına neden olabilir.
  • Sunucular güvenilir değil: Sunucularınızın istemci uygulamalarınıza bağlanabildiğinden emin olun.

Uygulamanızı performans analizi için ayarlama

Uygulamalardan doğru, tekrarlanabilir ve işlem yapılabilir karşılaştırmalar almak için ayarları doğru şekilde yapmak çok önemlidir. Gürültü kaynaklarını azaltırken üretime mümkün olduğunca yakın bir sistemde test yapın. Aşağıdaki bölümlerde, test kurulumu hazırlamak için uygulayabileceğiniz APK'ya ve sisteme özel bazı adımlar gösterilmektedir. Bu adımlardan bazıları kullanım alanına özeldir.

İzleme noktaları

Uygulamalar, kodlarını özel izleme etkinlikleri ile ayarlayabilir.

İzler yakalanırken izleme işlemi, bölüm başına yaklaşık 5 μs'lik küçük bir ek yüke neden olur. Bu nedenle, bu yöntemi her yöntemin başına yerleştirmeyin. 0,1 ms'den büyük iş parçalarının izlenmesi, performans sorunlarına dair önemli bilgiler sağlayabilir.

APK ile ilgili dikkat edilmesi gereken noktalar

Hata ayıklama varyantları, yığın örnekleriyle ilgili sorunların giderilmesi ve bunların simgeleştirilmesi açısından faydalı olabilir ancak bu varyantların performans üzerinde ciddi etkileri vardır. 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 manifest dosyalarında profileable android:shell="true" kullanabilir.

Üretim düzeyinde kod daraltma yapılandırmanızı kullanın. Uygulamanızın kullandığı kaynaklara bağlı olarak bu durum, performansı önemli ölçüde etkileyebilir. Bazı ProGuard yapılandırmaları iz noktalarını kaldırır. Bu nedenle, üzerinde test çalıştırdığınız yapılandırma için bu kuralları kaldırabilirsiniz.

Derleme

Cihazdaki uygulamanızı bilinen bir durumla (genellikle speed veya speed-profile) derleyin. Arka plan tam zamanında (JIT) etkinliği önemli ölçüde performans yüküne sahip olabilir ve bu etkinliğe genellikle test çalıştırmaları arasında APK'yı yeniden yüklüyorsanız ulaşırsınız. Bunu yapmak için aşağıdaki komutu kullanabilirsiniz:

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, bunları kullanmaya karar verirseniz beklediğiniz verileri topladıklarını onaylayın. Profiller şu konumda bulunur:

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

Makrobenchmark, derleme modunu doğrudan belirtmenizi sağlar.

Sistemle ilgili dikkat edilmesi gereken noktalar

Düşük seviye ve yüksek doğruluk oranına sahip ö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 mikro karşılaştırmalar için lockClocks komut dosyası kullanabilirsiniz. Bu komut dosyaları, diğer işlevlerinin yanı sıra aşağıdakileri 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.

Uygulama başlatma, DoU testi ve jank testi gibi kullanıcı deneyimi odaklı testler için lockClocks komut dosyası kullanılması önerilmez. Ancak bu komut dosyası, Microbenchmark testlerinde gürültüyü azaltmak için gerekli olabilir.

Mümkün olduğunda, ölçümlerinizdeki gürültüyü azaltabilecek ve ölçüm hatalarını önleyebilecek Makrobenchmark gibi bir test çerçevesi kullanabilirsiniz.

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

Trambolin etkinliği, uygulamanın başlatma süresini gereksiz yere uzatabilir ve uygulamanızın bunu yapıp yapmadığının farkında olmak önemlidir. Aşağıdaki örnek izde gösterildiği gibi, ilk etkinlik tarafından herhangi bir kare çizilmeden bir activityStart hemen ardından başka bir activityStart gelir.

alternatif metin Şekil 1. Trambolin aktivitesini 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.

Sık GC'leri tetikleyen gereksiz ayırmalar

Atık toplama (GC) işlemlerinin, Systrace'te beklediğinizden daha sık gerçekleştiğini görebilirsiniz.

Aşağıdaki örnekte, uzun süreli bir işlem sırasında her 10 saniye, uygulamanın zaman içinde gereksiz ama tutarlı bir şekilde harcama yapıyor olabileceğini gösterir:

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

Bellek Profil Aracı'nı kullanırken ayırmaların büyük çoğunluğunu belirli bir çağrı yığınının yaptığını da fark edebilirsiniz. Bu, kodun bakımını zorlaştırabileceğinden tüm ayırmaları etkin bir şekilde ortadan kaldırmanıza gerek yoktur. Bunun yerine, ayırmaların hotspot'ları üzerinde çalışarak başlayın.

Pis çerçeveler

Grafik ardışık düzeni nispeten karmaşıktır ve kullanıcının nihayetinde karenin atlandığını görüp görmeyeceğini belirlemede bazı ince ayrıntılar olabilir. Bazı durumlarda platform, arabelleğe alma yöntemini kullanarak bir çerçeveyi "kurtarabilir". Ancak uygulamanızın bakış açısından sorunlu kareleri belirlemek için bu nüansın çoğunu yok sayabilirsiniz.

Uygulamada çok az bir çalışma gerektirmeden kareler çizilirken Choreographer.doFrame() iz noktaları 60 FPS'lik bir cihazda 16, 7 ms'lik bir tempoda gerçekleşir:

alternatif metin Şekil 3. Sık kullanılan 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örürsünüz ancak ayrılan 16,7 ms'den fazla zaman almadıkları için bu sorun değildir:

alternatif metin Şekil 4. Sık sık kullanılan hızlı kareleri periyodik olarak gerçekleşen patlamalarla gösteren bir iz.

Bu düzenli tempoda bir kesinti gördüğünüzde, Şekil 5'te gösterildiği gibi çetin bir kare olur:

alternatif metin Şekil 5. Kötü bir kare gösteren iz.

Bunları tespit etme alıştırması yapabilirsiniz.

alternatif metin Şekil 6. Daha kötü kareler gösteren bir iz.

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

Zayıf kareleri tanımlama ve bunların nedenlerini ayıklama hakkında daha fazla bilgi edinmek için Yavaş oluşturma bölümüne bakın.

Sık karşılaşılan RecyclerView hataları

RecyclerView yedekleme verilerinin tamamının gereksiz şekilde geçersiz kılınması, uzun kare oluşturma sürelerine ve olumsuzluğa neden olabilir. 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ını önlemenin yolları için Dinamik veriler sunma bölümüne bakın.

İç içe yerleştirilmiş her RecyclerView doğru şekilde desteklenmiyorsa dahili RecyclerView her seferinde tamamen yeniden oluşturulabilir. İç içe yerleştirilmiş her RecyclerView iç RecyclerView arasında bir RecycledViewPool ayarlayarak görüntülemelerin geri dönüştürülebilmesini sağlayın.

Yeterli verinin önceden getirilmemesi veya önceden getirilmemesi, kullanıcının sunucudan daha fazla veri beklemesi gerektiğinde kaydırma listesinin sonuna ulaşmayı zorlaştırabilir. Bu, teknik olarak olumsuz olmasa da, hiçbir çerçeve son tarihi kaçırılmadığı için, zamanlamayı ve önceden getirme miktarını değiştirerek kullanıcı deneyimini önemli ölçüde iyileştirebilirsiniz. Böylece kullanıcının verileri beklemek zorunda kalmazsınız.

Uygulamanızda hata ayıklama

Uygulamanızın performansındaki hataları ayıklamak için kullanabileceğiniz farklı yöntemler aşağıda verilmiştir. Sistem izlemeye ve Android Studio profil aracını kullanmaya genel bakış için aşağıdaki videoyu izleyin.

Systrace ile uygulama başlatma hatalarını ayıklama

Uygulama başlatma sürecine genel bir bakış için Uygulama başlatma süresi'ne, sistem izlemeye genel bakış için de aşağıdaki videoyu izleyin.

Aşağıdaki aşamalarda başlatma türlerini netleştirebilirsiniz:

  • Baştan başlatma: Kayıtlı durum olmadan yeni bir süreç oluşturmaya başlayın.
  • Hazır başlatma: İşlemi yeniden kullanırken etkinliği yeniden oluşturur veya işlemi kaydedilmiş durumda yeniden oluşturur.
  • Çalışırken başlatma: Etkinliği yeniden başlatır ve enflasyonla başlar.

Systrace'leri cihazdaki Sistem İzleme uygulamasıyla yakalamanızı öneririz. Android 10 ve sonraki sürümler için Perfetto'yu kullanın. Android 9 ve önceki sürümler için Systrace'i kullanın. İzleme dosyalarını web tabanlı Perfetto iz görüntüleyici ile görüntülemenizi de öneririz. Daha fazla bilgi için Sistem izlemeye genel bakış sayfasını inceleyin.

Dikkat edilecek bazı noktalar şunlardır:

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

  • 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 çalışmayı düşünün.

  • Eşzamanlı GC: Bu yaygın bir durumdur ve nispeten düşük bir etkiye sahiptir. Ancak bu sorunu sık yaşıyorsanız Android Studio bellek profil aracı ile araştırabilirsiniz.

  • G/Ç: başlatma sırasında gerçekleştirilen G/Ç'yi kontrol edin ve uzun bekleme durumları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 plan çalışmasına dikkat edin.

Daha iyi uygulama başlatma metriği raporlaması için, uygulama açısından başlatma tamamlandığında reportFullyDrawn'i çağırmanızı öneririz. reportFullyDrawn işlevini kullanmayla ilgili daha fazla bilgi edinmek için Tam gösterime kadar geçen süre bölümüne bakın. Perfetto iz işlemcisi aracılığıyla RFD tanımlı başlangıç zamanlarını ayıklayabilirsiniz. Bu durumda, kullanıcının görebildiği bir izleme etkinliği yayınlanır.

Cihazda Sistem İzleme özelliğini kullanma

Bir cihazda sistem izlemeyi yakalamak için Sistem İzleme adlı sistem düzeyindeki uygulamayı kullanabilirsiniz. Bu uygulama, cihazı takmanıza veya adb uygulamasına bağlamanıza gerek kalmadan cihazdaki izleri kaydetmenize olanak tanır.

Android Studio Memory Profiler'ı kullanma

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

GC'lerin neden ve ne sıklıkta meydana geldiğini izlemek için Bellek Profil Aracı'nı kullanma bilgilerinden yararlanarak uygulamanızdaki bellek sorunlarını düzeltebilirsiniz.

Uygulama belleğinin profilini çıkarmak için aşağıdaki adımları uygulayın:

  1. Bellek sorunlarını algılama.

    Odaklanmak istediğiniz kullanıcı yolculuğunun bellek profili oluşturma oturumunu kaydedin. Şekil 7'de gösterildiği gibi, Şekil 8'de gösterildiği gibi sonuçta GC'lere yol açan, artan bir nesne sayısına bakın.

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

    alternatif metin Şekil 8. Atık toplama.

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

  2. Bellek baskısı etkin noktalarını teşhis etme.

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

    alternatif metin Şekil 9. Ayırmalar ve Sığ Boyut değerleri.

    Bu verileri sıralamanın birden çok 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üzenleme: Bir bellek havuzundan önbelleğe alınan veya yeniden kullanılan nesneler üreten sınıfları bulmak istediğinizde kullanışlıdır.

      Örneğin, bir uygulamanın saniyede "Vertex" adında 2.000 sınıf nesne oluşturduğunu görürseniz Ayırmalar sayısını saniyede 2.000 artırır ve sınıfa göre sıralama yaparken bunu 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üzenleme: Bir döngünün içinde veya çok sayıda ayırma işi yapan belirli bir işlevin içinde olma gibi belleğin ayrıldığı yoğun bir yol olduğunu bulmak istediğinizde kullanışlıdır.

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

    • Korunan Boyut: Nesneye bağlı toplam belleği ve yalnızca nesnenin başvurduğu referansları gösterir. Karmaşık nesnelerden kaynaklanan bellek basıncını izlemek için faydalıdır. Bu değeri elde etmek için şekil 10'da gösterildiği gibi tam bellek dökümünü alın ve Şekil 11'de gösterildiği gibi Korunan Boyut 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ı azalttığında 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 işlemin ardından GC'ler arasında işlemin daha uzun sürdüğünü görebilirsiniz.

    Bellek iyileştirmelerinin en önemli etkileri şu şekildedir:

    • Uygulama sürekli olarak bellek baskısı yaratmazsa bellek yetersizliğinin kapanması büyük olasılıkla azalır.
    • Daha az GC'ye sahip olmak, özellikle P99'da jank metriklerini iyileştirir. Bunun nedeni, GC'lerin CPU çakışmasına neden olarak, GC gerçekleşirken oluşturma görevlerinin ertelenmesine yol açmasıdır.