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

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

Temel performans sorunları

Bir uygulamanın kötü performans göstermesine neden olabilecek birçok sorun vardır. Ancak uygulamanızda karşılaşabileceğiniz bazı yaygın sorunlar aşağıda verilmiştir:

Başlangıç gecikmesi

Başlangıç gecikmesi, uygulama simgesine, bildirime veya başka bir giriş noktasına dokunulması ile kullanıcının 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. Sıfırdan başlatma, başlatılan uygulama sistem belleğinde olmadığında gerçekleşir. Bu durum, uygulamanın yeniden başlatılmasından veya uygulama işleminin kullanıcı ya da sistem tarafından durdurulmasından sonra ilk kez başlatıldığı durumlarda ortaya çıkar.

    Buna karşılık, hazır durumda başlatma, uygulama arka planda çalışırken gerçekleşir. Baştan başlatma, her şeyi depolama alanından yüklemesi ve uygulamayı başlatması gerektiğinden sistemden en fazla çalışmayı gerektirir. Baştan başlatma işlemlerinin 500 ms veya daha kısa sürmesini sağlamaya çalışın.

  • P95 ve P99 gecikmeleri, ortanca gecikmeye çok yakın. Uygulamanın başlatılması uzun sürerse kullanıcı deneyimi olumsuz etkilenir. Uygulamanın başlatılmasının kritik yolunda, kilit anlaşmazlığı yaşanabilir ve tutarsızlıklar ortaya çıkabilir. Bunun nedeni, işlemler arası iletişimler (IPC'ler) ve gereksiz G/Ç işlemleridir.

Kaydırma sarsıntısı

Takılma, sistem istenilen 60 Hz veya daha yüksek ritimde ekrana çizmek için kareleri zamanında oluşturup sağlayamadığında ortaya çıkan görsel kesintiyi tanımlayan terimdir. Kesintiler en çok kaydırma sırasında görülür. Bu durumda, akıcı animasyonlu akış yerine aksama yaşanır. Uygulamanın içeriği oluşturması sistemdeki bir karenin süresinden daha uzun sürdüğü için hareket bir veya daha fazla kare boyunca durakladığında takılma meydana gelir.

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

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

Sorunlu 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, gecikme veya görsel titreşim içermeyen, akıcı animasyonlar olmalıdır.

Enerji verimsizlikleri

Çalışmak, pil şarjını azaltır. Gereksiz işler yapmak da pil ömrünü kısaltır.

Kodda yeni nesneler oluşturmaktan kaynaklanan bellek tahsisleri, sistemde önemli miktarda çalışma yapılmasına neden olabilir. Bunun nedeni, yalnızca ayırma işlemlerinin Android Runtime (ART) tarafından yapılmasının değil, bu nesnelerin daha sonra serbest bırakılmasının (çöp toplama) da zaman ve çaba gerektirmesidir. Hem ayırma hem de toplama işlemi, özellikle geçici nesneler için çok daha hızlı ve verimlidir. Geçmişte mümkün olduğunda nesne ayırmaktan kaçınmak en iyi uygulama olarak kabul edilse de uygulamanız ve mimariniz için en uygun seçeneği belirlemenizi öneririz. ART'nin yapabileceklerini göz önünde bulundurarak, bakıma uygun olmayan kod riskiyle birlikte ayırmalardan 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 performans sorunlarına yol açabileceğini unutmayın.

Sorunları belirleme

Performans sorunlarını tespit etmek ve düzeltmek için aşağıdaki iş akışını önerdik:

  1. Aşağıdaki kritik kullanıcı yolculuklarını belirleyin ve inceleyin:
    • Başlatıcı ve bildirim dahil olmak üzere yaygın başlangıç 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ü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: Kesin zamanlama verileriyle cihazın tamamında neler olduğunu görmenizi sağlar.
    • Bellek Profiler: Yığın üzerinde hangi bellek ayırmalarının yapıldığını görmenizi sağlar.
    • Simpleperf: Belirli bir süre boyunca en fazla CPU kullanan işlev çağrılarının alev grafiğini gösterir. Systrace'te uzun süren bir işlem tespit ettiğinizde ancak nedenini bilmiyorsanız Simpleperf ek bilgi sağlayabilir.

Bu performans sorunlarını anlamak ve hatalarını ayıklamak için her bir test çalıştırmasının hatalarını manuel olarak ayıklamak önemlidir. Toplu verileri analiz ederek önceki adımları değiştiremezsiniz. Ancak kullanıcıların gerçekte ne gördüğünü anlamak ve gerilemelerin ne zaman gerçekleşebileceğini belirlemek için otomatik testte ve sahada metrik toplamayı ayarlamak önemlidir:

  • Başlangıç akışları
  • Jank
    • Alan metrikleri
      • Play Console çerçevesi temel metrikleri: Play Console'da metrikleri belirli bir kullanıcı yolculuğuyla sınırlayamazsınız. Yalnızca uygulama genelindeki genel takılmaları raporlar.
      • FrameMetricsAggregator ile özel ölçüm: Belirli bir iş akışı sırasında takılma metriklerini kaydetmek için FrameMetricsAggregator'ı kullanabilirsiniz.
    • Laboratuvar testleri
      • Makro Karşılaştırma ile Kaydırma.
      • Makro karşılaştırma, tek bir kullanıcı yolculuğunun aralığını belirten dumpsys gfxinfo komutlarını kullanarak kare zamanlamasını toplar. Bu, belirli bir kullanıcı yolculuğundaki takılmadaki değişimi anlamanın bir yoludur. Karelerin çizilmesinin ne kadar sürdüğünü vurgulayan RenderTimemetrikleri, gerileme veya iyileştirmeleri belirlemek için sarsıntılı karelerin sayısından daha önemlidir.

Uygulama Bağlantıları, web sitenizin URL'sine dayalı ve web sitenize ait olduğu doğrulanmış derin bağlantılardır. Uygulama Bağlantısı doğrulamalarının başarısız olmasına neden olabilecek nedenler aşağıda açıklanmıştır.

  • 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 adı yönlendirmeleri güvenlik riski olarak kabul edilir ve doğrulama işleminde başarısız olur. Bu, 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ğ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.
  • 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ırmalar elde etmek için doğru şekilde ayarlama yapmanız ö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 APK'ya ve sisteme özgü bazı adımlar (bazıları kullanım alanına özeldir) gösterilmektedir.

İzleme noktaları

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

İzler yakalanırken izleme, bölüm başına yaklaşık 5 μs'lik küçük bir ek yüke neden olur. Bu nedenle, her yöntemin etrafına izleme eklemeyin. 0,1 ms'den uzun iş parçalarını izlemek, darboğazlar hakkında önemli bilgiler verebilir.

APK ile ilgili dikkat edilmesi gereken noktalar

Hata ayıklama varyantları, sorun giderme ve yığın örneklerini sembolize etme 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, sürüm derlemelerinde profillemeyi etkinleştirmek için manifest dosyalarında profileable android:shell="true" kullanabilir.

Üretim düzeyinde kod sıkıştırma 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, test çalıştırdığınız yapılandırma için bu kuralları kaldırabilirsiniz.

Derleme

Uygulamanızı cihaz üzerinde bilinen bir duruma derleyin. Genellikle basitlik için speed veya üretim performansıyla daha uyumlu olması için speed-profile (ancak bunun için uygulamayı ısıtmak ve profilleri dökmek ya da uygulamanın temel profillerini derlemek gerekir)

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

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

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 derleyebilir. Profilleri tutarlı ve doğru bir şekilde toplamak zor olabilir. Bu nedenle, bu yöntemi kullanmaya karar verirseniz beklediğiniz verileri topladıklarını onaylayın. 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ğruluk ölçümleri için cihazlarınızı kalibre edin. Aynı cihaz 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.

Köklenmiş cihazlarda mikro karşılaştırmalar için lockClocks komut dosyası kullanmayı düşünebilirsiniz. Bu komut dosyaları, diğerlerinin yanı sıra aşağıdakileri yapar:

  • CPU'ları sabit bir sıklıkta 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 lansmanı, DoU testi ve takılma testi gibi kullanıcı deneyimine odaklanan testler için lockClocks komut dosyası kullanmanızı önermeyiz ancak mikro karşılaştırma testlerinde gürültüyü azaltmak için gerekli olabilir.

Mümkün olduğunda, ölçümlerinizdeki gürültüyü azaltıp ölçüm hatalarını önleyebilecek Macrobenchmark gibi bir test çerçevesi kullanmayı düşünün.

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

Trambolin etkinliği, uygulamanın başlatılma süresini gereksiz yere uzatabilir. 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 gelir.

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

Bu durum hem bildirim giriş noktasında hem de normal bir uygulama başlangıç giriş noktasında gerçekleşebilir ve genellikle yeniden yapılandırarak çözülebilir. Örneğin, başka bir etkinlik çalıştırılmadan önce kurulumu gerçekleştirmek için bu etkinliği kullanıyorsanız bu kodu yeniden kullanılabilir bir bileşene veya kitaplığa dahil edin.

Sık GC'leri tetikleyen gereksiz ayrıştırmalar

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

Aşağıdaki örnekte, uzun süren bir işlem sırasında her 10 saniyede bir, uygulamanın zaman içinde gereksiz yere ancak tutarlı bir şekilde ayırma işlemi gerçekleştirdiğinin bir göstergesidir:

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

Bellek Profilleyici'yi kullanırken belirli bir çağrı yığınının, ayırmaların büyük çoğunluğunu yaptığını da fark edebilirsiniz. Tüm tahsisleri agresif bir şekilde ortadan kaldırmanız gerekmez. Aksi takdirde kodun bakımı zorlaşır. Bunun yerine, tahsislerin yoğun olduğu noktalar üzerinde çalışmaya başlayın.

Bozuk kareler

Grafik ardışık düzeni nispeten karmaşıktır ve kullanıcının atlanan bir kare görüp göremeyeceğini belirlemede bazı nüanslar olabilir. Bazı durumlarda platform, arabelleğe alma özelliğini kullanarak bir kareyi "kurtarabilir". Ancak, sorunlu kareleri uygulamanızın bakış açısından belirlemek için bu ayrıntıların çoğunu göz ardı edebilirsiniz.

Uygulamadan çok az çalışma gerektiren kareler çizilirken Choreographer.doFrame() izleme noktaları, 60 FPS'lik bir cihazda 16,7 ms aralıkla gerçekleşir:

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

Yakınlaştırmayı azaltır ve izlemede gezinirseniz bazı karelerin tamamlanmasının biraz daha uzun sürdüğünü görebilirsiniz.Ancak bu kareler, ayrılan 16, 7 ms'den daha uzun sürmediği için sorun oluşturmaz:

alt_text Şekil 4. Düzenli çalışma patlamaları içeren sık sık hızlı kareler gösteren bir izleme.

Bu normal ritimde bir kesinti gördüğünüzde, 5. resimde gösterildiği gibi sarsıntılı bir kare olur:

alt_text Şekil 5. Sarsak bir kareyi gösteren bir izleme.

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

alt_text Şekil 6. Daha fazla sarsıntılı kare gösteren bir izleme.

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

Takılmalı kareleri tanımlama ve nedenleriyle ilgili hata ayıklama hakkında daha fazla bilgi için Yavaş oluşturma başlıklı makaleyi inceleyin.

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

RecyclerView öğesinin yedek verilerinin tamamını gereksiz yere geçersiz kılmak, kare oluşturma sürelerinin uzamasına ve takılmalara 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 pahalı notifyDatasetChanged() çağrılardan kaçınmanın yolları için Dinamik verileri sunma başlıklı makaleyi inceleyin.

İç içe yerleştirilmiş her RecyclerView öğesini düzgün şekilde desteklemezseniz dahili RecyclerView öğesinin her seferinde tamamen yeniden oluşturulmasına neden olabilirsiniz. Görüntülemelerin her iç RecyclerView arasında geri dönüştürülebilmesini sağlamak için iç içe yerleştirilmiş her iç RecyclerView öğesinde bir RecycledViewPool ayarlanmalıdır.

Yeterli veri ön beslemesi yapılmaması veya ön beslemenin zamanında yapılmaması, kullanıcının sunucudan daha fazla veri beklemesi gerektiğinde kaydırmalı listenin en altına ulaşmayı can sıkıcı hale getirebilir. Çerçeve son tarihleri kaçırılmadığından bu durum teknik olarak sarsıntılı olmasa da ön getirmenin zamanlamasını ve miktarını değiştirerek kullanıcının veri beklemek zorunda kalmaması için kullanıcı deneyimini önemli ölçüde iyileştirebilirsiniz.

Uygulamanızda hata ayıklama

Aşağıda, uygulamanızın performansıyla ilgili hata ayıklamayla ilgili farklı yöntemler verilmiştir. Sistem izleme ve Android Studio profilleyicisinin kullanımı hakkında genel bilgi edinmek için aşağıdaki videoyu izleyin.

Systrace ile uygulama başlatma sorunlarını giderme

Uygulama başlatma sürecine genel bakış için Uygulama başlatma süresi başlıklı makaleyi, sistem izlemeye genel bakış için aşağıdaki videoyu inceleyin.

Aşağıdaki aşamalarda başlatma türlerinin anlamını netleştirebilirsiniz:

  • Soğuk başlatma: Kayıtlı durum içermeyen yeni bir işlem oluşturarak başlayın.
  • Sıcak başlatma: İşlemi yeniden kullanırken etkinliği yeniden oluşturur veya işlemi kayıtlı durumla yeniden oluşturur.
  • Sıcak başlatma: Etkinliği yeniden başlatır ve şişirme işleminin başından başlar.

Cihazdaki Sistem İzleme uygulaması ile sistem izleme kayıtları almanızı öneririz. Android 10 ve sonraki sürümler için 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üleyicisiyle görüntülemenizi öneririz. Daha fazla bilgi için Sistem izlemeye genel bakış başlıklı makaleyi inceleyin.

Dikkat etmeniz gereken bazı noktalar şunlardır:

  • İzleyici çekişmesi: İzleyici tarafından korunan kaynaklar için rekabet, uygulamanın başlatılmasında önemli gecikmeler oluşturabilir.

  • Senkronize bağlayıcı işlemleri: Uygulamanızın kritik yolunda gereksiz işlemleri arayın. Gerekli bir işlem pahalıysa iyileştirme yapmak için ilgili platform ekibiyle birlikte çalışabilirsiniz.

  • Eşzamanlı GC: Bu durum yaygındır ve nispeten düşük bir etkiye sahiptir. Ancak bu durumu sık sık yaşıyorsanız Android Studio bellek profilleyicisini kullanarak bu konuyu incelemeyi düşünebilirsiniz.

  • G/Ç: Başlatma sırasında yapılan G/Ç işlemlerini ve uzun süreli duraklamaları kontrol edin.

  • Diğer mesaj dizilerinde önemli etkinlik: Bu etkinlikler kullanıcı arayüzü mesaj dizisini etkileyebilir. Bu nedenle, başlatma sırasında arka planda çalışan işlemlere dikkat edin.

Daha iyi uygulama başlatma metriği raporlaması için uygulama açısından başlatma işlemi tamamlandığında reportFullyDrawn çağrısını yapmanızı öneririz. reportFullyDrawn simgesini kullanma hakkında daha fazla bilgi için Tam ekrana geçme süresi bölümüne bakın. Perfetto izleme işleyicisi aracılığıyla RFD tarafından tanımlanan başlangıç zamanlarını ayıklayabilirsiniz. Bu işlem sonucunda kullanıcı tarafından görülebilen bir izleme etkinliği yayınlanır.

Cihaz üzerinde sistem takibi kullanma

Cihaz üzerinde sistem izleme kaydetmek için Sistem İzleme adlı sistem düzeyindeki uygulamayı kullanabilirsiniz. Bu uygulama, cihazı prize takmanıza veya adb'e bağlamanıza gerek kalmadan cihazdan iz kaydetmenize 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 Bellek Profilleyicisi'ni kullanabilirsiniz. Nesne tahsislerinin canlı görüntüsünü sağlar.

GC'lerin neden ve ne sıklıkta gerçekleştiğini izlemek için bellek profilleyiciyi 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 edin.

    Odaklanmanızı istediğiniz kullanıcı yolculuğunun bellek profilleme oturumunu kaydedin. Şekil 7'de gösterildiği gibi artan bir nesne sayısı olup olmadığını kontrol edin. Bu durum, sonunda şekil 8'de gösterildiği gibi GC'lere yol açar.

    alt_text Şekil 7. 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 basıncı yoğun bölgelerini teşhis edin.

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

    alt_text Şekil 9. Allocations ve Shallow Size 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, her saniye "Vertex" adlı sınıfta 2.000 nesne oluşturan bir uygulama görürseniz bu uygulama, Ayrımlar sayısını her saniye 2.000 artırır ve sınıfa göre sıralarken bu uygulamayı görürsünüz. Çöp oluşturmamak için bu nesneleri yeniden kullanmak istiyorsanız bir bellek havuzu uygulayın.

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

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

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

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

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

  3. Bir optimizasyonun etkisini ölçme.

    Bellek optimizasyonlarının etkisini daha belirgin ve daha kolay ölçmek için GC'ler kullanılır. Bir optimizasyon bellek baskısını azalttığında daha az GC görürsünüz.

    Optimizasyonun etkisini ölçmek için, profilleyici 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 baskısına maruz kalmıyorsa bellek yetersizliği nedeniyle kapatılma olasılığı azalır.
    • Daha az GC'nin olması, özellikle P99'da sarsıntı metriklerini iyileştirir. Bunun nedeni, GC'lerin CPU çekişmesine neden olmasıdır. Bu da GC gerçekleşirken oluşturma görevlerinin ertelenmesine yol açabilir.