Nasıl yapılır? rehberleri

Bellek Verimliliğine Öncelik Verme: Android 17 İçin Temel Adımlar

Okuma süresi 10 dakika
3 Yazarlar
Alice Yuan, Ajesh Pai, Fung Lam

Uygulama performansı genellikle sorunsuz bir kullanıcı arayüzü ve hızlı başlangıç süreleriyle eşdeğer tutulsa da bellek, bu görünür metriklerin üzerine inşa edildiği sessiz temeldir. Cihaz belleğinin her zamankinden daha önemli hale geldiği bir değişim sürecinde olduğumuz bir sır değil. Android 17 ile Android bellek optimizasyonlarında önemli ilerleme kaydettik. Ayrıca, bu yılın ilerleyen dönemlerinde daha katı bellek gereksinimlerine uyum sağlamanıza yardımcı olacak araç ve API desteği sunuyoruz.

Cihaz kararlılığını sağlamak için Android 17'den itibaren sistem, cihazın toplam RAM'ine göre uygulama bellek sınırlarını uygulamaya başlayacak. Bir uygulama bu sınırları aşarsa Android, işlemi ilişkili yığın izi olmadan sonlandırır.

Bu zorunlu sonlandırmaların ötesinde, optimize edilmemiş bellek kullanımı kaçınılmaz olarak kullanıcı deneyimini kötüleştirir. Uygulama, yığın bellek sınırlarına yaklaştığında sık sık atık toplama işlemi tetiklenir. Bu durum, kullanıcı arayüzünde fark edilebilir takılmalara neden olur. Ayrıca, cihazın kullanılabilir belleği tükendiğinde sistem sayfaları geri kazanmak için uğraşır. Bu durum CPU'nun zorlanmasına, kullanıcı arayüzünde gecikmeye ve pilin hızlı tükenmesine neden olur. Bellek yetersizliği çok şiddetliyse arka plan işlemlerini aniden sonlandıran ve uygulamaların yavaş başlatılmasına, kullanıcı durumunu kaybetmesine neden olan düşük bellek sorunu (LMK) olaylarına yol açabilir.

Yüksek performanslı uygulamalar oluşturmak ve bu zorunlu sonlandırmalardan kaçınmak için aşağıdaki bellek optimizasyonu stratejilerini uygulamanızı öneririz:

  1. R8 ile bayt kodu optimizasyonunu en üst düzeye çıkarma
  2. Resim yüklemeyi optimize etme
  3. Android Studio ile bellek sızıntılarını tespit etme ve düzeltme
  4. Uygulama görünür durumdan çıktığında anıyı kırp
  5. ProfilingManager ile gelişmiş bellek gözlemlenebilirliği

Bu blog yayınının özetlenmiş bir sürümü video formatında da mevcuttur. Göz atmayı unutmayın.

Android 17'deki uygulama bellek sınırlarını anlama

Android 17'de, "kötü niyetli bir aktörün" çoklu görev deneyimini ve kullanıcının cihazının kararlılığını bozmasını önlemek için uygulama bellek sınırları getiriliyor.

Bu mimari değişikliğe yol açan nedenlerin dökümünü aşağıda bulabilirsiniz:

  • Kademeli sonlandırmaları önleme: Bir uygulama ayrıcalıklı bir durumda (ör. ön plan hizmeti çalıştırırken) şişirildiğinde veya bellek sızdırdığında başlangıçta sistemin düşük bellek sonlandırıcı (LMK) tarafından korunur. Bu tek uygulama kontrolsüz bir şekilde büyüyüp RAM'i işgal ettiğinden LMK, bellek canavarı için yer açmak amacıyla düzinelerce küçük ve iyi davranan önbelleğe alınmış uygulamayı ve arka plan görevini kapatarak durumu telafi etmek zorunda kalır.
     
  • Çoklu görev ve kullanıcı durumunu koruma: Sistem, tek bir sızıntı sürecini barındırmak için önbelleğe alınmış uygulamaları temizlemeye zorlandığında çoklu görev deneyimi ciddi şekilde bozulur. Önceden önbelleğe alınmış uygulamalara dönen kullanıcılar, neredeyse anında devam ettirme yerine yavaş sıfırdan başlatma ile karşılaşır. Bu verimsizlik, CPU'nun daha fazla zorlanmasına ve pilin daha hızlı tükenmesine neden olur. Ayrıca, kaydırma konumları, gezinme yığınları ve oyun içi ilerleme gibi, yakın zamanda kullanılan uygulamalardaki kullanıcı bağlamını da bozabilir.

Uygulama oturumunuzun bu kısıtlamalardan etkilenip etkilenmediğini belirlemek için ApplicationExitInfo içinde getDescription() işlevini çağırabilirsiniz. Sistem bir sınır uyguladıysa çıkış nedeni REASON_OTHER olarak bildirilir ve açıklama dizesinde "MemoryLimiter:AnonSwap" ifadesi yer alır. Bellek sınırına ulaşıldığında bellek yığını dökümlerini otomatik olarak yakalamak için TRIGGER_TYPE_ANOMALY kullanarak tetikleyici tabanlı profil oluşturma özelliğinden de yararlanabilirsiniz. Ayrıca Android, Google Play Console'da geliştiricilere daha fazla saha içi bellek metriği sunmak için aktif olarak çalışmaktadır.

Ayrıca, yerel hata ayıklama komutlarını da içerecek şekilde bellek sınırları dokümanımızı genişlettik. Bu sayede, yerel ortamınızda bellek kısıtlamalarını simüle edebilir ve uygulamanızın herhangi bir bellek sınırı yaptırımı altındaki davranışını doğrulayabilirsiniz. 

R8 ile bayt kodu optimizasyonunu en üst düzeye çıkarma

Uygulamanızın bellekte kapladığı yeri azaltmanın oldukça etkili bir yolu R8 optimize edicisini etkinleştirmektir. R8, sınıfları, yöntemleri ve alanları daha kısa adlara küçülterek ve kullanılmayan kodları ve kaynakları kaldırarak yürütme sırasında gereken yerleşik kod miktarını en aza indirir. Böylece uygulamanızın bellekte kaplanan yerini önemli ölçüde azaltır.

R8, yerleşik kodu en aza indirerek bellekte kaplanan yeri küçültür ve LMK sonlandırma riskini azaltır. Bu durum, yavaş gerçekleşen baştan başlatma yerine daha sık hazır durumda başlatmaya yol açar. Ayrıca, basitleştirilmiş bayt kodu, ana iş parçacığı CPU yükünü azaltarak daha akıcı bir kullanıcı deneyimi için ANR oranlarını doğrudan düşürür. Örneğin, dijital banka Monzo, tam R8 optimizasyonunu etkinleştirdi ve ANR oranında% 35 azalma, baştan başlatma oranında% 30 artış ve genel uygulama boyutunda% 9 azalma elde etti.

pic1-IO26_113_TSV-monzo-casestudy.jpg
Dijital banka Monzo, R8'in tam optimizasyonunu etkinleştirerek performans metriklerini %35'e kadar artırdı.

build.gradle dosyanızda R8'i doğru şekilde yapılandırmak için:

  • isShrinkResources = true ve isMinifyEnabled = true değerlerini ayarlayın.
  • Optimizasyonları engelleyen ve Android Gradle eklentisi 9'da artık desteklenmeyen eski proguard-android.txt yerine proguard-android-optimize.txt kullanın.
  • android.enableR8.fullMode = false uygulamasını gradle.properties cihazınızdan kaldırın.

Kod tabanınızda yansıtma kullanıyorsanız R8'in kodun bu kısımlarını optimize etmesini önlemek için Keep kurallarını ekleyin. Maksimum optimizasyon elde etmek için saklama kurallarının kapsamını daralttığınızdan emin olun. 

Maksimum optimizasyon elde etmek için saklama kuralı dosyanızda aşağıdaki en iyi uygulamalardan yararlanın.

  • R8'in kod tabanının tamamını optimize etmesini engelleyen -dontoptimize, -dontshrink ve -dontobfuscate gibi genel seçenekleri kaldırın.
  • Etkinlik, Hizmetler, Görünümler veya Yayın alıcılar gibi Android bileşenlerinin optimize edilmesini engelleyen saklama kurallarını kaldırın.
  • Yalnızca belirli sınıfları veya yöntemleri hedeflemek için paketin tamamı için geçerli olan geniş kapsamlı saklama kurallarını hassaslaştırın. 

Diğer en iyi uygulamaları görmek için saklama kuralları dokümanlarımıza göz atın.

Kitaplık Geliştiricileri İçin R8'de En İyi Uygulamalar

Kitaplık geliştiriciyseniz tüketicilerinizin ihtiyaç duyduğu kuralları kesinlikle consumer-rules file dosyanıza yerleştirin ve kitaplığınızın dahili koruma kurallarını proguard-rules.pro dosyanızda tutun. Kitaplıkları optimize etme hakkında daha fazla bilgi için Kitaplık yazarları için optimizasyon başlıklı makaleyi inceleyin.

R8 Yapılandırma Analiz Aracı

R8 optimizasyonunuzu denetlemek için Yapılandırma Analiz Aracı'nı kullanın. Yapılandırma analiz aracı,  karartma, optimizasyon ve küçültme puanlarıyla optimizasyonun mevcut durumunu gösterir. Yapılandırma analizcisiyle, her bir koruma kuralının kaç sınıfın, yöntemin veya alanın optimizasyonunu engellediğini de anlayabilirsiniz. Maksimum optimizasyon için bu geniş paket genelinde saklama kurallarını hassaslaştırın. 

Yapılandırma analizcisini kullanarak diğer saklama kurallarını kapsayan saklama kurallarını, gereksiz saklama kurallarını ve kullanılmayan saklama kurallarını da belirleyebilirsiniz.

pic2-r8-config-analyzer.png
Yapılandırma Analiz Aracı, karartma, optimizasyon ve küçültme puanlarıyla optimizasyonun mevcut durumunu gösterir.

R8 Agent Skill 

Yanlış yapılandırmaları çözmek ve kurallarınızı iyileştirerek uygulama performansını artırmak için Android Studio aracısı veya diğer yapay zeka araçlarıyla birlikte R8 Agent Skill'den de yararlanabilirsiniz. (Yapay zeka destekli becerilerden elde edilen analizler için teknik doğrulama gerekir)

Resim yüklemeyi optimize etme

Bit eşlemler genellikle uygulamanızın belleğinde bulunan en büyük ortak nesnelerdir. Bunlar, resim yükleme sürecinin son aşamasını temsil eder. Bu aşamada, JPEG veya PNG gibi sıkıştırılmış dosyalar, görüntülenmek üzere ham piksel verilerine dönüştürülür. Bu nedenle, bellek tüketimi resmin piksel boyutları ve renk derinliği ile belirlendiğinden, 100 KB'lık küçük bir sıkıştırılmış resim birkaç megabayt RAM'e kadar çıkabilir. Bitmap işlemleri genellikle kare çizme için kritik yolda olduğundan, optimize edilmemiş resimler ciddi bellek şişmesine ve kullanıcı arayüzü takılmasına neden olur.

Google, özellikle Jetpack Compose ile geliştirme yaparken Kotlin öncelikli projeler için Coil, Java tabanlı uygulamalar için ise Glide görüntü yükleme kitaplıklarını kullanmanızı önerir.

Şu beş en iyi uygulamayı benimseyin

  1. Resimleri küçültme: Bit eşlemleri manuel olarak yüklüyorsanız küçük bir resim görünümüne çok büyük bir resim yüklemeyin. Daha küçük bir sürümü yüklemek için inSampleSize kullanın. Glide ve Coil, resimleri varsayılan olarak alt örnekleme yapar. Bu alt örnekleme stratejisini sırasıyla DownsampleStrategy ve ImageLoader kullanarak yapılandırabilirsiniz.
  2. Kırpma: Mektup kutusu oluşturmak için doğrudan bir resim dosyasına dolgu yerleştirmekten kaçının (ör. resim boyutlarını genişletmek için şeffaf bir kenarlık oluşturma). Bu kenarlıkları yerleştirmek yerine InsetDrawable kullanın veya dolguyu doğrudan bit eşlemi içeren View veya Composable içinde uygulayın.
  3. Yapılandırma: Doğru piksel biçimini seçerek bellek ve kalite arasında denge kurun. Şeffaflık gerekmediğinde RGB_565 biçimini kullanın. Bu biçim, varsayılan ARGB_8888 biçiminin yarısı kadar bellek kullanır. Glide'da DecodeFormat'ı, Coil'da ise bitmapConfig özelliğini kullanarak bu ayarı yapılandırabilirsiniz.
  4. Vektör çizilebilir öğelere öncelik verin: Temel geometrik öğeler için rasterleştirilmiş bit eşlemlerin kodunu çözmeye yönelik hafif bir alternatif olarak ShapeDrawable'ı kullanın. Bu öğeleri XML aracılığıyla bir kez tanımlayarak, kaynak odaklı bellek şişmesini etkili bir şekilde ortadan kaldırırken tüm ekran yoğunluklarında sorunsuz bir şekilde ölçeklenmelerini sağlarsınız.
  5. Yeniden kullanma: Uygulamanız Bitmaps'i manuel olarak yönetiyorsa bellek karmaşasını en aza indirmek için bir bitmap'e artık ihtiyaç duyulmadığında uygulama bitmap.recycle() işlevini çağırmalı ve Bitmap referansını hemen silmelidir. Glide veya Coil gibi bir resim yükleme kitaplığı kullanıyorsanız bit eşlemi kitaplığın yönetilen havuzuna döndürün. Gelecekteki bellek ihtiyaçları için mevcut bir arabellek sağlayan havuz, yeni ayırmaların ek yükünü etkili bir şekilde önler.

Daha fazla bilgi edinmek için Görsellerin performansını optimize etme başlıklı dokümanımızı inceleyin.

Android Studio araçları

Ayrıca Android Studio Narwhal 4'ü kullanarak gereksiz bit eşlemleri de ortadan kaldırabilirsiniz. Bunları beş basit adımda nasıl bulacağınız aşağıda açıklanmıştır:

  1. Android Studio'da Profiler sekmesini açın.
  2. Heap Dump'ı (veya "Analyze Memory Usage") tıklayın ve uygulamanızın mevcut bellek durumunun anlık görüntüsünü almak için kayda basın.
  3. Android Studio'nun birden fazla kez depolanan yinelenen bit eşlemleri işaretlemek için kullandığı sarı uyarı üçgeni ⚠️ için analiz sonuçlarını tarayın. Alternatif olarak, profiler üstbilgisine gidin, "Filtreleme ölçütü:"nü seçin ve "Yinelenen Bit Eşlemler" ayarını belirleyin.
  4. Bitmap Önizleme bölmesini açmak için işaretli girişlerden herhangi birini tıklayın. Böylece, hangi resmin tekrar eden ihlalde bulunduğunu tam olarak görebilirsiniz.
  5. Kodunuzdaki gereksiz yükleme mantığını bulmak ve daha iyi bir önbelleğe alma stratejisi uygulamak için bu görsel onaydan yararlanın.
pic3-IO26_113_TSV -dup-bitmaps-cropped.jpg
Android Studio Profiler'ı kullanırken yığın dökümlerinde sarı uyarı üçgeni ⚠️ simgesini bulun.

Android Studio ile bellek sızıntılarını tespit etme ve düzeltme

Android'deki bellek sızıntıları, kodunuz bir nesnenin referansını yaşam döngüsü sona erdikten çok sonra tuttuğunda meydana gelir. Bu durum, çöp toplayıcının (GC) bu belleği geri kazanmasını engeller ve sonuç olarak performansın yavaşlamasına veya OutOfMemoryError (OOM) hatasına yol açar.

Android Studio Panda 3, geliştiricilerin gerçek zamanlı bellek sızıntılarını analiz etmesine ve izleri doğrudan IDE'de eşlemesine olanak tanıyan özel bir LeakCanary profiler görevine sahiptir.

Android Studio'daki LeakCanary profiler görevi, bellek sızıntısı analizini cihazınızdan geliştirme makinenize aktif olarak taşır. Bu sayede, sızıntı analizi aşamasında cihaz üzerinde yapılan sızıntı analizine kıyasla önemli bir performans artışı elde edilir.

pic4-android-studio-leaks.png
 Hata ayıklama için bildirime git ile bağlamsallaştırılmış LeakCanary bellek sızıntısı analizi

Ayrıca, sızıntı analizi artık IDE'de bağlamsallaştırılıyor ve kaynak kodunuzla tamamen entegre ediliyor. Bu sayede, bellek sızıntılarını incelemek ve düzeltmek için gereken süreyi ve zorluğu önemli ölçüde azaltan, bildirime gitme gibi özellikler ve diğer faydalı kod bağlantıları sağlanıyor.  

Sık karşılaşılan bellek sızıntısı örnekleri 

Bellek sızıntıları, bir nesne amaçlanan kullanım ömrünün ötesinde bellekte kalıcı olduğunda meydana gelir. Bu durum genellikle şu nedenlerden kaynaklanır:

  • Artık kullanılmayan Fragment'lara, Activity'lere veya View'lara yapılan referansları tutma
  • Bağlam referanslarının yanlış yönetilmesi.
  • Gözlemcilerin, işleyicilerin ve alıcıların kaydının düzgün şekilde silinmemesi.
  • Daha kısa yaşam döngülerine sahip bileşenlere bağlı nesnelere statik referanslar oluşturma.

Aşağıda birkaç örnek senaryo verilmiştir:

SenaryoCompose tabanlı örnekGörüntülemeye dayalı örnek
Bağlamın Sızdırılması

Örnek:
LocalContext.current öğesini bir ViewModel'e aktarma

Düzeltme:
Bağlama bağlı mantığı kullanıcı arayüzü katmanında tutun. Kullanıcı arayüzü olmayan katmanlarda, bağımlılık ekleme kullanmak için yeniden düzenleme yapın veya Kotlin akışı kullanarak kullanıcı arayüzü durumunu gözlemleyin.

Örnek: 
Bir Activity öğesini yardımcı nesnede veya statik değişkende depolama.

Düzeltme:
Kullanıcı arayüzü bileşenlerine statik referanslar tutmayın. Bağımlılık ekleme kullanmak için yeniden düzenleyin veya Kotlin akışı ile kullanıcı arayüzü durumunu gözlemleyin.

Sızıntı yapan işleyiciler

Örnek:
Bir dinleyiciyi başlatmak için DisposableEffect kullanma ancak onDispose öğesini boş bırakma.

Düzeltme:
Kaydı silme ve temizleme mantığını onDispose bloğunda gerçekleştirin.

Örnek:
SensorManager güncellemelerine kaydolup kaydı silmeyi unutma.

Düzeltme:
onStop() veya onDestroy() yaşam döngüsünde unregisterListener()'i manuel olarak çağırın.

Görüntüleme Sayılarının Sızması

Örnek:
Yayın stratejisi olmadan AndroidView içinde View eski bir referansı tutma.


Düzeltme:
Eski View öğesini temizlemek için AndroidView composable'ın release bloğunu kullanın.

Örnek:
Fragment kaldırıldıktan sonra görünüm bağlama nesnesine referans tutma.

 

Düzeltme:
Bağlama değişkenini onDestroyView() yaşam döngüsü yönteminde null olarak ayarlayın.

Uygulama görünür durumdan çıktığında anıyı kırp

Android, Bellek yönetimine genel bakış bölümünde açıklandığı gibi, kritik görevler için bellek boşaltmak gerektiğinde uygulamanızdan bellek geri alabilir veya uygulamanızı tamamen durdurabilir. Android, uygulamanız kullanıcıya görünür olmadığında genellikle uygulamanızın kullandığı belleği geri alır. Örneğin, uygulamanızın bellekteki kod ve veri sayfalarından bazılarını siler veya yığın ayırmalarınızı sıkıştırır. Kullanıcı uygulamanızı devam ettirdiğinde ve uygulamanız geri kazanılmış bir belleğe erişmeye çalıştığında işletim sistemi, bu belleği isteğe bağlı olarak geri değiştirir. Bu takas davranışı yavaş olabilir ve uygulamanızda beklenmedik duraklamalara veya takılmalara neden olabilir.

Uygulamanızdan hangi belleğin geri alınacağına işletim sisteminin karar vermesine izin verirseniz işletim sisteminin, uygulamanızı devam ettirdikten kısa süre sonra ihtiyacınız olacak belleği geri aldığını görebilirsiniz. Bunun yerine, uygulamanız daha sonra isteğe bağlı olarak ve düşük maliyetle yeniden oluşturabileceği bellek ayırmalarını gönüllü olarak silebilir. Bunun için ComponentCallbacks2 arayüzünü uygulayabilirsiniz. onTrimMemoryActivity, Fragment, Service veya özel Application sınıfınızda uygulayabilirsiniz. Bu özelliği Application sınıfında kullanmak, küresel önbellek yönetimi için oldukça etkilidir.

Sağlanan onTrimMemory() geri çağırma yöntemi, uygulamanızı yaşam döngüsü veya bellekle ilgili etkinlikler konusunda bilgilendirir. Bu etkinlikler, uygulamanızın bellek kullanımını gönüllü olarak azaltması için iyi bir fırsat sunar.

Bellek yaşam döngüsü yönetimi açısından uygulamanız yalnızca TRIM_MEMORY_UI_HIDDEN ve TRIM_MEMORY_BACKGROUND üzerine odaklanmalıdır. Android 14'ten itibaren sistem, Android 15'te resmen kullanımdan kaldırılan diğer eski sabitler için bildirim göndermeyi durdurdu.

TRIM_MEMORY_UI_HIDDEN: Bu sinyal, uygulamanızın kullanıcı arayüzünün kullanıcının görünümünden çıktığını gösterir. Bu, kesinlikle arayüze bağlı olan önemli bellek ayırmalarını (ör. bit eşlemler, video oynatma arabellekleri veya karmaşık animasyon kaynakları) serbest bırakma fırsatı sunar.

TRIM_MEMORY_BACKGROUND: Bu düzeyde, işleminiz arka planda çalışır ve sistemin genel bellek ihtiyaçlarını karşılamak için sonlandırılmaya adaydır. İşleminizin önbelleğe alınmış durumda kalma süresini uzatmak ve uygulamanın sıfırdan başlatılma sayısını azaltmak için, kullanıcı oturumuna devam ettiğinde kolayca yeniden oluşturulabilecek tüm kaynakları agresif bir şekilde serbest bırakmanız gerekir.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Not: onTrimMemory entegrasyonu, SDK desteğine bağlı olabilir. Örneğin, belirli oyunlar bu özelliği etkinleştirmek için oyun motorlarını kullanır. Lütfen oyun belleği optimizasyonu belgelerini inceleyin.

ProfilingManager ile gelişmiş bellek gözlemlenebilirliği

Sahada yerel olarak yeniden üretilemeyen bellek sorunlarını yakalamak ve teşhis etmek için ProfilingManager API'yi kullanmanız gerekir. Android 15'te kullanıma sunulan bu gelişmiş gözlemlenebilirlik API'si, gerçek kullanıcı Perfetto profillerini programatik olarak toplamanıza olanak tanır. 

Performans yapılarını yönetmek ve barındırmak için özel bir altyapısı olmayan ekipler için Crashlytics, bu iş akışını kolaylaştıracak özel bir çözüm üzerinde çalışıyor. Geliştiricileri geri bildirimde bulunmaya davet ediyorlar.

Android 17, yeni etkinlik odaklı tetikleyiciler sunuyor. Bunlardan en önemlileri TRIGGER_TYPE_OOM ve TRIGGER_TYPE_ANOMALY:

  • OOM tetikleyici, OutOfMemoryError kilitlenmesi gerçekleştiği anda Java yığın dökümünü otomatik olarak toplayarak kesin ayırma durumları sağlar. Toplanan bir OOM profili, uygulama bir sonraki başlatılışında ve registerForAllProfilingResults geri çağırmasını kaydettiğinde sağlanır.
  • Anomali tetikleyici, aşırı bağlayıcı spam'i veya bellek eşiklerinin ihlal edilmesi gibi ciddi performans sorunlarını tespit eder. Bellek anormalliği, sistem uygulamayı sonlandırmadan hemen önce yığın dökümü sağlar.
    val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Yığın dökümünü topladıktan sonra profili sunucudan veya yerel olarak adb pull aracılığıyla indirebilir ve dosyayı Perfetto kullanıcı arayüzüne sürükleyip bırakabilirsiniz. Bellek hata ayıklama iş akışınızı kolaylaştırmak için Heap Dump Explorer'ı kullanın. Bu, Perfetto kullanıcı arayüzündeki yığın dökümleri için yeni varsayılan görünümdür. Bu araç, Java yığın dökümlerini incelemek için sezgisel bir arayüz sunar. Böylece, nesne ayırma hiyerarşilerini görselleştirebilir, tutulan bellek boyutlarını hesaplayabilir ve atık toplama kökünden en kısa yolu belirleyebilirsiniz. Heap Dump Explorer'ı kullanarak bellek sızıntılarını, aşırı bit eşlem ayırmaları gibi şişirilmiş tutulan nesneleri hızlıca belirleyebilir ve yığın nesne ayırmalarını tek bir yerden analiz edebilirsiniz.

pic5-perfettoheapdump-analyzer.png
En yüksek yığın ayırmalarına sahip nesneleri görsel olarak incelemek ve bunlar arasında gezinmek için Heap Dump Explorer'ın yerleşik alev grafiğini kullanın.

Sonuç

R8 ile bayt kodunu optimize etme, görsel yükleme ile ilgili en iyi uygulamaları benimseme ve bellek sızıntılarını çözme, kaynakları baskı altında etkili bir şekilde yönetirken yüksek kaliteli bir kullanıcı deneyimi sunmaya yönelik kritik adımlardır. Bu proaktif önlemleri uygulamak, kullanıcı bağlamını korurken uygulamanın kararlılığını ve performansını korumaya yardımcı olur ve beklenmedik sonlandırmaları önler. Performans uzmanlığınızı geliştirmek için revize edilmiş bellek kılavuzumuzu inceleyin.

Yazan:
Okumaya devam et