1. 问题背景与现象描述
在Android系统开发过程中，内存泄漏问题一直是困扰开发者的顽疾。最近我们在某款智能手机的测试过程中，发现了一个值得深入分析的内存异常案例：vendor.qti.camera.provider-service_64进程在开机后内存占用超标约6MB。
这个现象是在以下标准测试环境下发现的：
- 设备刷入目标版本系统
- 执行恢复出厂设置
- 保持默认亮屏时间设置
- 手动跳过开机导航流程
- 清除所有可关闭的通知
- 开启ADB调试模式
- 设备连接电脑
- 执行内存一键清理
- 不插入SIM卡
- 不连接WiFi
在这种"纯净"状态下，测试机与对比机相比，vendor.qti.camera.provider-service_64进程的内存占用多出了5.8MB。作为系统关键服务进程，这种异常的内存占用增长可能会影响设备的整体性能和稳定性，特别是在低内存设备上。
2. 内存分析基础概念
在深入分析之前，我们需要明确几个关键的内存指标：
showmap输出指标解析：
- size：映射区域的总大小
- RSS（Resident Set Size）：实际驻留在物理内存中的部分
- PSS（Proportional Set Size）：按共享比例计算的内存占用
- clean/dirty：干净页（可回收）和脏页（已修改）
- swap：被交换到磁盘的内存
- Locked：被锁定无法换出的内存
特别值得注意的是PSS=0的情况，这通常意味着该内存区域是完全共享的，或者映射已经失效但尚未被正确释放。这正是我们本次案例中需要重点关注的现象。
3. 详细分析过程
3.1 对比机内存分析
我们首先获取了正常对比机的内存分布数据。通过showmap <pid>命令，可以详细查看特定进程的内存映射情况。对于vendor.qti.camera.provider-service_64进程，正常情况下的内存分布应该呈现特定的模式。
在对比机上，我们观察到该进程的典型内存分布：
- 多个so库映射（如libcamera、libqti等）
- 若干heap区域
- 一些anon（匿名）映射
- 必要的栈和vdso区域
关键指标如PSS、RSS等都在预期范围内，没有出现异常的dirty页积累。
3.2 测试机内存异常分析
在测试机上，我们发现了明显不同的内存分布模式。最显著的特点是出现了多个PSS=0的映射区域，这些区域在对比机上并不存在。通过详细比对，我们发现：
- 存在额外的mmap区域，标记为"deleted"但仍有RSS占用
- 某些共享库映射的PSS计算异常
- 匿名内存区域的大小明显偏大
使用procrank和dumpsys meminfo进一步确认，这些异常映射确实导致了约6MB的内存差异。
3.3 内存分布对比测试
为了准确定位问题，我们设计了以下对比测试方案：
- 时间维度对比：记录开机后不同时间点的内存变化
- 操作序列对比：相同操作下测试机与对比机的内存变化差异
- 映射状态对比：重点关注PSS=0的映射区域的生命周期
通过这种对比，我们发现测试机上某些mmap区域在理论上应该被释放后，仍然保持着RSS占用，这就是内存超标的直接原因。
3.4 PSS=0的深层原因分析
PSS=0通常有以下几种可能：
- 完全共享的映射（如某些系统库）
- 已经unmap但尚未完全释放的区域
- 内存统计的异常或错误
在我们的案例中，通过分析maps文件和smaps数据，确认这是第二种情况：某些通过mmap创建的内存区域在理论上已经被释放（表现为PSS=0），但实际上仍然占用物理内存（RSS>0）。这种现象通常被称为"幽灵内存"或"僵尸映射"。
进一步使用pmap -x和lsof分析，我们发现这些区域与相机服务的某些临时缓冲区相关，它们在完成工作后没有正确执行munmap操作。
4. 解决方案与验证
4.1 根本原因定位
经过代码审查和动态跟踪（使用strace和自定义的LD_PRELOAD钩子），我们发现问题的根源在于：
相机服务提供者进程在初始化时会mmap多个缓冲区用于图像处理。在某些异常路径下（如配置加载失败），这些缓冲区会被标记为无效但未正确释放。由于Android的Low Memory Killer机制，这些"半死不活"的映射区域不会被立即回收，导致内存占用持续存在。
4.2 修复方案实施
我们采取了以下修复措施：
- 资源释放逻辑加固：
c++复制// 修改前的危险代码
void cleanupBuffers() {
if (mBuffers) {
// 缺少实际的释放操作
mBuffers = nullptr;
}
}
// 修改后的安全代码
void cleanupBuffers() {
if (mBuffers) {
munmap(mBuffers, mBufferSize);
mBuffers = nullptr;
mBufferSize = 0;
}
}
-
异常路径处理增强：
在所有的错误处理分支中都加入资源释放逻辑，确保无论执行路径如何，分配的资源都能被正确释放。 -
生命周期管理改进：
使用智能指针和RAII技术重构部分代码，减少手动资源管理的出错可能。
4.3 验证结果
修复后经过多轮测试验证：
- 开机内存占用回归正常范围
- showmap显示异常的PSS=0区域消失
- 压力测试下未再出现内存累积增长
- 相机功能测试一切正常
内存对比数据显示，vendor.qti.camera.provider-service_64进程的内存占用与对比机差异缩小到正常波动范围内（<0.5MB）。
5. 经验总结与避坑指南
通过这个案例，我们总结了以下宝贵的经验：
-
mmap/munmap必须成对使用：
就像new/delete、malloc/free一样，mmap分配的内存必须确保有对应的munmap。在复杂的执行路径中，这一点特别容易被忽视。 -
Android内存分析的黄金组合：
showmap：详细进程内存映射分析procrank：进程内存排名dumpsys meminfo：系统级内存概况pmap：跨平台内存映射分析
熟练使用这些工具可以快速定位内存异常。
-
PSS=0不总是无害的：
看到PSS=0不要简单地认为这部分内存没有占用。结合RSS和映射状态分析，才能发现潜在的内存泄漏。 -
测试环境控制要点：
- 确保对比机和测试机的环境一致
- 注意后台服务和通知的影响
- 多次采样取平均值
微小的环境差异可能导致内存比较的误导。
-
防御性编程实践：
- 使用RAII管理资源
- 为所有资源操作添加日志
- 实现资源泄漏检测机制
这些实践可以在早期发现潜在问题。
在实际开发中，类似的内存问题往往隐藏得很深。这个案例告诉我们，即使是看似简单的mmap/munmap操作，在复杂的系统环境中也可能出现意想不到的问题。通过系统化的分析方法和严谨的编程实践，我们才能构建真正健壮的Android系统服务。