Why Android Phones Slow Down: Flash Fragmentation, Write Amplification, and TRIM Solutions

Story Origin

Tencent's product team noticed the common complaint that Android phones become sluggish after less than a year of use and sought to understand whether disk fragmentation contributes to this issue.

Step 0: Disk and System Smoothness Relationship

Disk read/write speed directly affects CPU execution efficiency; slower storage forces the CPU to wait for data, degrading overall system smoothness.

Step 1: Android Disk Read/Write Mechanism

Android devices primarily use NAND flash memory, organized as Page → Block → Plane → Die. Writes occur at the page level, while erases happen at the block level, leading to write amplification when space is scarce.

Step 2: Solving Write Amplification – TRIM

TRIM is an ATA command that tells the flash controller which pages are invalid, allowing it to reclaim space proactively. Effective TRIM requires support from the OS, driver, and flash controller.

Android versions below 4.3 do not support TRIM.

Some flash controllers (e.g., Samsung Galaxy Nexus) lack TRIM support.

Two common TRIM‑based solutions are:

Mounting ext4 with the discard option – immediate TRIM on each write, but may impact delete performance.

Running the fstrim command periodically – less frequent, no impact on normal operations.

Step 3: Implementing TRIM in Android

Android uses the IdleMaintenanceService to decide when to trigger TRIM. The service monitors screen idle time, battery level, and maintenance intervals to schedule fstrim execution.

Trigger conditions include screen off >71 min, battery >20 % (or >30 % when charging), and maintenance interval >71 min.

Step 4: Impact of Fragmentation and TRIM on I/O Performance

Testing on an LG Nexus 5 (CM‑11) used Bonnie++ to measure SD‑card I/O under three scenarios: fresh flash, simulated long‑term use without TRIM, and after manual TRIM.

Results:

Repeated writes reduced overall I/O efficiency, especially space allocation and write‑back performance.

Sequential Output‑Block dropped to 15‑20 % of the original value.

Sequential Output‑Rewrite fell to about 50 % of the original value.

Manual TRIM restored most metrics close to baseline, though not completely.

Step 5: Automatic FSTRIM Trigger Tests

Four devices (two Samsung Galaxy Nexus, two LG Nexus 5) were monitored for automatic FSTRIM execution over ~30 hours after a forced trigger.

Findings:

FSTRIM usually triggers automatically, but failures occur.

Wi‑Fi state influences trigger success due to push notifications and power consumption.

High battery‑level requirements (e.g., >80 % when not charging) can prevent execution.

Conclusion & Thoughts

Disk fragmentation (idle data blocks) significantly degrades read/write speed, contributing to Android’s “slow‑down” problem. TRIM can partially recover performance, but its automatic activation is not guaranteed because the IdleMaintenanceService imposes strict power‑level conditions.

Potential optimizations:

Lower the battery‑level threshold for TRIM activation.

Send explicit Intent events to force a FSTRIM run when needed.

Understanding Android’s storage internals enables test engineers to design effective performance‑validation strategies without writing application code.