Yerel tahsisleri kaydetme
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Yerel kod yazıyorsanız ve bellek kullanımıyla ilgili endişeleriniz varsa optimize etme fırsatı olup olmadığını öğrenmek için uygulamanızın yerel tahsislerini profillemek faydalı olabilir.
Uygulamanızın belleğini neden profillemeniz gerekir?
Android, yönetilen bir bellek ortamı sağlar. Android, uygulamanızın artık bazı nesneleri kullanmadığını belirlediğinde, çöp toplayıcı kullanılmayan belleği yığına geri bırakır. Android'in kullanılmayan belleği bulma yöntemi sürekli olarak iyileştiriliyor olsa da tüm Android sürümlerinde sistemin bir noktada kodunuzu kısa süreliğine duraklatması gerekir. Duraklamalar çoğu zaman fark edilmez.
Ancak uygulamanız belleği sistemden daha hızlı ayarlarsa toplayıcı, ayırdığınız alanı karşılayacak kadar bellek ayırırken uygulamanız gecikebilir. Gecikme, uygulamanızın kareleri atlamasına ve belirgin bir yavaşlığa neden olabilir.
Uygulamanızın bellek kullanımını azaltabilecek programlama uygulamaları hakkında bilgi edinmek için Uygulamanızın belleğini yönetme başlıklı makaleyi okuyun.
Doğal atamalara genel bakış
Bellek Tüketimini İzle (Yerel Ayırma İşlemleri) görevini çalıştırdığınızda Android Studio Profiler, belirttiğiniz dönem için yerel koddaki nesnelerin ayırma ve ayırma işlemlerini izler ve aşağıdaki bilgileri sağlar:
- Ayrımlar: Seçilen dönemde
malloc() veya new operatörü kullanılarak ayrılan nesnelerin sayısı.
- Deallocations: Seçilen dönemde
free() veya delete operatörü kullanılarak ayrılan nesnelerin sayısı.
- Ayrıntı boyutu: Seçilen dönemdeki tüm ayrıntıların bayt cinsinden birleştirilmiş boyutu.
- Deallocations Boyutu: Seçilen dönemde serbest bırakılan tüm belleğin bayt cinsinden toplam boyutu.
- Toplam Sayı: Ayrımlar sütunundaki değerden Anlaşma yerleri sütunundaki değer çıkarılarak hesaplanır.
- Kalan Boyut: Ayrımlar Boyutu sütunundaki değerden Anlaşma Ayrımları Boyutu sütunundaki değer çıkarılarak hesaplanır.
Görselleştirme sekmesi, seçilen zaman aralığında çağrı yığınındaki yerel kodla ilgili tüm nesnelerin toplu görünümünü gösterir. Temel olarak, gösterilen örneklerin bulunduğu çağrı yığınının ne kadar toplam bellek kapladığını gösterir.
İlk satırda ileti dizisi adı gösterilir. Nesneler varsayılan olarak, tahsis boyutuna göre soldan sağa doğru yığılır. Sırayı değiştirmek için açılır menüyü kullanın.
Profilleyici varsayılan olarak 2.048 baytlık bir örnek boyutu kullanır: 2.048 bayt bellek her atandığında belleğin anlık görüntüsü alınır. Örnek boyutunun daha küçük olması, daha sık anlık görüntü alınmasına ve bellek kullanımıyla ilgili daha doğru veriler elde edilmesine neden olur. Daha büyük örnek boyutları daha az doğru veriler sağlar ancak daha az sistem kaynağı tüketir ve kayıt sırasında performansı artırır. Sana Özel bölümündeki videoların örnek boyutunu değiştirmek için Kayıt yapılandırmasını düzenleme başlıklı makaleyi inceleyin.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# Record native allocations\n\nIf you're writing native code and concerned about its memory usage, it's helpful\nto profile your app's native allocations to discover if there's opportunity to\noptimize.\n\nWhy you should profile your app memory\n--------------------------------------\n\nAndroid provides a [managed memory\nenvironment](/topic/performance/memory-overview)---when Android determines that\nyour app is no longer using some objects, the garbage collector releases the\nunused memory back to the heap. How Android goes about finding unused memory is\nconstantly being improved, but at some point on all Android versions, the system\nmust briefly pause your code. Most of the time, the pauses are imperceivable.\nHowever, if your app allocates memory faster than the system can collect it,\nyour app might be delayed while the collector frees enough memory to satisfy\nyour allocations. The delay could cause your app to skip frames and cause\nvisible slowness.\n\nFor information about programming practices that can reduce your app's memory\nuse, read [Manage your app's memory](/topic/performance/memory).\n\nNative allocations overview\n---------------------------\n\nWhen you run the [**Track Memory Consumption (Native Allocations)**](/studio/profile#start-profiling) task,\nthe Android Studio Profiler tracks allocations and deallocations of objects in\nnative code for the time period that you specify and provides the following\ninformation:\n\n- **Allocations** : A count of objects allocated using `malloc()` or the `new` operator during the selected time period.\n- **Deallocations** : A count of objects deallocated using `free()` or the `delete` operator during the selected time period.\n- **Allocations Size**: The aggregated size in bytes of all allocations during the selected time period.\n- **Deallocations Size**: The aggregated size in bytes of all freed memory during the selected time period.\n- **Total Count** : The value in the **Allocations** column minus the value in the **Deallocations** column.\n- **Remaining Size** : The value in the **Allocations Size** column minus the value in the **Deallocations Size** column.\n\nThe **Visualization** tab shows an aggregated view of all the objects related to\nnative code in the call stack during the time range selected. It essentially\nshows you how much total memory the callstack with the instances shown takes.\nThe first row shows the thread name. By default, the objects are stacked left to\nright based on allocation size; use the drop-down to change the ordering.\n\nBy default, the profiler uses a sample size of 2048 bytes: Every time 2048 bytes\nof memory are allocated, a snapshot of memory is taken. A smaller sample size\nresults in more frequent snapshots, yielding more accurate data about memory\nusage. A larger sample size yields less accurate data, but it consumes fewer\nsystem resources and improves performance while recording. To change the sample\nsize, see [Edit the recording configuration](/studio/profile#edit-recording)."]]
