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 neden olabilecek birçok sorun vardır. Ancak 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ı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ı durumunda ortaya çıkar. 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.
  • 200 ms'den kısa sürede hazırda başlatma ve 150 ms'den kısa sürede çalışır durumda başlatma. Uygulamanın işlemi zaten arka planda çalışırken sistemin kullanıcı arayüzünü yeniden başlatması veya etkinliği ön plana getirmesi gerektiğinde (ör. kullanıcı uygulamadan çıkıp kısa süre sonra yeniden açtığında) sıcak başlatma gerçekleşir. Uygulamanın etkinliği zaten bellekte önbelleğe alındığından ve görünüm hiyerarşisinin yeniden oluşturulmasına gerek kalmadan yalnızca ön plana getirilmesi gerektiğinden çalışır durumda başlatma daha da hızlıdır. Sıcak başlatmaları 200 ms'nin, soğuk başlatmaları ise 150 ms'nin altında tutmayı hedefleyin.
  • P95 ve P99 gecikme değerleri, ortanca gecikme değerine çok yakın. P95 ve P99, başlangıç sürelerinin 95. ve 99. yüzdelik dilimlerini, medyan ise 50. yüzdelik dilimini temsil eder. 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 ortaya çıkarabilir.
Kaydırma duraklaması

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, sorunsuz animasyonlu akış yerine aksaklıklar olduğunda en belirgin şekilde kaydırma sırasında görülür. Uygulama, içeriği sistemdeki bir karenin süresinden daha uzun sürede oluşturduğundan hareket, bir veya daha fazla kare boyunca durakladığında sarsıntı (jank) oluşur.

Uygulamalarınızda 90 Hz yenileme hızını hedefleyin. 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'ye kadar daha yüksek yenileme hızlarını 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.

Akıcı 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 akıcı animasyonlar olmalı, gecikme veya görsel titreme içermemelidir.

Güç verimsizlikleri

Çalışmak, pil şarjını ve sonuç olarak pil ömrünü azaltır.

Kodda yeni nesneler oluşturmaktan kaynaklanan bellek ayırma işlemleri, sistemde çalışmaya neden olur. Yalnızca ayırmaların kendisi Android Çalışma Zamanı'ndan (ART) çaba gerektirmekle kalmaz, bu nesnelerin daha sonra serbest bırakılması (çöp toplama) da zaman ve çaba gerektirir.

Hem bellek ayırma hem de atık toplama, özellikle geçici nesneler için çok daha hızlı ve verimli hale geldi. Mümkün olduğunca 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 yapabilecekleri göz önüne alındığında, bakımı yapılamayan kod riskiyle tahsislerden tasarruf etmek en iyi uygulama değildir.

Ancak ayırmalar çaba gerektirir. Bu nedenle, iç döngünüzde birçok nesne ayırıyorsanız bunların performans sorunlarına neden olabileceğini unutmayın.

Sorunları belirleme

Performans sorunlarını gidermek için aşağıdaki önemli kullanıcı yolculuklarını belirleyip 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.

Bu akışların her birinde, aşağıdaki hata ayıklama araçlarını kullanarak neler olduğunu inceleyin:

  • Perfetto: Hassas zamanlama verileriyle cihazın tamamında neler olduğunu 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ığını gösteren bir alev grafiği gösterir. Systrace'te uzun süren bir işlem tespit ettiğ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. Toplanmış verileri analiz ederek önceki adımların yerine geçemezsiniz. 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 duraklamayı 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.
      • Macrobenchmark, tek bir kullanıcı yolculuğunu kapsayan dumpsys gfxinfokomutları kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğunda jank varyasyonunu anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü vurgulayan RenderTime metrikleri, gerilemeleri veya iyileştirmeleri belirlemek için titrek karelerin sayısından daha önemlidir.

Uygulama Bağlantıları, web sitenize ait olduğu doğrulanan web sitenizin URL'sine dayalı derin bağlantılardır. Uygulama bağlantısı doğrulamaları aşağıdaki nedenlerle başarısız olabilir:

  • Yanlış intent filtresi kapsamları: Yalnızca uygulamanızın yanıt verebileceği URL'ler için 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ını doğrulamadan bağlantıları HTTP'den HTTPS'ye yönlendirmek (ör. example.com'dan www.example.com'a) doğrulamanın başarısız olmasına neden olabilir. Intent 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 daha 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ümleri çalıştıran cihazlar, yayın derlemelerinde profil oluşturmayı etkinleştirmek için manifestlerinde 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ı izleme noktalarını kaldırır. Bu nedenle, testleri çalıştırdığınız yapılandırma için bu kuralları kaldırmayı düşünebilirsiniz.

Derleme

Uygulamanızı cihaz üzerinde bilinen bir durumda derleyin. Genellikle basitlik için speed veya üretim performansıyla daha yakından eşleşmesi için speed-profile kullanılır (ancak bu, uygulamanın ısınmasını ve profillerin dökülmesini ya da uygulamanın temel profillerinin derlenmesini gerektirir).

Hem speed hem de speed-profile, dex'ten yorumlanan kodun çalışma miktarını ve dolayısıyla önemli ölçüde girişime neden olabilecek arka plandaki JIT derleme miktarını azaltır. Yalnızca speed-profile çalışma zamanı sınıfı yüklemenin dex'ten 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üzeyli ve yüksek doğruluklu ö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 performansta ö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ı da 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 testler için lockClocks komut dosyası kullanmanızı önermiyoruz. Ancak bu komut dosyası, mikro kıyaslama 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 bunu yapıp yapmadığını bilmeniz önemlidir. Aşağıdaki örnek izlemede gösterildiği gibi, ilk etkinlik tarafından herhangi bir kare çizilmeden bir activityStart hemen ardından başka bir activityStart geliyor.

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

Bu durum hem bildirim giriş noktasında hem de normal uygulama başlangıcı 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.

Gereksiz ayırmalar nedeniyle sık sık çöp toplama işlemi tetikleniyor

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

Aşağıdaki örnekte, uzun süren bir işlem sırasında her 10 saniyede bir çöp toplama işlemi yapılması, uygulamanın zaman içinde gereksiz ancak tutarlı bir şekilde bellek ayırıyor olabileceğinin göstergesidir:

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

Ayrıca, Memory Profiler'da 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 etkin noktaları üzerinde çalışarak 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ş yapılması gerekerek çizildiğinde Choreographer.doFrame() izleme noktaları 60 FPS cihazda 16,7 ms aralıklarla gerçekleşir:

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

Uzaklaştırıp izlemeyi incelediğinizde bazen karelerin tamamlanmasının biraz daha uzun sürdüğünü görürsünüz ancak bu süre, ayrılan 16, 7 ms'den fazla olmaz. Bu çerçeveler uygun:

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. ve 6. şekillerde gösterildiği gibi, bu bir titrek karedir:

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

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

Bazı durumlarda, Compose'un hangi kullanıcı arayüzü bileşenlerini güncellediği veya Şekil 6'da gösterildiği gibi bir LazyColumn öğesinin ne yaptığı hakkında daha fazla bilgi edinmek için bir izleme noktasına yakınlaştırmanız gerekir. Bu kullanıcı arayüzü darboğazlarını teşhis ederken standart sistem izleme, hangi composable'ların temel neden olduğunu göstermeyebilir. Bu gibi durumlarda, tam composable işlevlerini doğrudan izleme içinde gösteren Jetpack Compose kompozisyon izlemeyi kullanın. Böylece, beklenmedik yeniden kompozisyonları belirlemek kolaylaşır. Şekil 5 ve 6'da kompozisyon izleme sonuçları gösterilmektedir.

Compose performansını optimize etme hakkında daha fazla bilgi için Jetpack Compose Performansı başlıklı makaleyi inceleyin. Düzensiz kareleri belirleme ve nedenlerini ayıklama hakkında daha fazla bilgi için Yavaş oluşturma başlıklı makaleyi inceleyin.

Sık karşılaşılan tembel düzen hataları

Lazy layout'un tüm destekleme durumunun gereksiz yere geçersiz kılınması, aşırı yeniden oluşturmalara, uzun çerçeve oluşturma sürelerine ve sarsıntıya neden olabilir. Güncellenmesi gereken liste öğelerinin sayısını en aza indirmek için öğelerinizde öğe anahtarlarını kullanın ve yalnızca değişen belirli durum öğelerini değiştirin.

İçeriğin tamamen değiştirilmesi yerine güncellenmesine neden olan, maliyetli tam liste yeniden ayırmalarını önlemenin yolları için Lazy layout tuşlarını kullanma başlıklı makaleyi inceleyin.

İç içe kaydırma listelerinin yanlış uygulanması performans düşüşlerine neden olabilir. Kaydırma içeren bir tembel düzeni, açık kısıtlamalar olmadan başka bir kaydırma içeren kapsayıcının içine yerleştirmeyin. Daha fazla bilgi için Aynı yönde kaydırılabilir bileşenleri iç içe yerleştirmeyin başlıklı makaleyi inceleyin.

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, teknik olarak jank olmasa da (çünkü herhangi bir kare son tarihi kaçırılmıyor) ö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 veriler için beklemesi gerekmez.

Uygulamanızda hata ayıklama

Uygulamanızın performansında hata ayıklama yöntemlerini aşağıda bulabilirsiniz.

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

Uygulama başlatma süreciyle ilgili genel bilgiler için Uygulama başlatma süresi başlıklı makaleyi, sistem izleme ve Android Studio profiler'ı kullanma hakkında genel bilgiler için aşağıdaki videoyu inceleyin.

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

  • Sıfırdan başlatma: Kaydedilmiş durum olmadan yeni bir işlem oluşturarak başlar.
  • Hazır durumda başlatma: İşlemi yeniden kullanarak etkinliği yeniden oluşturur veya kaydedilmiş durumu kullanarak işlemi yeniden oluşturur.
  • Çalışır durumda başlatma: Etkinliği yeniden başlatır ve ayrıştırmayla başlar.

Systrace'leri cihazdaki System Tracing 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. 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:

  • İzleme için çekişme: İzleme ile korunan kaynaklar için rekabet, uygulamanın başlatılmasında önemli bir gecikmeye neden olabilir.

  • Eşzamanlı 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ışmayı düşünebilirsiniz.

  • 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 profili oluşturucu 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ındaki önemli etkinlikler: 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 uygulama açısından başlatma işlemi 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.

GC'lerin neden ve ne sıklıkta gerçekleştiğini izlemek için Memory Profiler'ı kullanarak uygulamanızdaki bellek sorunlarını 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 Şekil 7. Nesne sayısını artırma

    alt_text Şekil 8. Atık 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ı yaşanan noktaları 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 uygulama her saniye belirli bir sınıfa ait 2.000 nesne oluşturuyorsa her saniye Ayırmalar sayısı 2.000 artar ve sınıfa göre sıralama yaptığınızda bu durumu 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üzenle: Döngü içinde veya çok fazla bellek ayırma işlemi yapan belirli bir işlev 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 temel değerlerden oluşan basit sınıfları izlemek için kullanışlıdır.

    • Saklanan Boyut: Nesnenin kendisinden ve yalnızca nesne tarafından referans verilen referanslardan kaynaklanan 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 bellek dökümü alın. Tutulan boyut, Şekil 11'de gösterildiği gibi sütun olarak eklenir.

      alt_text Ş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. 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. Olumlu etki, GC'ler arasındaki sürenin uzamasına neden olur.

    Bellek iyileştirmelerinin nihai etkileri şunlardır:

    • Uygulama sürekli olarak bellek baskısı oluşturmuyorsa 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.