Anyone here actually validated what “Extended RAM” on the vivo V25 is doing under the hood, and whether it’s worth having on?
I’m not buying the blanket claim that turning 8 GB into “up to 16 GB” is a free lunch, especially on UFS 2.2. Some brands quietly just bump zRAM and tune the lowmemorykiller, while others enable a real swapfile on flash. Those are very different beasts in terms of performance and storage wear.
What I want to get to the bottom of on the V25:
- Is “Extended RAM” just bigger zRAM, or does vivo mount a swapfile on UFS?
- Does it actually reduce app reloads in day-to-day use, or does Funtouch’s background-kill policy dominate anyway?
- If a swapfile is used, how aggressive is it? Are we trading marginal multitasking gains for accelerated UFS wear and long-term slowdowns?
If you have a V25, you can check without root in a couple minutes:
- With Extended RAM OFF and then ON (reboot after toggling each state), run:
- adb shell cat /proc/swaps
- adb shell cat /sys/block/zram0/disksize
- adb shell cat /proc/meminfo | grep -i swap
- If you see only zram0 in /proc/swaps and no file path, it’s zRAM-only. If you see a /data/…swap file, they’re using flash-backed swap too.
- Optional write-activity sanity check:
- adb shell cat /proc/diskstats | grep -E ‘ sda | sdb ’
- Note “sectors written” baseline (each sector is usually 512 bytes), then run a 10-15 minute heavy multitasking session, retake the value, and compare deltas with Extended RAM OFF vs ON. If swap-to-flash is active and used, the ON run should show a measurable bump in small writes even when you’re not downloading/recording media.
Quick real-world test I use to see if RAM marketing matters:
- Pick 12-15 heavyweight apps: camera, Instagram, Chrome with 10 tabs, YouTube in PiP, Maps, Spotify, a game, Drive/Docs, Photos, Telegram/WhatsApp, etc.
- Open them all, bounce between them twice, return to the first few, and count how many cold-restart. Do this with Extended RAM OFF and ON, after a reboot each time and with the same battery level and ambient temp.
- Also check iManager/Background restrictions are the same across both runs; Funtouch’s “smart” cleanup can mask the effect.
If someone with root wants to go deeper, the UFS health descriptor would settle the wear question over time (life_time_est_a/b), but I’ll take short-term diskstats plus app-reload counts as a decent proxy for now.
My hunch:
- On the base 8 GB V25, “Extended RAM” is mostly zRAM sizing and LMK tuning. If there’s a swapfile, the kernel’s swappiness is probably low enough that it rarely helps, but it could still nibble at UFS with low-value writes.
- Net benefit is minimal if Funtouch continues to aggressively cull background processes; better gains come from sane background policy and scheduler tuning, not virtual RAM.
Data beats hunches though. If you can, post:
- Your V25 variant (RAM/storage), Funtouch/Android version, Extended RAM setting (+x GB shown), and region.
- Outputs of the three commands above with Extended RAM OFF vs ON.
- Your app-reload counts and any noticeable lag differences.
- Any long-term anecdote on storage performance drift with Extended RAM permanently ON.
If this turns out to be mostly a zRAM toggle, vivo should just say so and give us a simple “background app retention” slider instead of hyping virtual GBs.