Picture-in-Picture (PiP) — mode ng pag-playback ng video sa isang lumulutang na window sa ibabaw ng iba pang mga app, na nagpapahintulot sa user na magpatuloy sa panonood ng content kapag mini-minimize ang app o lumilipat sa pagitan ng mga program. Ang PiP window ay awtomatikong nakaposisyon sa sulok ng screen at maaaring ilipat ng user. Ayon sa Apple AVPictureInPictureController documentation (2026), ang PiP mode ay suportado sa iOS simula sa bersyon 14 at sa Android simula sa bersyon 8.0.
Mga Pangunahing Punto
Picture-in-Picture (PiP) ay isang mode ng pagpapakita ng video sa isang maliit na lumulutang na window na nananatili sa ibabaw ng lahat ng iba pang mga window at app. Maaaring ilipat ng user ang PiP window sa screen, baguhin ang laki nito (sa ilang platform) at magpatuloy sa panonood ng content habang nagtatrabaho sa iba pang mga app.
Ang konsepto ng PiP ay nagmula sa telebisyon: noong 1990s, ang mga TV ay maaaring magpakita ng pangalawang channel sa sulok ng screen. Sa mga mobile device, unang lumitaw ang PiP sa iPad sa iOS 9 (2015) para sa video sa Safari, at ang buong sistema ng PiP para sa mga app ay naging available sa iOS 14 (2020). Sa Android, ang suporta sa PiP ay lumitaw nang mas maaga — sa bersyon 8.0 Oreo (2017), ngunit para lamang sa video, at simula sa Android 12 para sa lahat ng uri ng content.
Ang PiP ay naiiba sa background playback dahil ang video ay patuloy na ipinapakita sa screen, hindi lamang nagpe-play sa audio stream. Background playback (background audio) ay available sa parehong platform, ngunit ang PiP ay nagbibigay sa user ng visual na kontrol sa content: nakikita niya ang mga frame, maaaring mag-pause, mag-rewind, o isara ang window. Ito ay lalong mahalaga para sa mga video lesson, stream at video call kung saan ang visual na content ay kasinghalaga ng audio.
Sa arkitektura, ang PiP ay ipinatutupad sa pamamagitan ng system window manager na lumilikha ng isang hiwalay na window na may mas mababang priyoridad sa pagpapakita. Ang app ay nagde-delegate ng video output sa isang system service na nagpapatuloy sa pag-render ng video kahit na ang app ay lumipat sa background mode o na-minimize.
Nagsisimula ang proseso kapag na-minimize ng user ang app na may aktibong video o pinindot ang PiP button (sa iOS) o awtomatikong inilipat ng system ang Activity sa PiP mode (sa Android). Ang system window manager ay kumukuha ng video stream at lumilikha ng lumulutang na window na may nakapirming proporsyon. Ang laki ng window ay depende sa aspect ratio ng orihinal na video at sa mga limitasyon ng platform: sa iOS, ang PiP window ay sumasakop ng humigit-kumulang 1/6–1/4 ng lapad ng screen, sa Android — hindi bababa sa 108 dp ang lapad at 240 dp ang taas para sa mga mobile device.
Kapag aktibo ang PiP window, ang app ay maaaring nasa isa sa tatlong estado: sa background (na-minimize), sa aktibong estado (bumalik ang user sa app), o sa waiting state (sinuspinde ng system ang PiP dahil sa kakulangan ng resources). Sa paglipat sa PiP, dapat isuspinde ng app ang mga hindi kinakailangang UI operations (animation, rendering ng interface) at mag-free ng memory, dahil ang system resources sa multitasking mode ay mas mahigpit na ipinamamahagi. Ang iOS ay awtomatikong nagpapadala ng notifikasyon na AVPictureInPictureControllerWillStartNotification sa app, at ang Android — callback na onPictureInPictureModeChanged.
Ang PiP window ay may makabuluhang limitasyon: hindi ito maaaring magpakita ng mga standard na UI control element (pause button, progress slider) — tanging minimal na system overlay na may mga pangunahing elemento: play/pause, isara, palawakin sa full screen. Ang system UI ng PiP sa iOS ay may kasamang pause at close button, at sa Android — parehong elemento plus karagdagang settings button. Ang interaksyon sa content sa loob ng PiP (rewind, pagpili ng subtitle) ay hindi posible — para dito kailangang buksan ang app sa full screen.
Sa iOS, ang PiP ay ipinatutupad sa pamamagitan ng AVKit framework at klase na AVPictureInPictureController. Ang API na ito ay available sa iOS 14+ para sa iPhone at iPad, ngunit may iba't ibang kinakailangan: sa iPad ang PiP ay gumagana sa pamamagitan ng AVPlayerLayer, sa iPhone — sa pamamagitan lamang ng AVPlayerViewController.
Para gumana ang PiP sa iOS, maraming kondisyon ang dapat matugunan: ang app ay dapat gumamit ng AVPlayer para sa pag-playback ng video, ang audio session ay dapat na-configure sa kategoryang .playback o .playAndRecord, at ang app ay dapat may entitlements para sa background audio (UIBackgroundModes = audio). Kung wala ang mga setting na ito, hindi magsisimula ang PiP — tatanggihan ng system ang kahilingan na lumikha ng PiP session dahil hindi nito magagarantiya ang tamang pag-playback pagkatapos lumipat sa background.
Sa iOS, ang PiP window ay awtomatikong ipinapakita kapag na-minimize ang app kung ang video ay aktibong nagpe-play at hindi na-disable ng user ang feature na ito sa mga setting. Ang user ay maaari ring manu-manong i-minimize ang video sa PiP sa pamamagitan ng button sa AVPlayerViewController. Ang laki ng PiP window sa iOS ay nakapirmi at tinutukoy ng system — hindi ito mababago ng developer. Ang aspect ratio ng PiP window ay tumutugma sa aspect ratio ng orihinal na video, ngunit ang maximum na laki ay limitado sa 1/4 ng lapad ng screen sa iPhone at 1/3 sa iPad.
Ang mga pangunahing limitasyon ng PiP sa iOS: kawalan ng kakayahang mag-customize ng UI sa PiP window, limitasyon sa isang PiP stream sa isang pagkakataon, at kinakailangan ng aktibong AVPlayer para sa PiP. Multi-PiP — sabay-sabay na pag-playback ng maraming PiP window — ay hindi suportado sa iOS. Sa pagtatangkang magsimula ng pangalawang PiP, ang una ay awtomatikong magsasara. Ito ay isang hardware limitation: ang video processor ay hindi maaaring sabay na maghatid ng dalawang independiyenteng PiP channel dahil sa mga limitasyon ng DMA at video memory.
Isa pang mahalagang limitasyon — ang tagal ng pag-playback sa background. Kung hindi nakikipag-ugnayan ang user sa PiP window, maaaring isuspinde ng system ang pag-playback pagkatapos ng ilang oras upang makatipid ng enerhiya. Auto-pause ng PiP sa iOS ay nangyayari pagkatapos ng 10–15 minuto ng kawalan ng aktibidad, kung ang app ay hindi nagpatupad ng keep-alive mechanism sa pamamagitan ng background task. Para sa mga video call at stream, inirerekomenda ang paggamit ng PushKit at VoIP certificate, na lumalampas sa limitasyong ito.
Sa Android, ang PiP ay ipinatutupad bilang isang built-in na Activity mode na naa-activate sa pamamagitan ng enterPictureInPictureMode method. Simula sa Android 8.0 (API 26), ang anumang Activity ay maaaring lumipat sa PiP mode, at simula sa Android 12 (API 31) ay lumitaw ang suporta sa PiP para sa SurfaceView at TextureView nang hindi kinakailangang gumamit ng MediaCodec.
Para sa suporta sa PiP sa Android manifest, dapat tukuyin ang atribut na android:supportsPictureInPicture para sa Activity sa seksyong
Sa Android, ang PiP window ay walang mga control element bilang default. Ang developer ay maaaring magdagdag ng mga custom na aksyon sa pamamagitan ng RemoteAction sa setPictureInPictureParams method. Hanggang 3 aksyon ang available (halimbawa: pause/play, rewind/fast forward, isara). Ang bawat aksyon ay ipinapakita sa system PiP overlay bilang isang icon. Hindi tulad ng iOS, kung saan ang lahat ng UI element ay mahigpit na nakapirmi, ang Android ay nagbibigay ng higit na flexibility para sa mga basic na kontrol.
Ang PiP sa Android ay may iba't ibang kakayahan depende sa bersyon ng OS. Sa Android 8.0–8.1, ang PiP ay available lamang para sa video na pina-play sa pamamagitan ng MediaPlayer o MediaCodec na may SurfaceView. Simula sa Android 9, maaaring gamitin ang PictureInPictureArgs.Builder para sa pag-configure ng aspect ratio ng PiP window. Ang Android 12 ay nagdagdag ng suporta sa PiP para sa custom na SurfaceView at TextureView, pati na rin pinahusay na pamamahala ng mga transisyon sa pagitan ng full screen at PiP mode. Ang Android 13+ ay nagpapahintulot na ipakita ang PiP window kahit sa naka-lock na screen, kung ang app ay may naaangkop na pahintulot.
| Bersyon ng Android | Mga kakayahan ng PiP | API |
|---|---|---|
| 8.0–8.1 | Basic na PiP para sa MediaPlayer/MediaCodec | 26–27 |
| 9–11 | Configuration ng aspect ratio, custom na aksyon | 28–30 |
| 12 | Suporta sa SurfaceView/TextureView sa PiP | 31 |
| 13+ | PiP sa naka-lock na screen, pinahusay na animation | 33+ |
Ang pangunahing pagkakaiba ng Android PiP mula sa iOS — ang kakayahang mag-multi-PiP. Sa Android simula sa bersyon 12, ang system ay maaaring magpakita ng maraming PiP window nang sabay-sabay, kung sinusuportahan ito ng mga app at pinapayagan ng performance ng device. Gayunpaman sa pagsasagawa, ang multi-PiP ay limitado ng mga kakayahan ng SoC: karamihan sa mga device ay sumusuporta lamang ng isang PiP window dahil sa mga hardware limitation ng decoder, dahil ang bawat PiP window ay nangangailangan ng sarili nitong video stream at hiwalay na decoding session.
Tingnan natin ang praktikal na implementasyon ng PiP sa parehong mobile platform na isinasaalang-alang ang mga pinakabagong pagbabago sa API.
import AVKit
import AVFoundation
class VideoPlayerViewController: UIViewController {
var player: AVPlayer!
var pipController: AVPictureInPictureController?
override func viewDidLoad() {
super.viewDidLoad()
let playerLayer = AVPlayerLayer(player: player)
playerLayer.videoGravity = .resizeAspect
view.layer.addSublayer(playerLayer)
guard AVPictureInPictureController.isPictureInPictureSupported()
else { return }
pipController = AVPictureInPictureController(playerLayer: playerLayer)
pipController?.delegate = self
}
@IBAction func startPiPTapped() {
pipController?.startPictureInPicture()
}
}
extension VideoPlayerViewController: AVPictureInPictureControllerDelegate {
func pictureInPictureControllerWillStart(
_ pictureInPictureController: AVPictureInPictureController
) {
// Itago ang mga UI element, mag-free ng memory
}
func pictureInPictureControllerDidStop(
_ pictureInPictureController: AVPictureInPictureController
) {
// Ibalik ang UI, ipagpatuloy ang rendering
}
}
Sa halimbawa, ang AVPictureInPictureController ay ini-initialize gamit ang playerLayer pagkatapos suriin ang isPictureInPictureSupported (ang PiP ay hindi suportado sa iPhone SE 1st generation at ilang iPad na walang sapat na memory). Ang delegado ay nagpapaalam sa app tungkol sa simula at pagtatapos ng PiP — sa mga callback na ito, dapat itago at ibalik ang mga UI element, dahil sa PiP mode ang interface ng app ay hindi nakikita. Sa paglipat sa PiP, inirerekomenda na ihinto ang lahat ng animation, itago ang mga kontrol ng player, at mag-free ng hindi nagamit na memory upang maiwasan ang sapilitang pag-alis ng app ng system.
class PipVideoActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setupVideoPlayer()
}
private fun enterPipMode() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
val aspectRatio = Rational(16, 9)
val pipParams = PictureInPictureParams.Builder()
.setAspectRatio(aspectRatio)
.setAutoEnterEnabled(true)
.build()
enterPictureInPictureMode(pipParams)
}
}
override fun onPictureInPictureModeChanged(
isInPictureInPictureMode: Boolean,
newConfig: Configuration
) {
if (isInPictureInPictureMode) {
// Itago ang UI, tumuon lamang sa media
binding.controlsGroup.visibility = View.GONE
} else {
// Ibalik ang UI
binding.controlsGroup.visibility = View.VISIBLE
}
}
}
Ang halimbawa sa Kotlin ay gumagamit ng PictureInPictureParams.Builder para sa pag-configure ng PiP. Ang setAspectRatio method ay nagtatakda ng aspect ratio ng PiP window (16:9 para sa tipikal na video). Ang setAutoEnterEnabled(true) ay nag-a-activate ng awtomatikong paglipat sa PiP kapag na-minimize ang app. Ang callback na onPictureInPictureModeChanged ay tinatawag sa pagpasok at paglabas ng PiP — dito dapat itago o ipakita ang mga UI element. Para sa video sa SurfaceView, kinakailangan ang karagdagang paghawak ng configuration sa pamamagitan ng pagdagdag ng android:configChanges="screenSize|smallestScreenSize" sa manifest upang maiwasan ang muling paglikha ng Activity sa paglipat sa PiP mode.
Ang PiP ay isang makapangyarihang tool para sa pagpapabuti ng karanasan ng user sa mga app kung saan ang content ay nananatiling may kaugnayan kahit na lumilipat sa iba pang mga gawain. Gayunpaman, ang implementasyon ng PiP ay dapat na makatwiran at hindi makagambala sa user.
Mga video call at conference — isa sa mga pangunahing scenario ng PiP. Sa Zoom, FaceTime, Google Meet, pinapayagan ng PiP na makita ang kausap habang nagtatrabaho sa iba pang mga app: pagbabasa ng mga tala, panonood ng presentasyon, o pagsuri ng email. PiP para sa mga video call ay nangangailangan ng suporta sa camera sa background at tamang configuration ng audio session para sa pagpapatuloy ng pag-capture ng audio sa background. Sa iOS, para dito ginagamit ang AVSampleBufferDisplayLayer sa halip na AVPlayerLayer, dahil ang mga video call ay hindi gumagamit ng AVPlayer.
Ang mga serbisyo ng streaming (YouTube, Netflix, Twitch) ay aktibong gumagamit ng PiP para magpatuloy sa panonood habang naghahanap ng bagong content. Ang YouTube Premium ay nag-aalok ng PiP bilang isang bayad na feature, nililimitahan din ng Netflix ang PiP sa ilang partikular na plan dahil sa mga limitasyon sa lisensya ng content. Para sa pagpapatupad ng PiP sa isang streaming app, kinakailangan ang integrasyon sa DRM system (FairPlay, Widevine) na sumusuporta sa secure na pipeline sa PiP mode.
Ang PiP ay hindi angkop para sa mga app na may interactive na video content kung saan kinakailangan ang interaksyon ng user: educational platform na may mga test sa loob ng player, game stream na may chat, shopping app na may mga link sa produkto sa video. Sa mga kasong ito, ang PiP window ay masyadong maliit para magpakita ng karagdagang impormasyon, at ang mga interactive na elemento sa PiP ay hindi sinusuportahan ng system. Inirerekomenda na gamitin lamang ang PiP para sa passive na panonood, kapag hindi kinakailangan ang interaksyon sa content.
Para sa mga music at podcast app, ang PiP ay labis — sapat na ang background audio na walang visual na window. Ang PiP ay kumokonsumo ng karagdagang GPU resources para sa pag-render ng video sa lumulutang na window, na nagpapaikli sa buhay ng baterya. Kung ang content ay audio (musika, podcast, audiobook) — gumamit ng background playback na walang PiP. Kung visual — ipatupad ang PiP para sa pagpapabuti ng karanasan ng user.
Mga Madalas Itanong
Ang PiP sa iOS ay nangangailangan ng iPhone 6s+, iOS 14+ at rehiyong may suporta (US, Canada, Australia, EU, Russia at iba pa). Para sa app, ang audio session ay dapat i-configure sa kategoryang .playback at idagdag ang UIBackgroundModes = audio. Suriin din ang mga setting: Settings > General > Picture in Picture.
Sa iOS, ang laki ng PiP window ay ganap na tinutukoy ng system at hindi maaaring i-configure ng developer. Sa Android, ang aspect ratio lamang ang maaaring itakda sa pamamagitan ng setAspectRatio sa PictureInPictureParams.Builder, ngunit ang eksaktong laki ng window ay tinutukoy ng system. Maaaring baguhin ng user ang laki ng PiP window sa Android 12+ gamit ang pinch-to-zoom gesture.
Oo, gumagana ang PiP sa DRM-protected content (FairPlay sa iOS, Widevine L1 sa Android) sa kondisyon na ang DRM session ay sumusuporta sa secure na pipeline sa PiP mode. Ang Widevine L3 ay maaaring hindi sumuporta sa PiP dahil hindi nito ginagarantiyahan ang seguridad ng na-decode na content sa lumulutang na window. Suriin ang compatibility ng DRM sa PiP sa yugto ng pagsubok.
Sa iOS — isa lamang PiP window. Sa Android 12+ ay theoretically sumusuporta ng multi-PiP, ngunit sa pagsasagawa, karamihan sa mga device ay limitado sa isang window dahil sa hardware limitations. Ang mga top device (Samsung Galaxy S24, Pixel 8) ay maaaring sumuporta ng 2 PiP window, ngunit may pinababang performance.
Oo, ang pag-handle ng lifecycle ay kritikal. Sa iOS, sa paglipat sa PiP, ang app ay tumatanggap ng notifikasyon na willStart kung saan dapat itago ang UI at mag-free ng memory. Sa Android, ang onPictureInPictureModeChanged ay tinatawag sa pagpasok/paglabas ng PiP. Sa maling pag-handle ng lifecycle, maaaring alisin ng system ang app mula sa memory, na pumuputol sa pag-playback.
Buod
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din