arXiv:2603.17259v1 [cs.OS] 18 Mar 2026
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems Xiaochen Li
Sicong Liu∗
Bin Guo
Northwestern Polytechnical University [email protected]
Northwestern Polytechnical University [email protected]
Northwestern Polytechnical University [email protected]
Yu Ouyang
Fengmin Wu
Yuan Xu
Northwest University, China [email protected]
Northwestern Polytechnical University [email protected]
Northwestern Polytechnical University [email protected]
Zhiwen Yu Harbin Engineering University, Northwestern Polytechnical University [email protected]
Abstract GB-scale large apps like on-device LLMs and rich media editors are becoming the next-generation trend, but their heavy memory and I/O demands, especially during multitasking, cause devices to reclaim or kill processes, turning warm apps into cold launches. The challenge lies not in storing them, but in fast, accurate launching. For users, 1s is the usability cliff, yet our measurements show 86.6% of GB-scale cold launches exceed it. Also, Android Vitals flags only ≥5s as slow, exposing a large satisfaction gap. Existing optimizations are designed in isolation and conflict. For example, preloading reduces I/O stalls but consumes scarce memory and is undone by reclamation, while reclamation and killing free memory but sacrifice background survivability, leading to repeated cold relaunches. Our key insight is that, although multitasking makes runtime behavior complex, each app’s file access pattern remains predictable. The challenge lies in exploiting this predictability, i.e., preloading without exhausting memory, reclaiming without undoing gains, and killing selectively to preserve background survivability. We ∗ Corresponding author: [email protected]
introduce AppFlow, a prediction-based system-wide scheduler that integrates a Selective File Preloader, an Adaptive Memory Reclaimer, and a Context-Aware Process Killer. Implemented across the Android framework and Linux kernel without app changes, AppFlow cuts GB-scale cold-launch latency by 66.5% (e.g., 2s→690ms) and sustains 95% of launches within 1s over a 100-day test, significantly improving responsiveness and multitasking experience.
CCS Concepts • Human-centered computing → Ubiquitous and mobile computing; • Computer systems organization → Embedded systems; Availability; Embedded software.
Keywords GB-scale large app cold launch, mobile memory scheduler ACM Reference Format: Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu. 2026. AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems. In The 32nd Annual International Conference on Mobile Computing and Networking (MobiCom ’26), October 26–30, 2026, Austin, TX, USA. ACM, New York, NY, USA, 15 pages. https://doi.org/10.1145/3795866.3796690
1 This work is licensed under a Creative Commons Attribution 4.0 International License. MobiCom ’26, Austin, TX, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2505-0/2026/10 https://doi.org/10.1145/3795866.3796690
Introduction
GB-scale large apps have become the next-generation trend on mobile devices, placing high pressure on memory and I/O resources. Today’s popular apps such as LLM-powered assistants [7], image-to-text generators [45], rich-media editors like CapCut [4], streaming platforms such as TikTok [42], and
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
3D mobile games like PUBG Mobile [32], all ship with GBscale footprints. Notably, eight of the ten most-downloaded apps on Google Play now exceed 1GB [2, 39]. Despite limited mobile resources, users typically keep multiple tasks open at once. For example, Lucy may utilize TikTok and RedNote for trip planning, simultaneously leaving an on-device LLM active in the background. This repetitive switching leads to frequent cold launches that break her operational flow. Compounding the issue, the LLM’s intensive, instantaneous memory footprints can cause the system to terminate background apps, resulting in a fragmented and frustrating multitasking experience. In in-vehicle systems, drivers cold launch apps like Google Maps for navigation or pedestriandetection apps for driver assistance, where every second of delay degrades experience and can even affect driving safety. This common multitasking scenario stretches memory and I/O to their limits. To launch a GB-scale large app under such pressure, the OS must reclaim memory by either swapping cached pages [28, 29] or killing background processes [1]. Both sacrifice background app responsiveness: previously warm apps degrade into cold launches. When Lucy switches back to Instagram, the system must reload more than 1GB of assets from storage, often stalling for over 2s, twice the 1s usability cliff [30] at which users perceive apps as frozen or crashed. Crucially, this is not a corner case but a daily inevitability. Modern smartphones keep only 20 apps resident [14] (even fewer on other devices like vehicles), while users install 80+ on average [3], making 34 launches cold by design. For example, with just 15 GB-scale apps always running (e.g., TikTok, RedNote, and PUBG) on a mobile device, e.g., Google Pixel 8, 86.6% of relaunches exceed the 1s usability cliff. In short, users inevitably face these “frozen-app moments” multiple times a day (e.g., up to 7 times per day in our 100-day tests), breaking the seamless launch in multitasking experience. Despite extensive efforts, reducing cold launch latency without sacrificing background survivability remains fundamentally hard. Prior work tackles only one side of the bottleneck: I/O preloading [6, 33] reduces stalls but consumes scarce RAM and is quickly undone by aggressive reclamation, while memory reclamation [24, 29] frees space but often evicts preloaded pages, nullifying I/O gains. The core difficulty is that preloading and reclamation/killing are designed in isolation and inherently conflict. To our knowledge, there is no prior work that jointly optimizes them. To address these, we face two challenges: • Challenge #1: Deciding when, what, and how to preload for balancing cold-launch latency with multitasking is nontrivial. GB-scale launches involve thousands of small, scattered reads that fragment I/O and keep I/O throughput far below peak (see Sec. 2.2.1). Prior efforts either preload all files [20, 21, 31], which is prohibitive for GB-scale apps as it
exhausts memory and causes reclamation or killing, or load on demand [6, 16, 33], which saves memory but often lags behind CPU execution, turning file I/O into the bottleneck and making GB-scale cold launches even slower. Moreover, preloading competes with reclamation for I/O bandwidth and its extra footprint sacrifices background survivability. • Challenge #2: It is intractable to promptly reclaim memory for GB-scale cold launches without breaking background survivability or undoing preloading gains. In practice, cold launches stall allocations and even block preloading, yet existing solutions such as Android’s LMK [1] or follow-up studies [24, 26, 29] explore to address this by reclaiming pages [24, 26] or killing processes [1]. However, both of these approaches fall short as they treat file-backed and anonymous pages uniformly despite asymmetric costs [26]. Also, they inherently trade off new app responsiveness for background survivability, leaving the problem unresolved. To address these, we present AppFlow, a system-wide scheduler that jointly manages preloading, page reclaim, and process killing on commodity mobile and vehicle devices. • First. We profile GB-scale launches and identify a structural I/O imbalance, i.e., although small files are only 3% of total size, they dominate launch latency by interrupting largefile transfers and fragmenting sequential reads (see Sec. 2.2.1). Leveraging this, we design a Selective File Preloader that decides when, what, and how to preload. It preloads small files before launch to minimize memory use and avoid early stalls, while streaming large files during launch with large blocks to maximize throughput. A ms-level knapsack solver further selects per-app cutoffs (see Sec. 4.1). • Second. We decouple file-backed and anonymous page reclamation to exploit their asymmetric costs: file-backed pages can be reclaimed quickly in large contiguous blocks, while anonymous pages require slow write-back (Sec. 2.2.2). Harnessing this, AppFlow integrates an Adaptive Memory Reclaimer that prioritizes file-backed pages under pressure, switches to anonymous pages otherwise, and tags preloaded data to prevent premature eviction (see Sec. 4.2). It further includes a Context-Aware App Killer that removes only the long-running background apps (see Sec. 4.3). We implement AppFlow spanning the Android framework and Linux kernel layers, requiring no modifications to application layer. We conduct extensive evaluations on three platforms, including commercial smartphones and in-vehicle systems, using 60+ popular apps with diverse workloads. Compared with Android OS and three state-of-the-art baselines, AppFlow cuts GB-scale cold-launch latency by up to 66.5% (e.g., 2s→690ms). Unlike prior systems that sacrifice background responsiveness, AppFlow sustains 95% of launches within 1s over a 100-day test, even under 1.29× higher concurrency. These gains come from 2.35× higher I/O throughput
2018
2019
2020
2021
2022
2023
2024
2025
Figure 1: Over the past few years, the share of GB-scale apps in the Google Play top 10 has grown markedly, alongside a rapid surge in DRAM prices. and 67.9% lower memory pressure (measured by the number of kernel direct reclaims). Our main contributions are summarized as follows. • To our knowledge, this is the first to jointly optimize GB-scale cold launch and multitask survivability. It achieves sub-second latency (the usability cliff) for 95% launches and relaunches. • We design AppFlow, a system-wide scheduling framework that leverages the predictable app access patterns to unify selective file preloading, adaptive memory reclamation, and context-aware process killing. • Experiments show that AppFlow significantly reduces GB-scale cold launch latency and improves background survivability with higher I/O throughput and more efficient reclamation, compared to state-of-the-arts.
2 Background and Motivation 2.1 Primer of App Launch Processes Fast app launch is essential for user experience [23, 36, 38, 40], especially for GB-scale, memory-hungry apps (e.g., mobile games, LLM-powered apps) that suffer significant cold launch latency from hardware I/O and memory constraints. We note that prior studies [30] show that app launch delays over 1s is a usability cliff, leading users to suspect network or system failures. To systematically analyze app launch bottlenecks, we first summarize its fundamental mechanisms, costs, and the underlying hardware and OS limitations. 2.1.1 The Trend of GB-Scale Large Mobile Apps. Over the past ten years, apps on the Google Play Store have grown markedly in size [39, 44, 46]. Eight of the top-10 popular apps exceed 1GB [2, 39], and about 30% of the top 100 apps are over 1GB. These GB-scale apps include three main types. i) On-device AI apps, such as LLM-powered assistants [7] and image-to-text generators [45], run AI models locally for private and low-latency inference, driving up RAM usage. ii) Rich media apps, e.g., video editors CapCut [4] and streaming platforms TikTok [42], embed high-resolution and multimodal inputs that push memory footprints. iii) Mobile games, e.g., graphically intensive titles like PUBG Mobile that load large 3D assets, tend to incur substantial memory footprints. 2.1.2 GB-scale Large App Cold-Launch Problems. Mobile apps typically launch in three modes, i.e., cold, warm, and hot
Flash
libUE4.so
…
PUBG.apk
DRAM
Flash
libUE4.so
PUBG.apk
…
DRAM
libUE4.so
PUBG.apk
…
Hot launch: 66ms
Cold launch: 1679ms
Create app process
Warm launch: 650ms
Stop app process
Create app process
Figure 2: Illustration of GB-scale app launch progress. Cold launch 2000
Warm launch
Hot launch
User-acceptable latency threshold
1000 39
41
74
30
164
52
55
103
50
31
150
90
81
VL we M n2 (G .5 em ) m a) G oo Tem gl eE u ar Tw th itt er U b Bo er o R king ed N ot Ti e kT C ok ap cu Ti t Ph nd ot er os ho p Sn ow R ob lo PU x BG
5 0
Launch time(ms)
50
GB-scale apps
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
(Q
10
M
DRAM price/GB ($)
LL
Top10 app memory usage (GB)
DRAM price/GB ($)
GB-scale app percent (%)
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
Figure 3: Illustration of launch latency across cold, warm, and hot modes for 15 popular GB-scale apps. launch, and each mode feels different to the user. As shown in Fig. 2, in a hot launch, the app is already in RAM with all its data ready, so it launches almost instantly. A warm launch happens when the app process has been stopped but its cache remains; it launches more slowly than a hot launch but still fairly quickly [6]. In a cold launch, nothing is in memory, so the system must load the APK file ( e.g., PUBG.apk) and shared libraries (e.g., libUE4, etc.) from Flash into DRAM, making it the slowest [29]. We run tests on a Pixel 8 smartphone using 15 GB-scale apps across three modes and find that 33% cold launches often take more than 1s (see Fig. 3). Two main factors drive this delay. First, cold launch issues dozens of I/O requests that contend for limited mobile DRAM bandwidth, slowing each read. Second, mobile users often run multiple GB-scale apps (e.g., video players TikTok [42], or LLM-based assistants Google AI Edge Gallery [7]) until RAM is full or the battery runs out. To ensure memory for a new app, Android/Linux either kills background processes [1] or reclaims cached pages [11], turning potential hot launches into warm or cold ones. The persistent rise in DRAM prices [5, 15, 43] poses a significant constraint on memory expansion (see Fig. 1), making it difficult to increase the number of apps that can be kept in the active state for hot launches. Existing study [14] shows mobile devices can keep about 20 apps active, yet the typical user has around 80 apps installed [3], resulting in a cold launch for 75% apps, highlighting how often cold launches occur and their impact. Moreover, frequent multitask switch makes cold launch delays more problematic. For example, if a user switch from TikTok to Line and back, both apps load instantly only if they remain in RAM, otherwise each load is a slow cold launch.
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
Several systems [14, 19, 28] use aggressive memory management strategies to maximize the number of hot-launch apps. However, typical mobile DRAM holds just three GB-scale apps at once. Keeping state and caches for too many large apps and background services exceeds this limit. 2.1.3 Mobile Memory Management. Efficient memory management is critical to securing memory space (i.e., DRAM) for new launches and reducing cold-start delays of GB-scale apps on constrained mobile devices. Mobile OS typically employ two memory management strategies: i) memory reclamation [26] (discarding file-backed pages and swapping anonymous pages to free RAM) and ii) process killing [29] (terminating background apps). Specifically, when free RAM drops below a threshold, the kernel’s reclamation process (kswapd) runs a two-phase cleanup: i) discard file-backed pages (code/resources) that can be reloaded later [40]. ii) swap anonymous pages to the Flash before freeing RAM [18, 25, 27]. However, writing to flash is slow. Limited I/O bandwidth on mobile devices always causes reclamation to lag behind allocation, especially under high memory pressure. In our test (Fig. 4), launching a new app with ten apps in the background takes up to 2.2× longer than with no background apps, causing 86.6% of launches to exceed 1s. If reclamation and swap can’t free enough RAM, due to limited swap space or heavy memory pressure, the OS will kill background processes to reclaim their entire working sets. While this ensures memory space for the new app, it forces killed running apps into cold launches on next use, degrading user experience. To further reduce cold-launch delays, file preloading [31, 33, 47] is an orthogonal technique. By loading critical binaries and data into memory before [31] or during launch [33], the system can overlap I/O with other tasks and shorten launch time. However, it is non-trivial to speed up memory reclaim for fast cold launches while keeping background apps hot.
2.2
Observation
This subsection presents our key observation, revealing opportunities for optimization.
372
478 108
58
476 59100
27 69
130 48
304 118
135
482
390 103
134
108
147
133
195 74
148 61
(b) Sizes of large vs. small files
2302
2000
570
1807
23
20
169 19
157
5
224
1
315
1
358 18
445 19
472 18
549
524 7
23
572 20
682 19
221 15
341 2
W EN EM ) M A) G oo Tem gl eE u a Bo rth ok in g T Ph ind ot er os h R op ed N ot Tw e itt er Sn ow Ti kT o C k ap cu t U be R r ob lo PU x BG
0
M
(G
File number
62
0
(Q
File size (MB)
466
LL M
Figure 4: Impact of memory availability on app launch time: comparing cold-launch latencies with 10 background apps (<1GB free memory) vs. no background apps (>2GB free).
1002
1000
VL
LL
1000 0
Figure 5: During GB-scale large app launch, smallfile(≤128 KB) accesses outnumber large-file(>128 KB) accesses by 4.7× yet occupy just 2.2% of their memory. Bandwidth(MB/s)
User-acceptable latency threshold
Small files (a) Counts of large 1189 vs. small files
1000 500 0
4
8
16
32
64
128
256
512 1024 2048 4096 8192
I/O block size(KB)
Figure 6: I/O bandwidth varies with I/O block sizes. File pages size (MB)
4000
Large files
w/ memory pressure
Launch time(ms) M (Q VL we M n2 (G .5 em ) m a) G oo Tem gl eE u ar t Tw h itt er U Bo ber ok R ing ed N ot Ti e kT o C k ap cu T t Ph ind ot er os ho p Sn o R w ob lo PU x BG
w/o memory pressure
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
1000 0
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12C13C14C15C16 User workloads
Figure 7: Diverse file page sizes across 16 representative user workloads [41]. For example, C1 is a meal booking scenario, typically occurring in the afternoon, where users launch both social apps like WhatsApp and media apps like TikTok. 2.2.1 Idle I/O and Hot-set File. As mentioned above, efficient preloading can hide cold launch I/O latency. Towards it, we have three findings. First, we empirically find that 97.2% of cold-launch I/O waits across 24 apps involve predictable static data (e.g., UE4 [34] engine assets or LLM weights). Crucially, we observe that 79% of DRAM I/O bandwidth remains unused during app switches. This indicates the existence of idle windows that are ideal for preloading. Second, we also profile fifteen GB-scale apps over ten launches each, the results show that GB-scale apps actually depend on many small hot-set files whose total size is small. For example, as shown in Fig. 5, 1,002 small files are accessed during the TikTok [42] launch, which is 7.47× the number of large files. While they occupy only 23MB of memory, which is just 4% of the memory used by large files. Third, scaling up I/O blocks boost throughput for big files but waste bandwidth on small ones, while scaling down blocks suit tiny files yet limit throughput and add latency. Tuning I/O block size in a structured manner can boost I/O throughput significantly (see Fig. 6).
I/O throughput (MB/s)
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
750
6.4 ×
500 250
0 Ample memory, no reclamation Ample memory, active reclamation
Low memory, active reclamation Low memory, no reclamation
(a) Preload I/O throughput.
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
• I/O contention: When reclaiming anonymous pages, the reclamation increases I/O write traffic that competes with preload reads. • Page eviction: When reclaiming file-backed pages, the reclamation may evict preloaded pages, forcing apps to re-read them during launch.
(b) I/O latency.
Figure 8: Analysis of preload-reclaim interference. (a) memory reclamation reduces the throughput of preloading; (b) reclaiming preloaded files results in a 6.4× longer I/O latency during GB-scale app launch.
2.2.2 Page-varying Reclamation Cost. Reclamation cost varies by page type. Anonymous pages are expensive to reclaim, as they require I/O writes to Flash (e.g., swap_writepage()), while file-backed pages are cheap to reclaim, as they can be dropped without writes. Existing reclamation strategies alternate evenly between them, but this interleaving forces the system to wait for expensive writes before freeing cheap pages. Moreover, our analysis of 16 typical user workloads [41] (see Fig. 7) reclaimable file-backed pages often exceed 1000 MB, regardless of nonlinear growth in social apps or linear growth in media apps. Observation: Different page types require distinct reclamation strategies. Dropping file-backed pages first under high memory pressure frees memory instantly, avoiding I/O delays. Anonymous page writebacks can then be handled after peak demand, ensuring faster memory reclamation. 2.2.3 Temporal Killing Impact. When memory reclamation alone cannot free enough RAM, the OS’s low-memory killer (LMK) may terminate background processes to secure memory space. However, this blunt approach causes problems. First, killing apps that users may re-open quickly disrupts workflow. Existing user behavior studies report that 92.5% of apps are re-accessed within 30 minutes [41], yet LMK still kills 62% of these high-probability apps, causing duplicate I/O and expensive cold relaunches. Second, mobile users tend to focus on certain app categories at diverse time (e.g., productivity tools in the morning, media apps in the evening). Observation: Integrating the temporal locality into kill decisions can significantly cut unnecessary kills, saving I/O and reducing user discomfort. 2.2.4 Preload–Reclaim Interference. Cold launch delays for GB-scale apps arise from two tightly coupled bottlenecks, i.e., limited I/O bandwidth slows critical file reads, and low free memory blocks both new allocations and preloading. Speeding up cold launch means loading files and freeing RAM at the same time, yet these two actions often compete and cut each other’s gains. It mainly comes from two areas:
To quantify their interference, we first test I/O throughput under four memory conditions: i) ample memory, no reclamation; ii) ample memory, active reclamation; iii) low memory, active reclamation; and iv) low memory, no reclamation ( Fig. 8a). I/O throughput is worst in case (iv) because stalled allocations leave the storage under-utilised. Even with ample memory, turning on reclamation (case ii) still cuts throughput as write traffic from anonymous-page reclaim competes with pre-load reads. We next measure the extra I/O latency after pre-loading to quantify their interference in terms of page eviction, under both ample- and low-memory conditions (Fig. 8b). With low memory, launch-time I/O latency jumps by 6.4×, showing that many preloaded pages are evicted during reclaim and had to be re-read. Observation: Without proper coordination, memory reclaim and pre-loading can negate each other’s benefits. This observation suggests that predictable launch-time dependencies are necessary but insufficient. Preloading must be coordinated with reclamation to reduce contention and avoid immediate eviction, motivating a system-wide scheduler that (i) exploits idle I/O windows, (ii) prioritizes hot-set files under memory limits, and (iii) reclaims without negating preloading gains.
3 Overview 3.1 Problem Formulation Our goal is to minimize the cold-launch latency for GB-scale apps while ensuring relaunch of background apps sharing the same I/O and memory resources completes within 1𝑠 (a known responsiveness threshold [30]), i.e., every 𝑇𝑖 < 1, to maintain a smooth user experience. The cold launch latency 𝑇𝑖𝑐𝑜𝑙𝑑 is decomposed as: 𝑇𝑖𝑐𝑜𝑙𝑑 = 𝑇𝑖𝐼 /𝑂 + 𝑇𝑖
𝑐𝑝𝑢
+ 𝑇𝑖𝑎𝑙𝑙𝑜𝑐
(1)
where 𝑇𝑖𝐼 /𝑂 represents the data load time from Flash to DRAM, the primary component of launch time for each 𝑐𝑝𝑢 app. 𝑇𝑖 is the app initialization time, and 𝑇𝑖𝑎𝑙𝑙𝑜𝑐 represents the memory allocation time, which depends on the system’s 𝑐𝑝𝑢 available memory during app launch. Since 𝑇𝑖 depends on each app’s internal initialization logic, which we cannot modify at the system level, thus we target the reduction of the I/O and memory delays. On mobile devices, the total
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
Flash
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
3.2
GB-scale app files
File-backed page reclaimer
Protect preloaded files
① Selective Fine-Grained File Preloader
DRAM
Maximize reclaim efficiency
During-launch
②Adaptive Memory
Before-launch
Page-level
Reclaimer Re-balance memory pages
App-level
Anonymous page reclaimer
Launched apps
③
…
Context-Aware App Killer
Figure 9: Workflow of AppFlow. memory usage can be expressed as: ∑︁ ∑︁ 𝑀 = 𝑀 𝑠𝑦𝑠 + 𝑀 𝑎𝑣𝑎𝑙 + 𝑝𝑖 + 𝑚𝑗
(2)
𝑗∈J
𝑖
where 𝑀 𝑠𝑦𝑠 is system usage (e.g., the UI rendering engine), and 𝑀 𝑎𝑣𝑎𝑙 is the available RAM for allocation. 𝑝𝑖 is the memory preloaded for app 𝑖 to be launched. J is the background apps, and 𝑚 𝑗 is the memory occupied by each app 𝑗 ∈ J . As𝑓 𝑖𝑙𝑒 sume app 𝑖 must read 𝑀𝑖 bytes of files and allocate 𝑀𝑖𝑠𝑢𝑚 bytes of RAM during launch. Let 𝑣 𝐼 /𝑂 be the I/O throughput and 𝑣 𝑟𝑒𝑐 the memory-reclamation throughput, which depend on I/O block size and available memory, respectively (refer to Sec. 2.2). Then the two key sub-latencies become: 𝑓 𝑖𝑙𝑒
𝑇𝑖𝐼 /𝑂 =
𝑇𝑖𝑎𝑙𝑙𝑜𝑐 =
𝑀𝑖
− 𝑝𝑖 (3)
𝑣 𝐼 /𝑂
𝑀𝑎𝑥 {(𝑀𝑖𝑠𝑢𝑚 − 𝑀 𝑎𝑣𝑎𝑙 ), 0} 𝑣 𝑟𝑒𝑐
(4)
Here, 𝑝𝑖 , 𝑀 𝑎𝑣𝑎𝑙 , 𝑣 𝐼 /𝑂 , and 𝑣 𝑟𝑒𝑐 are the design variables we can tune to improve launch performance. We define the feasible design space F by: F = {(𝑝𝑖 , 𝑀 𝑎𝑣𝑎𝑙 , 𝑣 𝐼 /𝑂 , 𝑣 𝑟𝑒𝑐 ) | C1, C2} ∑︁ ∑︁ C1: 𝑀 𝑠𝑦𝑠 + 𝑀 𝑎𝑣𝑎𝑙 + 𝑝𝑖 + 𝑚 𝑗 ≤ 𝑀, 𝑖∈I cpu
C2: 𝑇𝑖
(5) (6)
𝑗∈J
+ 𝑇𝑖 (𝑝𝑖 , 𝑀 𝑎𝑣𝑎𝑙 ) ≤ 1𝑠, ∀ 𝑖 ∈ 𝑎𝑝𝑝 𝑠𝑒𝑡 J .
(7)
The combined I/O and allocation latency is: 𝑓 𝑖𝑙𝑒
𝑇𝑖 (𝑝𝑖 , 𝑀
𝑎𝑣𝑎𝑙
)=
𝑀𝑖
− 𝑝𝑖
𝑣 𝐼 /𝑂
+
𝑀𝑎𝑥 {(𝑀𝑖𝑠𝑢𝑚 − 𝑀 𝑎𝑣𝑎𝑙 ), 0} (8) 𝑣𝑟𝑒𝑐
With the trend of GB-scale apps on memory-limited devices (see Sec. 2.1.1), 𝐶1 tightly bounds 𝑝𝑖 and 𝑀 𝑎𝑣𝑎𝑙 . Ensuring every running app in J meets the sub-1s launch bound under these tight memory limits (𝐶2) makes the interactive tuning of 𝑀 𝑎𝑣𝑎𝑙 , 𝑣 𝐼 /𝑂 , and 𝑣 𝑟𝑒𝑐 extremely challenging.
Solution Overview
To address above intractable problems, we propose AppFlow, a system-wide memory scheduling framework tailored for mobile devices. As shown in Fig. 9, AppFlow comprises three tightly-coupled components operating at different granularities and optimization dimensions, i.e., preloading, reclamation, and killing, forming a comprehensive solution. In particular, the Selective File Preloader (file-level) proactively utilizes available free memory and I/O to preload critical file pages, reducing cold-start latency by up to 55.2% (see Sec. 4.1). When free memory runs low, the Adaptive Memory Reclaimer (page-level) keeps preloader efficiency by reclaiming clean pages from background apps at a rate tuned to real-time I/O load, while tagging and skipping the pages just fetched to avoid wasteful reloads (see Sec. 4.2). Also, the proposed Reclaimer is preloader-aware, which deliberately skips pages the Preloader has just loaded, preventing costly reloads. When proactive trimming still falls short, AppFlow activates the Context-Aware App Killer (process-level), that goes beyond Android’s LRU list. It targets long-running, memory-bloated apps whose relaunch footprint returns to baseline, avoiding repeat kills and cutting cold-launch time by 29.8% in long-term tests (see Sec. 6.6). Together, they enable AppFlow to maintain fast launch of GB-scale large apps even under tight memory pressure and high concurrency. As we will show in Sec. 6, AppFlow reduces cold launch latency by up to 66.5% across three categories of GB-scale large apps while improving background concurrency by 2.6×. Moreover, AppFlow sustains 95% of launches within 1s over a 100-day test, demonstrating that a system-wide memory scheduler that jointly orchestrates preloading, page reclamation, and process killing is critical for mobile responsiveness.
4 System Design 4.1 Selective File Preloader Modern GB-scale apps on DRAM-constrained mobile devices frequently stall on blocking I/O during cold launches, such as CPU tasks wait for file reads from flash to DRAM. As mentioned in Sec. 2.2.1, preloading can fill these gaps, but to avoid excessive memory use, we must carefully decide when (timing), what (which files), and how (scaling I/O block size) to preload. By tuning these three dimensions, we can overlap I/O with idle periods. Limitations of Existing Methods. Prior efforts struggle to balance launch speed and memory efficiency. First, preloading before launch loads all required files in advance [13, 31, 47], eliminating I/O delays but incurring high memory usage, which is often unacceptable on mobile devices. For example, as shown in Fig. 10a, preloading just three popular apps, e.g., PUBG (0.5 GB), Genshin (0.43 GB), and Gemini (1.8 GB), requires approximately 3GB of memory, while Pixel 8 phone
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
R
Flash reading
Large memory consumption
C1
Application
C2
C
Computation
C3
C4
Time
App launch R3
R2
R1
Preloading
Time
(a) Before-launch preloading Application Preloading
C2
C1
C4
C3
Long launch time
Time
App launch R2-1 R3
R1
R2-2
Time
(b) During-launch preloading
Preloading
C2
C1
Application
C3
C4
Time
App launch R1
R3
R2
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
constrained memory budget. It preloads all small files (<𝑠𝑖 , decided by each app 𝑖) and frequently accessed hot segments of large files. These files add minimal memory overhead but eliminate high-frequency I/O stalls. • During launch, throughput-first. Once the app starts, this stage aggressively loads large files using large block size (≥ 𝑠𝑖 ) to maximize I/O throughput of large files. However, overlapping with foreground I/O poses a new challenge, i.e., I/O contention between the preloader and the app itself. To address this, we run the preloader as a separate low-priority, separate process, ensuring that it never blocks or delays foreground I/O requests. Selecting the optimal app-specific cut-off size 𝑠𝑖 that separates small (< 𝑠𝑖 ) from large files is necessary yet challenging. A large 𝑠𝑖 raises prelaunch memory use, while a smaller 𝑠𝑖 leaves too many small files unpreloaded, throttling I/O during launch. We pose 𝑠𝑖 selection as a discrete optimization:
Time
(c) Our selective file preloader
𝑓 𝑖𝑙𝑒
arg min𝑇𝑖𝐼 /𝑂 =
Figure 10: Illustration of diverse preloading methods.
𝑠.𝑡 .
𝑀𝑖
− 𝑝𝑖
𝑣𝑖𝐼 /𝑂
,
𝑝𝑖 = 𝑃 (𝑠𝑖 ),
𝑣𝑖𝐼 /𝑂 = 𝑉 (𝑠𝑖 )
∑︁ 𝑝𝑖 ≤ 𝑀𝑝 𝑖
typically allocates only less than 1GB for preloading [29]. Second, preloading during launch conserves memory by loading files on demand at runtime, but still suffers from I/O bottlenecks when file access lags behind CPU execution. As shown in Fig. 10b, the computation steps C3 and C4 are significantly delayed due to the long I/O time of R2 and R3. These limitations call for a fine-grained approach that aligns preload timing with file characteristics. Actually, GBscale apps’ launch-critical files include two types: i) Small but frequent files (e.g., <128KB) contribute minimal memory overhead but cause frequent random I/O if not preloaded early. ii) Large and I/O bandwidth-intensive files (e.g., ≥128KB), whose loading time depends on I/O bandwidth. Preloading them improves performance, but consumes significant memory. As discussed in Sec. 2.2.1, small, frequent files dominate launch I/O (91%) in GB-scale apps, and their footprint is modest (≈3% of the total; see Fig. 5). Moreover, we find that the I/O bandwidth of large files with large block size (i.e., ≥128KB) can be up to 22.8× faster than with small block size. (Fig. 6). Based on these, to reduce launch latency without exceeding memory limits, we introduce a time-split, file-and-apptype-aware preloading strategy with two phases. The key idea is to preload I/O frequency-intensive files before launch with small I/O block size, to reduce latency-critical blocking with minimal memory overhead, and preload the remaining large files during launch with large I/O block size, to maximize I/O efficiency under time constraints. Specifically, AppFlow employs two complementary strategies: • Before launch, frequency-first. This stage focuses on loading as many frequency-intensive small files as possible within a
where 𝑃 (𝑠𝑖 ) is the size of files below 𝑠𝑖 (preloaded), and 𝑉 (𝑠𝑖 ) is the achieved I/O bandwidth when streaming the remaining files. Both 𝑃 and 𝑉 increase with 𝑠𝑖 . Since I/O block sizes are powers of two (i.e., 4KB, 8KB, etc.), we profile 𝑃 and 𝑉 only at these discrete sizes. We cast the selection as a multiplechoice knapsack: each app picks one precomputed 𝑠𝑖 under the preload budget 𝑀𝑝 (set as 100MB, see in Sec. 6.5.1). The instance is small, solved in < 0.1ms (see Sec. 6.5.3); we reoptimize 𝑠𝑖 only when an app’s launch profile changes (e.g., a GB-scale large app launched), so runtime overhead is negligible and configurations remain near optimal.
4.2
Adaptive Memory Reclaimer
Even with preload optimization, insufficient memory availability can still block launch, particularly when the system must reclaim memory before fulfilling new allocation requests. To address this, this module shifts focus to reducing the application’s memory allocation time 𝑇 𝑎𝑙𝑙𝑜𝑐 while avoiding the degradation of preloading efficiency under mobile memory constraints. As discussed in Sec. 2.1.2, when available memory 𝑀 𝑎𝑣𝑎𝑙 is sufficient, 𝑇 𝑎𝑙𝑙𝑜𝑐 is negligible. When 𝑀 𝑎𝑣𝑎𝑙 is low, memory allocation requests during launch may be blocked until the system reclaims enough memory. Thus, 𝑇 𝑎𝑙𝑙𝑜𝑐 is primarily determined by the memory reclamation speed 𝑣 𝑟𝑒𝑐 . Formally, 𝑠𝑢𝑚 𝑎𝑣𝑎𝑙 this can be approximated as 𝑇 𝑎𝑙𝑙𝑜𝑐 = 𝑀𝑎𝑥 { (𝑀 𝑣𝑟𝑒𝑐−𝑀 ),0} . 𝑠𝑢𝑚 Here, 𝑀 is the app’s total memory demand during launch. Preliminary of Prior Arts. Android/Linux-based mobile systems (e.g., smartphones, wearables, robotics) rely on
MobiCom ’26, October 26–30, 2026, Austin, TX, USA DRAM
F A…A F F…F A A… A
3
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
Standard reclaimer
_alloc_pages_nodemask() with a simple counter polled periodically (e.g., every 100ms), we compute 𝑛 alloc , the pages allocated in the last interval. We classify a phase as memory-sensitive if
Flash Preload-aware page retention
Efficiency-first mode
𝑀 𝑎𝑣𝑎𝑙 < 𝑀 𝐹
1 File-backed page
2 Anonymous page
reclaimer
reclaimer
Rebalancing mode
A
Anonymous page
F
File-backed page
Figure 11: Adaptive memory page reclaimer. Table 1: Anonymous (Anon.) and file-backed (File.) memory sizes (MB) across diverse GB-scale large apps. Types Multi media
Apps Photoshop Snow RedNote Tiktok
Anon. 636 679 778 616
File. 379 370 403 434
Types On-device V/LLM Game
Apps Qwen2.5 Gemma PUBG Roblox
Anon. 307 710 636 856
File. 1637 1925 392 281
the kernel’s background reclaimer thread kswapd, to free memory when 𝑀 𝑎𝑣𝑎𝑙 is low, during which the app launch is blocked. kswapd targets two main types of memory pages, i.e., file-backed pages, which are mapped from Flash, and anonymous pages, which are dynamically generated during runtime. kswapd evenly alternates between these two types, attempting to free roughly balanced file-backed and anonymous pages. However, we observe that this is inefficient under high memory pressure due to their fundamental heterogeneity and asymmetry in reclamation cost (see Sec. 2.2.2). As shown in ③ of the Fig. 11, evenly alternating reclaim blocks fast file-backed pages reclamation behind slow anonymous page handling. 4.2.1 Page-type-aware Memory Reclamation. To boost memory reclaim efficiency, we decouple file-backed and anonymous page reclamation. During cold launches, we first reclaim only file-backed pages, freeing RAM instantly without extra I/O or CPU overhead, to boost 𝑣 rec and cut allocation latency 𝑇 alloc . However, we observe that since most GB-scale large apps produce on average 1.92× more anonymous pages than file-backed pages (see Tab. 1), favoring file pages alone leads to reclamation starvation, where only anonymous pages remain and allocations stall. We therefore introduce an adaptive, page-type-aware strategy that switches modes based on runtime pressure: i) in high-pressure phases (e.g., cold launch), AppFlow reclaims only file-backed pages for maximum speed; ii) otherwise, reclaims anonymous pages to clear costly regions ahead of future bursts. The key challenge is detecting high-pressure windows without app changes or developer input. We leverage kernel’s page-allocation rate as an effective, low-overhead, and app-agnostic signal. By instrumenting
& 𝑛𝑎𝑙𝑙𝑜𝑐 > 𝑁 𝑎𝑙𝑙𝑜𝑐
Here, 𝑀 𝐹 is system-specific threshold, 𝑁 alloc is set as 12800 (Sec. 6.5.1), and 𝑀 𝑎𝑣𝑎𝑙 is the current free RAM. Upon detecting a memory-intensive condition, AppFlow switches to the efficiency-first mode that reclaims only file-backed pages (① in Fig. 11). When the pressure subsides, it shifts to a rebalancing mode that restores the normal file-to-anonymous reclamation ratio (② in Fig. 11). Finally, AppFlow falls back to the standard reclamation method (③ in Fig. 11). This fully automated, multi-phase controller runs with negligible overhead and requires no app changes, making it practical for deployment. 4.2.2 Preload-aware Page Retention. Reclaiming only filebacked pages during launch can evict preloaded data before it is used. To keep those pages in RAM until the app actually uses them, we introduce a preload-aware retention strategy that treats the two preload phases differently. The key idea is that each preload phase has different retention needs. The files fetched before launch are few and need only a short residency; we keep them alive by lightly touching their pages every ten seconds, a scan that takes about 10 ms and adds just 0.1% overhead. Once the GB-scale large app becomes active, those pages are dropped from future scans and can be reclaimed. By contrast, the files fetched during launch are far more numerous, making periodic scans too costly. Instead, we run a preload-file check in the memory-reclaim path shrink_page_list. If a page maps to a preloaded file, the reclaimer skips it and marks it active to avoid rescanning. The Selective File Preloader publishes the preloaded-file list via /proc and clears it after the app launch completes. As a result, preloaded pages remain in DRAM until the launch finishes and are not evicted prematurely. Algorithm 1 shows the pipeline. Every 100ms, AppFlow reads 𝑛 alloc and 𝑀 𝑎𝑣𝑎𝑙 , then chooses the file-only or full reclamation policy (lines 4). During the file-backed pages reclamation, AppFlow avoids reclaiming the preloaded pages (lines 5). Once the file-backed page reclamation completes, the anonymous page reclaimer is invoked to rebalance the page type ratio (lines 6). As we will demonstrate in Sec. 6.4.2, this adaptive scheme enables both rapid memory recovery and balanced long-term reclamation, preventing anonymous-page buildup and avoiding starvation, thereby reducing launch latency and the frequency of cold launches.
4.3
Context-Aware Process Killer
Even with adaptive page reclamation (Sec. 4.2), systems sometimes resort to process killing when only anonymous
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
Algorithm 1 Adaptive Memory Reclaimer thresholds every 100ms update 𝑛𝑎𝑙𝑙𝑜𝑐 ← AllocRate(). 2: for each allocation event do 3: 𝑀 𝑎𝑣𝑎𝑙 ← FreeMem() 4: if 𝑀 𝑎𝑣𝑎𝑙 < 𝑀 𝐹 ∧ 𝑛𝑎𝑙𝑙𝑜𝑐 > 𝑁 𝑎𝑙𝑙𝑜𝑐 then 5: ReclaimFilePages(exclude protected files) 6: ReclaimAnonPages() 7: end if 8: end for
Worse case
Relaunch
𝑁 𝑎𝑙𝑙𝑜𝑐 ;
Available memory Current
Low memory kill
Memory occupation
Memory occupation
1: Init:
𝑀𝐹 ,
Better case
Current
Available memory
Relaunch
Low memory kill
Application running time
Application running time
(a) Kill recently-used app
(b) Kill long-running app
Figure 12: Illustration of diverse killing methods. pages remain. Two common scenarios cause problematic anonymous-page dominance, forcing inefficient fallback. • Burst allocations. During large, repeated allocations, e.g., LLM inference, systems defer anonymous page writes (5× slower than dropping file pages), so anonymous pages accumulate. In our analysis of three categories app traces (Sec. 4.2), peak anonymous-to-file ratios are 1.92:1, exhausting file pages and leaving only anonymous pages to reclaim. • Reclaim capacity limits. Anonymous-page reclamation itself is bounded, either by swap partition size (e.g., 2GB on Pixel 8) or by zRAM capacity (25∼30% of DRAM). Once this bound is reached, anonymous reclamation stalls, and the system falls back to dropping file pages to run out of file pages and trigger process kills. These scenarios are unavoidable as anonymous pages grow with app activity. A clever killer must therefore factor in both the current page-type imbalance and reclaim capacity limits to avoid unnecessary terminations and preserve both performance and stability. Limitations of the Kernel LMK. When only anonymous pages remain, Android/Linux invokes the low-memory killer (LMK), terminating apps in background-to-foreground order. As mentioned in Sec. 2.2.3, each kill forces a full cold relaunch, often over 2 seconds for apps like PUBG [32], then immediately recreates memory pressure (e.g., freeing 1200MB but needing 1100MB on relaunch, as shown in Fig. 12a), trapping the system in a kill–restart loop. This is because LMK’s blind selection ignores an app’s restart cost, reaccess likelihood, and net memory benefit.
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
We introduce a novel, context-aware app killing mechanism that leverages two runtime patterns, i.e., long-term background bloat and short-term recency. Specifically, we find that long-running apps (e.g., social media apps) grow their memory footprint by 30∼50% over baseline state (i.e., the minimal memory used immediately after launch before any runtime cache) yet revert to baseline state on relaunch because the process clears all accumulated caches and temporary allocations. By harnessing this bloat-and-reset phenomenon, AppFlow prioritizes reclaiming from these apps to secure large and reliable memory. Conversely, recently used apps pair high reuse probability with elevated memory footprints. Rather than kill them following heuristics, we defer termination to avoid the large memory allocation brought by relaunch. As shown in Fig. 12b, AppFlow orders kills by net freed memory metric Δ𝑀 = 𝑀 current − 𝑀 relaunch, ensuring each kill maximizes lasting memory recovery without penalizing stable apps. For recent apps, it switches to recency-aware deferment, overlapping preloading with reclamation idle phases. As we will show in Sec. 6.4.2, this two-phase strategy reduces 30% kill events, balancing aggressive memory recovery with seamless interaction.
5
Implementation
We implement AppFlow on Android, one of the most widely used mobile operating systems. The Android OS is typically organized into three layers: the application layer, the Android framework, and the Linux kernel. AppFlow is a memory management mechanism that spans both the Android framework and the Linux kernel. It makes no modifications to the application layer, allowing GB-scale apps to benefit from its acceleration without any code changes. Specifically, the Selective File Preloader and the Context-Aware Process Killer modify 1,672 lines of the Android Framework to control preloading and process killing, while the Adaptive Memory Reclaimer modifies 1,107 lines of the Linux kernel to manage memory reclamation. Since the Adaptive Memory Reclaimer must avoid reclaiming files preloaded by the Selective File Preloader, the two modules communicate via the /proc filesystem.
6 Experiment 6.1 Experiment Setup Platforms. We prototype AppFlow on two commercial smartphones (Google Pixel 7 and Pixel 8) and an in-vehicle system powered by the vehicle with a Raspberry Pi 4B handling computation, all running the latest Android 15 operating system (OS) [9]. To emulate memory-constrained low-end mobile devices, we scale the visible DRAM of both smartphones to 6GB and 8GB by modifying arm64_memblock_init(). And the vehicle DRAM is 4GB by default.
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
• Android OS [9] performs memory reclamation without any preloading. This provides the fundamental system baseline. • Paralfetch [33] is a state-of-the-art preloading method that improves launch speed by scheduling I/O sequences to merge small blocks into larger ones. • Acclaim[26] is a state-of-the-art reclamation method that accelerates memory reclaim by enlarging batch sizes, thereby reducing both the frequency and latency of cold launches under high-load conditions. • Acclaim + Paralfetch combines the above SOTA techniques. Since, to the best of our knowledge, no joint optimization exists, this baseline demonstrates the limitation of naïve combination. Metrics. We evaluate AppFlow with (i) user-perceived metrics, i.e., cold-launch latency and frequency of GB-scale apps, captured via adb command [8]; and (ii) intermediate metrics,
Android OS
Acclaim
Paralfetch
Acclaim+Paralfetch
AppFlow
Low workload
2500
Launch time (ms)
0
Medium workload
2500 0
High workload
2500
ge ra
x lo
Av e
ob R
BG
Ph
PU
ow Sn
ho p ot
ed
os
N
ot
e
To k R
Ti k
em VL m M a G
Q
w
en LLM 2. 5
0
(a) on Pixel8-8GB: with low, medium, high workloads Low workload
2000 0
Medium workload
2000 0
High workload 2000
ge ra Av e
x lo ob R
PU BG
ow Sn
p ho os ot Ph
R
ed
N
ot e
To k Ti k
em VL m M a G
w L en LM 2. 5
0
Q
Tasks and workloads. We evaluate AppFlow using both a real-world 100-day trace and simulation workloads. The real-world 100-day dataset, AppFlow-100D, spans weekdays, weekends, and holidays, covering over 60 apps (e.g., TikTok, WhatsApp, Camera) and 10,000+ multitask switches, thereby capturing representative user workloads. To collect AppFlow-100D, we developed a headless Android application that runs continuously in the background. It utilizes UsageStatsManager to log app-usage sequences for 100 days, after which it automatically terminates and provides a user-facing dashboard allowing participants to review traces before uploading. Strict privacy safeguards are enforced: data is locally minimized, retaining only metadata (package names, timestamps, memory states) while strictly excluding all personally identifiable information and app content. After data collection, we replayed the app switching traces on the same device to evaluate AppFlow. Simulation workloads comprise several GB-scale apps (e.g., Gemma, TikTok, Roblox, etc.) and 15 low-memory apps (e.g., ChatGPT, Instagram, Zoom, etc.). In each test, one GB-scale app is selected for cold-launch under three scenarios: (i) five lowmemory apps (low workload), (ii) fifteen low-memory apps (medium workload), and (iii) fifteen low-memory apps plus two GB-scale apps (high workload). To ensure consistency in the background workload, we first terminate all background apps and clear the file cache. Next, we employ an automated script to launch the load-generating apps and place them in the background. Once the load is established, we execute the am start -W command to launch the target app and measure its launch time. Baselines. To ensure a comprehensive and fair evaluation, we select four representative baselines that span the design space of preloading and reclamation strategies:
Launch time (ms)
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
(b) on Pixel8-6GB: with low, medium, high workloads Figure 13: GB-scale cold launch latency comparison. i.e., I/O throughput and memory-pressure events (direct reclaims, LMK), obtained through logcat [10] or kernel hooks, to capture both user experience and system behavior.
6.2 GB-scale App Cold launch performance We test the cold-launch time of eight GB-scale apps (i.e., LLMbased Qwen2.5-2.0GB, VLM-based Gemma-2.6GB, TikTok1.1GB, Snow-1.1GB, PUBG-1.2GB, etc.) across four baselines and AppFlow on two configurations (i.e., Google Pixel 8 devices with 6GB and 8GB limits), each under three workloads (i.e., low, medium, high workloads as in Sec. 6.1). Fig. 13 shows the results. First, across all device configurations, workloads, and GB-scale apps, AppFlow achieves on average 33.7∼43.6% shorter cold-launch latency than native Android. Second, AppFlow outperforms the state-of-the-art preloading baseline Paralfetch even under low workload, reducing cold-launch latency by 29.2% on average through sustaining higher I/O throughput for GB-scale launches, as shown in Fig. 13a. Third, AppFlow maintains its advantage under memory pressure, reducing launch latency by up to 57% on a memory-constrained Pixel 8 (6 GB) with high workload (Fig. 13b). Fourth, naively combining preloading with reclamation may introduce performance degradation; for example, Paralfetch + Acclaim slows Gemma’s launch by 14.4% over
10
5 0
Pixel 7 (6G)
0
AppFlow
600 400 200 0
Pixel 7 (8G)
Pixel 7 (6G)
600
1500
AppFlow: 972 ms
0
0
AppFlow 2000
500
Paralfetch: 1432 ms Android OS: 1689 ms
600 1200 Time (ms)
1850
0
0
Android OS
Paralfetch: 946 ms
Paralfetch: 1510 ms
Android OS: 1126 ms
450 900 Time (ms)
1350
0
0
Android OS: 2027 ms
700 1400 Time (ms)
2150
Figure 15: I/O throughput and cold-launch latency of three GB-scale large apps: PUBG (left), TikTok (middle), Qwen 2.5 (right).
Paralfetch alone and 4.8% over Acclaim alone under high workload. AppFlow mitigates this by protecting preloaded pages, achieving 56.7% faster launches than the combination. Summary. AppFlow delivers the lowest cold-launch latency across diverse devices, workloads, and app scales, while avoiding pitfalls of naive baseline combinations, showing robustness and applicability in real-world mobile systems.
6.3
0
Avg. launch time
1000
0
Local LM: Qwen 2.5
1000 AppFlow: 717 ms
AppFlow: 794 ms
100
AppFlow
Figure 16: Memory-pressure mitigation comparison: number of kernel DR (left), LMK events (middle), and average launch latency (right).
1000
400 200
Paralfetch Multimedia: Tiktok
100
Acclaim Number of LMK
0
Multitask Performance
We test multitasking performance by comparing AppFlow with Android OS [9], Paralfetch [33], and Paralfetch+Acclaim on Pixel 7 (6/8 GB) under high workload (see Sec. 6.1). Two GB-scale apps(i.e., TikTok-1.1GB, Snow-1.1GB) and 15 lowmemory apps are each launched twice to simulate multitasking switching from other apps; in the second run, we measure the average relaunch latency and cold relaunch counts. Fig. 14 shows the results. First, AppFlow preserves 1.85× more background apps (i.e., from 7/17 to 13/17) and reduces average launch time by 37.6% compared to Android OS by rapidly freeing memory at both app and page levels, thus avoiding frequent LMK events. Second, AppFlow prevents the degradation of preloading: on Pixel 7 (6GB), Paralfetch incurs 20% more cold relaunches than Android OS, while AppFlow achieves 60% fewer. This comes from preloading-induced memory pressure that triggers excessive app killing. Third, AppFlow incurs 42.8% fewer cold launches than Paralfetch+Acclaim by protecting preloaded pages while ensuring reclaimed pages are unlikely to reload. Summary. AppFlow sustains multitask responsiveness under high memory pressure, reducing relaunch overheads.
Launch time(ms)
I/O throughput (MB/s)
Android OS
200
Pixel 7 (8G)
Figure 14: Multitasking performance with 17 apps: coldrelaunch count (left) and average relaunch time (right). Game: PUBG
Android OS Number of DR
Relaunch time
w/ AMR
w/ SFP
w/ CPK
1000 0
AppFlow
Cold-relaunch count
GB-scale app launch time Cold-relaunch count
0
Acclaim+Paralfetch 800
Number of LMK
Paralfetch
Number of DR
Acclaim
Cold-relaunch count
Avg. relaunch time (ms)
Cold-relaunch count
Android OS
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
Launch time (ms)
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
10 5 0
Figure 17: Ablation study: GB-scale large app launch time (left) and cold-relaunch count(right).
6.4
Understanding Performance Gains
6.4.1 I/O Throughput During GB-Scale App Launch. We measure I/O throughput during GB-scale cold launches under a low workload on a Google Pixel 8 (8GB) to illustrate how the Selective File Preloader accelerates cold launches (Fig. 15). AppFlow surpasses Android OS [9] and Paralfetch [33] via a two-phase, file- and app-aware preloading strategy: small files are prefetched before launch to reduce blocking, while large files are streamed during launch with larger blocks to maximize I/O efficiency. In Qwen2.5, it achieves 1.92× and 1.58× higher throughput, yielding 29.4%∼64.6% faster launches across diverse GB-scale large apps. Summary. By aligning preloading with file access patterns, AppFlow offers a principled path to scalable cold-launch acceleration. 6.4.2 Memory Reclaim Efficiency During GB-Scale App Launch. To evaluate how AppFlow mitigates memory pressure, we measure kernel direct reclaims (DR), low memory killed (LMK) events, and average launch latency during GB-scale app launches under high workload on Google Pixel 8 (6 GB) (Fig. 16). AppFlow reduces the number of kernel DR by 67.9% compared to Android OS, cutting allocation stalls and launch delays, and lowers LMK events by 33.7%, sustaining more background apps. These gains come from its Adaptive Memory Reclaimer, which accelerates reclamation by selectively targeting pages, and its Context-Aware App Killer, which prevents repetitive LMKs by prioritizing the termination of memory-intensive apps. Summary. By combining finegrained reclamation with intelligent app killing, AppFlow turns memory pressure into efficient resource management, preserving responsiveness under GB-scale workloads.
1000 800 50MB
100MB
1500 Android 15 Linux kernel 5.10 DRAM：4GB Raspberry Pi 4B
1250 1000 750
200MB
(a) Preloading size 𝑀 𝑝
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
6400
12800
25600
(b) Allocate thresh. 𝑁 𝑎𝑙𝑙𝑜𝑐
Figure 18: Impact of hyperparameter in AppFlow. Android (GB-scale)
AppFlow (non-GB)
Android latency
30
AppFlow
10000 5000 0
Contact Map Spotify TikTokAudible
(b) App-launch performance
1500 1250 1000
10
750
0
500
1
2
3
4
5
6
7
8
9
Week
10
11
12
13
14
15
Android OS Text to Text
Image to Text Text to Image
Micro-benchmark
6.5.1 Ablation Study. We evaluate each AppFlow module on Pixel 8 (6GB) to quantify its contribution to cold-launch and multitasking performance (Fig. 17). First, the Adaptive Memory Reclaimer (AMR) cuts cold launches by 60% compared to Android OS, though launch time drops only 14.7%. Second, the Selective File Preloader (SFP) reduces launch time by 26.1% but increases cold launches by 30% due to added memory pressure. Third, the Context-Aware Process Killer (CPK) lowers cold launches by 30% by terminating memory-heavy processes to prevent repeated killings. Fourth. When integrated, these three modules complement each other, delivering a 40.8% reduction in cold-launch latency while sustaining 1.85× more background apps. 6.5.2 Hyperparameter Settings. We explore different hyperparameter settings in AppFlow. First, before-launch size 𝑀 𝑝 . This controls the amount of data preloaded before launch (Sec. 4.1). As shown in Fig. 18a, 𝑀 𝑝 = 100 MB strikes the best balance. Smaller values fail to cover critical small files (6.5% slower), while larger values waste memory and increase launch-time variance. Second, allocate threshold 𝑁 𝑎𝑙𝑙𝑜𝑐 . It determines when the Adaptive Memory Reclaimer is triggered (Sec. 4.2). As shown in Fig. 18b, 𝑁 𝑎𝑙𝑙𝑜𝑐 = 12800 yields the best result; larger thresholds delay reclamation and cause up to 19.9% slowdown during launch. 6.5.3 Extra Overhead Analysis. Despite its benefits, AppFlow introduces two extra overheads, i.e., memory for beforelaunch preloading and CPU time for computing preload sizes. First, memory. Preloading is capped at 100 MB (<5% of DRAM on 4 GB devices), and these pages are reclaimed under pressure, leaving performance unaffected. Second, CPU time occurs only when GB-scale large apps change state (minutes apart); even with 60 apps, computation finishes in <0.1 ms, which is also negligible in practice.
Background apps killed by AGI app
AppFlow latency
20
Figure 19: AppFlow’s performance in a 100-day test.
6.5
Android OS
Figure 20: AppFlow’s in-vehicle performance.
AppFlow (GB-scale)
40
Slowest 5% launch time (ms)
No. of cold launch
Android (non-GB)
(a) In-vehicle testbed
Launch time(ms)
1200
Launch time (ms)
Launch time (ms)
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
10
9
AppFlow
9
8 3 1
0
0 Text to Text
Image to Text
Text to Image
(a) On-device AGI (b) Concurrency performance Figure 21: Performance under AGI workload.
6.6
Case Study
To validate AppFlow ’s practicality and generality, we conduct real-world case studies across diverse scenarios. 100-day multitasking. In everyday use, users habitually switch between social, productivity, and media apps dozens of times a day, creating sustained memory pressure where every second of launch latency affects perceived responsiveness. To capture this, we test a 100-day trace of 60+ real app launches on a Google Pixel 8 (8G), comparing Android OS with AppFlow. As shown in Fig. 19, GB-scale apps accounted for 75.7% of all cold launches experienced by the user. AppFlow cuts average cold-launch latency by 23% and GB-scale cold-relaunch counts by 31.6%, demonstrating AppFlow’s consistent, long-term gains in everyday multitasking. For example, in the third week, while the user is engaging in a travel planning task, the Android system triggers cold launches for TikTok and Rednote, resulting in frequent stuttering. In contrast, with AppFlow, these apps are hot-launched, ensuring a smooth user experience. In-vehicle systems. When a driver starts the car, the infotainment system boots with the ignition, clearing all processes and forcing apps such as navigation or music to launch cold, making cold launch latency directly noticeable. We deployed the latest Android OS 15 and AppFlow on BYD Seal vehicle, equipped with a Raspberry Pi 4B with 4 GB memory (smaller than typical smartphones), powered directly by the vehicle ignition (Fig. 20a), ensuring every launch was a true cold launch. We then measured the cold-launch latency of five popular apps, e.g., TikTok-1.1GB [42](Fig. 20b). AppFlow reduces cold-launch latency by 53.4% (4.3s→2.0s), compared to Android OS. This demonstrates significant benefits in resource-constrained automotive environments, where
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems
system responsiveness directly impacts the user experience upon every vehicle startup. On-device AGI. On-device AGI apps [7, 37] represent an emerging trend, offering offline, privacy-preserving generative intelligence powered by on-device V/LLM models. However, their massive memory footprint severely challenges multitasking. For example, when a user drafts an Instagram post with an image-to-text app and then switches back, Instagram is often killed, disrupting the workflow. To reproduce this scenario, we launched an AGI app followed by background switching on a Google Pixel 8(8G) (Fig. 21). Android OS killed 8∼9 background apps after AGI use, while AppFlow limited this to 0∼3, boosting multitask survivability from 66.6% to 100%. This ensures that after using the on-device AGI service, users can quickly switch to other apps without waiting through a long cold launch. Summary. Across long-term (100-day) daily use, ignitiondriven in-vehicle automotive systems, and emerging ondevice AGI workloads, AppFlow consistently reduces launch latency and prevents cold relaunches, demonstrating robustness across diverse mobile environments and its potential as a foundation for next-generation mobile intelligence.
7 Related Work 7.1 Mobile App Launch Optimization App launch time is a key user-experience metric [13, 23, 30]. Prior work tackles it by either caching more apps for hot launch [16, 28, 31, 47] (via swap space [19, 48], data compression [22, 28]), or speeding up cold launch [24, 26] (via file preloading [6, 33, 47] and faster reclamation [24, 26]). Yet with GB-scale working sets [39], caching fails to cover most apps, making cold launches unavoidable [14], while cold-launch accelerators waste resources by competing for scarce I/O and memory [6, 40]. AppFlow is the first to accelerate GB-scale cold launches while preserving background survivability, by tightly coupling preloading, reclamation, and app killing mechanisms.
7.2
Preloading on Mobile Devices
Preloading falls into two types, i.e., before-launch [20, 21, 31] and during-launch preloading [6, 16, 33] based on the timing of the preload. Before-launch schemes predict the next app a user will open and stage its working set in RAM [20, 21, 31]. For instance, MAPLE [17] prompts an LLM with user context to make that guess, yet its 52% hit rate means every miss wastes hundreds of megabytes and leaves cold-start latency untouched, an unacceptable trade-off for GB-scale large apps. During-launch schemes skip prediction altogether. Once the user taps an icon, they stream the app’s needed pages over idle I/O bandwidth [6, 16, 33]. Identifying those pages is reliable, such as Paralfetch [33] covers 97.2% of them via offline
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
profiling. AppFlow adopts the on-demand during-launch approach, but goes further. It selectively preloads files to boost launch speed with modest memory overhead, while cooperating seamlessly with memory-reclamation mechanisms.
7.3
Mobile Memory Reclamation
Memory reclamation is triggered when free RAM falls below a threshold [35]. Prior work follows two directions: deciding what/when to reclaim (e.g., Acclaim [26] prioritizes background apps [12, 48]) and shortening how long reclamation takes (e.g., SWAM compresses pages in DRAM instead of writing to Flash [14, 24, 29]). Our work instead focuses on preloading-aware target selection, as evicting the wrong pages can negate the benefits of preloading.
8
Conclusion
To address the rising cold-launch latency of GB-scale large mobile apps under constrained memory and I/O, AppFlow aims to guarantee that both foreground and background launches complete within 1s. It achieves this through three coordinated modules: a Selective File Preloader for latencycritical files, an Adaptive Memory Reclaimer that protects preloaded data, and a Context-Aware App Killer. Together, these modules reduce stalls, reclaim memory efficiently, and sustain multitasking. Evaluations show AppFlow cuts cold launch latency significantly while keeping relaunches within 1s even under heavy workloads. Across 100-day daily traces, in-vehicle systems, and emerging on-device AGI, AppFlow consistently reduces latency and prevents cold relaunches, showing robustness in diverse real-world scenarios. While AppFlow’s gains are limited for small, low-I/O apps (e.g., Calendar), it introduces no regression. In the future, ondevice apps (notably local AI agents) will continue to grow in size and I/O footprints, while DRAM capacity remains constrained by rising DRAM prices; in this regime, AppFlow is well positioned to address the increasingly dominant I/Olatency bottleneck. In future work, we will incorporate userbehavior prediction to shift from app-wise to activity-wise preloading and reclamation, further accelerating launches.
9
Acknowledgement
This work was partially supported by the National Key R&D Program of China (No.2024YFB4505502), the National Science Fund for Distinguished Young Scholars (62025205) and the National Natural Science Foundation of China (62522215, 62532009, 62472354)
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
Xiaochen Li, Sicong Liu, Bin Guo, Yu Ouyang, Fengmin Wu, Yuan Xu, and Zhiwen Yu
References [1] Android Open Source Project. 2025. Low memory killer daemon. https://source.android.com/docs/core/perf/lmkd Accessed: 2025-0725. [2] AppMagic. 2025. Live Store Rankings - AppMagic. https://appmagic. rocks/top-charts/live-store-rankings. Accessed: 2025-07-27. [3] BuildFire. 2021. Mobile App Download Statistics & Usage Statistics (2025). https://buildfire.com/app-statistics/ Accessed: 2025-06-29. [4] CapCut. 2025. CapCut Video Editor. https://www.capcut.com/. Accessed: 2025-07-29. [5] James Carbone. 2022. DRAM price increases will ease. Electronics Sourcing. https://electronics-sourcing.com/2022/05/12/dram-priceincreases-will-ease Accessed: 2025-07-27. [6] Shaleen Garg, Jian Zhang, Rekha Pitchumani, Manish Parashar, Bing Xie, and Sudarsun Kannan. 2024. Crossprefetch: Accelerating i/o prefetching for modern storage. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1. 102–116. [7] Google AI Edge. 2025. Google AI Edge Gallery: A gallery that showcases on-device ML/GenAI use cases. https://github.com/google-aiedge/gallery Accessed: 2025-07-25. [8] Google Android Developers. 2025. Android Debug Bridge (adb). https: //developer.android.com/tools/adb. Accessed: 2025-08-01. [9] Google Android Developers. 2025. Android15 — About the Android platform version 15. https://developer.android.com/about/versions/15. Accessed: 2025-08-01. [10] Google Android Developers. 2025. Logcat | Android Developers. https: //developer.android.com/tools/logcat. Accessed: 2025-08-01. [11] Mel Gorman. 2004. Understanding the Linux virtual memory manager. Vol. 352. Prentice Hall Upper Saddle River. [12] Weichao Guo, Kang Chen, Huan Feng, Yongwei Wu, Rui Zhang, and Weimin Zheng. 2015. 𝑚𝑎𝑟𝑠: Mobile application relaunching speed-up through flash-aware page swapping. IEEE Trans. Comput. 65, 3 (2015), 916–928. [13] Max Hort, Maria Kechagia, Federica Sarro, and Mark Harman. 2021. A survey of performance optimization for mobile applications. IEEE Transactions on Software Engineering 48, 8 (2021), 2879–2904. [14] Jiacheng Huang, Yunmo Zhang, Junqiao Qiu, Yu Liang, Rachata Ausavarungnirun, Qingan Li, and Chun Jason Xue. 2024. More Apps, Faster Hot-Launch on Mobile Devices via Fore/Background-aware GC-Swap Co-design. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 3. 654–670. [15] Francisco Jeronimo. 2025. Global Memory Shortage Crisis: Market Analysis and the Potential Impact on the Smartphone and PC Markets in 2026. https://www.idc.com/resource-center/blog/global-memoryshortage-crisis-market-analysis-and-the-potential-impact-on-thesmartphone-and-pc-markets-in-2026/. IDC Blog (Markets and Trends), published 2025-12-18, accessed 2026-01-03. [16] Yongsoo Joo, Junhee Ryu, Sangsoo Park, and Kang G Shin. 2011. {FAST}: Quick application launch on {Solid-State} drives. In 9th USENIX Conference on File and Storage Technologies (FAST 11). [17] Yonchanok Khaokaew, Hao Xue, and Flora D Salim. 2024. Maple: Mobile app prediction leveraging large language model embeddings. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies 8, 1 (2024), 1–25. [18] Sang-Hoon Kim, Jinkyu Jeong, and Jin-Soo Kim. 2017. Applicationaware swapping for mobile systems. ACM Transactions on Embedded Computing Systems (TECS) 16, 5s (2017), 1–19. [19] Niel Lebeck, Arvind Krishnamurthy, Henry M Levy, and Irene Zhang. 2020. End the senseless killing: Improving memory management for
mobile operating systems. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). 873–887. [20] Joohyun Lee, Kyunghan Lee, Euijin Jeong, Jaemin Jo, and Ness B Shroff. 2016. Context-aware application scheduling in mobile systems: What will users do and not do next?. In Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing. 1235–1246. [21] Joohyun Lee, Kyunghan Lee, Euijin Jeong, Jaemin Jo, and Ness B Shroff. 2017. CAS: Context-aware background application scheduling in interactive mobile systems. IEEE Journal on Selected Areas in Communications 35, 5 (2017), 1013–1029. [22] Changlong Li, Zongwei Zhu, Chao Wang, Fangming Liu, Fei Xu, Edwin H-M Sha, and Xuehai Zhou. 2025. Archer: Adaptive Memory Compression with {Page-Association-Rule} Awareness for {High-Speed} Response of Mobile Devices. In 23rd USENIX Conference on File and Storage Technologies (FAST 25). 497–511. [23] Tong Li, Tong Xia, Huandong Wang, Zhen Tu, Sasu Tarkoma, Zhu Han, and Pan Hui. 2022. Smartphone app usage analysis: datasets, methods, and applications. IEEE Communications Surveys & Tutorials 24, 2 (2022), 937–966. [24] Wentong Li, Li-Pin Chang, Yu Mao, and Liang Shi. 2025. {PMR}: Fast Application Response via Parallel Memory Reclaim on Mobile Devices. In 2025 USENIX Annual Technical Conference (USENIX ATC 25). 1569–1584. [25] Wentong Li, Dingcui Yu, Yunpeng Song, Longfei Luo, and Liang Shi. 2024. Elasticzram: Revisiting zram for swapping on mobile devices. In Proceedings of the 61st ACM/IEEE Design Automation Conference. 1–6. [26] Yu Liang, Jinheng Li, Rachata Ausavarungnirun, Riwei Pan, Liang Shi, Tei-Wei Kuo, and Chun Jason Xue. 2020. Acclaim: Adaptive memory reclaim to improve user experience in android systems. In 2020 USENIX Annual Technical Conference (USENIX ATC 20). 897–910. [27] Yu Liang, Riwei Pan, Tianyu Ren, Yufei Cui, Rachata Ausavarungnirun, Xianzhang Chen, Changlong Li, Tei-Wei Kuo, and Chun Jason Xue. 2022. {CacheSifter}: Sifting cache files for boosted mobile performance and lifetime. In 20th USENIX Conference on File and Storage Technologies (FAST 22). 445–459. [28] Yu Liang, Aofeng Shen, Chun Jason Xue, Riwei Pan, Haiyu Mao, Nika Mansouri Ghiasi, Qingcai Jiang, Rakesh Nadig, Lei Li, Rachata Ausavarungnirun, et al. 2025. Ariadne: A hotness-aware and sizeadaptive compressed swap technique for fast application relaunch and reduced cpu usage on mobile devices. In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 1588–1602. [29] Geunsik Lim, Donghyun Kang, MyungJoo Ham, and Young Ik Eom. 2023. Swam: Revisiting swap and oomk for improving application responsiveness on mobile devices. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking. 1–15. [30] Jakob Nielsen. 1994. Usability engineering. Morgan Kaufmann. [31] Abhinav Parate, Matthias Böhmer, David Chu, Deepak Ganesan, and Benjamin M Marlin. 2013. Practical prediction and prefetch for faster access to applications on mobile phones. In Proceedings of the 2013 ACM international joint conference on Pervasive and ubiquitous computing. 275–284. [32] PUBG Corporation. [n. d.]. PUBG Mobile Official Website. https: //www.pubgmobile.com/en-US/home.shtml. Accessed: 2025-08-05. [33] Junhee Ryu, Dongeun Lee, Kang G Shin, and Kyungtae Kang. 2023. Fast Application Launch on Personal {Computing/Communication} Devices. In 21st USENIX Conference on File and Storage Technologies (FAST 23). 425–440. [34] Andrew Sanders. 2016. An introduction to Unreal engine 4. AK Peters/CRC Press.
AppFlow: Memory Scheduling for Cold Launch of Large Apps on Mobile and Vehicle Systems [35] Mohit Saxena and Michael M Swift. 2010. {FlashVM}: Virtual Memory Management on Flash. In 2010 USENIX Annual Technical Conference (USENIX ATC 10). [36] Zhihao Shen, Kang Yang, Wan Du, Xi Zhao, and Jianhua Zou. 2019. DeepAPP: A deep reinforcement learning framework for mobile application usage prediction. In Proceedings of the 17th Conference on Embedded Networked Sensor Systems. 153–165. [37] ShiftHackZ. 2025. Stable-Diffusion-Android: Stable Diffusion AI Client (Android). https://github.com/ShiftHackZ/Stable-Diffusion-Android. Accessed: 2025-09-01. [38] Choonsung Shin, Jin-Hyuk Hong, and Anind K Dey. 2012. Understanding and prediction of mobile application usage for smart phones. In proceedings of the 2012 ACM conference on ubiquitous computing. 173–182. [39] Hadlee Simons. 2025. How much RAM does your phone really need in 2025? https://www.androidauthority.com/how-much-ram-do-i-needphone-3086661/. Accessed: 2025-07-27. [40] Sam Son, Seung Yul Lee, Yunho Jin, Jonghyun Bae, Jinkyu Jeong, Tae Jun Ham, Jae W Lee, and Hongil Yoon. 2021. {ASAP}: Fast mobile application switch via adaptive prepaging. In 2021 USENIX Annual Technical Conference (USENIX ATC 21). 365–380. [41] Yuan Tian, Ke Zhou, Mounia Lalmas, and Dan Pelleg. 2020. Identifying tasks from mobile app usage patterns. In Proceedings of the 43rd international ACM SIGIR conference on research and development in
MobiCom ’26, October 26–30, 2026, Austin, TX, USA
information retrieval. 2357–2366. [42] TikTok. 2025. TikTok - Make Your Day. https://www.tiktok.com/ Accessed: 2025-07-25. [43] TrendForce. 2025. DRAM spot price trends. TrendForce DRAM Price Trends (DRAM Spot Price). https://www.trendforce.com/price/dram/ dram_spot Last update: 2025-07-25 Accessed: 2025-07-27. [44] u/DeckerSU and others. 2019. What normal memory footprint for an Android app? https://www.reddit.com/r/androiddev/comments/ atfccg/what_normal_memory_footprint_for_an_android_app/ Accessed: 2025-07-27. [45] Whitespace Global. 2025. Collective AI: Secure Offline AI Assistant. Apple App Store (US). https://apps.apple.com/us/app/collective-ai/ id6608983600 Version 1.3.0 (2025-10-02). Accessed: 2026-01-13. [46] Wikipedia contributors. 2025. Android version history – Wikipedia. https://en.wikipedia.org/wiki/Android_version_history. https://en. wikipedia.org/wiki/Android_version_history Accessed: 2025-07-27. [47] Tingxin Yan, David Chu, Deepak Ganesan, Aman Kansal, and Jie Liu. 2012. Fast app launching for mobile devices using predictive user context. In Proceedings of the 10th international conference on Mobile systems, applications, and services. 113–126. [48] Xiao Zhu, Duo Liu, Kan Zhong, Jinting Ren, and Tao Li. 2017. SmartSwap: High-performance and user experience friendly swapping in mobile systems. In Proceedings of the 54th Annual Design Automation Conference 2017. 1–6.