进程内存组成Android 每个 App 通常运行在独立进程里进程内存大致分为几块区域说明Java HeapJava/Kotlin 对象new、数组、String、集合等由 ART/Dalvik 管理Native HeapC/C、malloc、newnative、JNI、相机、WebView、各类 Native SDKStack各线程栈空间Code映射进内存的 so、jar、dex、apk 等Graphics图形缓冲Bitmap、Surface 等其它mmap、Ashmem 等系统起来后每个app 的总内存占有都是动态的不是固定的根据使用情况而改变过大或系统内存紧张时可能被LMKLow Memory Killer杀掉而每个app都是一个独立的虚拟机VM系统会给这个进程的VM分配 相对固定的配置上限进程总内存和 VM 内存上限 是两个概念进程总内存包含 Java heapVM 管的那块也包含 Native 等总内存一般不是系统预先固定分配的一个数字而是各部分加起来、再受系统整体约束而java Heap 的内存就是在这个VM的内存上超过了这个指定的VM的内存 就会java oom但是Navtiv层 的内存就不受VM管了所以会出现Java heap 还不高App 已经被杀 —— 多半是 Native / 图形内存高了不是 Java OOM。设备物理内存 8GB│├── 系统 / 其它 App│└── 你的 App 进程│├── Java Heap ← 上限例如 512MBVM/ART 管├── Native Heap ← 不受 Java 512MB 限制├── Graphics└── 其它│└── 合起来 进程总内存可能 800MB、1.5GB…│└── 太大或系统紧张 → 可能被 LMK 杀掉不一定是 Java OOMadb shell dumpsys meminfo 包名 可以查看当前对应的进程 内存区域 java heapnative heap栈stack等内存分配情况这里是上面关键的字段分析关键行行含义Native HeapNative 内存Dalvik HeapJava 内存ART 管理Stack线程栈.so / .jar / .apk mmap代码与资源映射TOTAL汇总TOTAL PSS ≈ 进程总占用关键列列含义Pss Total该类内存在进程 PSS 中的贡献Heap Size / Alloc / Freeheap 内部统计排查 OOM / 被杀进程时Java OOM 看 Dalvik莫名被杀看 TOTAL PSS 和 Native/Graphics。adb shell getprop | grep -i heap 这个命令查看 查看当前设备的 VM的设置情况heapgrowthlimit (192m) 代表默认的每个app VM层的上限heapsize (512m) 当你的应用在android Manifest 中设置了 android:largeHeap“true” 能给到的最大内存heapstartsize (8m)刚启动时先给的 每个app VM层的内存VM虚拟机的创建new的对象有生命周期包括新声代和老年代等Android vm 会根据可达性分析算法对这些对象进行gc root 不是引用计数所以优化方向是断开不必要的引用置 null、从集合 remove、取消监听、关流等让对象变成不可达。系统会对每个进程分等级其中有空进程后台进程服务进程可见进程前台进程一层比一层等级变高前台进程是最高的当系统需要回收的时候会先回收空进程整个系统的ActivityManagerService 会对每个进程进行评分是哪个等级存在变量adj中.内存紧张时LMK按优先级从低到高回收进程。被杀不一定是 OOM常常是系统主动回收可以尝试吧进程等级调高来进行保活OOM 不只有 Java OOM还要关注.Native OOM大图、相机、FFmpeg等).进程总内存过大被 LMK 杀meminfo 里 TOTAL PSS 高但 Java heap 还不满出问题是要分析是 泄漏内存只涨不降还是 峰值过高某操作瞬间很大是 Java 还是 Native / Graphics峰值对应什么操作进页面、切图、列表滑动、测量、WebView…谁占最大Bitmap、byte[]、String、自定义大数组…为何还被引用从 GC Root 跟引用链分析的工具使用命令 adb shell dumpsys meminfo 包名 看 PSS、Java/Native/Graphics 内存使用情况Android Studio Memory Profiler 实时 Java/Native 曲线、分配记录、Heap Dump每个对象引用链路LeakCanary 开发期泄漏查看内存泄漏Perfetto / Systrace 和 GC、卡顿一起看总结 内存过高会导致 GC 频繁、卡顿、发热严重时 Java OOM 或进程因总内存过大被系统杀掉。内存管理要点是合理分配、避免泄漏、及时释放不再需要的引用与资源。排查上用 Memory Profiler 看内存随时间变化峰值时对照业务 Heap Dump每个对象引用链路用 LeakCanary 开发期泄漏查看内存泄漏优化上依据 可达性GC Roots 根搜索断开多余强引用、取消监听、关闭流、清理缓存让对象可被回收同时关注 Native/Graphics不只看 Java heap堆。Android Studio Memory Profiler 的使用当点击profile 的时候会出现如图下面的画面右边红色区域 就是看内存我们主要是 看 View Live Telemetry 和 Analyze Memory Usage Heap Dump 快照 点击Start anyway 就会开启Past Recordings 是你对Home 每个模块点击区域操作的记录我们先来使用 View Live Telemetry 如何使用如图因为我们只是分析内存所以我们只需要看 MEMORY 下面部分就是对应的当前进程内存的波动形式 以及具体每个部分占用多少内存最底下的蓝色模块趋势就是我们着重会看的java 内存使用部分而左脚的删除垃圾按钮就是 点击可以进行 人为 手动 gc一旦gc 包括人为手动gc或者进程被gc操作了那么下吗就会有个对应时间的的垃圾图标Live Telemetry 能做什么、不能做什么Live Telemetry 是用来看内存总趋势每个操作每个时间点每个场景对应的内存趋势波动如果你手动强制gc 内存能大幅度下降还好如果gc 不能下降一直占用着那么怀疑是有泄漏或者对象持有了大内存那么这个时候你想分析具体当前对应指定的场景和时间点每个对象对象占用对谁内存每个对象对应的引用链路是如何那么就需要使用工具 Analyze Memory Usage Heap Dump 快照Analyze Memory Usage Heap Dump 快照 快照的意思就是对某个时间点进行拍照记录当下场景 所有对象的内存占用情况现在我们来学习如何在快照中看对所有对象象内存占用情况和每个对象的引用链路现在我们进行模拟下泄漏场景手动代码制造泄漏我们创建了一个单例对象MemoryScenarioManager然后单例对象 里面有个 leakedByteArrays 然后他添加了字节而由于是静态的所有你gc的时候是不会回收的然后我们开下快照如图最上面显示着当前进程下每个类占用的内存大小Shallow Size 对象本身自己多大Retained Size删掉这个对象能释放多少内存其实你可以粗略理解为 Shallow Size是这个对象本身的大小而Retained Size是这个对象携带的对象占用的大小虽然不大准Retained Size正确理解是 删掉这个对象能释放多少内存因为删掉他他携带的对象也自然会被删掉。当我们点击对应的类后会 出现下面的对应当前对象链路情况References 就是 显示 这个对象整条链路状态Thread (GC Root)└── contextClassLoader└── PathClassLoader└── Object[]└── Class└── static INSTANCE└── MemoryScenarioManager ← 你选中的对象而 Fields 则是当前这个对象里面的变量对象是什么有哪些如图我们点击Fields 就能看到 MemoryScenarioManager 里面有着 leakedByteArrays 这个对象并且占用多少内存