Android Profiler时间线与堆转储数值差异及关联疑问

一、Native内存时间线与堆转储数值差异原因 #

Android Profiler时间线显示的**Native内存（4.6MB）**是进程所有Native内存的总占用，包含以下几类：

• 应用通过JNI直接调用malloc/new分配的Native堆内存
• 系统加载的所有Native库（.so文件）的内存占用
• 图形渲染相关的Native缓冲区（如OpenGL纹理、Surface缓冲区）
• 系统为应用分配的其他Native内存块（如文件缓存、Socket缓冲区）

而堆转储中的Native统计范围要窄得多：

• 「查看应用堆」的~91KB：仅统计与应用Java/Kotlin对象绑定的Native内存（比如Bitmap的像素数据、ByteBuffer.allocateDirect创建的直接内存），这部分内存和Java对象强关联，会被堆转储追踪。
• 「查看所有堆」的~505KB：包含应用堆的Native内存，再加上进程中其他Native堆（如系统为应用创建的辅助堆），但依然不包含Native库加载内存、图形缓冲区这类非堆分配的Native内存。

两者的差距，本质是统计范围的不同——时间线是全局Native内存，堆转储只统计属于堆分配范畴的Native内存。

二、堆转储保留大小与时间线各内存项的关联 #

堆转储的保留大小是指：如果某对象被GC回收，能释放的所有关联内存总量（包括该对象本身，以及它引用的其他对象的内存）。它和时间线各部分的关联如下：

• Java内存：时间线的Java部分，对应堆转储中所有Java对象的保留大小总和，两者统计范围一致。
• Code：这是应用DEX字节码、Native库可执行代码的内存占用，属于代码段而非堆内存，堆转储不会统计这部分，和保留大小无关联。
• Stack：线程栈的内存（存储局部变量、调用栈），是线程私有空间，不属于堆分配，堆转储不统计，和保留大小无关。
• Graphics：图形相关内存大部分是系统管理的Native缓冲区（如SurfaceFlinger缓存），仅当Java对象（如Bitmap）绑定这部分内存时，才会在Native保留大小中体现一小部分，其余部分堆转储无法追踪。
• Others：系统分配的杂项内存（如文件缓存、Socket缓冲区），除非是和Java对象绑定的直接内存，否则堆转储不统计，和保留大小无直接关联。

内容的提问来源于stack exchange，提问作者Maksim Dmitriev