android dumpsys meminfo 详解

本文深入探讨了OOM机制,一种在低内存环境下保障系统稳定性的关键机制。文章详细解析了不同内存指标的概念,如USS、PSS、RSS和VSS,并通过dumpsys meminfo命令的输出结果,指导如何分析和优化Android应用的内存使用,防止OOM异常。

OOM机制是机器底层的一种强制保鲜,在OOM发生的时候内核会排序强制杀掉进程来保证系统的继续运行,同样这种OOM异常容易发生在低内存机器上,比如512M。

首先系统会根据程序是否是空进程(已经由用户关闭的不带有任何服务和provider的进程),是否有服务,是否有provider,是否为前台进程,来排序,可以输入 adb shell dumpsys meminfo来查看,列出信息中的Total PSS by OOM adjustment:就是系统为程序的OOM排序结果,OOM异常的时候会根据这个表单从下网上杀掉进程释放内存。

 

 

1.1 内存指标概念

Item全称含义等价
USSUnique Set Size物理内存进程独占的内存
PSSProportional Set Size物理内存PSS= USS+ 按比例包含共享库
RSSResident Set Size物理内存RSS= USS+ 包含共享库
VSSVirtual Set Size虚拟内存VSS= RSS+ 未分配实际物理内存

 

故内存的大小关系:VSS >= RSS >= PSS >= USS

从以上打印可以看出,一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS
VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)是单个进程全部可访问的地址空间
RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存)是单个进程实际占用的内存大小,对于单个共享库, 尽管无论多少个进程使用,实际该共享库只会被装入内存一次。
PSS - Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
USS - Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)USS 是一个非常非常有用的数字, 因为它揭示了运行一个特定进程的真实的内存增量大小。如果进程被终止, USS 就是实际被返还给系统的内存大小。
USS 是针对某个进程开始有可疑内存泄露的情况,进行检测的最佳数字。怀疑某个程序有内存泄露可以查看这个值是否一直有增加。

 

 

 

dumpsys meminfo命令的输出结果分以下4部分

 

序列划分类型排序解释
1processPSS以进程的PSS从大到小依次排序显示,每行显示一个进程;
2OOM adjPSSNative/System/Persistent/Foreground/Visible/Perceptible/A Services/Home/B Services/Cached,分别显示每类的进程情况
3categoryPSS以Dalvik/Native/.art mmap/.dex map等划分的各类进程的总PSS情况
4total总内存、剩余内存、可用内存、其他内存

打印某个程序内存信息,把包名写上,如:com.android.launcher

 

 

 

1 sh-4.2# dumpsys meminfo com.android.launcher  
 2 Applications Memory Usage (kB):  
 3 Uptime: 4497753 Realtime: 4497741  
 4   
 5 ** MEMINFO in pid 2683 [com.android.launcher] **  
 6                          Shared  Private     Heap     Heap     Heap  
 7                    Pss    Dirty    Dirty     Size    Alloc     Free  
 8                 ------   ------   ------   ------   ------   ------  
 9        Native     2144      988     2040     8636     5124     1699  
10        Dalvik     9481     8292     8644    13639    13335      304  
11        Cursor        0        0        0                             
12        Ashmem        2        4        0                             
13     Other dev        4       20        0                             
14      .so mmap      922     1892      292                             
15     .jar mmap        0        0        0                             
16     .apk mmap       90        0        0                             
17     .ttf mmap        0        0        0                             
18     .dex mmap      300        0        0                             
19    Other mmap     1634       16      112                             
20       Unknown     1830      580     1772                             
21         TOTAL    16407    11792    12860    22275    18459     2003  
22    
23  Objects  
24                Views:      146         ViewRootImpl:        1  
25          AppContexts:      374           Activities:        1  
26               Assets:        4        AssetManagers:        4  
27        Local Binders:       13        Proxy Binders:       23  
28     Death Recipients:        1  
29      OpenSSL Sockets:        0  
30    
31  SQL  
32                 heap:       59          MEMORY_USED:       59  
33   PAGECACHE_OVERFLOW:        1          MALLOC_SIZE:       46  
34    
35  DATABASES  
36       pgsz     dbsz   Lookaside(b)          cache  Dbname  
37          1      179             55         2/11/2  launcher.db  
38    
39  Asset Allocations  
40     zip:/system/app/Launcher2.apk:/resources.arsc: 340K  
41     zip:/system/app/MediaCenter.apk:/resources.arsc: 604K  

复制代码

 

Android程序内存被分为2部分:native和dalvik,dalvik就是我们平常说的java堆,我们创建的对象是在这里面分配的,而bitmap是直接在native上分配的,对于内存的限制是 native+dalvik 不能超过最大限制。Android程序内存一般限制在16M,当然也有24M的。
从上信息对于分析内存泄露,内存溢出都有极大的作用,从以上信息可以看到该应用程序占用的native和dalvik,当TOTAL 16407 11792 12860 22275 18459 2003超过内存最大限制时会出现OOM错误。
dumpsys能做的事还有很多

 

复制代码

1 dumpsys [options]  
2                meminfo 显示内存信息  
3                cpuinfo 显示CPU信息  
4                account 显示accounts信息  
5                activity 显示所有的activities的信息  
6                window 显示键盘,窗口和它们的关系  
7                wifi 显示wifi信息  

复制代码

 

 

 

 

 

 

<think>我们正在处理用户关于Android系统中dumpsys meminfo命令显示的Unknown内存部分的问题。用户希望了解Unknown内存的来源。 根据引用[2]:内存泄漏系列专题分析之三十一:Camx进程dumpsys meminfo Unknown部分内存拆解。其中提到: - 从dumpsys meminfo信息看:只有程序段、数据段、BSS段和栈区可能是unknown,但从50M大小看,也就代码code和全局变量定义可能这么大。而code我们无非大面积改动,更倾向于全局变量定义的数组太大等等原因。[^2] 另外,引用[5]:android meminfo,android dumpsys meminfo 详解。其中提到: - android程序内存被分为2部分:native和dalvik,dalvik就是java堆,普通java对象是在java堆分配,而bitmap是直接在native上分配,对于内存的限制是 native+dalvik 不能超过最大限制。[^5] 但是,我们关注的Unknown内存部分并不在native和dalvik中,它属于进程内存中的未知部分。 根据Android系统内存管理的知识,dumpsys meminfo命令输出的内存信息通常包括以下类别: - PSS Total: 整个进程的总内存 - Native Heap: 本地堆(如C/C++分配的内存) - Dalvik Heap: Java堆 - Dalvik Other: Dalvik部分的其他内存(如类加载器等) - Stack: 栈内存 - Ashmem: 匿名共享内存 - Gfx dev: 图形设备内存 - Other dev: 其他设备内存 - .so mmap: 共享库的内存映射 - .jar mmap: jar文件的内存映射 - .apk mmap: apk文件的内存映射 - .ttf mmap: 字体文件的内存映射 - .dex mmap: dex文件的内存映射 - Other mmap: 其他内存映射 - Unknown: 未知内存 Unknown内存通常是指那些无法被明确归类到以上类别的内存。根据引用[2]的分析,Unknown内存可能来源于: 1. 程序段(代码段,即text段) 2. 数据段(data段,存放已初始化的全局变量和静态变量) 3. BSS段(存放未初始化的全局变量和静态变量) 4. 栈区(stack) 然而,在dumpsys meminfo的输出中,这些区域通常会被分别统计,但有时候可能因为某些原因无法被正确归类,从而被归为Unknown。 另外,引用[3]提到:Android的swap并不像其他操作系统一样,将内存信息交换到外存中。它是将内存暂时不用的区域压缩之后放入另外一个内存区域中(zRam)。[^3] 但Unknown内存并不直接与zRam相关。 因此,我们可以总结Unknown内存的来源如下: - 主要是进程的代码段、数据段、BSS段和栈区等,这些区域在统计时可能因为某些原因没有被正确识别。 - 有时,一些自定义的内存分配(如通过mmap分配但未标记为特定类型的内存)也可能被归为Unknown。 为了进一步分析Unknown内存,可以尝试以下方法: 1. 使用更详细的内存分析工具,如`procrank`或`showmap`来查看进程的详细内存映射。 2. 检查代码中是否有大型的全局数组或静态数组,这些可能占用大量BSS或数据段内存。 3. 检查是否有大量的线程创建,因为每个线程会有一个栈,多个线程的栈内存总和可能很大。 最后,根据引用[4]:android dumpsys meminfo 详解。其中提到其他常用服务信息查询,但未直接涉及Unknown内存。[^4] 而引用[1]主要介绍了dumpsys meminfo命令的执行流程,也没有具体解释Unknown部分。[^1] 综上所述,Unknown内存主要来源于进程的代码段、数据段、BSS段和栈区等,这些区域在统计时未被明确归类。如果Unknown内存过大,需要检查代码中是否有大型全局数组或大量线程栈等。 §§相关问题§§ 1. 如何进一步分析Android进程中的Unknown内存? 2. 有哪些工具可以详细查看Android进程的内存映射? 3. 如何减少Android应用中的Unknown内存占用?</think>### Android dumpsys meminfo "Unknown" 内存来源详解 在 `dumpsys meminfo` 输出中,"Unknown" 内存指无法被明确归类到标准内存类别(如 Native Heap、Dalvik Heap、Stack 等)的部分。其来源主要包括: #### 1. **内核空间内存映射** - 进程通过 `mmap()` 直接分配的内存,但未标记为特定类型(如 `ASHMEM` 或 `DMA_BUF`)。 - 例如:自定义的共享内存或未标记的 I/O 缓冲区[^2]。 #### 2. **全局变量与静态数据区(BSS/Data段)** - **BSS 段**:存储未初始化的全局变量和静态变量(如大型数组 `static char buffer[50*1024*1024]`)。 - **Data 段**:存储已初始化的全局变量(如 `int global_array[10000] = {1};`)。 - 这些区域通常被归类为 "Unknown",因为系统未将其纳入堆或栈的统计[^2][^5]。 #### 3. **代码段(Text段)** - 可执行代码本身占用的内存(如 `.so` 库或 APK 中的机器指令)。 - 若代码段过大(如包含大量未压缩的本地库),可能被计入 "Unknown"[^2]。 #### 4. **线程栈的未统计部分** - 每个线程的栈空间默认约 1MB,但部分栈内存可能因未完全使用而未被精确统计[^3]。 #### 5. **内核驱动与硬件抽象层(HAL)** - 相机、传感器等硬件模块通过内核驱动分配的内存。 - 例如:Camera HAL 为图像处理预留的缓冲区[^2]。 #### 6. **内存压缩(zRAM)的间接影响** - 当内存不足时,系统用 zRAM 压缩部分内存。压缩/解压过程中的临时缓存可能被标记为 "Unknown"[^3]。 --- ### 排查建议 1. **使用 `procrank` 或 `showmap` 工具** ```bash adb shell procrank -p <PID> # 查看详细内存映射 ``` 可定位具体是哪些地址区间(如 `/data/my_lib.so` 或 `[anon]`)贡献了 "Unknown" 内存。 2. **检查全局变量** 大型全局数组或静态缓存是常见原因,需优化数据结构或改用动态分配[^2][^5]。 3. **分析内存映射文件** ```bash adb shell cat /proc/<PID>/maps # 查看进程内存映射 ``` 关注标记为 `---p`(私有)且无名称的区域。 4. **监控线程数量** 过多线程会导致栈内存累积,通过 `dumpsys threadstats` 检查线程数[^4]。 --- ### 示例输出解析 ``` Total PSS: 250MB Native Heap: 80MB Dalvik Heap: 60MB Stack: 10MB Unknown: 50MB <-- 可能来自 BSS 段的大型数组 ``` 此情况下,"Unknown" 占比较高,需重点检查全局变量或自定义内存分配[^2][^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值