客厅里的屏幕更难做的是软件：电视端的六个工程约束
电视端应用难做，不是因为屏幕大了，而是因为链路上多出来的每一环都不在开发方控制之内。芯片方案由整机厂决定，焦点由遥控器按键驱动，字体渲染被观看距离重新定标，投屏对端的解码能力你只能探测不能假设，上架要过厂商商店，机型卖出去之后还要被服务端认出来。手机应用把这些环节藏在了操作系统和浏览器里，电视端把它们全部摊在交付面前。
下面六条是我们把电视端问题归类后得到的约束。它们互相独立，各自有独立的失效表现和独立的应对手段，任何一条靠”多测几台机器”都覆盖不掉。
一、碎片化的芯片与低内存机型：降级路径要设计出来
同一份安装包在不同机型上的首帧时间和滚动流畅度差别非常大，而且差别不体现在平均值上，体现在最旧那一档机型上。低端方案的内存上限低、图形解码能力弱、存储读写慢，还常伴随被裁剪过的系统组件。手机项目里我们把首帧指标写在测试机上，电视项目里必须写成”从冷启动到列表可交互，以最旧在网机型为基准”。
降级不能靠碰运气，要显式设计成三层。
- 能力探测层：进应用时读取设备内存档位、可用存储、解码器能力、系统组件是否存在，把结果写成一份能力标志，后续所有分支只读标志，不重复探测。
- 资源分层层：图像按档位选择尺寸与色彩深度，动效按档位可关，列表按档位调整缓存池大小。资源加载入口收在一个地方，避免每个页面各自决定。
- 行为退化层：探测到不支持的能力时要有可接受的替代行为，而不是抛异常。比如某类硬解不可用就退回软解加降分辨率，再不行就明确提示”该机型不支持此内容”，而不是让用户对着黑屏猜。
还有一条常见事故源：内存告警回调只是记了日志，没真的释放图片缓存和列表回收池。电视应用生命周期长，一次会话几小时，回收不彻底就会在长时间使用后崩溃，而这种崩溃只在老机型上复现。
二、焦点导航：遥控器模型不是触屏模型的放大版
触屏是”指哪打哪”，遥控器是”在一张焦点图上移动光标”。差别在于后者要求界面自己声明可达性，而界面通常没声明对。
焦点顺序必须与空间布局一致。按布局写成网格、按代码写成流水，用户在网格上按方向键就会跳到意料之外的位置，感觉像”遥控器坏了”。显式指定下一个焦点只用在跨区块的跳转，滥用会让局部改动毁掉全局顺序，务必配合回归。
焦点必须始终可见。默认的高亮在大屏上远看只是一点变化，需要放大加描边加阴影三者之一，并在深色背景上验证对比度。更麻烦的是焦点跑到屏幕外或跑到不可见元素上——页面滚动后光标不见了，用户只能反复按返回，这是电视端最典型的”卡住”。
大位图与焦点动画是性能陷阱。列表项绑定时同步解码大图，再加一个缩放动画，方向键连按就掉帧，看起来像遥控器失灵。做法是把图片解码交给可回收的加载器，焦点动画只做描边和轻微位移，动画时长短到不阻塞下一个按键。
另外几个必须定规矩的点：长按方向键的连续滚动速率与列表加载要匹配，否则滚到底还在空转；返回键的语义要分层（退出当前页、收起面板、退出应用），三层里少一层都会造成”退不出去”；确认键与回车键在不同系统上的按键码不同，只处理其中一个的界面在部分机型上完全没反应；输入框必须提供屏幕软键盘加遥控器输入的通道，指望用户外接键盘的方案过不了验收。
三、观看距离改写排版与对比度底线
手机排版的前提是三十厘米观看距离，电视的前提是两三米。同样物理尺寸的字符，在电视上对应的视角小得多，于是最小字号不是审美问题而是可读性阈值。所有正文和按钮文字都要按大屏重定一档下限，并在这条下限上重新检查换行、截断和行高。
对比度同样被重定标。远看时低对比灰字最先消失，浅灰说明文字、次要按钮、分割线在电视上等于不存在。深色底配高亮文字是安全做法，但要避免纯白字配饱和色块产生的边缘抖动。任何用透明度表达的层级，在大屏上都要转成可见的描边或明度差。
文字安全区是电视特有的约束。一部分显示设备存在过扫描，画面四周会被裁掉一圈，贴在屏幕边缘的台标、字幕、滚动条提示就丢了。做法是把关键文字约束在内缩的安全框里，背景与装饰可以出框。安全框要写成全局常量，由布局层统一施加，而不是每个页面自己算。
字幕、进度条、弹幕这类叠在画面上的文字，还要额外确认它在不同分辨率与缩放模式下的位置，以及播放器画面上下移时是否被吃掉。
四、投屏协商与应用分发、签名、预装
投屏失败之所以难定位，是因为”镜像”和”推流”根本是两条链路。镜像是本机画面编码后整体送过去，延迟高、对码率敏感，受保护内容常被直接压成黑屏；推流是把媒体地址交给对端自己拉流解码，本机退化成遥控器。前者问题在编码与网络抖动，后者问题在解码能力与地址可达性，混在一起排查必然得不出结论。
推流路径上最脆的一环是能力协商。发送端按自己认为可用的高规格编码发起，接收端硬解不支持，表现往往是黑屏但有声音、一直缓冲、或者一个不含原因的失败提示。稳的做法是先探测对端声明的能力再选码，协商失败要有确定的回退档位，回退到底还不行就明确告知不支持，而不是无限重试。设备发现依赖局域网组播与广播类协议，在企业网络、访客网络开了客户端隔离、或者跨网段的无线环境里，最常见的原因是根本搜不到对方——这类现场问题不该算应用缺陷。
分发这一侧的碎片化比手机更严重。厂商商店的审核项与材料要求不同，同一份内容要按渠道分别准备；打包与签名规则各家接受范围不一致，装了不更新或装不上的问题常出在这里，要多渠道实机验证而不是只看包能装上。预装渠道还要处理另一组约束：卸载受限意味着用户拿到的是一个删不掉的应用，升级通道由整机厂掌握，出现问题时不能依赖用户主动更新，只能靠服务端下发。
五、开机广告与会员体系：启动链路上的插入点
这一段只讲工程侧是什么，不做价值判断。
开机阶段插入的内容改变了启动链路的形状：广告发生在应用进程之前，应用真正被拉起的时点后移，于是所有以”应用启动”为起点的性能指标都被污染。指标要分段计时，把整机启动、广告阶段、应用冷启动、首帧可交互分开统计，否则优化会打在错误的一段上。埋点时机同样受影响，早期埋点在广告阶段可能根本没到上报通道，缓存与补报策略必须提前设计。
用户可关闭性带来的是实现要求而不是口号：入口要能在无网络时仍可达、要能只用方向键走完、状态要跨重启保持、关闭范围要说清到底关了开机阶段还是应用内推荐位。这几条都需要在功能设计阶段就写清，否则后面全是补丁。
会员体系在电视端的难点是登录与支付。小屏上正常的短信验证码和第三方授权，在大屏上输入成本过高，普遍要借助手机扫码确认，于是引入跨端会话问题：会话如何绑定设备、有效期多长、如何在手机上撤销、登录态过期后怎样不丢播放进度。设备令牌与账号令牌要分开发放和刷新，混在一个令牌里会导致一次换机就把用户全部状态清空。
六、长期生命周期、灰度与是否做电视端：洹拓视角
电视机型的产品周期比手机长得多，一台机型会在网上一路跑到淘汰，期间固件与应用各自升级，组合数量远超测试能力。这决定了服务端必须能够按”机型、固件版本、应用版本”三元组区分请求，否则任何一次接口改动都可能让旧机型全量报错。
| 约束 | 主要失效表现 | 必须做的事 |
|---|---|---|
| 芯片与内存碎片化 | 老机型首帧慢、长时间使用后崩溃 | 能力探测、资源分层、行为退化三层都要写实现 |
| 焦点导航 | 光标跑丢、方向键连按掉帧、退不出去 | 焦点顺序与布局一致，返回语义分层，可见焦点样式 |
| 观看距离 | 远看字太小、灰字看不见、贴边文字被裁 | 最小字号下限、对比度重定标、全局文字安全框 |
| 投屏协商 | 黑屏有声、一直缓冲、搜不到设备 | 先探测能力再选码，明确回退档，网络隔离单独归因 |
| 分发与签名 | 装不上、装了不更新、审核被退 | 多渠道实机验证，签名与打包规则按渠道核对 |
| 长生命周期 | 一次服务端改动让旧机型全量报错 | 三元组识别机型，字段只加不删，未知字段忽略，留回滚通道 |
协议兼容的规则要写死，落地成五条可核对的约束：
- 接口字段只增加、不删除、不复用语义，改含义等于破坏兼容。
- 客户端遇到未知字段必须忽略而不是崩溃，解析层按这个标准写一次并单测。
- 新能力靠版本号或能力标志门控，不允许默认开启后等旧机型报错。
- 服务端下发配置要能按机型分组灰度，并保留一条可立即生效的回滚通道。
- 旧机型不能强制升级，就要假设它长期存在并持续访问线上服务，把它列入回归范围而不是排除在外。旧机型不能强制升级，就要假设它长期存在并持续访问线上服务。
是否值得做电视端，洹拓视角按三问回答。第一问是内容形态：以长时间观看、被动消费为主的内容适合大屏，需要频繁输入、精细选择、多字段核对的业务不适合，遥控器会把交互成本放大好几倍。第二问是交互复杂度：层级超过两到三层的焦点图就需要专门设计可达性与返回语义，成本高于把同一内容做成手机与网页版本。第三问是目标机型：机型分布只能从自家渠道和实际反馈里拿，不能假设”主流机型都能跑”；只要存在无法被服务端识别的机型，就无法做灰度，任何改动都是在做全量发布。
三问里任何一问答不上来，先做只读的轻量版本上线，把机型识别与埋点链路打通，再决定要不要投入完整的电视端交互。