Enregistrer les allocations natives
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Si vous écrivez du code natif et que vous êtes préoccupé par son utilisation de la mémoire, il est utile de profiler les allocations natives de votre application pour déterminer s'il est possible de l'optimiser.
Pourquoi profiler la mémoire d'une application ?
Android fournit un environnement mémoire géré. Lorsqu'Android détermine que votre application n'utilise plus certains objets, le récupérateur libère la mémoire inutilisée pour la rendre disponible. La façon dont Android détecte la mémoire inutilisée est constamment améliorée, mais toutes les versions ont un point commun : à un moment donné, le système doit suspendre brièvement votre code. La plupart du temps, ces pauses sont imperceptibles.
Toutefois, si votre application alloue de la mémoire plus rapidement que le système ne peut la récupérer, son fonctionnement peut être retardé pendant que le collecteur libère suffisamment de mémoire pour satisfaire la demande. Certains frames peuvent être ignorés pendant ce délai, et votre application peut sembler lente à réagir.
Pour en savoir plus sur les pratiques de programmation permettant de réduire l'utilisation de mémoire de votre application, consultez la page Gérer la mémoire de votre application.
Présentation des allocations natives
Lorsque vous exécutez la tâche Suivre la consommation de mémoire (allocations natives), le profileur Android Studio suit les allocations et désallocations d'objets dans le code natif pendant la période que vous spécifiez, et fournit les informations suivantes:
- Allocations: nombre d'objets alloués à l'aide de
malloc() ou de l'opérateur new pendant la période sélectionnée.
- Deallocations: nombre d'objets désalloués à l'aide de
free() ou de l'opérateur delete pendant la période sélectionnée.
- Volume alloué: l'espace mémoire cumulatif (en octets) occupé par les allocations effectuées pendant la période sélectionnée.
- Volume désalloué: l'espace mémoire cumulatif (en octets) libéré par les désallocations effectuées pendant la période sélectionnée.
- Nombre total: la valeur de la colonne Allocations après déduction de celle de la colonne Désallocations.
- Volume restant: la valeur de la colonne Volume alloué après déduction de celle de la colonne Volume désalloué.
L'onglet Visualisation affiche une vue agrégée de tous les objets liés au code natif dans la pile d'appels pendant la période sélectionnée. Il indique essentiellement la quantité totale de mémoire utilisée par la pile d'appels avec les instances affichées.
La première ligne indique le nom du thread. Par défaut, les objets sont empilés de gauche à droite en fonction de la taille d'allocation. Utilisez le menu déroulant pour modifier l'ordre.
Par défaut, le profileur utilise un intervalle d'échantillonnage de 2 048 octets. Chaque fois que 2 048 octets de mémoire sont alloués, une capture instantanée est enregistrée. Un intervalle réduit génère des instantanés plus fréquents et fournit des données plus précises sur l'utilisation de la mémoire. Un intervalle large fournit des données moins précises, mais consomme moins de ressources système et améliore les performances lors de l'enregistrement. Pour modifier la taille d'échantillon, consultez Modifier la configuration d'enregistrement.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
