Registrar alocações nativas
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Se você estiver escrevendo código nativo e estiver preocupado com o uso de memória, é útil
criar um perfil das alocações nativas do app para descobrir se há oportunidades de
otimização.
Por que é necessário criar o perfil da memória do app
O Android oferece um ambiente de memória
gerenciado: quando o Android determina que
o app não está mais usando alguns objetos, o coletor de lixo libera a
memória não utilizada de volta para a heap. A forma como o Android encontra memória não utilizada é
sempre melhorada, mas em todas as versões do Android, o sistema
precisa pausar brevemente o código. Na maior parte das vezes, as interrupções são imperceptíveis.
No entanto, se o app alocar memória com mais rapidez do que o sistema consegue coletá-la,
o app poderá ficar mais lento enquanto o coletor libera memória suficiente para atender
às alocações. Esse atraso pode fazer com que o app pule frames e gere
uma lentidão visível.
Para saber mais sobre práticas de programação que podem reduzir o uso de memória do app,
leia Gerenciar a memória do app.
Visão geral das alocações nativas
Quando você executa a tarefa Track Memory Consumption (Native Allocations),
o Profiler do Android Studio rastreia as alocações e desalocações de objetos no
código nativo pelo período especificado e fornece as seguintes
informações:
- Alocações: uma contagem de objetos alocados usando
malloc() ou o operador new
durante o período selecionado.
- Deallocations: uma contagem de objetos desalocados por
free() ou pelo operador
delete durante o período selecionado.
- Deallocations: o tamanho agregado em bytes de todas as alocações durante
o período selecionado.
- Deallocations Size: o tamanho agregado em bytes de toda a memória liberada
durante o período selecionado.
- Total Count: o valor da coluna Allocations menos o valor da coluna Deallocations.
- Remaining Size: o valor da coluna Allocations Size menos o valor da coluna Deallocations Size.
A guia Visualização mostra uma visualização agregada de todos os objetos relacionados ao
código nativo na pilha de chamadas durante o período selecionado. Ele mostra
quanta memória total o callstack com as instâncias mostradas consome.
A primeira linha mostra o nome da linha de execução. Por padrão, os objetos são empilhados da esquerda para a direita com base no tamanho da alocação. Use o menu suspenso para mudar a ordem.
Por padrão, o profiler usa o tamanho de amostra de 2048 bytes: sempre que 2048 bytes
de memória são alocados, um instantâneo da memória é tirado. Uma amostra menor
resulta em snapshots mais frequentes, gerando dados mais precisos sobre o uso da
memória. Um tamanho de amostra maior produz dados menos precisos, mas consome menos
recursos do sistema e melhora o desempenho durante a gravação. Para mudar o tamanho
da amostra, consulte Editar a configuração de gravação.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
