The Window That Refuses to Sleep
You shrink the video down to that little floating rectangle, slide it into the corner, and go back to texting. The phone feels calm. Quiet, even. It is not.
That thumbnail-sized overlay is one of the most resource-privileged states your phone knows how to create, and your operating system is working hard to keep it alive in ways it flatly refuses to bother with for ordinary background apps.
So why does a postage-stamp video get a priority lane? The answer is mechanical, not mysterious.
A Hierarchy Your Phone Runs All Day
Every app on your phone exists in a state. Android formalises this as a process importance hierarchy. iOS uses a roughly equivalent model under the hood. At the top sits the foreground app you're actively touching. At the bottom: cached processes the system will kill without ceremony the moment RAM runs low.
Picture-in-picture lives in its own tier, right below full-foreground. On Android, the system assigns PiP apps a `FOREGROUND_SERVICE`-equivalent importance level, which instructs the low-memory killer to leave them alone. iOS does something architecturally similar: a PiP session holds a background entitlement that ordinary apps simply cannot request, and the video rendering pipeline stays fully active.
Fully active matters. A standard backgrounded app, say a podcast app that's been minimised but isn't playing audio, gets throttled. Its CPU time slices shrink. The scheduler deprioritises it and moves on. A PiP app has to decode video frames continuously, composite that overlay onto your screen at your display's refresh rate, and respond instantly when you drag the window or tap to expand. The system has to allocate real, scheduled CPU and GPU cycles to make that happen. You can't fake smooth video with leftover scraps.
Here's a worked example. Take a mid-range phone running a 1080p YouTube video in PiP while the user scrolls a photo gallery in the foreground. The GPU is simultaneously compositing two distinct rendering layers: the gallery beneath, the floating video on top. The video decoder, often a dedicated hardware block but always coordinated by the CPU, is processing roughly 30 frames per second. Drop that coordination and the video stutters. So the scheduler doesn't drop it. Simple as that.
The Battery Bill You're Quietly Signing
That priority costs something. This is where a lot of people get surprised.
Background video decoding is one of the more power-hungry tasks a phone performs quietly. Display-on power draw is already your biggest single drain, and continuous video decode piled on top compounds it. Streaming video in PiP over Wi-Fi can consume somewhere between 15 and 25 percent more battery per hour than simply having the screen on with a static app in the foreground, depending on codec, resolution, and how aggressively your chip's power management is tuned. That range is wide, but the direction is always the same.
AV1, the codec YouTube increasingly uses, is more efficient to decode than older H.264 streams. The problem: that efficiency only materialises on phones with hardware AV1 decoders, which became common in flagship chips from roughly 2021 onward. On older hardware, the CPU handles AV1 in software, and the power cost climbs sharply. That mid-range phone from the example above might not have a hardware AV1 decoder. Its CPU does the work instead.
The battery notices.
If your phone has per-app battery usage breakdowns, check them after a day of heavy PiP use. You'll likely find the video app sitting higher than you expected for something that was supposedly running in the background.
What People Misread About Background Limits
The common assumption is that shrinking an app to PiP is basically the same as minimising it. It isn't, and treating it that way produces a specific frustration: people wonder why their battery drains faster when they're barely using their phone.
Minimising an app with no background entitlements means it's frozen within seconds on iOS, or heavily throttled on Android. PiP is the opposite of frozen. It's a deliberate exception the OS makes because the user explicitly requested ongoing, visible output. The energy use is the honest price of that.
Consider two people who buy the same phone on the same day. Sarah uses PiP constantly: YouTube in the corner while she reads articles, a FaceTime call floating while she checks her calendar. By dinner, she's at 30 percent. Marcus uses the same apps in sequence, minimising between tasks. Same usage time, similar content. Marcus is at 52 percent. The difference isn't the apps. It's the rendering state the OS is maintaining for Sarah's benefit.
Neither is wrong. Sarah is getting something real for that battery cost. That cost is real too, though, and pretending the floating window is basically idle is how people end up confused and annoyed by their own phone.
The Smarter Way to Think About the Floating Window
Picture-in-picture is genuinely useful, and the engineering behind it is elegant. Think of it less like a background app and more like a second foreground task wearing a smaller coat. Your phone isn't wasting resources carelessly. It's making a deliberate trade: continuous CPU and GPU allocation in exchange for a fluid, responsive overlay that doesn't interrupt what you're doing.
If you want to reduce the cost, a few things actually help. Lower the video quality in the app's settings before entering PiP. Smaller resolution means fewer bytes per frame for the decoder to handle. Connect to Wi-Fi if you're on mobile data, since the radio draws additional power when streaming. On Android, you can often resize the PiP window to its smallest setting, which reduces the compositor's workload slightly, though the decode still happens at source resolution.
But none of those tips change the underlying reality. Your phone isn't giving that little floating window special treatment out of generosity. It's doing it because smooth, interactive video is one of the hardest real-time tasks a mobile chip runs, and the only way to make it look effortless is to never, ever treat it as an afterthought.