当观众打开 Amazon Fire TV 上的流媒体应用时，他们期望应用能快速启动、易于使用遥控器导航，并可靠地开始播放。在客厅环境中，质量问题会立即显现。如果应用缓慢、令人困惑或不可靠，即使内容本身很出色，观众也可能失去耐心而离开。

为什么团队需要统一的质量视角

本文介绍了 Fire TV 流媒体应用质量蓝图，这是一个由六部分组成的系列文章，面向负责 Fire TV 流媒体体验的合作伙伴和应用团队。每篇文章将涵盖团队应具备的要素、这些要素对观众和负责应用的相关团队的重要性，以及团队和领导者在质量审查期间应提出的问题。它是为对 Fire TV 流媒体应用整体质量负责的人撰写的，无论该人是工程负责人、产品负责人、TPM 还是工程师。在本系列文章的其余部分，我们将此人/团队称为质量负责人。

每篇文章旨在帮助团队共同审视相同的应用体验。哪些方面运作良好？哪些方面仍存在风险？在下一次发布之前需要关注哪些方面？目标是在流媒体应用体验的完整生命周期中更早地考虑这些对话，以便在规划、设计、开发、测试、发布和运营期间考虑质量。如果质量主要被视为最终测试或发布就绪性检查，团队可能会发现重要问题太晚，此时修复难度更大，发布选项有限，观众更有可能在生产环境中遇到问题。

流媒体应用质量不仅仅与应用代码有关，而且很少由一个团队负责。在 Fire TV 上，应用体验取决于许多部分协同工作：应用、目录、登录、订阅、播放、广告、第三方集成、监控、发布就绪性和支持。当问题发生时，观众看不到背后的所有权映射。他们看到的是内容缺失、应用缓慢、缓冲、重复广告或付费内容仍处于锁定状态。在内部，原因可能存在于不同的系统、团队甚至组织中。一个团队可能在查看崩溃报告，另一个团队在查看播放错误，另一个团队在查看支持联系人或合作伙伴端指标。如果这些信号是分开审查的，团队可能会花费太多时间争论症状，而很少时间决定在下一次发布之前需要改变什么。

蓝图为团队提供了一种实用的方式来审查最影响 Fire TV 流媒体应用体验的领域。它还推动审查超越单个缺陷，转向所有权、信号和发布实践。

这与实施指导有何关联

本系列不是操作指南、SDK（软件开发工具包）手册，也不是实施文档的替代品。对于实施指导，团队应继续使用 Fire TV 和 Appstore 文档、SDK 指南、示例代码以及适用的 Fire OS 或 React Native 指导。本系列讨论的是实施工作背后的质量问题：应用体验是否符合观众对 Fire TV 的期望？它是否易于使用、播放期间可靠、生产环境稳定、有用信号支持且发布安全？

六大支柱

蓝图围绕六大支柱组织。每个支柱都侧重于观众体验或其背后的运营模式的一部分。尽管这些文章可以独立阅读，但这些支柱是按依赖关系排序的。在提高性能之前需要了解正在发生的情况，在体验感觉精致之前需要稳定性，在有信心发布之前需要运营成熟度：

  • 洞察与遥测：团队能否看到应用对观众的表现如何、问题发生在哪里以及发布后哪些问题发生了变化？这包括应用健康状况、播放质量、错误、关键观众旅程和发布影响。

  • 性能与效率：启动时间、遥控器响应能力、浏览感觉的流畅度、屏幕加载和设备资源使用情况。在开发期间感觉良好的东西在真实客厅中的旧款 Fire TV 硬件上可能感觉迟缓。该支柱侧重于应用对观众来说是否足够快，而不是它是否通过内部性能关卡。

  • 稳定性与弹性：观众不会从根本原因的角度思考。应用停止工作，这就是全部故事。该支柱涵盖崩溃、ANR（应用无响应）、屏幕冻结、错误处理不当、服务中断和网络中断。如果团队有已知的崩溃场景或尚未优先处理的不可恢复状态，这就是显示的地方。

  • 客厅体验与无障碍：这是一款专为电视设计的应用与一款从移动端移植、仅在技术上可运行的应用之间的区别。遥控器导航、焦点行为、返回按钮可预测性、适合电视的布局、语音支持、无障碍功能。其中大多数问题发现较晚，因为团队首先在桌面或模拟器上测试，直到接近发布时才拿起真正的遥控器。

  • 流媒体体验：视频是否能开始播放、持续播放，并在出现问题时恢复？涵盖点播和直播内容、适用的广告插播、流中错误和恢复。观众的许多“应用损坏”报告实际上是跨越多个服务边界的播放路径故障。

  • 发布与运营卓越：团队能否有信心发布、快速发现生产环境中的回归、无需紧急操作即可回滚，并在下一次发布前从事件中吸取教训？该支柱较少涉及代码，更多涉及发布实践和围绕它的运营就绪性。

下一步

在我们与 Fire TV 合作伙伴应用团队的合作中，最难清晰回答的问题之一是：目前哪个问题正在伤害最多的观众？下一篇文章将讨论如何构建这个答案。我们从洞察与遥测开始，因为团队需要了解应用对观众的表现，然后才能改进它。它着眼于生产环境中的应用健康状况和播放质量、如何识别影响观众的问题以及如何决定首先修复什么。