内存管理基础：鸿蒙内存架构、虚拟内存与物理内存、内存分配与回收机制
大家好，我是老张。今天咱们聊聊鸿蒙的内存管理。
说实话，内存这块儿，是很多开发者的“噩梦”。我见过太多应用因为内存问题卡顿、闪退。我自己也踩过不少坑。所以这一章，咱们把地基打牢。
鸿蒙内存架构：分层与隔离
鸿蒙的内存架构，说白了就是一套“分层管理”的体系。它不像传统Linux那样“大锅饭”，而是把内存分成了几个层级，各管各的。
我个人习惯把鸿蒙内存架构想象成一个“三明治”：
- 内核层：最底层，负责物理内存的分配和回收。它直接跟硬件打交道。
- 服务层：中间层，管理各种系统服务的内存。比如图形服务、多媒体服务。
- 应用层：最上层，就是我们写的App。每个App有自己的独立空间。
为什么要这么分？你想想看，如果某个App内存泄漏了，它最多把自己搞崩，不会影响到系统服务。这就是“隔离”的好处。
核心要点：鸿蒙通过“进程-服务-应用”三层隔离，实现了内存的故障域隔离。一个进程挂了，不会拖垮整个系统。
我在项目中遇到过一个问题：某个第三方App疯狂申请内存，结果系统服务的内存被挤占，导致桌面卡死。后来我们调整了服务层的内存水位线，才解决了这个问题。
虚拟内存与物理内存：一场“骗局”
虚拟内存，说白了就是给每个进程画了个“大饼”。每个进程都以为自己有4GB（32位）或更多（64位）的连续内存空间。但实际上，物理内存可能只有2GB。
为什么会这样？因为CPU和操作系统联手搞了个“骗局”。它们通过MMU（内存管理单元），把虚拟地址映射到物理地址。
我画了一张图，帮你理解这个映射关系：
你看，虚拟页0x1000映射到了物理页0xA000，虚拟页0x2000映射到了物理页0xD000。映射是随机的，不连续的。这就是虚拟内存的核心思想：让每个进程都觉得自己拥有连续的内存，实际上物理内存可能支离破碎。
避坑指南：我曾经在调试一个内存泄漏问题时，发现进程的虚拟内存占用很高，但物理内存占用很低。这就是典型的“虚拟内存膨胀”。别慌，先检查是不是有大量未使用的内存映射。
内存分配与回收机制：谁管谁？
鸿蒙的内存分配，分两个层面：
- 内核层面：使用
buddy system（伙伴系统）分配物理页。它把内存按2的幂次分成块，比如4KB、8KB、16KB…… - 用户层面：使用
slab allocator（slab分配器）分配小对象。比如你new一个对象，底层就是slab在管。
我举个例子，你写代码时：
// 鸿蒙中分配内存
void* ptr = malloc(1024); // 用户态分配
// 或者
void* ptr = LOS_MemAlloc(m_aucSysMem0, 1024); // 内核态分配底层发生了什么？
malloc会调用鸿蒙的musl libc实现，最终走到内核的mmap或brk。- 内核用伙伴系统找到一块足够大的连续物理页。
- 然后通过页表建立虚拟地址到物理地址的映射。
回收机制呢？鸿蒙用的是LRU（最近最少使用）算法。当内存紧张时，内核会扫描所有进程的内存页，把那些长时间没被访问的页换出到zRAM（压缩内存）或者直接回收。
注意：鸿蒙的zRAM机制和Linux不太一样。鸿蒙会优先压缩匿名页（比如堆、栈），而不是文件页。我调优时发现，如果zRAM压缩率过高，反而会增加CPU负载。所以需要平衡。
我记得有一次，一个视频播放应用在后台被频繁杀掉。查了半天，发现是它的内存页被LRU算法误判为“不活跃”。后来我们给这个进程设置了OOM_ADJ优先级，才解决了问题。
内存碎片：隐形杀手
内存碎片分两种：
| 类型 | 描述 | 鸿蒙的应对 |
|---|---|---|
| 外部碎片 | 空闲内存不连续，无法分配大块内存 | 伙伴系统合并空闲页，/proc/meminfo查看 |
| 内部碎片 | 分配的内存块比实际需求大，浪费空间 | slab分配器按对象大小分类，减少浪费 |
我建议你定期检查/proc/buddyinfo，看看伙伴系统的空闲页分布。如果某个order（比如order 3，即32KB）的空闲页为0，说明外部碎片严重。
调优技巧：在鸿蒙的build/ohos/init.cfg中，可以调整watermark水位线。比如把min_free_kbytes调大，可以预留更多内存给紧急情况。但别调太大，否则普通应用会频繁触发OOM。
嗯，这一章的内容就到这里。内存管理是门手艺活，多实践才能找到感觉。下一章咱们聊聊内存泄漏的检测与定位，那才是真正的实战。