记录原生分配
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
如果您正在编写原生代码,并且担心其内存用量,不妨分析应用的原生分配情况,看看是否有优化机会。
为什么应分析您的应用内存
Android 提供了托管内存环境 - 当 Android 确定您的应用不再使用某些对象时,垃圾回收器会将未使用的内存释放回堆中。虽然 Android 查找未使用内存的方式在不断改进,但对于所有 Android 版本,系统都必须在某个时间点短暂地暂停您的代码。大多数情况下,这些暂停难以察觉。不过,如果您的应用分配内存的速度比系统回收内存的速度快,则当回收器释放足够的内存以满足您的分配需要时,您的应用可能会延迟。此延迟可能会导致您的应用跳帧,使其明显变慢。
如需了解可减少应用内存使用量的编程做法,请阅读管理应用内存。
原生分配概览
当您运行跟踪内存用量(原生分配)任务时,Android Studio 性能分析器会跟踪指定时间段内采用原生代码表示的对象的分配和解除分配情况,并提供以下信息:
- Allocations:在选定时间段内使用
malloc()
或 new
运算符分配的对象数。
- Deallocations:在选定时间段内使用
free()
或 delete
运算符解除分配的对象数。
- Allocations Size:在选定时间段内所有分配的总大小(以字节为单位)。
- Deallocations Size:在选定时间段内所有已释放内存的总大小(以字节为单位)。
- Total Count:Allocations 列中的值减去 Deallocations 列中的值所得的结果。
- Remaining Size:Allocations Size 列中的值减去 Deallocations Size 列中的值所得的结果。

可视化标签页会显示所选时间范围内调用堆栈中与原生代码相关的所有对象的汇总视图。它本质上显示的是包含所示实例的调用堆栈所占用的总内存量。第一行显示线程名称。默认情况下,对象会按分配大小从左到右堆叠;您可以使用下拉菜单更改排序。

默认情况下,性能分析器使用的采样大小为 2048 个字节:每次分配 2048 个字节的内存时,系统都会截取内存的快照。示例规模越小,快照越频繁,从而产生更准确的内存用量数据。示例规模越大,数据的准确性越差,但占用的系统资源越少,因此录制时的性能就越高。如需更改采样大小,请参阅修改录制配置。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-27。"],[],[],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)."]]