Android 系统内存不足时，kswapd 导致的性能问题之冷热文件回收方案

​​Nubia 分享过一个APP性能卡顿案例，链接见：Android卡顿掉帧问题分析之实战篇 - 简书

三方应用唯品会的首页界面上下滑动严重掉帧卡顿：

系统内存不足，kswapd 线程唤醒进行内存回收。一个是占用 cpu 资源，一个是导致唯品会 app 的 page cache 被回收。唯品会 app 作为当前应用，本身就要读写文件，io 问题又进一步加剧。

标准 linux 内核中，kswapd 负责页面回收（包括 Page Cache 的回收），其回收策略并非直接以进程为维度，而是通过内存的活跃性（Active/Inactive LRU 链表）和内核的回收算法间接实现的。

​以下是具体机制：

Linux 内核将页面分为两类 LRU 链表（每个内存节点和区域均有独立的链表）：

• Active List：存放最近被访问过的“活跃”页面。
• Inactive List：存放可能未被频繁访问的“非活跃”页面，优先从这里回收。

Page Cache 页面（文件缓存）会被挂到这些链表中，并根据访问频率动态调整（通过“第二次机会”算法或类似机制）。

kswapd的回收逻辑主要基于以下原则：

• 优先回收 Inactive List：首先尝试回收 Inactive List 中的页面，如果不足才会从 Active List 中迁移页面到 Inactive List。
• 区分文件页（Page Cache）和匿名页：
• 文件页（Page Cache）：可被直接回收（丢弃后可从磁盘重新读取）。
• 匿名页：需通过交换分区（Swap）换出，成本更高。

针对 Android 类系统，由于有当前 APP 的明显独特性。 回收算法有一个区分当前进程的页面和非当前进程的页面，对各个 APP 的文件进行冷热区分，比如常规的冷文件，温文件，热文件。优先回收冷文件，优先回收后台应用的冷文件。 前台应用的文件的回收优先级要降低。回收策略要进行调整，不要仅仅按 adj level 进行触发，还要一个常态化的 swap 运行策略，比如 每分钟进行定时少量回收，降低内存不足时候的 kswapd 的突发性高开销，把这个摊平。