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

Bu belge, uygulamanızdaki temel performans sorunlarını belirlemenize ve düzeltmenize yardımcı olur.

Temel performans sorunları

Bir uygulamada kötü performansa katkıda bulunabilecek birçok sorun vardır ancak uygulamanızda aramanız gereken yaygın sorunlardan bazıları şunlardır:

Başlatma gecikmesi

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

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

  • 500 ms'den kısa sürede baştan başlatma. Sıfırdan başlatma, başlatılan uygulama sistemin belleğinde bulunmadığında gerçekleşir. Bu durum, yeniden başlatmadan veya uygulama işlemi kullanıcı ya da sistem tarafından durdurulduktan sonra uygulamanın ilk kez başlatılmasıyla oluşur.

    Buna karşılık, uygulama arka planda çalışırken hazır durumda başlatma gerçekleşir. Sıfırdan başlatma, sistemin en çok çalışmasını gerektirir. Çünkü sistemin her şeyi depolamadan yüklemesi ve uygulamayı başlatması gerekir. Sıfırdan başlatma süresini 500 ms veya daha kısa tutmaya çalışın.

  • Ortanca gecikmeye çok yakın olan P95 ve P99 gecikmeleri. Uygulamanın başlatılması uzun sürdüğünde kullanıcı deneyimi olumsuz etkilenir. Uygulama başlatma işleminin kritik yolu sırasında süreçler arası iletişim (IPC) ve gereksiz G/Ç, kilit çekişmesine neden olabilir ve tutarsızlıklar oluşturabilir.

Kaydırma sırasında takılma

Jank, sistemin kareleri zamanında oluşturup sağlayamadığı ve bu nedenle karelerin ekrana istenen 60 Hz veya daha yüksek sıklıkta çizilemediği durumlarda oluşan görsel aksaklığı tanımlayan terimdir. Jank, kaydırma sırasında en belirgin şekilde görülür. Bu durumda, sorunsuz animasyonlu akış yerine aksaklıklar yaşanır. Uygulama, içeriği sistemdeki bir karenin süresinden daha uzun sürede oluşturduğunda hareket, bir veya daha fazla kare boyunca durakladığı için titreme oluşur.

Uygulamalar 90 Hz yenileme hızını hedeflemelidir. Geleneksel oluşturma hızları 60 Hz'dir ancak birçok yeni cihaz, kullanıcı etkileşimleri (ör. kaydırma) 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'i kullanarak bir yer paylaşımı etkinleştirin.

Sorunsuz olmayan geçişler

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

Güç verimsizlikleri

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

Kodda yeni nesneler oluşturmaktan kaynaklanan bellek ayırmaları, sistemde önemli iş yüküne neden olabilir. Bunun nedeni, yalnızca ayırmaların kendisi için Android çalışma zamanının (ART) çaba göstermesi gerekmemesi, aynı zamanda bu nesnelerin daha sonra serbest bırakılması (çöp toplama) için de zaman ve çaba gerekmesidir. Hem ayırma hem de toplama işlemleri, özellikle geçici nesneler için çok daha hızlı ve verimlidir. Mümkün olduğunda nesne ayırmaktan kaçınmak eskiden en iyi uygulama olsa da uygulamanız ve mimariniz için en mantıklı olanı yapmanızı öneririz. ART'nin yetenekleri göz önüne alındığında, sürdürülebilir olmayan kod riskiyle tahsislerden tasarruf etmek en iyi uygulama değildir.

Ancak bu işlem çaba gerektirir. Bu nedenle, iç döngünüzde çok sayıda nesne ayırıyorsanız bunun performans sorunlarına yol açabileceğini unutmayın.

Sorunları belirleme

Performans sorunlarını belirleyip 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 bildirimden başlatma dahil olmak üzere yaygın başlangıç akışları.
    • Kullanıcının veriler arasında kaydırdığı ekranlar.
    • Ekranlar arasındaki geçişler.
    • Gezinme veya müzik çalma gibi uzun süren akışlar.
  2. Aşağıdaki hata ayıklama araçlarını kullanarak önceki akışlar sırasında neler olduğunu inceleyin:
    • Perfetto: Tüm cihazda neler olduğunu kesin zamanlama verileriyle görmenizi sağlar.
    • Bellek Profiler: Yığında hangi bellek ayırmalarının yapıldığını görmenizi sağlar.
    • Simpleperf: Belirli bir süre boyunca hangi işlev çağrılarının en fazla CPU kullandığına dair bir alev grafiği gösterir. Systrace'te uzun süren bir işlemi belirlediğinizde ancak nedenini bilmediğinizde Simpleperf ek bilgiler sağlayabilir.

Bu performans sorunlarını anlamak ve hatalarını ayıklamak için tek tek test çalıştırmalarında manuel olarak hata ayıklama yapmanız gerekir. Önceki adımları, toplu verileri analiz ederek değiştiremezsiniz. Ancak kullanıcıların gerçekten ne gördüğünü anlamak ve gerilemelerin ne zaman meydana gelebileceğini belirlemek için otomatik testlerde ve sahada metrik toplama işlemini ayarlamak önemlidir:

  • Başlangıç akışları
  • Jank
    • Alan metrikleri
      • Play Console'daki kare hızıyla ilgili temel performans göstergeleri: Play Console'da metrikleri belirli bir kullanıcı yolculuğuyla sınırlandıramazsınız. Yalnızca uygulama genelindeki toplam jank'ı bildirir.
      • 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
      • Makro karşılaştırma testi, tek bir kullanıcı yolculuğunu kapsayan dumpsys gfxinfo komutlarını kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğu boyunca takılma varyasyonunu anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü vurgulayan RenderTime metrikler, gerilemeleri veya iyileştirmeleri belirlemek için kare sayısından daha önemlidir.

App Links, web sitenize ait olduğu doğrulanan web sitenizin URL'sine dayalı derin bağlantılardır. Aşağıda, uygulama bağlantısı doğrulamalarının başarısız olmasına neden olabilecek durumlar verilmiştir.

  • Intent filtresi kapsamları: Yalnızca uygulamanızın yanıt verebileceği URL'lerin intent filtrelerine autoVerify ekleyin.
  • Doğrulanmamış protokol geçişleri: Doğrulanmamış sunucu tarafı ve alt alan yönlendirmeleri güvenlik riski olarak kabul edilir ve doğrulama başarısız olur. Bu durum, tüm autoVerify bağlantılarının başarısız olmasına neden olur. Örneğin, HTTPS bağlantıları doğrulanmadan bağlantıların HTTP'den HTTPS'ye (ör. example.com'dan www.example.com'a) yönlendirilmesi doğrulamanın başarısız olmasına neden olabilir. Niyet filtreleri ekleyerek uygulama bağlantılarını doğruladığınızdan emin olun.
  • Doğrulanabilir olmayan bağlantılar: Test amacıyla doğrulanabilir olmayan bağlantılar eklemek, sistemin uygulamanız için 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 uygulanabilir karşılaştırma ölçümleri elde etmek için doğru şekilde ayarlama yapmak önemlidir. Gürültü kaynaklarını bastırırken mümkün olduğunca üretime yakın bir sistemde test yapın. Aşağıdaki bölümlerde, test kurulumu hazırlamak için uygulayabileceğiniz bir dizi APK'ya ve sisteme özel adım gösterilmektedir. Bu adımlardan bazıları kullanım alanına özeldir.

İzleme noktaları

Uygulamalar, kodlarını özel izleme etkinlikleriyle donatabilir.

İzlemeler yakalanırken izleme, bölüm başına yaklaşık 5 μsn'lik küçük bir ek yük oluşturur. Bu nedenle, her yöntemin etrafına yerleştirmeyin. 0,1 ms'den uzun süren büyük iş parçalarının izlenmesi, darboğazlar hakkında önemli bilgiler sağlayabilir.

APK ile ilgili dikkat edilmesi gereken noktalar

Hata ayıklama varyantları, sorun giderme ve yığın örneklerini sembolleştirme konusunda faydalı olabilir ancak performans üzerinde ciddi etkileri vardır. Android 10 (API düzeyi 29) ve sonraki sürümlerin yüklü olduğu cihazlar, yayın derlemelerinde profil oluşturmayı etkinleştirmek için manifestlerinde profileable android:shell="true" kullanabilir.

Üretim düzeyinde kod küçültme yapılandırmanızı kullanın. Bu durum, uygulamanızın kullandığı kaynaklara bağlı olarak performansı önemli ölçüde etkileyebilir. Bazı ProGuard yapılandırmaları izleme noktalarını kaldırır. Bu nedenle, testleri üzerinde çalıştırdığınız yapılandırma için bu kuralları kaldırmayı düşünebilirsiniz.

Derleme

Uygulamanızı cihazda bilinen bir durumda derleyin. Bu işlem genellikle basitlik için speed, üretim performansıyla daha yakından eşleşmek için ise speed-profile olarak yapılır (ancak bu, uygulamanın ısıtılmasını ve profillerin dökülmesini ya da uygulamanın temel profillerinin derlenmesini gerektirir).

Macrobenchmark'ı kullanmanız önerilir.

Hem speed hem de speed-profile, dex'ten yorumlanan kod miktarını ve dolayısıyla önemli ölçüde müdahaleye neden olabilecek arka plandaki tam zamanında (JIT) derleme miktarını azaltır. Yalnızca speed-profile çalışma zamanında dex'ten sınıf yüklemenin etkisini azaltır.

Aşağıdaki komut, uygulamayı speed modunu kullanarak derler:

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

speed derleme modu, uygulamanın yöntemlerini tamamen derler. speed-profile modu, uygulamanın yöntemlerini ve sınıflarını, 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, kullanmaya karar verirseniz beklediğiniz verilerin toplandığından emin olun. Profiller aşağıdaki konumda bulunur:

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

Sistemle ilgili dikkat edilmesi gereken noktalar

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

Root edilmiş cihazlarda, mikro kıyaslama için lockClocks komut dosyası kullanabilirsiniz. Bu komut dosyaları diğer işlemlerin yanı sıra şunları yapar:

  • CPU'ları sabit bir frekansta 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ı deneyimine odaklanan testlerde lockClocks komut dosyası kullanmanızı önermiyoruz. Ancak bu komut dosyası, mikro karşılaştırma testlerindeki gürültüyü azaltmak için gerekli olabilir.

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

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

Trambolin etkinliği, uygulamanın başlatılma süresini gereksiz yere uzatabilir. Bu nedenle, uygulamanızın bu işlemi yapıp yapmadığını bilmeniz önemlidir. Aşağıdaki örnek izlemede gösterildiği gibi, bir activityStart'dan hemen sonra, ilk etkinlik tarafından herhangi bir çerçeve çizilmeden başka bir activityStart geliyor.

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

Bu durum hem bildirim giriş noktasında hem de normal uygulama başlatma giriş noktasında meydana gelebilir ve genellikle yeniden düzenleme yaparak çözülebilir. Örneğin, bu etkinliği başka bir etkinlik çalışmadan önce kurulum yapmak için kullanıyorsanız bu kodu yeniden kullanılabilir bir bileşene veya kitaplığa ayırın.

Sık sık GC'leri tetikleyen gereksiz ayırmalar

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

Aşağıdaki örnekte, uzun süren bir işlem sırasında her 10 saniyede bir uygulama gereksiz yere ancak tutarlı bir şekilde zaman içinde kaynak ayırıyor olabilir:

alt_text Şekil 2. GC etkinlikleri arasındaki alanı gösteren bir izleme.

Bellek Profil Oluşturucu'yu kullanırken belirli bir çağrı yığınının, tahsislerin büyük çoğunluğunu yaptığını da fark edebilirsiniz. Kodun bakımını zorlaştırabileceğinden tüm ayırmaları agresif bir şekilde ortadan kaldırmanız gerekmez. Bunun yerine, tahsislerin yoğun olduğu alanlarda çalışmaya başlayın.

Düzensiz kareler

Grafik işlem hattı nispeten karmaşıktır ve kullanıcının sonuçta bırakılan bir kareyi görüp görmeyeceğini belirleme konusunda bazı nüanslar olabilir. Bazı durumlarda platform, arabelleğe alma özelliğini kullanarak bir kareyi "kurtarabilir". Ancak uygulamanız açısından sorunlu kareleri belirlemek için bu ayrıntıların çoğunu göz ardı edebilirsiniz.

Çerçeveler, uygulamadan çok az iş gerektirecek şekilde çizildiğinde Choreographer.doFrame() izleme noktaları 60 FPS'lik bir cihazda 16,7 ms aralıklarla gerçekleşir:

alt_text 3.Şekil Sık sık hızlı kareler gösteren bir izleme.

Uzaklaştırıp izleme boyunca ilerlediğinizde bazen karelerin tamamlanmasının biraz daha uzun sürdüğünü görürsünüz.Ancak bu kareler, kendilerine ayrılan 16, 7 ms'lik süreyi aşmadığı için sorun yoktur:

alt_text Şekil 4. Periyodik çalışma patlamalarıyla sık sık hızlı kareler gösteren bir izleme.

Bu düzenli ritimde bir aksama gördüğünüzde, 5. şekilde gösterildiği gibi bu bir titrek karedir:

alt_text 5.Şekil Titrek bir kareyi gösteren iz.

Bunları tanımlama alıştırması yapabilirsiniz.

alt_text 6.Şekil Daha fazla titrek kare gösteren bir iz.

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

Titrek kareleri belirleme ve nedenlerini ayıklama hakkında daha fazla bilgi için Yavaş oluşturma bölümüne bakın.

RecyclerView ile ilgili sık yapılan hatalar

RecyclerView öğesinin tüm destek verilerini gereksiz yere geçersiz kılmak, uzun kare oluşturma sürelerine ve sarsıntıya neden olabilir. Bunun yerine, güncellenmesi gereken görünüm 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ı önlemenin yolları için Dinamik verileri sunma başlıklı makaleyi inceleyin.

Tüm iç içe yerleştirilmiş RecyclerView öğelerini düzgün şekilde desteklemezseniz dahili RecyclerView öğesi her seferinde tamamen yeniden oluşturulabilir. Görünümlerin her bir iç içe yerleştirilmiş RecyclerView arasında yeniden kullanılabilmesini sağlamak için her iç içe yerleştirilmiş RecyclerView öğesinde RecycledViewPool ayarlanmalıdır.

Yeterli verinin önceden getirilmemesi veya zamanında önceden getirilmemesi, kullanıcının sunucudan daha fazla veri beklemesi gerektiğinde kaydırma listesinin sonuna ulaşmayı zorlaştırabilir. Bu durum, kare son tarihleri kaçırılmadığı için teknik olarak jank olmasa da önceden getirme işleminin zamanlamasını ve miktarını değiştirerek kullanıcı deneyimini önemli ölçüde iyileştirebilirsiniz. Böylece kullanıcıların verileri beklemesi gerekmez.

Uygulamanızda hata ayıklama

Aşağıda, uygulamanızın performansında hata ayıklama için kullanabileceğiniz farklı yöntemler verilmiştir. Sistem izleme ve Android Studio profiler'ı kullanma hakkında genel bilgi edinmek 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 başlıklı makaleyi, sistem izlemeye genel bir bakış için ise aşağıdaki videoyu inceleyin.

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

  • Soğuk başlatma: Kaydedilmiş durum olmadan yeni bir işlem oluşturarak başlama.
  • Sıcak başlatma: İşlemi yeniden kullanarak etkinliği yeniden oluşturur veya kayıtlı durumla işlemi yeniden oluşturur.
  • Sıcak başlatma: Etkinliği yeniden başlatır ve enflasyonla başlar.

Cihazdaki Sistem İzleme uygulaması ile sistem izlerini 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. Ayrıca izleme dosyalarını web tabanlı Perfetto izleme görüntüleyicisi ile görüntülemenizi öneririz. Daha fazla bilgi için Sistem izlemeye genel bakış başlıklı makaleyi inceleyin.

Dikkat etmeniz gereken bazı noktalar:

  • İzleyici çekişmesini izleme: İzleyici tarafından korunan kaynaklar için rekabet, uygulamanın başlatılmasında önemli bir gecikmeye neden olabilir.

  • Senkron bağlayıcı işlemleri: Uygulamanızın kritik yolunda gereksiz işlemler olup olmadığını kontrol edin. Gerekli bir işlem pahalıysa iyileştirmeler yapmak için ilişkili platform ekibiyle birlikte çalışabilirsiniz.

  • Eşzamanlı GC: Bu durum yaygındır ve etkisi nispeten düşüktür. Ancak bu durumla sık karşılaşıyorsanız Android Studio bellek profiler'ı ile incelemeniz önerilir.

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

  • Diğer iş parçacıklarında önemli etkinlik: Bunlar kullanıcı arayüzü iş parçacığına müdahale edebilir. Bu nedenle, başlatma sırasında arka planda yapılan çalışmalara dikkat edin.

Uygulama başlatma metriği raporlamasını iyileştirmek için başlatma işlemi uygulama açısından tamamlandığında reportFullyDrawn işlevini çağırmanızı öneririz. reportFullyDrawn kullanma hakkında daha fazla bilgi için Tam görüntüleme süresi bölümüne bakın. RFD tarafından tanımlanan başlangıç zamanlarını Perfetto izleme işlemcisi aracılığıyla ayıklayabilirsiniz. Kullanıcı tarafından görülebilen bir izleme etkinliği yayınlanır.

Cihazda sistem takibini kullanma

Cihazda sistem izi yakalamak için Sistem İzleme adlı sistem düzeyindeki uygulamayı kullanabilirsiniz. Bu uygulama, cihazı prize takmanıza veya adb'ya bağlamanıza gerek kalmadan cihazdan iz kaydı almanıza olanak tanır.

Android Studio Memory Profiler'ı kullanma

Bellek sızıntılarından veya kötü kullanım kalıplarından kaynaklanabilecek bellek baskısını incelemek için Android Studio Memory Profiler'ı kullanabilirsiniz. Nesne ayırmalarıyla ilgili canlı bir görünüm sağlar.

Uygulamanızdaki bellek sorunlarını, çöp toplama işlemlerinin neden ve ne sıklıkta gerçekleştiğini izlemek için Bellek Profil Oluşturucu'yu kullanmayla ilgili bilgileri uygulayarak düzeltebilirsiniz.

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

  1. Bellek sorunlarını tespit etme

    Odaklanmak istediğiniz kullanıcı yolculuğunun bellek profili oluşturma oturumunu kaydedin. Şekil 7'de gösterildiği gibi, nesne sayısının arttığını ve bunun sonunda şekil 8'de gösterildiği gibi GC'lere yol açtığını görün.

    alt_text 7.Şekil Nesne sayısını artırma

    alt_text Şekil 8. Çöp toplama

    Bellek baskısı oluşturan kullanıcı yolculuğunu belirledikten sonra bellek baskısının temel nedenlerini analiz edin.

  2. Bellek baskısı yoğun bölgelerini teşhis edin.

    Şekil 9'da gösterildiği gibi hem Ayırmaları hem de Yüzeysel Boyutu görselleştirmek için zaman çizelgesinde bir aralık seçin.

    alt_text Şekil 9. Allocations (Ayırmalar) ve Shallow Size (Yüzeysel 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 dair bazı örnekler verilmiştir.

    • Sınıfa göre düzenle: Aksi takdirde ö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 her saniyede "Vertex" adlı sınıftan 2.000 nesne oluşturduğunu görürseniz bu durum, her saniyede Ayırmalar sayısını 2.000 artırır ve sınıfa göre sıraladığınızda bunu görürsünüz. Çöp oluşturmayı önlemek için bu nesneleri yeniden kullanmak istiyorsanız bellek havuzu uygulayın.

    • Çağrı yığınına göre düzenleme: Döngü içinde veya çok fazla bellek ayırma işlemi yapan belirli bir işlevin içinde olduğu gibi, belleğin ayrıldığı bir sıcak yolun nerede olduğunu bulmak istediğinizde kullanışlıdır.

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

    • Saklanan Boyut: Yalnızca nesne tarafından referans verilen nesne ve referanslar nedeniyle oluşan toplam belleği gösterir. Karmaşık nesnelerden kaynaklanan bellek baskısını izlemek için kullanışlıdır. Bu değeri elde etmek için Şekil 10'da gösterildiği gibi tam bir bellek dökümü alınır ve Şekil 11'de gösterildiği gibi Saklanan Boyut sütun olarak eklenir.

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

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

  3. Optimizasyonun etkisini ölçün.

    GC'ler daha belirgindir ve bellek optimizasyonlarının etkisini ölçmek daha kolaydır. Bir optimizasyon bellek baskısını azalttığında daha az GC görürsünüz.

    Optimizasyonun etkisini ölçmek için profiler zaman çizelgesinde GC'ler arasındaki süreyi ölçün. Bu durumda, GC'ler arasında daha uzun süre geçtiğini görebilirsiniz.

    Bellek iyileştirmelerinin nihai etkileri şunlardır:

    • Uygulama sürekli olarak bellek kullanımına neden olmuyorsa bellek yetersizliğinden kaynaklanan kapatma işlemleri azalır.
    • Daha az GC olması, özellikle P99'da jank metriklerini iyileştirir. Bunun nedeni, GC'lerin CPU çekişmesine neden olmasıdır. Bu durum, GC gerçekleşirken oluşturma görevlerinin ertelenmesine yol açabilir.