Android性能优化原理：APP运行时的内存模型_android swap pss(1)

m0_74535175

已于 2024-04-09 15:21:38 修改

阅读量1k

点赞数 9

分类专栏： 2024年程序员学习文章标签： android 性能优化

于 2024-04-09 15:21:36 首次发布

本文链接：https://blog.csdn.net/m0_74535175/article/details/137553894

版权

2024年程序员学习专栏收录该内容

247 篇文章 2 订阅

订阅专栏

话不多说，让我们马上开始这一章学习吧！

内存描述指标

在进行内存优化之前，我们必须要先熟悉常用的内存描述指标。内存描述指标可以用来度量一个 App 的内存情况，也可以在我们做内存优化时，更直观地展示出优化前后的效果。

常用的内存描述指标有 6 个，我们先来简单了解一下。

PSS（ Proportional Set Size ）：实际使用的物理内存，会按比例分配共享的内存。比如一个应用有两个进程都用到了 Chrome 的 V8 引擎，那么每个进程会承担 50% 的 V8 这个 so 库的内存占用。PSS 是我们使用最频繁的一个指标，App 线上的内存数据统计一般都取这个指标。
RSS（ Resident Set Size ）：PSS 中的共享库会按比例分担，但是 RSS 不会，它会完全算进当前进程，所以把所有进程的 RSS 加总后得出来的内存会比实际高。按比例计算内存占用会有一定的消耗，因此当想要高性能的获取内存数据时便可以使用 RSS，Android 的 LowMemoryKiller 机制就是根据每个进程的 RSS 来计算进程优先级的。
Private Clean / Private Dirty：当我们执行 dump meminfo 时会看到这个指标，Private 内存是只被当前进程独占的物理内存。独占的意思是即使释放之后也无法被其他进程使用，只有当这个进程销毁后其他进程才能使用。Clean 表示该对应的物理内存已经释放了，Dirty 表示对应的物理内存还在使用。
Swap Pss Dirty：这个指标和上面的 Private 指标刚好相反，Swap 的内存被释放后，其他进程也可以继续使用，所以我们在 meminfo 中只看得到 Swap Pss Dirty，而看不到Swap Pss Clean，因为 Swap Pss Clean 是没有意义的。
Heap Alloc：通过 Malloc、mmap 等函数实际申请的虚拟内存，包括 Naitve 和虚拟机申请的内存。
Heap Free：空闲的虚拟内存。

内存描述指标并不多，上面这几个就完全够用了，而且我相信大家或多或少都接触过，所以这里列出来便于我们后面查阅。

内存数据获取

了解了内存的描述指标，我们再来看看如何获取内存的数据，主要有 2 种方式。

① 线下通过 adb 命令获取，一般用于线下调试：

adb shell
dumpsys meminfo 进程名/pid

② 线上通过代码获取，一般用于收集线上的内存数据：

ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();

虽然获取方法不同，但这两种方式获取数据的原理完全一样，它们调用的都是 android_os_Debug.cpp 对象中的 android_os_Debug_getDirtyPagesPid 接口，它的源码如下：

static jboolean android_os_Debug_getDirtyPagesPid(JNIEnv *env, jobject clazz,
jint pid, jobject object)
{
bool foundSwapPss;
stats_t stats[_NUM_HEAP];
memset(&stats, 0, sizeof(stats));

//1. 加载maps文件，获取
if (!load_maps(pid, stats, &foundSwapPss)) {
return JNI_FALSE;
}

struct graphics_memory_pss graphics_mem;
//2. 获取graphics区域内存数据
if (read_memtrack_memory(pid, &graphics_mem) == 0) {
stats[HEAP_GRAPHICS].pss = graphics_mem.graphics;
stats[HEAP_GRAPHICS].privateDirty = graphics_mem.graphics;
stats[HEAP_GRAPHICS].rss = graphics_mem.graphics;
stats[HEAP_GL].pss = graphics_mem.gl;
stats[HEAP_GL].privateDirty = graphics_mem.gl;
stats[HEAP_GL].rss = graphics_mem.gl;
stats[HEAP_OTHER_MEMTRACK].pss = graphics_mem.other;
stats[HEAP_OTHER_MEMTRACK].privateDirty = graphics_mem.other;
stats[HEAP_OTHER_MEMTRACK].rss = graphics_mem.other;
}

//3. 获取Unkonw区域数据
for (int i=_NUM_CORE_HEAP; i<_NUM_EXCLUSIVE_HEAP; i++) {
stats[HEAP_UNKNOWN].pss += stats[i].pss;
stats[HEAP_UNKNOWN].swappablePss += stats[i].swappablePss;
stats[HEAP_UNKNOWN].rss += stats[i].rss;
stats[HEAP_UNKNOWN].privateDirty += stats[i].privateDirty;
stats[HEAP_UNKNOWN].sharedDirty += stats[i].sharedDirty;
stats[HEAP_UNKNOWN].privateClean += stats[i].privateClean;
stats[HEAP_UNKNOWN].sharedClean += stats[i].sharedClean;
stats[HEAP_UNKNOWN].swappedOut += stats[i].swappedOut;
stats[HEAP_UNKNOWN].swappedOutPss += stats[i].swappedOutPss;
}

//4. 将获取的数据存放到容器中
……
return JNI_TRUE;
}

这段源码比较长，我们一起来梳理下里面的逻辑，主要分为 4 部分。

读取 maps 文件，获取该进程的内存详情：通过上一节的学习，我们知道进程使用的内存都是虚拟内存，并且虚拟内存都以页为维度来管理和维护。这个进程的虚拟内存每一页上存放了什么数据，都会记录在 maps 文件中，maps 文件是一个很重要的文件，后面会详细介绍它。
调用 libmemtrack 接口获取 graphics 内存数据：Graphic 内存分配和使用方式具有特殊性，并没有全部映射到应用进程，需要通过 HAL 层（抽象硬件层）libmemtrack 的接口查询，才能完整得到使用的 graphics 内存数据。
分配 Unknow 区域的内存数据：根据前面的知识我们知道，mmap 除了做内存映射，还可以用来申请虚拟内存，如果在申请内存时是私有且匿名的（ fd 如果为 -1，flag 入参为MAP_ANONYMOUS 或 MAP_PRIVATE ）就会算入 Unknow 中，如果 mmap 申请内存时指定了申请这段内存的名字，就会算入 Other Dev 当中。因此，对这一区域内存问题的排查往往比较复杂，因为我们不知道内存的来源。
存放获取到的内存数据并返回：最后一部分就是将前面获取到的数据放到对应的数据结构中，并返回给接口调用方。

内存模型详解

我们已经知道如何获取内存数据，但是这些数据从哪儿来呢？毕竟只有知道来源，我们才能从源头进行治理。那接下来，我们就对 App 运行时的内存模型进行一个全面且详细的剖析。

我们以系统设置这个 App 为例子，通过 adb 命令获取的内存数据如下：

这里把上面的数据分为两个部分：A 区域和 B 区域。其中 A 区域的数据主要来自前面提到的 android_os_Debug_getMemInfo 接口，B 区域的数据则是对 A 区域中的数据做了汇总处理。

A区域

前面我们已经了解到，android_os_Debug_getMemInfo 接口的数据有两部分来源，一部分是读取 maps 文件解析到每块内存所属的数据，另一部分是读取 libmemtrack 接口的数据获取到的 graphic 内存数据。这两部分的数据来源就组成了 A 区域中的三块数据。下面我们分别来看看这三块数据。

数据 ①：maps 文件数据

maps 文件是分析内存很重要的一个文件，通过 maps 文件我们可以详细知道这个进程的内存中存放了哪些数据。maps 文件存放在 /proc/{ pid }/maps 路径中，该路径除了存放该进程的 maps 文件，还存放了该进程的所有其他信息的数据。如果你感兴趣可以深入了解一下。

对于 root 的手机，我们可以直接查看该目录下的 maps 文件。但是 maps 文件非常长，直接看会很吃力，所以我们一般会通过脚本对 maps 文件中的数据做分析和归类。下面还是以系统设置这个应用为例，它的 maps 文件的部分内容如下：

图中从左至右各个数据段的解释如下：

字段	address	perms offset	offset	dev	inode	pathname
数据	12c00000-32c00000	rw-p	00000000	00:00	0	main space (region space)]
含义	本段内存映射的虚拟地址空间范围	读写权限	本段映射地址在文件中的偏移	所映射的文件所属设备的设备号	文件的索引节点号	对有名映射而言，pathname 是映射的文件名；对匿名映射来说，pathname 是此段内存在进程中的作用

如果手机没有 root 也没关系，我们可以在运行时通过 native 层的 c++ 代码读取该文件，可以看一下android_os_Debug_getMemInfo 接口中调用的 load_maps 方法，该方法读取 maps 文件后，还做了一个详细的分类操作，分完类之后就是我们看到的数据 ① 中的数据，这个方法比较长，所以我精简了部分代码。

static bool load_maps(int pid, stats_t* stats, bool* foundSwapPss)
{
*foundSwapPss = false;
uint64_t prev_end = 0;
int prev_heap = HEAP_UNKNOWN;

std::string smaps_path = base::StringPrintf(“/proc/%d/smaps”, pid);
auto vma_scan = [&](const meminfo::Vma& vma) {
int which_heap = HEAP_UNKNOWN;
int sub_heap = HEAP_UNKNOWN;
bool is_swappable = false;
std::string name;
if (base::EndsWith(vma.name, " (deleted)“)) {
name = vma.name.substr(0, vma.name.size() - strlen(” (deleted)"));
} else {
name = vma.name;
}

uint32_t namesz = name.size();
// 解析Native Heap 内存
if (base::StartsWith(name, “[heap]”)) {
which_heap = HEAP_NATIVE;
} else if (base::StartsWith(name, “[anon:libc_malloc]”)) {
which_heap = HEAP_NATIVE;
} else if (base::StartsWith(name, “[anon:scudo:”)) {
which_heap = HEAP_NATIVE;
} else if (base::StartsWith(name, “[anon:GWP-ASan”)) {
which_heap = HEAP_NATIVE;
}

// 解析 stack 部分内存
else if (base::StartsWith(name, “[stack”)) {
which_heap = HEAP_STACK;
} else if (base::StartsWith(name, “[anon:stack_and_tls:”)) {
which_heap = HEAP_STACK;
}
// 解析 code 部分的内存
else if (base::EndsWith(name, “.so”)) {
which_heap = HEAP_SO;
is_swappable = true;
} else if (base::EndsWith(name, “.jar”)) {
which_heap = HEAP_JAR;
is_swappable = true;
} else if (base::EndsWith(name, “.apk”)) {
which_heap = HEAP_APK;
is_swappable = true;
} else if (base::EndsWith(name, “.ttf”)) {
which_heap = HEAP_TTF;
is_swappable = true;
} else if ((base::EndsWith(name, “.odex”)) ||
(namesz > 4 && strstr(name.c_str(), “.dex”) != nullptr)) {
which_heap = HEAP_DEX;
sub_heap = HEAP_DEX_APP_DEX;
is_swappable = true;
} else if (base::EndsWith(name, “.vdex”)) {
which_heap = HEAP_DEX;
……
} else if (base::EndsWith(name, “.oat”)) {
which_heap = HEAP_OAT;
is_swappable = true;
} else if (base::EndsWith(name, “.art”) || base::EndsWith(name, “.art]”)) {
which_heap = HEAP_ART;
……
} else if (base::StartsWith(name, “/dev/”)) {
which_heap = HEAP_UNKNOWN_DEV;
// 解析 gl 区域内存
if (base::StartsWith(name, “/dev/kgsl-3d0”)) {
which_heap = HEAP_GL_DEV;
}
// 解析 cursor 区域内存
else if (base::StartsWith(name, “/dev/ashmem/CursorWindow”)) {
which_heap = HEAP_CURSOR;
} else if (base::StartsWith(name, “/dev/ashmem/jit-zygote-cache”)) {
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;
}
//解析ashmen匿名共享内存
else if (base::StartsWith(name, “/dev/ashmem”)) {
which_heap = HEAP_ASHMEM;
}
} else if (base::StartsWith(name, “/memfd:jit-cache”)) {
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_APP_CODE_CACHE;
} else if (base::StartsWith(name, “/memfd:jit-zygote-cache”)) {
which_heap = HEAP_DALVIK_OTHER;
sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;
}

//解析java Heap内存
else if (base::StartsWith(name, “[anon:”)) {
which_heap = HEAP_UNKNOWN;
if (base::StartsWith(name, “[anon:dalvik-”)) {
which_heap = HEAP_DALVIK_OTHER;
if (base::StartsWith(name, “[anon:dalvik-LinearAlloc”)) {
sub_heap = HEAP_DALVIK_OTHER_LINEARALLOC;
} else if (base::StartsWith(name, “[anon:dalvik-alloc space”) ||
base::StartsWith(name, “[anon:dalvik-main space”)) {
// This is the regular Dalvik heap.
which_heap = HEAP_DALVIK;
sub_heap = HEAP_DALVIK_NORMAL;
} else if (base::StartsWith(name,

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。