1. Bibliographic Information

1.1. Title

Freezing-based Memory and Process Co-design for User Experience on Resource-limited Mobile Devices

1.2. Authors

CHANGLONG LI, ZONGWEI ZHU, CHUN JASON XUE, YU LIANG, RACHATA AUSAVARUNGNIRUN, LIANG SHI, XUEHAI ZHOU

1.3. Journal/Conference

ACM Transactions on Computer Systems (ACM Trans. Comput. Syst.). This is a highly reputable journal in the field of computer systems, known for publishing high-quality, rigorous research. Its influence is significant in the academic community for operating systems, distributed systems, and computer architecture research.

1.4. Publication Year

2025

1.5. Abstract

Mobile devices with limited resources are widely used due to their affordability, but delivering a good user experience on such devices remains challenging. This work identifies that foreground (FG) applications are frequently hampered by background (BG) applications' memory activities. To enhance user experience, the paper proposes Ice, a framework that integrates memory and process management. Ice identifies and freezes BG processes that are prone to causing frequent refaults. These frozen applications are then thawed when memory conditions permit. Furthermore, the paper introduces $Ice+$, which refines the Least Recently Used (LRU) lists in the kernel to be app-freezing aware, thereby further reducing refaults. Evaluations on resource-limited mobile devices demonstrate that Ice significantly improves user experience, boosting the frame rate by an average of 1.57x over state-of-the-art methods. $Ice+$ further enhances the frame rate by an additional 5.14% on average.

1.6. Original Source Link

/files/papers/6915d96b4d6b2ff314a02ee2/paper.pdf (Published at (UTC): 2025-01-18T00:00:00.000Z)

2. Executive Summary

2.1. Background & Motivation

The core problem this paper aims to solve is the degraded user experience on resource-limited mobile devices, primarily caused by the memory activities of background (BG) applications interfering with foreground (FG) applications. Low-end and mid-range mobile devices constitute a significant portion of the global market (over 1 billion in use), making this a widespread issue.

This problem is important because a jerky screen or frame dropping severely impacts user satisfaction, even though these devices are cost-effective. Existing solutions for memory management, such as optimizing page reclaiming algorithms (LRU, SmartSwap, Acclaim, Fleet), have not fully considered the negative impact of BG processes' memory activities on FG processes. This leads to frequent refaults by BG applications, which, despite not being CPU-intensive, often access memory pages. This memory thrashing can cause priority inversion, where high-priority FG tasks are blocked by low-priority BG memory operations, leading to significant frame rate drops (often below 30 frames per second, which is insufficient for a good user experience).

The paper's entry point and innovative idea stem from four key observations:

1. CPU contention is not the primary cause of frame rate drops.

2. BG applications, while not CPU-intensive, frequently access memory pages, leading to refaults.

3. Memory reclaiming negatively affects FG applications due to priority inversion and refault-induced memory thrashing.

4. The root of the problem lies in improper process scheduling in conjunction with memory management.

   These observations lead to the hypothesis that a strong collaboration between memory management and process scheduling is essential, especially for resource-limited mobile systems, to address the BG refault problem and improve user experience.

2.2. Main Contributions / Findings

The paper makes several significant contributions to address the challenge of user experience on resource-limited mobile devices:

• Reveals the BG Refault Problem: Based on data collected from real-life users, the paper highlights that current user experience on mobile devices suffers significantly from memory refaults caused by over-active BG processes. This is a critical insight, as existing memory management solutions often overlook this specific interaction.
• Proposes Ice Framework: It introduces Ice, a collaborative framework for memory and process management. Ice is the first known effort to tackle the problem of ineffective memory reclaiming by integrating process management, specifically through refault-driven process freezing (RPF) and memory-aware dynamic thawing (MDT).
• Proposes $Ice+$ for Co-design with Existing Mechanisms: The paper further develops $Ice+$, a novel solution that redesigns existing system mechanisms like ZRAM (memory compression) and Low Memory Killer (LMK). By modifying LRU lists to be app-freezing aware, $Ice+$ effectively addresses resource waste caused by the "reclaim-then-kill" phenomenon.
• Empirical Validation: The Ice and $Ice+$ frameworks have been implemented on real mobile devices (Google Pixel3 and HUAWEI P20). Experimental results demonstrate substantial improvements in user experience:

  • Ice boosts the frame rate by an average of 1.57x compared to state-of-the-art mechanisms.

  • $Ice+$ further enhances the frame rate by an additional 5.14% on average.

    These findings suggest that Ice and $Ice+$ offer a practical and effective approach to improving the responsiveness and fluidity of mobile devices, especially those with constrained resources, by intelligently managing BG application interference.

3. Prerequisite Knowledge & Related Work

3.1. Foundational Concepts

To understand the Ice framework and its contributions, a basic understanding of mobile operating system concepts, particularly in memory and process management, is crucial.

• Resource-limited Mobile Devices: These are smartphones, tablets, or other portable devices characterized by relatively lower specifications compared to high-end models. This typically includes:
  • Limited RAM: Often 4GB or 6GB, which can be quickly consumed by multiple applications.
  • Less powerful CPUs: Older or mid-range processors that may struggle with heavy workloads or context switching.
  • Slower storage: eMMC (Embedded MultiMediaCard) flash storage is common, which is slower than UFS (Universal Flash Storage) found in high-end devices, impacting I/O performance.
• User Experience (UX): This refers to a user's overall perception and feelings when interacting with a mobile device. Key metrics include:
  • Frame Rate (FPS - Frames Per Second): The number of unique images or frames that a display can produce in one second. A higher FPS (e.g., 60fps) results in smoother, more fluid visuals and interactions. Below 30fps, users often perceive jank (choppy or unresponsive visuals).
  • Jank: The phenomenon of screen jerking, stuttering, or unresponsiveness that negatively impacts the user's perception of fluidity and performance.
• Memory Management in Mobile OS (Linux/Android):
  • Main Memory (RAM): The primary, volatile storage used by the CPU to hold data and instructions that are currently in use.
  • Page: The basic unit of memory that the operating system manages. Memory is divided into fixed-size blocks called pages.
  • Page Reclaiming: When free memory falls below a certain threshold (e.g., low-watermark), the operating system frees up memory pages that are not currently in active use. This process involves identifying inactive pages and moving them out of RAM.
  • LRU (Least Recently Used) Algorithm: A common page replacement algorithm used in the Linux kernel. It assumes that pages that have not been used for the longest time are least likely to be used again soon, making them prime candidates for reclaiming. Pages are typically tracked in active and inactive LRU lists.
  • Anonymous Pages: Memory pages that hold program data (e.g., heap, stack) and are not backed by files on permanent storage. When reclaimed, they are often moved to a compressed memory area (ZRAM) or swapped to secondary storage.
  • File-Backed Pages: Memory pages that contain data loaded from files on secondary storage. Dirty (modified) file-backed pages are written back to storage, while clean (unmodified) ones can be discarded and reloaded later if needed.
  • ZRAM: A Linux kernel module that creates a compressed block device in RAM. When anonymous pages are reclaimed, instead of writing them to slow disk swap, they are compressed and stored in ZRAM, allowing faster access if they need to be brought back into memory.
  • Swapping: The process of moving memory pages from RAM to a dedicated area on secondary storage (a swap partition or swap file) to free up RAM.
• Page Refault: Occurs when a memory page that was previously reclaimed (evicted from RAM) is needed again by a process. The system must then retrieve it from ZRAM (decompress) or secondary storage (read from disk), which incurs latency and can degrade performance.
  • Refault Distance: The time between a page being evicted and then subsequently faulted in again. Longer refault distances are desirable.
  • FG Refaults: Page refaults caused by the foreground application.
  • BG Refaults: Page refaults caused by background processes. This paper argues these are particularly problematic for FG user experience.
• Process Management:
  • Foreground (FG) Application: The application currently being actively used and displayed on the screen by the user. It typically has the highest priority.
  • Background (BG) Application/Process: Applications that are running but not currently visible or actively interacted with by the user. They often have lower priority but can still consume resources.
  • Process Freezing: A mechanism where an operating system can suspend a process, making it inactive until explicitly thawed (resumed). This saves CPU cycles and prevents memory access.
  • Priority Inversion: A problematic scenario where a high-priority task (e.g., FG application's rendering task) is blocked or delayed by a lower-priority task (e.g., BG application's memory reclamation or refault handling task) that holds a necessary resource.
  • Low Memory Killer (LMK): A mechanism in Android/Linux that selectively kills BG applications when memory is critically low, to prevent the system from crashing. It typically targets applications with the lowest priority or those consuming the most memory.
  • CFS (Completely Fair Scheduler): The default CPU scheduler in the Linux kernel. It aims to provide fair CPU time to all processes based on their priority.

3.2. Previous Works

The paper discusses various previous efforts in memory and process management and highlights their limitations concerning the BG refault problem.

• Memory Management Schemes:
  • LRU [23]: The foundational Least Recently Used page replacement algorithm in the Linux kernel. It prioritizes reclaiming pages that haven't been accessed recently.
    • Differentiation: While effective for general page reclaiming, LRU doesn't differentiate between FG and BG pages sufficiently, nor does it account for the high refault rate of BG pages due to their low-priority, yet active, nature. Ice explicitly addresses BG refaults.
  • SmartSwap [72]: Optimizes memory reclaiming by predicting which applications are unlikely to be used and preemptively evicting their pages. It uses user behavior analysis.
    • Differentiation: SmartSwap focuses on hot-launch performance and caching apps. Ice argues that SmartSwap (and similar proactive reclaiming approaches) can still lead to memory thrashing and refaults if BG apps remain active. Ice aims to inhibit the source of refaults directly.
  • Acclaim [51]: A FG-aware page eviction scheme that prioritizes keeping FG application pages in memory, even if BG pages are more "active." It aims to reduce FG refaults.
    • Differentiation: Acclaim improves FG refaults, but by aggressively reclaiming BG pages, it can inadvertently increase BG refaults and the associated interference, as shown in the paper's evaluation (Figure 11, S-C on Pixel3). Ice specifically targets BG refaults.
  • Fleet [35]: Proposed to improve the number of cached applications and hot-launch performance.
    • Differentiation: Similar to SmartSwap, Fleet aims to keep more apps cached for quick switching. Ice notes that while these solutions help with caching, they don't fully solve the BG refault problem if cached BG apps remain active and cause memory thrashing.
  • Marvin [46]: Focuses on addressing GC-induced BG refaults in language runtimes (like Java).
    • Differentiation: Ice observes that GC is only one source of BG refaults, and even with GC disabled, a significant percentage of refaults persist (77%). Ice takes a broader approach by targeting all BG process activities that cause refaults.
  • MARS [31] / SEAL [47] / FlashVM [61]: These works leverage flash storage to speed up swapping or application launching. MARS speeds up app launching through flash-aware swapping, and SEAL proposes a two-level swapping framework. FlashVM modifies the virtual memory system for fast storage.
    • Differentiation: While these improve I/O performance, they don't prevent the fundamental issue of BG processes frequently accessing and refaulting pages. Ice aims to reduce the number of refaults themselves, thereby reducing I/O pressure.
• Process Scheduling Schemes:
  • CFS (Completely Fair Scheduler) [13]: The standard Linux scheduler, which aims to provide fair CPU time to all processes.
    • Differentiation: CFS treats FG and BG processes fairly, but this fairness doesn't prevent BG memory activities from interfering with FG tasks.
  • UCSG [65]: Prioritizes FG applications by giving their processes higher CPU priority.
    • Differentiation: While UCSG helps with CPU contention, it doesn't solve the memory-induced priority inversion problem, as low-priority BG processes can still run and cause refaults. The paper shows UCSG's refault reduction is limited (24.4% vs. Ice's 42.1%-57.6%).
  • Energy managers with process freezing [16, 38, 54]: Some commercial smartphones use process freezing for power management.
    • Differentiation: These freezing mechanisms are typically power-oriented, not memory-aware. They may freeze processes indiscriminately or based on energy consumption, not refault likelihood. They often lack dynamic tuning based on memory pressure and may not freeze when charging, making them less effective for BG refault reduction.
  • Other Scheduling Optimizations [29, 50, 57, 60, 69, 71]: Various strategies to optimize process scheduling, including FG differentiation, priority promotion, and interactive application performance.
    • Differentiation: Ice argues that these approaches, without memory insight, cannot fully address the BG refault issue because BG applications have diverse memory behavior characteristics. Ice brings a novel co-design perspective, integrating memory and process management.

3.3. Technological Evolution

Mobile operating systems, largely based on the Linux kernel, have continuously evolved their memory and process management strategies to improve user experience. Early systems relied heavily on basic LRU for page reclaiming and CFS for CPU scheduling. As RAM became more abundant but user expectations for multitasking grew, solutions like ZRAM emerged to mitigate slow swapping to flash storage. The focus then shifted to hot-launch performance and caching more applications (SmartSwap, Fleet). Recognizing the importance of FG responsiveness, FG-aware memory (Acclaim) and CPU scheduling (UCSG) schemes were introduced. Specific BG activities, like GC, were also targeted (Marvin).

This paper's work (Ice) fits into this evolution by identifying a persistent gap: the often-overlooked and detrimental interaction between BG application memory activities and FG user experience, particularly through BG refaults. It argues that prior solutions, while improving specific aspects, have not fundamentally resolved this co-design challenge. Ice represents a leap towards a more holistic memory and process management by explicitly linking BG refaults to process freezing, thus entering a new phase of co-design for improved user experience on resource-limited devices.

3.4. Differentiation Analysis

Compared to existing memory management and process scheduling methods, Ice introduces several core differentiations and innovations:

• Co-design of Memory and Process Management: This is Ice's most significant departure. Unlike previous works that primarily optimize memory or processes in isolation (e.g., Acclaim for memory, UCSG for processes), Ice explicitly creates a feedback loop. It uses memory refault events as triggers for process management decisions (freezing), and process states (frozen/thawed) to inform memory reclamation policies ($Ice+$).

• Refault-Driven Freezing: Instead of static priorities or general activity metrics, Ice's Refault-Driven Process Freezing (RPF) directly targets BG processes that are actively causing page refaults. This is a fine-grained, event-driven approach that addresses the root cause of memory thrashing more effectively than simply lowering BG process priority (as in UCSG) or proactively reclaiming (as in SmartSwap).

• Dynamic and Memory-Aware Thawing: Ice's Memory-Aware Dynamic Thawing (MDT) component introduces dynamic freezing intensity based on current memory pressure. This allows the system to adapt, freezing more aggressively when memory is scarce and relaxing when resources are available, which is more flexible than fixed freezing policies in power managers.

• Application-Granularity Freezing for Robustness: Ice freezes processes at application granularity (UID-level), acknowledging that applications often consist of multiple interdependent processes. This ensures application robustness and avoids partial freezing issues.

• Freezing-Aware LRU Modification ($Ice+$): $Ice+$ specifically modifies the LRU algorithm to be freezing-aware. It re-prioritizes pages belonging to frozen applications as immediately inactive, allowing them to be reclaimed faster. This is more efficient than traditional LRU which might be misled by historical BG activity.

• Avoids "Reclaim-Then-Kill" Waste ($Ice+$): By coordinating with ZRAM and LMK, $Ice+$ prevents pages from being reclaimed (compressed to ZRAM) only for the entire application to be subsequently killed by LMK. It flags frozen applications as "unkillable" if their pages have been compressed, thereby saving resource waste.

• Low Overhead and Compatibility: Ice is designed for low overhead, using kernel-level mechanisms and asynchronous operations, and is compatible with existing Android/Linux systems without requiring application or hardware modifications.

  In essence, Ice and $Ice+$ move beyond fragmented optimizations to offer an integrated, adaptive, and refault-centric solution that leverages existing system capabilities in a novel co-designed manner.

4. Methodology

4.1. Principles

The core idea behind Ice is to foster a strong collaboration between memory management and process management to optimize user experience on resource-limited mobile devices. The fundamental principle is to identify and selectively inhibit background (BG) processes that frequently cause page refaults, thereby reducing memory thrashing and priority inversion that negatively impact foreground (FG) applications. Ice achieves this by freezing such problematic BG processes when refaults are detected and thawing them dynamically when memory conditions allow. This refault-driven approach ensures that resource interference from BG activities is minimized, leading to a smoother FG user experience.

4.2. Core Methodology In-depth (Layer by Layer)

Ice is implemented through two main components: Refault-Driven Process Freezing (RPF) and Memory-Aware Dynamic Thawing (MDT), coordinated by an Ice Daemon. The framework's overall architecture and control flow are depicted in the figure below (Figure 5 from the original paper).

该图像是一个示意图，展示了Ice框架在资源有限的移动设备上的内存和进程管理的协作。图中说明了进程的冻结和解冻控制流，以及如何通过中介组件（如Ice Daemon）与主内存进行相互作用，优化用户体验。

Fig. 5. Ice overview. It detects the refault event and transfers the ID of the process causing refault to the RPF component for freezing (see the dashed lines). The MDT component monitors the memory pressure and thaws the frozen processes periodically (see the thick lines).

The control flow for process freezing and thawing in Ice is as follows:

1. Ice detects a refault event in the kernel space.

2. The process ID ($pid_i$) that induced the page refault is obtained and delivered to the RPF component.

3. Ice then determines the freezing targets (e.g., $pid_i, \ldots, pid_j$) and sends commands to the process management subsystem to inhibit (freeze) the activity of the selected processes.

4. In parallel, the MDT component continuously monitors memory pressure.

5. MDT intermittently thaws the frozen processes based on memory conditions. The thawing cycle is dynamically adjusted according to memory pressure.

   This design addresses several challenges: ensuring low refault event tracking overhead, intelligent control of freezing targets and intensity, and compatibility with existing system mechanisms.

4.2.1. Refault-Driven Process Freezing (RPF)

The RPF component is responsible for selectively freezing BG processes that cause sustained refaults. It focuses on selective freezing rather than aggressive freezing of all BG applications, minimizing the overhead of hot-launching frozen applications. RPF consists of two core sub-components: Refault Event Handling and Application-Grain Freezing. The overview of RPF is shown in the figure below (Figure 6 from the original paper).

该图像是一个示意图，展示了基于应用程序粒度的冻结机制和缺页事件处理流程。左侧图表展示了应用程序的UID、PID和标志位信息，右侧描述了缺页事件的识别和处理过程，其中涉及冻结信号的传递和处理方式。

Fig. 6. RPF overview. It consists of two core components: refault event handling and application-grain freezing.

4.2.1.1. Refault Event Handling

RPF operates based on an ECA (event-condition-active) rule.

• Refault Identification: The refault event is detected at the kernel level by inspecting the Page Table Entry (PTE). Each PTE contains a _PAGE_PRESENT flag (bit-0). When a page is evicted to storage, this flag bit is modified. If a page fault occurs and the _PAGE_PRESENT flag for the requested page is found to be unset, it indicates that the page was previously evicted, thus identifying a refault event. Ice leverages the shadow entry interface in the modern Linux kernel to acquire this refault-related information.
• Process Selection: Upon detecting a refault event, RPF identifies the process that owns the faulting page. This is possible because page faults originate from the page fault interruption, allowing the Linux kernel to obtain the page table and virtual address of the fault, thereby linking the memory page to its process. RPF then checks if this process is freezable. Certain critical processes, such as kernel processes (kswapd, kworker) and core Android services (UI thread, GC thread), are explicitly excluded from freezing to maintain system stability. The process ID (pid) of a freezable BG process causing a refault is then passed to the Application-Grain Freezing module.
• Response to the Refault Event: Refault events are detected in near real-time, allowing RPF to respond immediately. Since simply freezing a single process might disrupt the entire mobile application (as apps often have multiple interdependent processes), freezing is performed at application granularity.

4.2.1.2. Application-Grain Freezing

RPF implements freezing at the application granularity.

• Mapping Table: Ice maintains a mapping table that links application unique IDs (UIDs) to their corresponding process IDs (PIDs). The UID is a fixed identifier for an application. This table is updated when applications are installed, deleted, or launched.
• Freezing Mechanism: When RPF needs to freeze a process, it consults the mapping table to identify the application the process belongs to. It then sends freezing signals to all relevant target processes of that application. These processes respond to the signals by calling the try_to_freeze() function (a Linux kernel mechanism), which causes them to hibernate until a thawing signal is received. This method ensures that BG applications causing page refaults are effectively frozen.
• Kernel Space Management: The mapping table resides in the kernel space for fast access. Cross-space communication (between kernel and user space) only occurs when updating the table (e.g., when an app is launched or its state changes). Application information (UID, PID, state) is passed from the Android framework to the kernel via the proc file system (specifically, by writing a protocol string to the /proc/{pid}/ice-mp node). This communication overhead is minimal, given the infrequent changes to application lifecycle information compared to frequent process indexing operations.
• Freezing vs. Killing: Ice opts for freezing rather than outright killing BG applications. This is because frozen applications can be hot-launched (fast switched) and their state can be restored, improving user experience when switching back.

4.2.2. Memory-Aware Dynamic Thawing (MDT)

MDT is responsible for giving frozen applications a chance to run and dynamically tuning the freezing intensity based on memory pressure. This mechanism is illustrated in the figure below (Figure 7 from the original paper).

该图像是示意图，展示了内存消耗随时间的变化情况。曲线描述了在不同纪元（Epoch 0 到 Epoch 4）中内存的使用情况，包括“冻结期”（$E_f$）和“解冻期”（$E_t$）。图中还标示了峰值内存大小。整体上，图像展示了内存消耗的波动及其管理策略对用户体验的影响。

Fig. 7. Memory-aware heartbeat.

• Heartbeat Mechanism: MDT maintains a system-wide heartbeat. Each heartbeat epoch is divided into two phases: a freezing period ($E_f$) and a thawing period ($E_t$).
• Dynamic Tuning: At the beginning of each epoch, selected applications are frozen for $E_f$ seconds, then thawed for $E_t$ seconds. The length of $E_f$ (and thus the epoch) is dynamically adjusted based on the current memory state.
  • If memory pressure increases (less available memory), the freezing period ($E_f$) is lengthened, increasing freezing intensity.
  • If memory pressure decreases (more available memory), the freezing period ($E_f$) is shortened, reducing freezing intensity.
• Ratio of Freezing to Thawing: The freezing intensity is quantified by the ratio ($R$) of the freezing duration ($E_f$) to the thawing duration ($E_t$). The formula for the ratio $R$ is: $ R = \frac { E _ { f } } { E _ { t } } = \delta \times 2 ^ { \lceil \frac { H _ { w m } } { S _ { a m } } \rceil } $ Where:
  • $R$: The ratio of freezing duration to thawing duration. A higher $R$ means a longer freezing period relative to the thawing period, indicating higher freezing intensity.
  • $E_f$: The duration of the freezing period in seconds.
  • $E_t$: The duration of the thawing period in seconds. By default, $E_t$ is set to 1 second for simplicity, allowing $E_f$ to directly represent the intensity.
  • $\delta$: A weight coefficient that allows for fine-tuning the base freezing intensity.
  • $H_{wm}$: The high watermark (threshold) for memory in the system, determined at system initialization.
  • $S_{am}$: The current size of available memory in the system.
  • $\lceil \cdot \rceil$: The ceiling function, which rounds its argument up to the nearest integer. This formula ensures that $R$ (and thus $E_f$) increases exponentially as $S_{am}$ decreases relative to $H_{wm}$, making Ice more aggressive in freezing when memory is scarce.
• Handling Refault During Epoch:
  • If a refault occurs at time $T$ within the freezing period ($0 < T \leq E_f$), the application is frozen instantly and thawed at $E_f$, then allowed to run until the next epoch.
  • If a refault occurs at time $T$ within the thawing period, the application is frozen instantly but will not be thawed until the thawing period of the next epoch.
• Advantages over Priority Reduction: The paper notes that simple priority reduction for BG processes is insufficient because even low-priority processes can run frequently and cause unpredictable refaults. MDT provides strict control over BG refaults.

4.2.3. ${ \mathbf { I c e } } ^ { + }$ : Co-Design Ice with Existing Mechanisms

$Ice+$ extends the benefits of Ice by redesigning how Ice coordinates with existing memory management mechanisms like ZRAM (for memory reclamation) and LMK (for process killing). The goal is to address two key problems in the original system:

1. "Reclaim-Then-Killing" Waste: In the original system, pages of inactive applications are often reclaimed (compressed or swapped), only for the application itself to be killed shortly after by LMK because reclamation alone couldn't free enough memory. This wastes resources spent on reclaiming.
2. LRU Inefficiency with Freezing: The traditional LRU algorithm doesn't account for frozen applications. Pages of frozen applications, even if historically "active," should be treated as immediately inactive, but LRU might not prioritize them correctly.

4.2.3.1. Freezing-Aware Eviction

$Ice+$ introduces a freezing-aware eviction strategy, modifying the LRU algorithm to accelerate the reclamation of pages belonging to frozen applications. The scheme is illustrated in the figure below (Figure 8 from the original paper).

该图像是图示，展示了基于冻结状态的LRU列表页淘汰方案。当应用程序状态为冻结时，其对应的页面被移入非活动列表，而当被引用时则保持在活动列表中。这种策略有助于优化内存管理和提高用户体验。

Fig. 8. Freeze-aware page evict scheme of LRU lists.

• Page Prioritization: $Ice+$ identifies pages belonging to frozen applications (using the mapping table and UID notifications). It then lowers the priorities of these frozen pages and moves them out of the standard LRU lists more quickly. This allows $Ice+$ to efficiently extract memory space from frozen applications for the FG application.
• Benefits:
  • Accurate Inactivity: Frozen pages are immediately recognized as inactive, overcoming LRU's reliance on historical access patterns that might be misleading due to prior BG activity.
  • Resource Efficiency: By operating on application granularity, $Ice+$ can perform targeted operations (either reclaim or kill) on a frozen application, avoiding the resource waste of "reclaim-then-kill."

4.2.3.2. Process Killing with Ice

$Ice+$ integrates with the LMK to prevent unnecessary reclamation efforts before killing an application.

• Coordinated Action: When a page is about to be evicted from the tail of the inactive LRU list, $Ice+$ checks its UID. If the corresponding application is frozen and its pages are being compressed (e.g., into ZRAM), $Ice+$ flags this application in the mapping table as "unkillable" by LMK.
• Resource Waste Prevention: This means that if an application's pages are already undergoing compression due to reclamation, LMK will skip this application when looking for victims. This prevents the scenario where memory is spent compressing pages, only for the application to be killed moments later, rendering the compression effort wasted. This strategy helps LMK find more effective killing targets, leading to more efficient memory release.

4.2.4. Implementation and Discussions

• Whitelist for Safety: To ensure user imperceptibility, Ice employs a whitelist mechanism. This list contains applications that should never be frozen, regardless of their refault behavior.
  • Automatic Identification: Android identifies user-perceptible applications at the framework level:
    • FG applications (calling onResume()) are critical and are not frozen.
    • BG applications performing perceptible tasks (e.g., playing music, downloading files, indicated by calling startService()) are also excluded.
  • Priority Score (adj value): Android assigns a priority score (oom_score_adj) to each process. FG processes have a score of 0, perceptible BG applications have a default score of 200, and normal BG processes have higher scores. Ice adds applications with low process scores ($\leq 200$) to the whitelist.
  • Dynamic Updates: The whitelist is dynamically updated as application priority scores change (e.g., BG download finishes, FG application switches).
  • Offline Management: Vendors can manually add specific application UIDs (e.g., antivirus, messaging apps) to the whitelist for further customization.
• Thawing on Launch: If a user switches to a frozen application, Ice detects this application switching behavior. It thaws the application before it is displayed on the screen. This thawing operation is asynchronous and takes precedence over the MDT scheme, ensuring immediate responsiveness.
• Implementation Details: Ice is implemented by modifying the Linux kernel source code. It requires recompiling the Android project and flashing system.img and boot.img in fastboot mode. It is designed to be compatible across different Android versions and maintainable.
• Future Implications:

  • Flash Storage Lifetime: Ice's reduction of refault-induced I/Os can extend the lifetime of flash storage, which is particularly relevant for newer QLC (Quad-Level Cell) flash chips with lower endurance, especially with storage-based swap functions.

  • User-Experience Sensitive Applications: Ice can benefit MR (Mixed Reality) headsets, automotive systems, and IoT devices by optimizing resource utilization and improving UX.

  • Temperature Management (DVFS): By constraining BG activity, Ice helps alleviate temperature rise, preventing DVFS (dynamic voltage and frequency scaling) from throttling the processor frequency, thereby maintaining performance.

  • Compatibility: Ice is designed to be compatible with other advanced memory management strategies (e.g., adaptive swap), as its focus is on process-level memory optimization.

    The following are the results from Table 3 of the original paper:

    Category	Application
    Social Network	Facebook, Skype, Twitter, WeChat, WhatsApp
    Multimedia	YouTube, Netflix, TikTok
    Mobile Game	Angry Birds, Arena of Valor, PUBG Mobile
    Electronic Commerce	Amazon, PayPal, AliPay, eBay, Yelp
    Others	Chrome Browser, Camera, Uber, Google Maps

Table 3: Applications Used in the Evaluation

5. Experimental Setup

5.1. Datasets

In the context of this system-level paper, "datasets" refer to the experimental platforms, workloads, and scenarios used for evaluation rather than typical data samples.

• Platforms: Experiments were conducted on two commercially available smartphones, representing different segments of the market:

  • Google Pixel3 (Low-end device): Equipped with a Qualcomm Snapdragon 845 core, 4GB DDR4 RAM, and 64GB eMMC5.1 Flash. It ran Android 10.0 (r41).
  • HUAWEI P20 (Mid-range device): Equipped with a HiSilicon Kirin 970 core, 6GB DDR4 RAM, and 64GB UFS2.1 Flash. It ran Android 9.0. These platforms were chosen to demonstrate the effectiveness of Ice across different hardware configurations typical of resource-limited devices.

• Workloads (Applications): To simulate real-world usage, 20 popular applications (Table 3 from the Methodology section) were pre-installed. These applications span various categories, reflecting typical user behavior of having many apps cached in the background.

  • Foreground (FG) Scenarios: Four typical real-life scenarios were used to evaluate user experience:
    • Scenario A: Video Call: Using WhatsApp for a video call, where screen content changes dynamically.
    • Scenario B: Short-Form Video Switching: Playing and switching TikTok videos, representing a common interactive multimedia workload.
    • Scenario C: Screen Scrolling: Browsing the timeline of Facebook, a ubiquitous scrolling activity.
    • Scenario D: Mobile Game: Playing PUBG Mobile, a popular, resource-intensive real-time game.
  • Background (BG) Applications: For BG-apps cases, eight randomly selected applications from Table 3 were cached in the BG to simulate high memory pressure. Additionally, BG-cputester (occupies CPU but not memory) and BG-memtester (occupies memory but not CPU) were used for root cause analysis.

5.2. Evaluation Metrics

The paper uses several metrics to quantify user experience and system performance. For each metric, the conceptual definition, formula (if applicable), and symbol explanations are provided below.

• Frame Rate (FPS - Frames Per Second):
  1. Conceptual Definition: FPS measures the number of individual frames (images) rendered and displayed per second. It directly reflects the smoothness and fluidity of on-screen animations and interactions. A higher FPS generally indicates a better user experience.
  2. Mathematical Formula: $ \text{FPS} = \frac{\text{Number of Rendered Frames}}{\text{Total Time (seconds)}} $
  3. Symbol Explanation:
     • Number of Rendered Frames: The total count of unique frames successfully drawn by the system.
     • Total Time (seconds): The duration over which the frames were counted, expressed in seconds.
• Ratio of Interaction Alert (RIA):
  1. Conceptual Definition: RIA quantifies the proportion of frames that fail to render within a critical time threshold of 16.6 ms. This threshold is significant because humans can typically perceive jank (stuttering or lag) if a frame takes longer than this to render (equivalent to a target of 60 FPS). A lower RIA indicates a smoother user experience.
  2. Mathematical Formula: $ \text{RIA} = \frac{\text{Number of Frames taking } > 16.6 \text{ ms}}{\text{Total Number of Frames}} \times 100% $
  3. Symbol Explanation:
     • $Number of Frames taking > 16.6 ms$: The count of frames that exceeded the 16.6 ms rendering time limit.
     • Total Number of Frames: The total number of frames attempted to be rendered.
• Number of Refaulted Pages (in k):
  1. Conceptual Definition: The total count of memory pages that were previously reclaimed (evicted from RAM) but subsequently needed again by a process, causing a page fault. This metric, often expressed in thousands ($k$), directly indicates the inefficiency of memory management.
  2. Mathematical Formula: No explicit formula provided, typically a direct count from system logs or instrumentation.
  3. Symbol Explanation: $k$ denotes thousands (e.g., 5.8k means 5,800 pages).
• Number of Reclaimed Pages (in k):
  1. Conceptual Definition: The total count of memory pages that were removed from RAM by the operating system to free up memory. A high number can indicate intense memory pressure or inefficient reclamation if many are refaulted soon after.
  2. Mathematical Formula: No explicit formula provided, typically a direct count from system logs or instrumentation.
  3. Symbol Explanation: $k$ denotes thousands.
• I/O Size (for I/O Pressure):
  1. Conceptual Definition: The total amount of data (in bytes or KB/MB) transferred to and from storage devices (flash) during memory operations (e.g., swapping, writing dirty file-backed pages). High I/O size indicates significant disk activity, which consumes power and can slow down the system.
  2. Mathematical Formula: No explicit formula provided, typically a direct summation of block I/O operations.
• CPU Utilization:
  1. Conceptual Definition: The percentage of time the CPU is actively engaged in processing tasks. High CPU utilization can indicate a busy system, potentially leading to CPU contention.
  2. Mathematical Formula: $ \text{CPU Utilization} = \frac{\text{CPU Busy Time}}{\text{Total Time}} \times 100% $
  3. Symbol Explanation:
     • CPU Busy Time: The duration when the CPU was actively processing tasks.
     • Total Time: The total measurement duration.
• Application Launching Speed (Cold/Hot Launching Latency):
  1. Conceptual Definition: The time taken for an application to become interactive after a user initiates its launch.
     • Cold Launching: The app is not currently in memory or recent caches; it needs to be loaded from storage.
     • Hot Launching: The app is already partially or fully in memory (cached in BG), allowing for faster startup.
  2. Mathematical Formula: No explicit formula provided, typically a direct time measurement.
  3. Symbol Explanation: Measured in milliseconds (ms).
• QoS (Quality of Service) of BG Services (Audio Smoothness):
  1. Conceptual Definition: A composite score reflecting the perceived quality and uninterrupted playback of audio in BG. It combines Zero-Crossing Rate, RMS Amplitude Variation, and Spectral Flux. Higher score means smoother audio.
  2. Mathematical Formula: $ \text{Smoothness Score} = w _ { 1 } \times ( 1 - \text{ZCR} ) + w _ { 2 } \times ( 1 - \text{RMS Variation} ) + w _ { 3 } \times ( 1 - \text{Spectral Fluxion} ) $
  3. Symbol Explanation:
     • Smoothness Score: The weighted sum indicating overall audio smoothness.
     • $w_1, w_2, w_3$: Weight coefficients for each metric, summing to 1 (e.g., $\frac{1}{3}$ each).
     • ZCR (Zero-Crossing Rate): Measures how often an audio signal changes sign (crosses the zero line). High ZCR can indicate noise or abrupt changes, suggesting less smoothness. Normalized to a 0-1 scale.
     • RMS Variation (Root Mean Square Amplitude Variation): Measures the consistency of the audio signal's power. Large variations indicate volume fluctuations, potentially signifying stuttering. Normalized to a 0-1 scale.
     • Spectral Fluxion (Spectral Flux): Measures the rate of change in the power spectrum of the audio signal. Higher Spectral Flux indicates more sudden changes in frequency content, implying less smooth audio. Normalized to a 0-1 scale.
• Download Efficiency:
  1. Conceptual Definition: How quickly data can be downloaded by BG applications. Measured by bandwidth (Mbps) for single files and total time (minutes) for larger content like TV series.
  2. Mathematical Formula: No explicit formula provided, direct measurements of network speed and duration.
  3. Symbol Explanation: Mbps (megabits per second), min (minutes).

5.3. Baselines

The proposed Ice framework was compared against several existing and state-of-the-art memory and process management schemes:

• LRU + CFS:
  • Description: This represents the default memory management (LRU for page reclaiming) and process scheduling (Completely Fair Scheduler (CFS) for CPU) mechanisms in the Linux kernel and Android. LRU identifies inactive pages for reclamation, and CFS aims for fair CPU allocation among all processes, including FG and BG.
  • Why Representative: It serves as the fundamental baseline, reflecting the behavior of a standard Android system without specialized optimizations.
• UCSG [65]:
  • Description: UCSG (User-Centric Scheduler for Graphics) is a process scheduling scheme that prioritizes FG applications. It specifically sets higher priorities for processes belonging to the FG application, assuming they dominate user attention.
  • Why Representative: It's a relevant baseline for process scheduling optimizations aimed at improving FG responsiveness by explicitly favoring FG tasks over BG tasks.
• Acclaim [51]:
  • Description: Acclaim is an FG-aware and size-sensitive memory reclaiming scheme. Its core idea is to protect pages belonging to the FG application from reclamation, while aggressively reclaiming pages from BG applications, even if those BG pages are "more active" than some FG pages.
  • Why Representative: Acclaim is a state-of-the-art memory management solution explicitly designed to improve FG user experience by reducing FG refaults, making it a strong comparison for Ice's memory-focused aspects.

5.4. Parameter Configurations

The following are the results from Table 4 of the original paper:

Table 4: Summary of Parameters Used by Ice

• $S^g$ (ZRAM size on Pixel3): Set to 512MB. This defines the maximum amount of anonymous pages that can be compressed into ZRAM on the Pixel3.

• $S^h$ (ZRAM size on P20): Set to 1,024MB. This defines the maximum amount of anonymous pages that can be compressed into ZRAM on the P20.

• $H_{wm}^g$ (High-watermark on Pixel3): Set to 256. This is the memory threshold (in units of pages or memory blocks) on the Pixel3 at which the system starts memory reclamation.

• $H_{wm}^h$ (High-watermark on P20): Set to 1,024. This is the memory threshold on the P20 at which the system starts memory reclamation.

• $\delta$ (Weight coefficient for MDT): Configured as 8.0. This parameter, used in the MDT formula $R = \delta \times 2 ^ { \lceil \frac { H _ { w m } } { S _ { a m } } \rceil }$, directly influences the freezing intensity. A higher $\delta$ generally leads to more aggressive freezing for a given memory pressure.

• $E_t$ (Thawing epoch length): Set to 1 second. This parameter defines the duration for which frozen applications are thawed within each MDT epoch. By fixing $E_t$ to 1 second, the freezing duration ($E_f$) directly scales with the calculated ratio $R$, simplifying the dynamic adjustment of freezing intensity.

  These parameters are configurable, allowing flexibility for different device characteristics and user experience goals.

6. Results & Analysis

6.1. Core Results Analysis

This section details the experimental results, comparing Ice and $Ice+$ against baseline and state-of-the-art schemes in terms of user experience metrics like frame rate and application launching speed, as well as underlying system metrics such as refaults, reclaims, I/O, and CPU pressure.

6.1.1. Effect of Ice on the User Experience

6.1.1.1. Benefit on Frame Rate

The evaluation of frame rate (FPS) and Ratio of Interaction Alert (RIA)) across four typical scenarios (Video Call, Short-Form Video Switching, Screen Scrolling, Mobile Game) consistently shows that Ice significantly improves user experience, especially when multiple BG applications are cached.

The figure below (Figure 9 from the original paper) illustrates the frame rate comparison across the four scenarios.

该图像是图表，展示了不同方法在 Pixel3 和 P20 设备上的 FPS 和 RIA 比较。左侧为 FPS 比较，右侧为 RIA 比较，分别标示了 LRU+CFS、UCSG、Acclaim 和 Ice 方法的性能表现。图中数据指示了 Ice 方法在提高用户体验方面的有效性。

Fig. 9. Frame rate comparison in four typical scenarios: video call (S-A), short-video switching (S-B), screen scrolling (S-C), and mobile game (S-D).

• Overall Improvement: For a video call (S-A) on Pixel3, $LRU+CFS$ averaged 25.4fps, UCSG 29.3fps, and Acclaim 24.1fps. With Ice, the frame rate boosted to 37.2fps, indicating a much smoother experience. This is significant as FPS below 30 is generally perceived as janky.
• RIA Reduction: Ice also substantially reduced RIA. For PUBG Mobile (S-D) on P20, RIA was reduced from 46% (meaning almost half of frames failed to render within 16.6ms) to 28% with Ice.
• Comparison with Baselines:

  • UCSG showed some frame rate improvement by prioritizing FG processes, but its benefit was limited because it doesn't inhibit BG processes causing refaults.

  • Acclaim, while reducing FG refaults, sometimes degraded FPS (e.g., S-C on Pixel3) because its aggressive reclamation of BG pages could lead to more BG refaults.

    The figure below (Figure 10 from the original paper) presents the frame rate comparison with varying numbers of applications cached in the BG.

    该图像是一个图表，展示了在不同应用缓存数量下，Pixel3和P20设备上的帧率（FPS）与R/A（Refault Awareness）之间的比较。图中显示‘With Ice’和‘Without Ice’两种状态下的性能差异，表明使用Ice优化框架可显著提升用户体验。

Fig. 10. Frame rate comparison with various numbers of applications cached in the BG.

• Scaling with BG Apps: Frame rendering performance naturally degrades as more BG applications are cached.
• Ice's Impact: In cases with 6 BG applications on Pixel3 and 8 BG applications on P20, Ice dramatically curbed this degradation. FPS was enhanced by 1.57x and 1.44x, respectively, while RIA was reduced by 32.7% and 34.6%. This highlights Ice's effectiveness particularly under high memory pressure.

6.1.1.2. Reduction of Refault and Reclaim

The user experience improvements from Ice are directly attributable to its ability to reduce BG refaults and reclaim operations.

The figure below (Figure 11 from the original paper) illustrates the number of refaulted and reclaimed pages with $LRU+CFS$, UCSG, Acclaim, and Ice.

该图像是一个图表，展示了不同策略下的页面重fault和页面回收数量。图中蓝色条形表示重fault页面数量，橙色条形表示回收页面数量，策略分别标记为 S-A、S-B、S-C 和 S-D，以及对应的 L、U、A 和 I。

Fig. 11. The number of refaulted and reclaimed pages with LRU $^ +$ CFS (L), UCSG (U), Acclaim (A), and Ice (I).

• Refault Reduction: Ice significantly reduced the number of refault pages. On P20, refaults were reduced by 42.1% (S-A), 44.4% (S-B), 57.6% (S-C), and 40.5% (S-D) compared to $LRU+CFS$.

• Reclaim Reduction: Consequently, the total number of reclaimed pages was also reduced because fewer pages needed to be reclaimed multiple times due to refaults. With Ice, the number of reclaimed pages was only 70.7% of $LRU+CFS$ on average. This is crucial as reclaiming itself consumes CPU resources.

• Comparison with Baselines: Ice outperformed UCSG and Acclaim in refault and reclaim reduction. UCSG achieved 51.7% and 53.9% of Ice's refault and reclaim reductions, respectively. Acclaim even saw an increase in refaults by 4.3% in some cases, confirming Ice's argument that FG-aware eviction alone can exacerbate BG refaults.

• Effect of Power Manager Freezing: The paper also compared Ice with power managers that include process freezing.

  The following are the results from Table 5 of the original paper:

  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

Table 5: Number of Refaulted and Reclaimed Pages ($\times 1 \text{K}$) with Process Freezing (Power Manager vs. Ice)

As shown in Table 5, the power manager's freezing reduced reclaimed pages by 22.4% and refaulted pages by 33.5% on average compared to $LRU+CFS$. However, Ice achieved even greater reductions (as seen in Figure 11 for total Ice vs $LRU+CFS$ comparisons). This indicates that Ice's dynamic, memory-aware freezing is more effective than the generally power-oriented and less flexible freezing mechanisms in typical power managers.

6.1.1.3. Reduction of I/O and CPU Pressure

• I/O Pressure: Ice reduced I/O size by 9.2% compared to $LRU+CFS$. This is because Ice effectively avoids senseless I/Os caused by file-backed pages being frequently demanded, discarded, and refaulted by BG applications.
• CPU Pressure: CPU utilization decreased from 55.8% (with $LRU+CFS$) to 47.3% with Ice. This reduction comes from freezing some BG tasks and the decreased need for memory compression/decompression tasks due to fewer refaults.

6.1.1.4. Whitelist Study

The whitelist mechanism allows certain applications to be excluded from freezing. When all BG applications were added to the whitelist (an extreme case, effectively disabling Ice's core function), the FPS performance degraded to be close to the original system (e.g., 25.2fps for video calls on Pixel3). This confirms that the benefits of Ice are directly tied to its ability to selectively freeze BG applications.

6.1.1.5. Impact on Application Launching

The impact of Ice on application launching speed is multifaceted.

The figure below (Figure 12 from the original paper) shows the impact of Ice on application launching.

该图像是图表，展示了不同方法下应用程序启动延迟和热启动应用程序数量的比较。其中(a)展示了平均、冷启动和热启动延迟的时间成本，(b)展示了在各个测试环境下热启动应用程序的数量。结果表明，Ice方法在提高用户体验方面具有显著优势。

Fig. 12. Impact of Ice on application launching. The result shows that Ice's impact on hot launching is small and the cold launching speed can be improved (a), and applications could be hot launched when enabling Ice (b).

• Average Launching Speed (Figure 12a): Ice improved the average launching time by 36.6% compared to $LRU+CFS$. This indicates that the positive effects (reduced BG interference, more CPU cycles for FG) outweigh the negative effects (time to thaw).
• Cold Launching (Figure 12a): Cold launching time was reduced by 28.8% with Ice. This is a significant improvement, as cold launches benefit greatly from reduced BG interference and increased resource availability. Freezing doesn't penalize cold launches as the app isn't already frozen.
• Hot Launching (Figure 12a): The impact on hot launching varied. 47% of applications showed a slowdown, but the latency increase was smaller than their standard deviations, suggesting that the benefits generally offset penalties. The worst-case hot launching (all pages reclaimed and app frozen) was 839ms, which is 1.98x slower than $LRU+CFS$ hot launching but still much faster than cold launching. This penalty is considered acceptable and can be mitigated by application prediction or launch boosting schemes.
• Ratio of Hot Launching (Figure 12b): Ice increased the number of hot-launched applications by 25%. This is because Ice alleviates refault-induced memory pressure, reducing the likelihood of LMK being triggered and delaying app killing. More applications remain cached and can be hot-launched.

6.1.2. Effect of ${ \mathbf { I c e } } ^ { + }$ on the User Experience

$Ice+$ further optimizes user experience by coordinating Ice's freezing capabilities with ZRAM and LMK.

The following are the results from Table 6 of the original paper:

Table 6: Frame Rate Improvement Comparison of Ice and Ice+, and Their Effect on the System

6.1.2.1. Frame Rate Improvement

As shown in Table 6, $Ice+$ further boosts the frame rate by an average of 5.14% compared to Ice. For example, in Short-Video Switching (S-B), FPS increased by 4.1fps on Pixel3 (48.6 to 52.7) and 2fps on P20 (43.6 to 45.6).

6.1.2.2. System Improvement Analysis

• Reclaimed Pages: The number of reclaimed pages with $Ice+$ was reduced by 14.5% on average compared to Ice. This indicates that $Ice+$'s freezing-aware eviction scheme, preventing "reclaim-then-kill," is effective. The paper observed that 5.8k reclaimed pages (21.4%) would have been pointlessly processed by ZRAM only to be released by LMK in the Ice case without $Ice+$'s coordination.
• Refault Pages: The total amount of refaults was reduced by 12.7% on average with $Ice+$. This reinforces that by intelligently coordinating with ZRAM and LMK, $Ice+$ can further minimize memory thrashing.

6.1.2.3. Impact on App Launching

The figure below (Figure 13 from the original paper) compares the average launch latency and its deviation between Ice and $Ice+$.

该图像是图表，展示了 Ice 和 ${ ext{Ice}^+ }$ 在热启动和冷启动时的平均启动延迟及其偏差的比较。结果显示，当结合现有机制时，用户体验可以进一步改善。

Fig. 13. Average launch latency and the deviation comparison between Ice and ${ \\mathrm { l c e } } ^ { + }$ .The results illustrate that the user experience can be further improved when Ice coordinates with existing mechanisms.

Table 6 and Figure 13 indicate that $Ice+$'s enhancements do not noticeably impact application launching speed (both cold and hot). The differences in mean launching latency between Ice and $Ice+$ are smaller than their standard deviations, suggesting that the additional overhead of freezing-aware LRU maintenance is negligible compared to the benefits gained.

6.1.3. QoS of BG Services

The paper also evaluated the Quality of Service (QoS) for critical BG services like audio playback and file downloads to ensure Ice doesn't negatively impact them.

The following are the results from Table 7 of the original paper:

Table 7: Effect on the BG Services

• Audio Smoothness: The Smoothness Score (calculated as $w _ { 1 } \times ( 1 - \text{ZCR} ) + w _ { 2 } \times ( 1 - \text{RMS Variation} ) + w _ { 3 } \times ( 1 - \text{Spectral Fluxion} )$, with $w_1=w_2=w_3=\frac{1}{3}$) was used.
  • $Ice/Ice+$ did not stop audio services. This confirms the effectiveness of Android's framework-level identification of critical BG services and Ice's whitelist mechanism.
  • The impact on audio smoothness scores was negligible, with small positive or negative deviations from the baseline (Empty-NoIce case, which has a score of 0.0). Amplitudes were within $\pm 1.0$ normalized range.
  • Notably, when BG was busy (Full case), Ice and $Ice+$ even slightly improved the QoS for music playback (scores of 0.0075 and 0.0139 respectively), likely due to reduced system-wide interference.
  • A user study confirmed that Ice's effect on audio was user imperceptible.
• Download Efficiency:

  • $Ice/Ice+$ did not stop download services.

  • For downloading a single file, bandwidth Mbps remained comparable across all cases.

  • For downloading TV series, the time cost in minutes also remained comparable, with slight variations that were not significant.

  • In the Full case, Ice and $Ice+$ even showed minor improvements in download speed (e.g., 59.6/60.2 Mbps vs. 58.9 Mbps for Full-NoIce).

    These results demonstrate that Ice and $Ice+$ achieve significant FG user experience improvements without compromising the QoS of critical BG services.

6.1.4. Overhead Analysis

6.1.4.1. Memory Consumption

Ice maintains a mapping table to track UID-PID relationships and freezing states. For a device with 20 installed applications, each having three processes, the maximum memory consumption is estimated at 13.8KB. This includes space for UIDs, PIDs, freezing states, and priority scores. The table's size is controlled by deleting entries when application lifecycles end, and an upper bound (32KB) is set. This memory overhead is considered negligible compared to the total RAM available on a smartphone.

6.1.4.2. Performance Overhead

The performance overhead of Ice is broken down into three parts:

• Refault Event Response: Ice's response to refault events (obtaining process information, PID indexing, freezing) is performed asynchronously, ensuring that page accessing is not suspended.

• Mapping Table Maintenance: The UID-PID mapping table is initialized at boot, updated upon app installation/launch/deletion, and freezing state changes. Since the table is small and in memory, indexing operations are at the microsecond level, making their time consumption negligible compared to application launching latency. Cross-space communication for updates occurs infrequently.

• Freezing-Induced Overhead: The time to thaw a frozen application is in the tens of milliseconds, which is acceptable relative to launching time. Ice minimizes this penalty by only freezing active BG applications that cause refaults, not all BG apps.

  Overall, the overhead introduced by Ice is acceptable and small in comparison to the user experience benefits it provides.

6.2. Ablation Studies / Parameter Analysis

While the paper does not present explicit "ablation studies" in the traditional sense (e.g., removing one component of Ice at a time), it does provide a comparative analysis that serves a similar purpose:

• Comparison of Ice vs. $Ice+$: This comparison (Table 6, Figure 13) acts as an ablation study for the LRU modification and LMK coordination aspects. It shows that $Ice+$ (which adds these features on top of Ice) provides further improvements in frame rate, refault, and reclaim reduction, with negligible impact on launching latency. This validates the effectiveness of the freezing-aware eviction and LMK coordination components.
• Whitelist Study: This experiment (discussed under Section 6.1.1.4) effectively "ablates" Ice's freezing functionality by whitelisting all BG applications. The results show a degradation of FPS back to baseline levels, confirming that Ice's benefits are directly derived from its BG process freezing mechanism.
• Comparison with Power Manager Freezing (Table 5): This comparison shows that generic process freezing (like in power managers) is less effective than Ice's memory-aware, refault-driven freezing. This validates the specificity and intelligence of Ice's freezing approach.
• Parameter Configuration (Table 4): The paper specifies the values for Ice's configurable parameters ($\delta$, $E_t$, ZRAM sizes, high-watermarks). While no sensitivity analysis on these parameters is explicitly shown, their fixed values are part of the evaluated system configuration. The formula for $R$ in MDT shows how freezing intensity is dynamically tuned based on memory pressure, implying an adaptive rather than static parameter setting for $E_f$.

7. Conclusion & Reflections

7.1. Conclusion Summary

This paper effectively identifies and addresses a critical problem impacting user experience on resource-limited mobile devices: the pervasive negative interference from background (BG) applications' memory activities, particularly page refaults. The authors propose Ice, a novel framework that integrates memory and process management through refault-driven process freezing (RPF) and memory-aware dynamic thawing (MDT). Ice selectively freezes BG processes causing refaults and thaws them dynamically based on memory pressure. Furthermore, $Ice+$ enhances this by introducing app-freezing aware LRU modifications and coordinating with ZRAM and LMK to prevent resource waste from "reclaim-then-kill" scenarios.

Implemented and evaluated on real mobile devices (Google Pixel3 and HUAWEI P20), Ice demonstrated significant improvements, boosting the average frame rate by 1.57x over state-of-the-art methods. $Ice+$ further enhanced this by an additional 5.14% on average. These improvements come with negligible overhead and without compromising the Quality of Service (QoS) for critical BG services. Ice represents a crucial step toward more intelligent and holistic resource management in mobile systems.

7.2. Limitations & Future Work

The authors acknowledge certain limitations and suggest future research directions:

• Hot Launching Penalty Mitigation: While Ice generally improves application launching speed, a potential penalty exists in worst-case hot launching scenarios where a frozen application has had many of its pages reclaimed. The paper suggests that this penalty could be further eliminated by combining Ice with application prediction techniques (e.g., pre-thawing predicted next apps) or existing launch boosting schemes like MARS or ASAP.
• Future Device Compatibility: The paper discusses how Ice's principles could be even more beneficial for future mobile devices, especially those with new flash storage technologies (e.g., QLC) where storage lifetime is critical due to reduced endurance, and for new UX-sensitive applications like MR headsets and automotive systems.
• Adaptive Swap Compatibility: Ice is designed to be compatible with future memory management strategies, such as adaptive swap mechanisms, as its focus is on process-level memory optimization rather than replacing fundamental memory operations.

7.3. Personal Insights & Critique

This paper presents a highly relevant and impactful solution to a persistent problem in mobile computing. The strength of the work lies in its co-design approach, bridging memory and process management in a way that previous fragmented solutions could not achieve.

• Innovation: The refault-driven process freezing mechanism is a truly novel and intuitive approach. By directly targeting the cause of memory thrashing (BG refaults) rather than just its symptoms (low free memory, slow I/O), Ice offers a more fundamental solution. The memory-aware dynamic thawing mechanism adds an essential layer of adaptability, ensuring that freezing intensity scales with actual memory pressure. $Ice+$'s integration with LRU, ZRAM, and LMK demonstrates a deep understanding of Linux/Android internals and a practical approach to system-level optimization.
• Rigorous Evaluation: The evaluation on real-world devices with diverse application scenarios (video calls, games, scrolling) and comprehensive metrics (FPS, RIA, refaults, reclaims, I/O, CPU, launching speed, QoS) lends significant credibility to the findings. The root cause analysis (using cputester and memtester) is particularly insightful, clearly isolating memory contention as the primary culprit.
• Practicality: The fact that Ice can be implemented via kernel modifications without invasive changes to mobile applications or hardware makes it highly practical for adoption by OS vendors. The whitelist and thawing on launch mechanisms ensure user imperceptibility, which is crucial for any system-level optimization.
• Potential Improvements/Critiques:

  • Dynamic Parameter Tuning: While MDT introduces dynamic tuning of $E_f$, the core weight coefficient $\delta$ is fixed. A more advanced Ice version could explore machine learning or reinforcement learning approaches to dynamically tune $\delta$ or other aspects of the freezing policy based on longer-term system behavior and user profiles.

  • Application-Specific Freezing: The application-grain freezing is good for robustness, but BG apps can have wildly different memory access patterns and refault behaviors. Future work could explore more granular freezing policies that differentiate between types of BG activities within an application (e.g., background sync vs. pre-rendering).

  • Interaction with Other OS Optimizations: The paper briefly mentions compatibility with application prediction and adaptive swap. A deeper investigation into how Ice could be synergistically combined with these other OS optimizations to achieve even greater gains, especially in worst-case hot launching, would be valuable.

  • Long-Term User Study: While the paper mentions a user study for QoS (audio), a more extensive, longer-term user study specifically on perceived jank and overall fluidity across devices and user habits could provide richer qualitative validation.

    Overall, Ice is an exemplary piece of research that not only identifies a critical user experience bottleneck but also provides an elegant, well-engineered, and thoroughly validated solution. Its co-design philosophy offers a valuable blueprint for future system-level optimizations in resource-constrained environments.