1. 论文基本信息

1.1. 标题

Freezing-based Memory and Process Co-design for User Experience on Resource-limited Mobile Devices (基于冻结的内存与进程协同设计，以优化资源受限移动设备的用户体验)

1.2. 作者

• CHANGLONG LI (李长龙): 华东师范大学计算机科学与技术学院、江淮先进技术中心、教育部软硬件协同设计技术与应用工程研究中心，中国。
• ZONGWEI ZHU (朱宗伟): 中国科学技术大学软件工程学院、中国科学技术大学苏州高等研究院，中国。
• CHUN JASON XUE (薛春): 穆罕默德·本·扎耶德人工智能大学，阿联酋。
• YU LIANG (梁宇): 瑞士苏黎世联邦理工学院计算机科学与技术学院。
• RACHATA AUSAVARUNGNIRUN: 泰国先皇理工大学。
• LIANG SHI (石亮): 华东师范大学计算机科学与技术学院，中国。
• XUEHAI ZHOU (周学海): 中国科学技术大学软件工程学院，中国。

1.3. 发表期刊/会议

ACM Transactions on Computer Systems (ACM Trans. Comput. Syst.)

1.4. 发表年份

2025年4月 (Published at UTC: 2025-01-18T00:00:00.000Z)

1.5. 摘要

资源有限的移动设备因其相对较低的价格而普及。在有限资源下提供良好的用户体验一直是一个巨大的挑战。这项工作发现，前台应用程序（foreground applications）的性能经常受到后台应用程序（background applications）内存活动的意外干扰。在资源有限的移动设备上改善用户体验需要内存管理（memory management）和进程管理（process management）之间的强力协作。本文提出了 Ice，一个旨在优化资源有限移动设备用户体验的框架。通过 Ice，那些在后台会引起频繁重fault（refaults）的进程被识别并相应地冻结。被冻结的应用程序会在内存条件允许时解冻。基于所提出的 Ice，这项工作表明，通过重新审视原始内核中具有应用冻结感知（app-freezing awareness）的 LRU 列表（称为 $Ice+$），可以进一步减少重fault。在资源有限移动设备上的评估表明，Ice 有效地改善了用户体验。具体而言，Ice 比现有技术平均提升了 1.57 倍的帧率（frame rate）。通过 $Ice+$，帧率平均进一步提升了 5.14%。

1.6. 原文链接

/files/papers/6915d96b4d6b2ff314a02ee2/paper.pdf 发布状态：已于 2025-01-18T00:00:00.000Z 正式发布。

2. 整体概括

2.1. 研究背景与动机

2.1.1. 核心问题

论文旨在解决资源有限移动设备上的用户体验（User Experience, UX）问题。具体而言，这类设备上运行的前台应用程序（Foreground Application, FG）经常受到后台应用程序（Background Application, BG）内存活动的意外干扰，导致屏幕卡顿（screen jerking）和帧率（frame rate）显著下降。

2.1.2. 问题的重要性

低端和中端移动设备在全球市场中占据主导地位，用户基数庞大。然而，这些设备在有限的硬件资源（如内存、CPU）下提供流畅的用户体验是一个持续的挑战。现有的优化方案未能充分解决后台应用内存活动对前台应用造成的负面影响，这严重影响了数十亿用户的日常使用。

2.1.3. 现有研究的挑战与空白 (Gap)

• 内存回收（Memory Reclaim）的不足： 现有的内存回收算法（如 Linux 内核的 LRU 算法、SmartSwap、Acclaim 等）主要关注识别不活跃页面或保护前台应用页面不被回收。然而，这些方案并未完全考虑后台应用即使不占用大量 CPU 资源，其内存访问模式（尤其是频繁的重fault）也会对前台应用造成干扰。
• 进程调度（Process Scheduling）的局限： 传统的调度器（如 CFS）或前台优先的调度器（如 UCSG）通过调整进程优先级来管理资源分配，但即使后台进程优先级很低，它们仍然可以执行并触发内存活动，导致重fault，进而影响前台应用。
• 协同机制的缺失： 现有的内存管理和进程管理通常是独立运作的，缺乏强有力的协同机制来解决由后台进程内存活动引起的性能问题。

2.1.4. 论文的切入点与创新思路

论文通过深入分析发现，CPU 竞争并非主要原因，而是后台应用频繁的内存访问和重fault导致了优先级反转（priority inversion）和内存颠簸（memory thrashing），从而严重干扰了前台应用。基于这一观察，论文提出：

• 强协同的必要性： 解决上述问题需要内存管理和进程调度之间的强力协作。
• 核心思想： 通过“冻结”（freezing）那些可能导致频繁重fault的后台进程，直接抑制其内存活动，从而减少重fault，优化用户体验。这与现有仅仅回收页面或调整优先级的方法有本质区别。

2.2. 核心贡献/主要发现

论文的核心贡献和主要发现可以总结如下：

• 揭示了后台重fault对用户体验的负面影响： 基于真实用户数据和实验分析，论文首次明确指出后台应用程序的内存重fault是导致资源有限移动设备用户体验下降（如帧率降低）的关键原因，并且这种问题被现有的内存管理和进程调度方案所忽视。超过 60% 的重fault由后台进程引起，且 77% 的重fault并非由垃圾回收（GC）导致。
• 提出了 Ice 框架： 提出了一个名为 Ice 的框架，通过协同内存管理和进程管理来优化用户体验。Ice 的核心思想是选择性地冻结可能导致频繁重fault的后台进程。这是首次尝试通过进程管理手段（冻结）来解决内存回收效率低下和重fault问题的方案。
• 设计了 RPF 和 MDT 组件： Ice 框架包含两个核心组件：
  • RPF (Refault-Driven Process Freezing，重fault驱动的进程冻结)： 能够以低开销实时检测重fault事件，并以应用粒度（application-granularity）选择性冻结导致重fault的后台进程。
  • MDT (Memory-Aware Dynamic Thawing，内存感知的动态解冻)： 能够根据内存压力动态调整冻结强度，周期性地解冻被冻结的应用程序。
• 提出了 Ice+ 优化方案： 在 Ice 的基础上，进一步提出了 $Ice+$。$Ice+$ 通过引入应用冻结感知（app-freezing awareness）的 LRU 列表修改，与现有内存压缩（ZRAM）和低内存杀手（LMK）机制协同工作。这解决了传统 LRU 算法在冻结应用下效率不高以及“回收-然后-杀死”的资源浪费问题。
• 在真实设备上验证了有效性： 在 Google Pixel3 和 HUAWEI P20 等真实移动设备上的实验评估表明，Ice 显著改善了用户体验。具体来说，Ice 相较于现有最先进方案，平均帧率提升了 1.57 倍。$Ice+$ 在此基础上，平均帧率进一步提升了 5.14%。同时，Ice 减少了 I/O 和 CPU 压力，并对后台服务的服务质量（QoS）影响微乎其微。

3. 预备知识与相关工作

3.1. 基础概念

为了全面理解 Ice 框架，我们需要掌握以下关键概念：

• 资源有限移动设备 (Resource-limited Mobile Devices)： 指的是内存、CPU、存储等硬件资源相对较少的移动设备，通常是市面上的中低端智能手机。这类设备由于价格较低而广泛普及，但也更容易遇到性能瓶颈。

• 用户体验 (User Experience, UX)： 衡量用户在使用设备或应用时的整体感受，包括界面的流畅度、应用的响应速度、视觉效果的平滑性等。论文主要通过帧率（FPS）和交互警报比率（RIA）来量化用户体验。

• 前台应用 (Foreground Application, FG)： 用户当前正在直接操作和交互的应用程序。例如，正在观看视频的播放器、正在聊天的即时通讯应用等。对 FG 应用的流畅度要求最高。

• 后台应用 (Background Application, BG)： 那些虽然没有在前台显示，但仍然在操作系统中运行或缓存的应用程序。例如，已经切换出去但仍在同步数据的社交媒体应用、正在播放音乐的应用等。移动操作系统通常会保持这些应用活跃，以便快速切换和恢复状态。

• 内存回收 (Memory Reclaim)： 当系统可用内存不足时，操作系统会启动的一种机制，旨在通过将不活跃或低优先级的内存页面（memory pages）从物理内存中移出（例如，压缩或写入到交换空间）来释放内存资源。

  • kswapd： Linux 内核中的一个轻量级线程（kernel thread），当空闲内存低于某个阈值（low-watermark）时，kswapd 会被唤醒来执行内存回收任务。
  • 匿名页 (Anonymous Pages)： 不与文件系统关联的内存页面，通常包含进程的运行时数据（如堆、栈）。在回收时，通常会被压缩到 ZRAM 或交换到存储设备。
  • 文件支持页 (File-backed Pages)： 与存储设备上的文件关联的内存页面，通常包含程序代码、库文件或文件数据。回收时，如果未修改（clean），可以直接丢弃；如果已修改（dirty），则需要写回存储设备。
  • LRU (Least Recently Used)： 一种常用的页面替换算法，其核心思想是“如果一个页面最近被使用过，那么它在未来被使用的可能性也较高；如果一个页面很久没有被使用，那么它在未来被使用的可能性也较低”。因此，LRU 算法会优先回收最久未使用的页面。

• ZRAM： Linux 内核模块，通过实时压缩内存页面来扩展可用 RAM，而无需使用传统意义上的磁盘交换（disk swap）。它在 RAM 中创建一个虚拟的压缩块设备，当内存压力大时，不活跃的页面会被压缩并存储在这个区域，从而腾出物理 RAM 空间。这比直接写入闪存更快，但会消耗 CPU 资源进行压缩/解压缩。

• 缺页中断 (Page Fault)： 当一个进程试图访问的内存页面不在物理内存中时，会触发一个硬件中断，即缺页中断。操作系统会介入，将所需的页面从存储设备（或 ZRAM）加载到物理内存中。

• 重fault (Refault)： 特指一个页面在被回收（evicted）出物理内存后，又在稍后被进程再次访问，从而导致缺页中断并需要重新加载到物理内存中的事件。频繁的重fault表明内存管理效率低下。

  • 重fault距离 (Refault Distance)： 一个页面从被逐出到再次被访问（导致重fault）的时间间隔。理想情况下，这个距离应该越长越好。

• 帧率 (Frame Rate, FPS)： 每秒显示的图像帧数。是衡量屏幕动画和用户界面流畅度的关键指标。通常，高于 30 FPS 被认为是流畅的，更高（如 60 FPS）则提供更平滑的体验。低于 30 FPS 会导致明显的卡顿（jank）。

• 优先级反转 (Priority Inversion)： 一种操作系统调度问题，指一个高优先级的任务被一个或多个低优先级的任务阻塞，无法及时执行。在本文中，可能指前台高优先级应用被后台低优先级应用的内存回收或重fault操作阻塞。

• 内存颠簸 (Memory Thrashing)： 当系统内存严重不足，且进程对内存的需求很高时，操作系统会花费大部分时间在内存页面交换（page swapping）上，而不是执行实际的计算任务。这导致系统性能急剧下降，CPU 利用率高但有效吞吐量极低。频繁的重fault是内存颠簸的典型表现。

• 低内存杀手 (Low Memory Killer, LMK)： Android 系统中的一个内核机制。当系统可用内存持续低于危险阈值时，LMK 会根据预设的优先级（oom_score_adj）杀死一些低优先级的后台进程，以释放大量内存，从而避免系统崩溃。

• 进程冻结 (Process Freezing)： 操作系统提供的一种机制，可以强制一个或一组进程暂停其执行，进入一种休眠状态。被冻结的进程不会消耗 CPU 周期，也不会访问内存页面，直到被明确地解冻。这与终止进程（killing）不同，冻结的进程可以在解冻后恢复其完整的运行状态。

3.2. 前人工作与技术演进

在移动设备内存和进程管理领域，前人做了大量工作，主要集中在内存回收优化和进程调度优化两个方面。

3.2.1. 内存回收优化

• 传统 LRU (Least Recently Used) [23]： 这是 Linux 内核默认的页面回收算法，通过追踪页面最近的访问历史来决定哪些页面应该被回收。它假设最近使用过的页面更有可能在未来被使用。
• SmartSwap [72]： 通过分析用户行为来预测哪些应用不太可能被再次使用，从而提前将这些应用的页面逐出，以期在用户需要时有更多可用内存。
• Acclaim [51]： 提出了一种前台应用感知且大小敏感的页面回收方案。Acclaim 旨在保护前台应用的页面不被回收，即使它们的活跃度可能低于某些后台应用的页面。其目标是减少前台应用的重fault，从而改善前台用户体验。
• Fleet [35]： 专注于提高缓存应用的数量和热启动性能。通过更智能的内存管理策略，允许更多应用驻留在内存中，从而加快用户切换应用的响应速度。
• MARS [31] 和 SEAL [47]： 这些工作关注利用闪存存储作为扩展内存的策略。MARS 通过闪存感知的页面交换来加速应用启动。SEAL 则提出了一个两级交换框架，旨在结合闪存的特性来优化内存管理，提升用户体验。
• Marvin [46]： 发现运行时垃圾回收（GC）可能导致后台重fault，并提出了在语言运行时层面进行新的内存管理方案，以避免 GC 引起的页面重fault。

3.2.2. 进程调度优化

• CFS (Completely Fair Scheduler) [13]： Linux 内核默认的调度器，旨在公平地分配 CPU 资源给所有运行中的进程，包括前台和后台进程。这种“公平”在资源受限设备上可能导致前台应用无法获得足够的资源。
• UCSG [65]： 针对移动系统设计，它区分前台和后台进程，并重新设计了优先级方案，给予前台应用进程更高的优先级，以确保它们获得更多的 CPU 资源。
• 用户感知调度 [5, 63]： 这些方案在操作系统框架层识别用户交互的进程，并动态提升这些进程的优先级，以改善用户可感知到的响应速度。

3.3. 差异化分析

本文提出的 Ice 框架与上述现有工作的主要区别和创新点在于：

• 对问题根源的识别： 现有工作大多关注内存回收本身（如 LRU、SmartSwap）或前台应用的页面保护（如 Acclaim），或特定原因的重fault（如 Marvin 针对 GC）。本文则通过实证研究揭示了后台应用的频繁重fault（而非简单的内存占用或 CPU 占用）是影响前台用户体验的核心痛点，且大部分重fault并非由 GC 引起。
• 协同设计的范式创新： 多数现有工作将内存管理和进程调度视为相对独立的领域。Ice 首次提出了内存管理和进程管理之间的强协同设计。它不再仅仅是调整进程优先级或被动地回收页面，而是主动地通过进程“冻结”这种进程管理手段，来直接抑制后台进程的内存活动，从而从根源上解决重fault问题。
• 主动抑制策略： 与那些试图积极或主动回收后台应用脏页（如 SmartSwap、Marvin）的方法不同，Ice 采取了更为根本的“冻结”策略。积极回收可能导致更严重的内存颠簸和资源消耗，而冻结则能更彻底地阻止进程产生重fault。
• 冻结粒度与影响： Ice 以“应用粒度”进行冻结，这与一些基于能耗管理或通用目的的进程冻结（如一些智能手机的电源管理器）不同。Ice 的冻结是“重fault驱动”且“内存感知”的，确保冻结是针对性且动态调整的，以最小化对用户可感知后台服务的影响。
• 与现有机制的兼容性与增强： $Ice+$ 进一步展示了 Ice 并非取代现有机制，而是通过“冻结感知”的 LRU 列表修改，与 ZRAM、LMK 等现有内存管理模块协同工作，解决了“回收-然后-杀死”的资源浪费问题，并提升了整体效率。这体现了其良好的兼容性和扩展性。

4. 方法论

本文提出了 Ice 框架，旨在通过内存和进程管理的协同设计，优化资源受限移动设备的用户体验。Ice 的核心思想是选择性地冻结那些可能导致频繁重fault的后台进程。在此基础上，$Ice+$ 进一步将冻结感知融入现有的内存回收机制中。

4.1. 方法原理

Ice 的核心原理基于对资源受限移动设备上用户体验瓶颈的深入洞察。研究发现，虽然后台应用程序（BG applications）可能不占用大量 CPU 资源，但它们频繁的内存访问活动，特别是页重fault（page refaults），会引发一系列问题：

1. 优先级反转 (Priority Inversion)： 前台应用程序（FG application）的高优先级任务可能会被后台低优先级进程的内存回收（memory reclaiming）或重fault处理任务所阻塞。

2. 内存颠簸 (Memory Thrashing)： 频繁的重fault导致系统花费大量时间在页面加载和回收上，而非执行有效工作，从而降低整体系统性能。

3. I/O 和 CPU 开销： 重fault需要从存储或 ZRAM 中读取页面，产生额外的 I/O 压力和 CPU 压缩/解压缩开销。

   Ice 的直觉是，如果能及时、准确地识别并抑制那些会频繁导致重fault的后台进程，就可以从源头上减少这些负面影响，从而显著提升前台用户体验。Ice 选择了“进程冻结”（process freezing）而非简单的优先级降低或页面回收，因为冻结能更彻底地阻止进程的活动及其内存访问行为。

4.2. 核心方法详解 (Ice框架)

Ice 框架主要由两个核心组件构成：RPF (Refault-Driven Process Freezing，重fault驱动的进程冻结) 和 MDT (Memory-Aware Dynamic Thawing，内存感知的动态解冻)。此外，一个 Ice Daemon 负责与现有系统模块进行通信。

4.2.1. Ice 框架概述与控制流

Ice 框架的整体架构如图像 9 (Fig. 5) 所示，它在内存管理和进程管理子系统之间搭建了桥梁。

控制流 (Control Flow)：

1. 重fault检测： Ice 在内核空间（kernel space）检测到重fault事件。
2. 进程识别： 识别导致重fault的进程 ID ($pid_i$)。
3. RPF 处理： $pid_i$ 被传递给 RPF 组件。RPF 确定冻结目标（一个或多个进程 $pid_i, ..., pid_j$），然后向进程管理子系统发送命令，抑制这些选定进程的活动（即冻结）。
4. MDT 监控： MDT 组件持续监控系统的内存压力。
5. MDT 解冻： MDT 根据内存压力动态调整周期，间歇性地解冻被冻结的进程。

4.2.2. RPF (Refault-Driven Process Freezing，重fault驱动的进程冻结)

RPF 的目标是选择性地冻结那些在后台可能导致持续重fault的活跃进程。

核心思想：选择性、事件驱动的冻结。

• 选择性冻结： RPF 不会激进地冻结所有后台应用，而是只冻结那些可能导致内存颠簸的后台应用，以最小化开销并保持系统稳定性。
• 事件驱动： RPF 通过检测到重fault事件来触发冻结，而非通过复杂的预测模型。论文发现一个进程往往会连续触发多个重fault，因此在首次重fault发生时即冻结该进程是有效的策略。

RPF 内部组件 (如图像 10 (Fig. 6) 所示)：

1. 重fault事件处理 (Refault Event Handling)：

   • ECA (Event-Condition-Action) 规则： RPF 遵循 ECA 规则，即当检测到满足特定条件的事件时，触发相应的动作。
   • 重fault识别 (Refault Identification)： RPF 在内核空间通过检查页表项（Page Table Entry, PTE）来识别重fault事件。
     • 当一个页面被逐出到存储时，其对应的 PTE 中的一个标志位会被修改（例如，位 0 的 _PAGE_PRESENT 标志）。
     • 当发生缺页中断（page fault）时，系统会访问 PTE 来获取页面地址。通过检查该标志位，RPF 可以判断所需的页面是否曾被逐出。
     • 现代 Linux 内核已提供 shadow entry 接口来获取重fault相关信息，RPF 利用此接口实现重fault检测。
   • 进程选择 (Process Selection)：
     • 一旦检测到重fault事件，RPF 识别该页面所属的进程。
     • 然后判断该进程是否“可冻结”（freezable）。内核进程（如 kswapd, kworker）和 Android 服务（如 UI 线程，GC 线程）等核心系统进程被识别为不可冻结，并被过滤掉。
     • 在 Linux 内核中，可以通过缺页中断处理程序（page fault handler）轻松获取页表和虚拟地址，从而确定导致重fault的进程。
   • 响应重fault事件 (Response to the Refault Event)： 对于被识别为可冻结的后台进程，RPF 会立即采取行动，通过冻结来抑制其活动。

2. 应用粒度冻结 (Application-Grain Freezing)：

   • 映射表 (Mapping Table)： RPF 维护一个从应用程序到进程的映射表。应用程序由其唯一的 UID (User ID) 表示，UID 在安装时固定。一个应用通常包含多个进程。
   • 冻结流程： 当 RPF 决定冻结某个进程时，它会查询映射表，识别该进程所属的应用程序，然后向该应用程序的所有相关进程发送冻结信号。
   • 进程响应： 收到冻结信号的进程会调用 try_to_freeze() 函数（[25]），进入休眠状态，直到收到解冻信号。
   • 优势： 以应用粒度冻结可以增强应用的鲁棒性，因为同一应用的不同进程通常相互依赖或通信。此外，冻结而非杀死进程，能够保留应用快速切换（hot launch）和恢复历史状态的能力。
   • 实现细节： 映射表维护在内核空间，以实现快速索引。应用信息（UID、PID、状态等）通过 /proc 文件系统从 Android 框架传递到内核，并在应用安装、删除或启动时更新。这种跨空间通信频率较低，对性能影响可接受。

4.2.3. MDT (Memory-Aware Dynamic Thawing，内存感知的动态解冻)

MDT 的目标是动态地解冻被冻结的应用程序，同时根据当前的内存压力调整冻结强度。

核心思想：动态心跳机制。

• 心跳周期 (Heartbeat Epoch)： MDT 维护一个系统心跳。每个心跳周期被分为两个阶段：冻结期 ($E_f$) 和解冻期 ($E_t$)。
• 动态强度调整：
  • 在每个周期的开始，被选定的应用程序会被冻结 $E_f$ 秒，然后解冻 $E_t$ 秒。
  • 周期的长度会根据系统的内存状态动态调整。当内存压力升高时，冻结期 $E_f$ 应该延长；当内存压力缓解时，冻结期 $E_f$ 应该缩短。
  • 冻结强度（freezing intensity）通过冻结期与解冻期的比率 $R = E_f / E_t$ 来量化。

冻结强度计算公式 (如图像 11 (Fig. 7) 所示)： $$R = \frac { E _ { f } } { E _ { t } } = \delta \times 2 ^ { \lceil \frac { H _ { w m } } { S _ { a m } } \rceil }$$ 其中：

• $R$：冻结强度，表示冻结持续时间 $E_f$ 与解冻持续时间 $E_t$ 的比率。
• $E_f$：冻结持续时间（秒）。
• $E_t$：解冻持续时间（秒），默认为 1 秒。
• $\delta$：权重系数（weight coefficient），用于调整冻结强度，在实验中配置为 8.0。
• $H_{wm}$：高水位线（high watermark），表示系统在初始化阶段设定的内存阈值。
• $S_{am}$：当前可用内存的大小（size of available memory）。

公式解释： 该公式表明，当系统可用内存 $S_{am}$ 减小时（即内存压力增大），比值 $\frac{H_{wm}}{S_{am}}$ 增大，导致指数 $\lceil \frac{H_{wm}}{S_{am}} \rceil$ 增大，进而使得 $2^{\lceil \frac{H_{wm}}{S_{am}} \rceil}$ 和 $R$ 显著增大。这意味着冻结期 $E_f$ 会延长，从而增强冻结强度。反之，当可用内存充足时，冻结强度会降低。通过这种方式，MDT 实现了内存感知的动态冻结。

冻结与解冻时机：

• 如果一个应用在冻结期内（$0 < T \leq E_f$）触发重fault并被冻结，它将在该冻结期结束时（$E_f$ 时刻）解冻，并在接下来的 $E_t$ 秒内运行，直到下一个周期。
• 如果一个应用在解冻期内触发重fault并被冻结，它将立即被冻结，但不会在该周期内解冻，而是等到下一个周期的解冻期才被解冻。

4.2.4. 白名单 (Whitelist) 与安全性

为了确保用户对冻结操作无感知，Ice 采用了白名单机制：

• 识别可感知应用： 利用 Android 系统现有机制识别用户可感知的应用。
  • 前台应用： 调用 onResume() 接口的应用被识别为前台应用，不会被冻结。
  • 可感知后台应用： 调用 startService() 接口的应用（如播放音乐、下载文件）被视为可感知的后台应用，也不会被冻结。
  • 优先级分数： Android 系统通过 adj value (进程优先级分数) 来区分进程。$adj value <= 200$ 的进程（如前台进程为 0，可感知后台应用为 200）被加入白名单。
• 实现： 这些优先级分数被传递到内核空间并记录在映射表中。当 adj value 改变时（如下载任务完成），白名单也会更新。
• 厂商自定义： 设备厂商可以预先将特定应用的 UID 加入白名单，以保护防病毒软件、通话应用等关键后台服务。
• 用户切换时解冻： 如果一个被冻结的应用被用户切换到前台，Ice 会在其显示之前立即解冻它。这个解冻操作是异步的，不被 MDT 的周期性解冻打断。

4.3. Ice+：与现有机制协同设计

$Ice+$ 是在 Ice 基础上对现有内存管理和进程杀死机制的重新设计，旨在解决传统方案中的资源浪费和低效问题。

4.3.1. 现有问题回顾

• “回收-然后-杀死”现象： 在传统系统中，当内存压力大时，页面被回收（例如，压缩到 ZRAM 或交换）。如果内存压力仍未缓解，LMK 机制会被触发，杀死低优先级进程。问题在于，LMK 经常杀死那些其大部分页面已经被压缩或交换的“不活跃”应用。这导致：
  1. 资源浪费： 页面回收操作（压缩/交换）本身消耗了 CPU 和 I/O 资源，但随后应用就被杀死，使得这些回收操作变得毫无意义。
  2. LMK 效率低下： 被杀死的应用由于页面已被大量回收，实际能释放的内存可能不如预期，导致 LMK 可能需要连续杀死多个应用才能达到效果。
• 传统 LRU 的局限性： 传统的 LRU 算法基于页面访问历史来判断活跃度。然而，当 Ice 冻结一个应用后，该应用的所有页面将停止访问。即使这些页面在冻结前非常活跃，LRU 也会认为它们不再被使用，但无法区分这是由于冻结还是真正的非活跃。这可能导致 LRU 做出次优的回收决策。

4.3.2. 冻结感知逐出 (Freezing-Aware Eviction)

$Ice+$ 结合 Ice 的应用粒度冻结特性，提出了一种冻结感知的逐出策略（freezing-aware eviction strategy）。

核心思想：整体处理冻结应用页面。

• 策略： $Ice+$ 会将一个冻结应用的页面作为一个整体来处理，而不是像传统 LRU 那样逐个页面评估。
• 优势 1： 被冻结的页面可以立即被识别为不活跃，避免了 LRU 算法中访问历史可能带来的误导。
• 优势 2： 由于 Ice 以应用粒度冻结，$Ice+$ 可以对整个冻结应用执行特定的操作（回收或杀死），从而避免了前述“回收-然后-杀死”的资源浪费问题。
• 实现 (如图像 12 (Fig. 8) 所示)：
  • $Ice+$ 维护一个冻结应用的 UID 列表。
  • 当内存压力驱动 LRU 列表上的页面迁移时：
    • 不活跃列表（inactive list）尾部的页面是回收的候选者。
    • $Ice+$ 会检查这些候选页面的 UID。
    • 如果一个页面属于一个被冻结的应用，$Ice+$ 会降低其优先级，并快速将其移出 LRU 列表，使其更容易被回收。
  • 通过这种方式，$Ice+$ 可以更有效地从冻结应用中提取空间，供前台应用使用。

4.3.3. 与 Ice 协同的进程杀死 (Process Killing with Ice)

$Ice+$ 协调 Ice 与 LMK 机制，以更智能地处理进程杀死。

核心思想：回收与杀死互斥，或至少按序进行。

• 策略： 属于同一个应用的页面将采用一致的处理方法（要么被压缩/回收，要么被杀死）。关键在于避免在一个应用已被大量回收后又被杀死。
• 实现：
  • 当 LMK 引擎选择目标应用时，$Ice+$ 会检查该应用的 UID。
  • 通过 Ice 维护的映射表，$Ice+$ 可以知道一个应用是否已被冻结。
  • 如果应用 $w$ 的页面已被压缩到 ZRAM，并且它被标记为“不可杀死”（unkillable），那么 LMK 将跳过该应用。
  • 这样，$Ice+$ 避免了在应用页面已被回收后又被杀死的资源浪费。映射表的大小很小，存储在内存中，因此状态查询可以立即完成。

4.4. 实现与讨论

4.4.1. 白名单 (Whitelist)

如前所述，Ice 采用白名单机制来识别并保护用户可感知的应用，确保冻结操作对用户无感知。这通过利用 Android 框架层对应用生命周期和优先级的识别能力（例如 onResume()、startService()、adj value）实现。白名单数据传递到内核空间并维护在映射表中。厂商也可以手动配置白名单，以保护关键应用。

4.4.2. 启动时解冻 (Thawing on Launch)

为了避免用户切换到冻结应用时出现无响应的情况，Ice 会检测应用切换行为。当一个冻结应用被切换到前台时，Ice 会在其显示之前立即解冻该应用。此解冻操作是异步进行的，且不依赖于 MDT 的周期性解冻。

4.4.3. 实现细节

• Ice 的实现涉及到对 Linux 内核源代码的修改，但无需对移动应用程序或硬件基础设施进行侵入性修改。
• 部署 Ice 需要重新编译 Android 项目，并替换 fastboot 模式下的 system.img 和 boot.img。
• 这种设计使得 Ice 易于在不同版本的 Android 设备上进行维护和部署。

4.4.4. Ice 在未来的实现

论文讨论了 Ice 在未来移动设备发展中的潜在价值：

• 闪存寿命： 新型闪存（如 QLC）的耐久性较低，频繁的 I/O 操作会缩短其寿命。Ice 通过减少重fault引起的 I/O，有助于延长闪存存储的寿命。尤其是在采用基于存储的交换（storage-based swap）功能的设备上，Ice 和 $Ice+$ 的寿命优势会更显著。
• 新兴应用场景： Ice 适用于 MR（混合现实）头显、车载系统、物联网（IoT）设备等对用户体验敏感的新兴移动设备。
• 缓解温度升高： 后台活动可能导致设备温度升高，触发 DVFS（动态电压和频率调节）机制，降低处理器频率。限制后台应用活动有助于缓解温度升高，避免性能下降。
• 兼容性： Ice 从进程层面优化内存，可与自适应交换（adaptive swap）等新型内存管理策略兼容，无需过多修改。

5. 实验设置

5.1. 数据集

实验环境选择了两款具有代表性的资源有限移动设备，以模拟低端和中端设备的使用场景。

• 设备 1 (低端设备代表):

  • 型号：Google Pixel3
  • CPU：Qualcomm Snapdragon845
  • 内存：4GB DDR4 RAM
  • 存储：64GB eMMC5.1 Flash
  • 操作系统：Android 10.0 (r41)

• 设备 2 (中端设备代表):

  • 型号：HUAWEI P20
  • CPU：HiSilicon Kirin970
  • 内存：6GB DDR4 RAM
  • 存储：64GB UFS2.1 Flash
  • 操作系统：Android 9.0

工作负载： 为了模拟日常用户行为，实验预装了 20 款流行的应用程序，涵盖多种类别。这些应用在实验中被用作前台（FG）或后台（BG）应用。

以下是原文 Table 3 的结果：

典型场景： 论文选择了四个典型的真实使用场景进行用户体验评估：

• 场景 A (S-A)： 视频通话 (使用 WhatsApp)
• 场景 B (S-B)： 短视频切换 (使用 TikTok)
• 场景 C (S-C)： 屏幕滚动 (在 Facebook 上滚动)
• 场景 D (S-D)： 手机游戏 (玩 PUBG Mobile)

5.2. 评估指标

论文使用了多种指标来量化用户体验和系统性能，具体解释如下：

• 帧率 (Frame Rate, FPS)：

  • 概念定义： 每秒渲染的图像帧数，是衡量屏幕动画和用户界面流畅度的最主要指标。通常，更高的 FPS 意味着更流畅的用户体验。低于 30 FPS 通常被认为是卡顿（jank）。
  • 数学公式： $FPS = \frac{\text{渲染的帧数}}{\text{总时间 (秒)}}$
  • 符号解释：
    • 渲染的帧数：在特定时间段内成功渲染并显示到屏幕上的图像帧总数。
    • 总时间 (秒)：测量帧数的时间长度，以秒为单位。

• 交互警报比率 (Ratio of Interaction Alert, RIA)：

  • 概念定义： 指未能在一个标准渲染时间窗口内（通常是 16.6 毫秒，对应 60 FPS）完成渲染的帧所占的比例。RIA 越高，表示屏幕卡顿越严重，用户感知到的延迟和不流畅度越大。
  • 数学公式： $RIA = \frac{\text{渲染时间} > 16.6\text{ms 的帧数}}{\text{总帧数}}$
  • 符号解释：
    • 渲染时间 > 16.6ms 的帧数：在测量期间，渲染时间超过 16.6 毫秒的帧的数量。
    • 总帧数：在测量期间，尝试渲染的总帧数。

• 应用启动速度 (Application Launching Speed)：

  • 概念定义： 从用户点击应用图标到应用完全加载并可交互的时间间隔。分为冷启动（Cold Launching，应用首次启动或被系统彻底杀死后启动）和热启动（Hot Launching，应用已在后台缓存或部分驻留内存中再次启动）。
  • 数学公式： $\text{启动时间} = \text{应用可交互时间点} - \text{用户点击图标时间点}$
  • 符号解释：
    • 应用可交互时间点：应用完全加载，用户界面可以响应用户输入的时间点。
    • 用户点击图标时间点：用户发起应用启动操作的时间点。

• 重fault页面数量 (Number of Refaulted Pages)：

  • 概念定义： 记录在实验期间，从内存中被逐出（evicted）后又被进程再次访问，从而导致重新加载回内存的页面总数。该指标直接反映了内存管理效率的低下和后台活动的干扰。

• 回收页面数量 (Number of Reclaimed Pages)：

  • 概念定义： 记录在实验期间，为了释放内存资源而被系统从物理内存中移出的页面总数。

• I/O 请求数量 (Number of I/O Requests)：

  • 概念定义： 衡量系统在执行任务时，与存储设备（如闪存、ZRAM）进行数据读写操作的频率和数量。频繁的 I/O 请求会增加系统延迟和能耗。

• CPU 利用率 (CPU Utilization)：

  • 概念定义： 衡量 CPU 资源被进程利用的百分比，反映了 CPU 的繁忙程度。

• 后台服务质量 (Quality of Service, QoS)：

  • 音频流畅度： 通过对录制的音频信号进行时间域和频域分析，使用三个指标综合评估：
    • 零交叉率 (Zero-Crossing Rate, ZCR)： 衡量音频信号在单位时间内穿越零轴的次数。高 ZCR 可能表示噪声或突变，暗示流畅度较低。
    • RMS 振幅变动 (RMS Amplitude Variation)： 衡量信号功率的一致性。大的变动表示音量波动，可能意味着卡顿或丢帧。
    • 频谱通量 (Spectral Flux)： 衡量功率谱的变化率。高的 Spectral Flux 表示频率内容突然变化，可能意味着音频不流畅。
    • 音频流畅度得分 (Smoothness Score)： 通过对上述三个指标进行归一化（0-1 范围）并加权求和得到。 $$\mathrm {Smoothness~Score} = w _ {1} \times (1 - ZCR) + w _ {2} \times (1 - RMS~Variation) + w _ {3} \times (1 - Spectral~Fluxion)$$ 其中：
      • ZCR：归一化后的零交叉率。
      • RMS~Variation：归一化后的 RMS 振幅变动。
      • Spectral~Fluxion：归一化后的频谱通量。
      • $w_1, w_2, w_3$：权重系数，且 $w_1 + w_2 + w_3 = 1$。论文中默认设置为 $w_1 = w_2 = w_3 = \frac{1}{3}$。
  • 下载效率： 衡量文件下载的速度（Mbps）和下载特定内容（如电视剧）所需的时间。

5.3. 对比基线

为了全面评估 Ice 和 $Ice+$ 的性能，论文将它们与以下现有或基线方案进行了比较：

• LRU+CFS (Least Recently Used + Completely Fair Scheduler)：

  • 描述： 这是 Linux 内核默认的内存管理和进程调度组合。LRU 用于内存页面回收，CFS (完全公平调度器) 用于 CPU 调度。
  • 特点： CFS 公平对待所有进程，包括前台和后台进程，不作特殊区分。LRU 算法根据页面的最近使用情况来决定回收顺序。
  • 代表性： 作为移动设备上最基础、最普遍的系统行为，是所有优化方案的性能基线。

• UCSG (User-Centric Scheduling Grouping)：

  • 描述： UCSG 是一种用户感知（user-centric）的进程调度方案，它将前台应用程序的进程与后台进程区别对待，并赋予前台进程更高的优先级。
  • 特点： 旨在通过优先满足前台应用的资源需求来改善用户体验，但对后台进程的内存活动管理不如 Ice 深入。
  • 代表性： 代表了现有通过调整进程优先级来优化用户体验的调度策略。

• Acclaim：

  • 描述： Acclaim 是一种前台应用感知（FG-aware）且大小敏感（size-sensitive）的内存回收方案。它旨在保护前台应用的内存页面不被回收，即使它们的活跃度可能低于某些后台页面。
  • 特点： 主要关注减少前台应用的重fault，通过优先回收后台应用的页面来为前台应用腾出空间。
  • 代表性： 代表了现有通过优化内存回收策略来改善用户体验的方案。

• Ice：

  • 描述： 论文提出的基于重fault驱动进程冻结的内存与进程协同管理框架。
  • 特点： 核心是 RPF 和 MDT，通过选择性冻结可能导致频繁重fault的后台进程，直接抑制其内存活动。

• Ice+：

  • 描述： 在 Ice 的基础上，进一步将冻结感知融入现有的内存回收（ZRAM）和进程杀死（LMK）机制中，通过修改 LRU 列表来优化资源利用。
  • 特点： 解决了“回收-然后-杀死”的资源浪费问题，并提升了整体内存管理效率。

5.4. 参数配置

实验中 Ice 框架所使用的关键参数配置如下表所示：

以下是原文 Table 4 的结果：

参数解释：

• $S^g$ 和 $S^h$：分别表示 Pixel3 和 P20 手机中 ZRAM 分区的大小。这些参数决定了可以压缩的最大匿名页数量。

• $H_{wm}^g$ 和 $H_{wm}^h$：分别表示 Pixel3 和 P20 系统中的内存高水位线（high-watermark）。当可用内存低于此阈值时，系统会触发内存回收。

• $\delta$：是 MDT 策略中用于调整冻结强度（freezing intensity）的权重系数，此处设置为 8.0。

• $E_t$：表示在每个冻结/解冻周期中，解冻应用程序的持续时间（epoch length to thaw an application），默认设置为 1 秒。这意味着在一个周期内，应用程序至少有 1 秒的运行时间。

  这些参数是可配置的，允许根据具体设备和使用场景进行调整。

6. 实验结果与分析

本节详细分析了 Ice 及其增强版 $Ice+$ 在资源有限移动设备上的实验结果，主要关注其对用户体验、系统行为（如重fault、回收、I/O、CPU 压力）以及后台服务质量（QoS）的影响，并讨论了其性能开销。

6.1. Ice 对用户体验的影响

6.1.1. 帧率提升 (Benefit on Frame Rate)

论文使用帧率（FPS）和交互警报比率（RIA）来评估用户体验。实验结果表明，Ice 在多个后台应用程序（BG applications）运行时，显著优于其他方案。

• FPS 提升：
  • 在 Pixel3 上进行 WhatsApp 视频通话（S-A）时，Ice 将平均帧率提升到 37.2fps，而 $LRU+CFS$ 为 25.4fps，UCSG 为 29.3fps，Acclaim 为 24.1fps。这使得视频通话体验从卡顿（通常低于 30fps）变得流畅。
  • 图像 13 (Fig. 9) 展示了四种典型场景下的帧率对比。
• RIA 降低： Ice 显著降低了 RIA。例如，在 P20 上玩 PUBG Mobile 游戏时，RIA 从 46% 降低到 28%，意味着卡顿现象减少。
• 对抗 BG 应用数量增加： 随着后台缓存应用数量的增加，帧渲染性能通常会下降。但 Ice 能有效遏制这种下降趋势。
  • 图像 2 (Fig. 10) 展示了不同 BG 应用数量下的帧率对比，特别是在 Pixel3 的 $6B+F$ (6个后台应用+前台应用) 和 P20 的 $8B+F$ (8个后台应用+前台应用) 情况下，Ice 分别使 FPS 提升了 1.57 倍和 1.44 倍，同时 RIA 分别降低了 32.7% 和 34.6%。这表明 Ice 在内存压力较大时效果尤为显著。
• 对比其他方案：
  • UCSG 也能提升帧率，但效果有限，因为其通过降低 BG 进程优先级，但这些低优先级进程仍能执行并导致重fault。UCSG 相比 $LRU+CFS$ 平均减少了 24.4% 的页面重fault。
  • Acclaim 主要针对减少 FG 重fault，但在某些场景下（如 Pixel3 上的 S-C），由于其更积极地回收 BG 页面，可能导致 BG 重fault增加，反而使 FPS 下降。

6.1.2. 重fault和回收减少 (Reduction of Refault and Reclaim)

Ice 改善用户体验的根本原因在于其有效减少了后台的重fault和内存回收操作。

• 图像 3 (Fig. 11) 展示了不同方案下重fault和回收页面的数量对比（以 P20 为例）。
  • 重fault减少： Ice 显著减少了重fault页面数量。在 S-A、S-B、S-C、S-D 四个场景中，重fault页面数量分别减少了 42.1%、44.4%、57.6% 和 40.5%。
  • 回收减少： Ice 将总回收页面数量平均减少到 $LRU+CFS$ 的 70.7%。这表明 Ice 减少了无意义的回收操作。
  • 选择性冻结的有效性： 实验显示，Ice 平均只冻结了 4 个 BG 应用程序就实现了这些改进，证明其选择性冻结策略是高效的，无需激进地冻结所有 BG 应用程序。
• 与电源管理冻结对比： 某些商业智能手机的电源管理器也支持进程冻结。

  • 表格 5 (Table 5) 对比了电源管理器和 Ice 在重fault和回收页面数量上的表现。 以下是原文 Table 5 的结果：

    Scenarios	Power Manager		Ice
    	Refault	Reclaim	Refault	Reclaim
    Video Call (S-A)	6.712	20.063	5.233	18.688
    Short-Video Switching (S-B)	7.332	26.061	6.457	24.832
    Screen Scrolling (S-C)	3.856	15.772	2.929	13.312
    Mobile Games (S-D)	14.858	51.433	12.18	46.848

    电源管理器平均减少了 22.4% 的回收页面和 33.5% 的重fault页面，但效果不如 Ice。原因是电源管理器主要关注节能，其冻结策略不是动态且内存感知的，例如在充电时不冻结，或在内存压力增加时冻结强度不变。

6.1.3. I/O 和 CPU 压力减少 (Reduction of I/O and CPU Pressure)

• I/O 减少： Ice 减少了 I/O 请求数量，I/O 总量比 $LRU+CFS$ 平均减少 9.2%。Ice 有效避免了 BG 应用导致的无意义 I/O（页面被频繁回收又重fault）。
• CPU 减少： Ice 将 CPU 利用率从 $LRU+CFS$ 的 55.8% 降低到 47.3%。这得益于两方面：一是部分 BG 任务被冻结，直接减少了 CPU 消耗；二是内存压缩和解压缩任务的减少，因为重fault和回收操作减少了。

6.1.4. 白名单研究 (Whitelist Study)

实验表明，Ice 可以在不依赖白名单的情况下，通过 Android 系统机制识别并保护关键服务。如果将所有 BG 应用都加入白名单，Ice 的效益会显著降低，FPS 接近原始系统。这说明 Ice 尊重用户操作，即使这意味着牺牲部分性能提升。

6.1.5. 对应用启动的影响 (Impact on Application Launching)

Ice 对应用启动速度的影响是复杂的，既有负面因素（解冻时间），也有正面因素（减少 BG 干扰）。

• 启动速度提升：
  • 图像 4 (Fig. 12) 的 (a) 部分展示了 Ice 对应用启动速度的影响。
  • 平均而言，Ice 使应用启动时间比 $LRU+CFS$ 减少了 36.6%。这表明 Ice 的积极影响（减少 BG I/O 和为 FG 任务分配更多 CPU）超过了其负面影响。
  • 冷启动： Ice 将冷启动时间平均缩短了 28.8%。冷启动时没有冻结惩罚，且资源分配更优，因此收益显著。
  • 热启动： 47% 的应用热启动速度可能略有下降，但延迟增加小于标准差。最坏情况下，冻结应用的热启动延迟平均为 839ms，是 $LRU+CFS$ 热启动延迟的 1.98 倍，但仍远快于冷启动，被认为是可接受的。论文建议结合应用预测（application prediction）来消除这种惩罚。
• 热启动比率提升：
  • 图像 4 (Fig. 12) 的 (b) 部分展示了 Ice 对热启动应用数量的影响。
  • Ice 使得可热启动（hot launched）的应用数量增加了 25%。这是因为 Ice 缓解了重fault引起的内存压力，降低了 LMK 触发的可能性，并延迟了应用被杀死的时间点，从而让更多应用能保持在可热启动状态。

6.2. Ice+ 对用户体验的影响

在 Ice 的基础上，$Ice+$ 通过与现有内存回收（ZRAM）和 LMK 机制协同，进一步优化了用户体验。

6.2.1. 帧率提升 (Frame Rate Improvement)

• 表格 6 (Table 6) 详细对比了 Ice 和 $Ice+$ 在帧率、回收页面和重fault页面数量上的表现。 以下是原文 Table 6 的结果：

  		Frame Rate (fps)		Num. of Reclaimed Pages (× 1k)		Num. of Refault Pages (× 1k)
  		Ice	Ice+	Ice	Ice+	Ice	Ice+
  Video Call	Pixel3	37.2	39.1	21.372	16.256	8.737	7.618
  	P20	39.2	42.2	18.688	13.375	5.233	5.122
  Short-Video Switching	Pixel3	48.6	52.7	19.637	16.254	10.526	8.662
  	P20	43.6	45.6	24.832	19.938	6.457	4.434
  Screen Scrolling	Pixel3	39.5	41.3	17.618	15.261	5.533	5.006
  	P20	49.1	50	13.312	12.127	2.929	3.128
  Mobile Games	Pixel3	38.7	40.1	53.761	50.535	18.632	16.736
  	P20	46.2	48.7	46.848	41.336	12.18	10.628
  Average		42.8	45	27.054	23.135	8.778	7.667
  Summary (Ice+ : Ice)		1.05 ↑		85.52%↓		87.34%↓

  $Ice+$ 平均额外提升了 5.14% 的帧率。例如，在短视频切换（S-B）场景，Pixel3 上帧率提升了 4.1fps，P20 上提升了 2fps。

6.2.2. 系统改进分析 (System Improvement Analysis)

• $Ice+$ 平均减少了 14.5% 的回收页面和 12.7% 的重fault页面。
• 通过监控 ZRAM 分区，发现在 Ice 情况下，有 5.8K (21.4%) 的回收页面很快会被 LMK 释放，$Ice+$ 通过其协同机制避免了这种资源浪费。这进一步优化了重fault引起的 UX 问题。

6.2.3. 对 App 启动的影响 (Impact on App Launching)

• 图像 5 (Fig. 13) 展示了 Ice 和 $Ice+$ 在启动延迟上的对比。 $Ice+$ 对应用启动速度没有明显的负面影响。$Ice+$ 的平均启动延迟和标准差与 Ice 相比差异很小，这表明在引入更复杂的协同机制后，并没有引入显著的额外开销。

6.3. BG 服务质量 (QoS of BG Services)

为了评估 Ice 对后台服务质量的影响，论文对音频播放和下载任务进行了单独评估。

• 表格 7 (Table 7) 详细展示了 Ice 对后台服务 QoS 的影响。 以下是原文 Table 7 的结果：

  Scenarios		Empty			Full
  		NoIce	Ice	Ice+	NoIce	Ice	Ice+
  Audio	Music	0.0	-0.0148	-0.0132	0.0	0.0075	0.0139
  	Navigation	0.0	-0.0067	0.0114	0.0	0.0236	0.0131
  	Talk	0.0	0.0217	-0.0083	0.0	0.0217	0.0193
  	User Perceptible	NO			NO
  Download	Download One File (Mbps)	66.3	65.8	67.1	58.9	59.6	60.2
  	Download TV Series (min)	357	355	361	373	368	365

• 音频流畅度： Ice 对音频流畅度（通过 Smoothness Score 衡量）的影响微乎其微。

  • 在“空载”（Empty）情况下，Ice 和 $Ice+$ 的得分与 Empty-NoIce 相比略有波动，但幅度很小，表明用户无感知。
  • 在“满载”（Full）情况下，Ice 甚至能略微提升关键后台服务的 QoS。
  • 用户主观评估也证实了 Ice 对音频服务的影响是用户无感知的。这得益于 Ice 的白名单机制，系统能够识别并保护关键的后台服务不被冻结。

• 下载效率： Ice 对下载效率的影响也很小。单文件下载速度和下载电视剧所需时间在 NoIce、Ice 和 $Ice+$ 之间差异不大。

6.4. 开销分析 (Overhead Analysis)

6.4.1. 内存消耗 (Memory Consumption)

• Ice 维护一个映射表来存储应用和进程信息（UID-PID、冻结状态、优先级分数）。对于一个安装了 20 个应用（每个应用 3 个进程）的设备，映射表的内存消耗最大约为 13.8KB。
• 为安全起见，映射表的上限设置为 32KB。
• 该内存开销相对于智能手机的总内存而言可以忽略不计。

6.4.2. 性能开销 (Performance Overhead)

Ice 的性能开销主要分为三部分：

1. 重fault事件响应： Ice 采用异步方式处理重fault事件（获取进程信息、索引 PID、执行冻结），以避免阻塞页面访问，确保低延迟。
2. UID-PID 映射维护： 映射表在系统启动时初始化，并在应用安装、启动或生命周期结束时更新。由于表小且常驻内存，索引操作在微秒级别即可完成，相对于应用启动延迟等时间尺度，其开销可忽略。
3. 冻结引起的性能开销： 解冻一个应用通常只需要几十毫秒，这是可接受的。Ice 的设计中包含了多项优化来最小化惩罚，例如：
   • 只冻结活跃且可能导致重fault的应用程序。
   • 不冻结那些没有页面被回收的应用，或页面被回收但未导致重fault的应用。 这些优化确保了 Ice 在带来显著用户体验提升的同时，其性能开销是可接受的。

7. 总结与思考

7.1. 结论总结

本文深入研究了资源有限移动设备上用户体验下降的根本原因，发现后台应用程序的频繁内存重fault是导致前台应用卡顿的关键因素。基于此，论文提出了 Ice 框架，旨在通过内存管理和进程管理之间的协同设计来优化用户体验。

Ice 框架的核心是两个创新组件：

1. RPF (Refault-Driven Process Freezing，重fault驱动的进程冻结)： 能够以低开销实时检测重fault事件，并以应用粒度选择性地冻结那些可能导致持续重fault的后台进程。

2. MDT (Memory-Aware Dynamic Thawing，内存感知的动态解冻)： 根据系统内存压力动态调整冻结强度，周期性地解冻被冻结的应用程序。

   在此基础上，论文进一步提出了 $Ice+$，它通过引入应用冻结感知（app-freezing awareness）的 LRU 列表修改，与现有内存压缩（ZRAM）和低内存杀手（LMK）机制协同工作，解决了传统 LRU 算法的局限性以及“回收-然后-杀死”的资源浪费问题。

实验结果在真实的 Google Pixel3 和 HUAWEI P20 移动设备上得到了验证。Ice 显著改善了用户体验，平均帧率比现有最先进方案提升了 1.57 倍。$Ice+$ 在此基础上，平均帧率进一步提升了 5.14%。此外，Ice 还减少了 I/O 和 CPU 压力，并对后台服务的服务质量影响微乎其微，同时保持了可接受的开销。

7.2. 局限性与未来工作

论文本身并未在专门章节中明确列出局限性，但可以从其设计和实验讨论中推断出一些潜在的局限性以及作者提出的未来工作方向：

• 潜在局限性：

  • 热启动延迟： 尽管 Ice 提升了冷启动速度并增加了热启动比率，但在最坏情况下，被冻结应用的热启动延迟仍可能增加。虽然论文认为这是可接受的，但仍是潜在的用户体验瑕疵。
  • 白名单的全面性： 尽管 Ice 利用了 Android 框架来识别关键服务，但对于所有可能的后台关键应用（例如定制化的企业应用、特定安全服务等），自动识别可能不总是全面，可能仍需要手动配置白名单，这增加了部署的复杂性。
  • 参数调优的泛化性： MDT 中的权重系数 $\delta$ 和解冻周期 $E_t$ 等参数的选取，虽然在实验中表现良好，但在不同硬件平台、不同 Android 版本、或极端用户使用模式下，其最优值是否能保持，仍需进一步研究。
  • 特定类型的后台活动： Ice 专注于解决重fault问题。对于某些不产生重fault但持续占用其他重要资源（如网络带宽、GPU）的后台活动，Ice 的效果可能有限。
  • 冻结粒度： Ice 采用应用粒度冻结。对于一些大型应用，可能只有其中某个子模块或特定线程导致重fault。冻结整个应用可能过于粗糙，能否实现更细粒度的冻结以进一步减少对应用可用性的影响，是一个挑战。

• 未来工作方向：

  • 结合应用预测： 将 Ice 与应用预测（application prediction）技术结合，可以在用户即将切换到某个应用之前提前解冻，进一步消除热启动延迟的惩罚。
  • 与其他启动加速方案集成： 与现有的启动加速方案（如 MARS [31] 或 ASAP [62]）协同工作，以进一步优化应用启动体验。
  • 扩展应用场景： 将 Ice 的理念和技术推广到更广泛的移动设备场景，如 MR (混合现实) 头显、车载系统和物联网 (IoT) 设备，这些设备对用户体验的流畅性要求更高。
  • 优化闪存寿命： 进一步利用 Ice 减少 I/O 的特性，与新型闪存（如 QLC）和基于存储的交换（storage-based swap）功能协同，延长存储设备的寿命。
  • 结合 DVFS： Ice 限制后台活动有助于缓解设备温度升高。未来可与 DVFS (动态电压和频率调节) 机制更紧密结合，共同避免因高温导致的性能下降。
  • 兼容未来内存管理技术： Ice 从进程层面优化内存，与未来可能出现的自适应交换等新型内存管理策略应具有良好的兼容性，并可进一步协同优化。

7.3. 个人启发与批判

7.3.1. 个人启发

• 系统级协同解决复杂问题： 这篇论文最显著的启发是，解决现代移动设备中的复杂性能问题，往往不能仅限于单一模块的优化。内存管理和进程调度之间的紧密协同（co-design）是解锁更高性能和更好用户体验的关键。这种宏观的系统设计思维，超越了传统上对各自领域独立优化的限制。
• 重构对“后台不活跃”的理解： 论文通过实证数据揭示了一个常被忽视的事实：后台应用即使不占用 CPU，其内存活动（特别是重fault）也可能对前台用户体验造成严重干扰。这挑战了“后台应用不活跃就应该被回收”的传统观念，强调了“不活跃”与“无害”之间的差异。
• 事件驱动与实时响应的价值： RPF 组件采用重fault事件驱动的冻结机制，而非复杂的预测模型。这种轻量级、实时的响应方式，在资源受限的环境下，可能比高开销的预测方法更具实用价值。
• 用户感知的设计考量： Ice 在设计中充分考虑了用户感知，例如通过白名单保护关键服务、在应用切换时立即解冻。这提醒我们在进行系统优化时，技术先进性必须与实际用户体验相结合，避免为了性能而牺牲用户可接受性。
• “冻结”作为一种强大的调度原语： 进程冻结通常被用于节能或系统休眠。本文将其创造性地应用于性能优化，作为一种主动抑制后台干扰的强大原语，为调度器和内存管理提供了新的工具箱。

7.3.2. 批判性思考

• 动态参数的鲁棒性与自适应性： MDT 组件中的冻结强度公式依赖于权重系数 $\delta$ 和系统高水位线 $H_{wm}$。虽然论文给出了实验中的配置，但这些参数在不同芯片平台、不同 RAM 大小、不同 Android 版本甚至不同用户使用习惯（例如，重度游戏玩家与轻度社交用户）下，其最优值是否能自适应地调整？缺乏对这些参数敏感性分析和自适应调整机制的深入探讨。
• “冻结”的潜在副作用与不透明性： 尽管论文努力使其对用户无感知，但冻结本质上是暂停了应用活动。除了启动延迟，是否存在某些应用（例如，后台即时通讯、股票行情刷新、云同步）对实时性要求很高，一旦被冻结即使短暂也会影响其功能或数据一致性？白名单机制能解决一部分，但对于未被识别为“关键”但对用户仍重要的后台服务，可能会造成困扰。系统如何更好地向用户透明地展示哪些应用被冻结，并提供用户层面的控制？
• 细粒度冻结的探讨： Ice 采用应用粒度冻结，理由是增强鲁棒性。然而，一个应用可能包含多个进程或线程，其中只有少数导致频繁重fault。冻结整个应用可能会暂停其他不产生干扰的进程。更细粒度的冻结（例如，基于线程或模块的冻结）是否可行，并且能否在不牺牲鲁棒性的前提下，进一步减少对应用整体功能的潜在影响？
• 能量消耗的量化： 论文提到 Ice 有助于缓解温度升高和减少 I/O，从而间接有利节能。但频繁的冻结/解冻循环本身是否会带来额外的能量开销（例如，上下文切换、重新加载状态）？更详细的能量消耗模型和量化分析将使结论更具说服力。
• 与高级调度器的冲突与协同： 现代 Android 系统和 Linux 内核已经集成了很多高级调度器（如 EAS、RT 调度等）和电源管理模块。Ice 的冻结机制如何与这些现有的复杂调度和电源管理逻辑更无缝地协同工作，避免不必要的冲突或重复优化，值得进一步研究。