K8.04.2content stream versus control stream设计
投屏需区分内容流与控制流
别名: 投屏控制 · Chromecast · AirPlay 播放 · cast versus mirror
概念解释
Chromecast 把影片送到电视上播，手机立刻变成遥控器：进度条、音量、选下一集都在手里，电视上只有画面。镜像则相反，触摸仍发生在源设备上，电视只是另一块显示器。内容流与控制流要分开：一路是正在被看的媒体或窗口，一路是播放、暂停、选片这些命令。混在一起时，人不知道该盯哪块屏、该在哪点。AirPlay 播视频走的是「电视播、手机控」；AirPlay 镜像走的是「手机既是源也是控」。同一「投屏」词覆盖两种结构，操作预期完全不同。
机制
真正的投播把解码和显示放到接收端，源设备只发URL 或码流，随后可以锁上、去干别的。控制协议是另一条窄通道：播放、暂停、seek、音量。人的手因此被解放，眼睛留给大屏。镜像没有这条分工，所有输入仍落在源屏的坐标系里，大屏只是像素的回显；人必须低头看手机才能点暂停，和「对着电视看」的姿势冲突。若产品在投播过程中突然切回镜像（应用不支持独立会话、网络不够改传整屏），控制面从大屏旁的遥控器变回源设备上的原界面，模式切了人却不一定看见。两条流的状态还可能脱节：电视还在播，手机控制条已经关掉；或控制条还在，电视已回到主页。
边界
把电脑桌面镜像到投影、用键鼠在电脑上操作，控制流本来就在源设备，不必再造一条手机遥控器。游戏和低延迟演示需要输入和画面在同一时间轴上，走镜像或无线显示器，而不是「先传到盒子再远程控」。没有第二块可触摸表面时（只有电视和一只传统遥控器），控制流只能落在遥控器键上，产品要适配键而不是假设手机还在手里。纯展示的静态幻灯片可以只有内容流，翻页用演讲者的一台设备即可。
怎么落地
- 进入投播时明确告诉人：画面在接收端播放，控制在发起设备；提供始终可找的控制条（播放/暂停/音量/退出），即使发起设备锁屏。
- 不要在同一次会话里悄悄从「独立播放」改成「整屏镜像」。能力不够时，在开始前就让人选择，而不是中途换模式。
- 控制条显示的播放头必须跟接收端一致；接收端被电视遥控器打断时，发起设备的控制条要跟着变成「已在电视上退出」而不是假暂停。
- 验证：投一部影片到电视，把发起的手机锁上再打开。控制条仍应能暂停电视上的播放，电视不得因为手机锁上而改去镜像桌面。再用电视遥控器按主页，看手机控制条是否在几秒内反映会话已结束。