性能至关重要

性能是观众无需测量即可察觉的质量维度 [1] [3]。当观众按下遥控器，启动画面停留的时间略长于预期时，他们已经在判断该应用是否缓慢且不可用。启动缓慢、菜单卡顿或滚动停滞会促使观众卸载应用并不再返回。

优秀的团队将“性能与效率”视为持续工作，而非周期性冲刺，并将其融入每次变更发布前的审查流程。

性能驱动应用的所有产品特性：优质内容、精妙设计和个性化推荐，都无法承受空白启动画面或导航时丢帧的 UI。观众等待四秒钟才能看到首页时，已经在对其内容目录做出判断。启动迅速且导航流畅时，内容与个性化团队的努力才能真正触达观众；若非如此，这些努力便有投入无回报。

资源效率至关重要

在 Fire TV 流媒体设备上高效管理资源比移动设备更具挑战，因为硬件限制更严格。一款典型的低端手机拥有 8-12GB RAM 和 >3GHz CPU，而低端 Fire TV Stick 仅有约 1GB RAM 和 1.7GHz 左右的 CPU。不同于手机，Fire TV Stick 设备被密封在电视背后的 HDMI 接口中，无法主动散热。应用必须在 Fire TV Stick 的所有资源约束下保持稳定。操作系统会在内存压力下回收内存并终止应用以释放资源。可接受与有问题的差距很小，应用必须在整个受支持的设备系列（包括仍在使用的旧型号）上保持稳定。Fire TV 设备的使用时长也比移动设备更长，因为流媒体应用可能运行数小时而非数分钟。随时间缓慢累积的问题，观众会在一个晚上就感受到，而非数周。

识别性能问题

功能问题或崩溃会留下清晰的调查线索和责任归属。而性能阈值回归不会产生任何警报/崩溃/线索，直到多个此类回归的累积效应在观众信号中显现。

→ 崩溃与 ANR 信号已在“稳定性和韧性”支柱中讨论。

商业理由很简单：快速启动的会话会带来更长的参与度。缓慢进入资源压力的应用会逐渐流失观众，而不会出现足以动员团队的明显故障信号。一个团队可能连续发布三个版本，每个版本在仪表板上看起来都正常，但累积的留存下降会在季度复盘时显现，且无法归因于任何单一变更。严格执行性能标准的质量负责人，正在保护产品所有其他投资的回报。

开发流程中的性能习惯

明确的性能阈值与目标

团队需为冷启动到首帧（TTFF）、暖启动与恢复、导航期间的持续帧率、1080p 与 4K 播放时的内存占用以及空闲 CPU 使用率设定明确目标。目标应设定在 Fire TV 设备认证阈值 [3] [7] 之内，而非恰好在阈值上，以便应用能够吸收新功能与 CX 更新而不超出合规范围。实际基准：60fps UI 每帧预算为 16.67ms。在 Fire TV Stick Lite 上，健康的后台占用应远低于设备 RAM 上限，而非接近上限。这些目标需文档化、明确归属并对质量负责人可见，而非仅存在于少数工程师的头脑中。

良好表现：应用性能 KPI [7] 需在每次发布提交前均低于平台设定的目标阈值。

将应用启动阈值视为 Go/No-Go 决策点

从用户体验角度，应用启动可分为 TTFF（从启动应用到屏幕上渲染首帧的时间）和 TTFD（应用渲染完成并可接受用户输入的时间）。这两项指标直接反映用户决定打开应用后看到黑屏的时间，以及启动后需要等待多久才能开始使用应用。

从速度角度将启动服务分为必需与可延迟。审查并限制应用启动时的网络调用，仅保留必要请求，因为网络流量直接影响启动性能。对剩余的网络请求采用缓存或并行化机制。从后台恢复应用时，尽可能恢复状态而非重新初始化栈。主动跟踪每个启动服务影响的团队，更有可能在不延长冷启动（应用首次启动而非后台运行）的前提下发布 CX 改进。

良好表现：所有应用启动条件均遵守文档化的启动阈值 [7]。在所有 KPI 阈值达标前暂缓应用发布。

在真实环境中测量性能指标

在支持范围内的 MVD（最小可用设备）系列及真实设备上分析应用，因为问题最早会在这些设备上显现。最小可用设备是规格最低、最可能率先出现性能问题的设备。需在长时间使用和受限网络下观察性能指标，使用设备端分析和内存工具 [3]，而非仅依赖开发测试或理想环境。关键指标需从真实生产数据采样，而非仅来自内部测试运行。标准测试计划应包含在符合观众最大使用时长的场景下对应用进行长时间连续使用的测试。

良好表现：确保所有性能指标数据点均在 MVD 设备及目标设备平台上采集。这些数据是应用发布的签核点。

资源消耗阈值

应用资源监控始于应用包大小，延伸至用户交互时的内存/CPU 消耗。内存预算应在发布测试中强制执行，回归问题应视为质量缺陷而非后期小问题。若未及早处理，资源使用可能在多个版本中累积成观众感受到的菜单卡顿和启动延迟。第三方服务（如分析、广告、崩溃报告和 A/B 测试）应在集成前进行分析，并与第一方代码适用相同的资源标准。

良好表现：应用及集成服务的所有资源利用率测量均在设备定义的质量阈值内。 [7]

设备热量占用

由于 Fire TV 设备由市电供电且密封在电视后方，相关考量是热量与功耗效率，而非移动设备关注的电池续航。应最小化持续 CPU 和 GPU 使用，并在可用时优先使用硬件解码。需在真实观看场景下测试应用，以分析并确认长时间使用不会增加设备热量测量值。降频很少以单一可见事件出现，而是表现为长时间观看会话后半段的渐进式丢帧和音视频漂移。

良好表现：确保应用发布时进行长时间浸泡测试，以检查热量影响。

性能是质量负责人的指标 [3]

性能数据与崩溃数据并列于发布审查中。每项新功能引入都应回答一个问题：这在启动时间和资源上会带来什么成本？SDK 采纳决策需考虑占用情况，而非仅考虑能力。当发布决策未将性能纳入讨论时，差距会在后期以观众行为而非单一工单的形式显现。这种所有权至关重要，因为 200ms 的冷启动回归不会产生警报或升级，必须主动查找。质量负责人的关注能使缓慢移动的信号变得像明显问题一样清晰。质量负责人应负责应用对质量指标的遵守，并将性能测试纳入开发流程 [6]

良好表现：每次发布就绪审查都携带性能数据与崩溃数据，并仅在审查性能影响后签核功能发布。 [7]

质量负责人问题

这些问题旨在供质量负责人在质量审查、发布 Go/No-Go 讨论和发布后复盘中使用。强有力的回答需由数据和明确的责任人支持。

启动与恢复

团队的 TTFF 和可交互时间按设备系列细分是多少？该测量是否在支持范围内的 MVD 上、在真实条件下进行？

开发团队是否已实施提升启动性能的性能指导 [5]。

当观众在 30 秒、5 分钟和 1 小时后返回应用时，是看到保留的状态还是完全重新加载？这种行为是否是有意的？

帧率与流畅度

团队是否拥有来自真实观众的帧率数据？团队能否识别出 UI 导航中最卡顿的屏幕、交互和设备型号？

新的 CX 功能对 UI 响应性和导航流畅度有何影响？

内存、CPU 和资源预算

团队在启动、资源密集操作和长时间浸泡后的内存占用是多少？

该占用在过去几个版本中如何变化？

团队如何在发布测试中分析资源使用，并根据趋势进行调整？

最近一次在扩展会话中进行堆分析以检测缓慢泄漏是在何时，由谁负责结果？

热量与持续行为

团队是否在目标设备上以真实设置运行了一小时浸泡测试，并确认无热量降频？生产遥测是否能显示降频事件？

应用在前台但无内容播放时的空闲 CPU 使用率是多少，该数值在最近版本中是否发生变化？

性能文化

启动延迟、UI 响应性和资源占用是否是每次发布 Go/No-Go 标准的一部分，并附带数据？团队能否指出上一次在发布前捕获性能回归的版本？

当观众报告缓冲或播放降级时，团队是否有设备端遥测来确定原因是在客户端还是网络端，再升级到流媒体管道？

下一步

性能与效率是蓝图的第二个支柱。下一篇将介绍稳定性和韧性。这是未管理的性能压力最常表现为崩溃、挂起和不可恢复状态的地方，也是同样的测量工作开始回报的地方。后续支柱建立在此基础上。流媒体体验依赖健康的设备端运行时。发布与运营卓越依赖于在此处建立的性能关口在后续每个版本中得到执行。