做 OTT 设备相关的开发有一段时间了，计划写一点关于这些设备上开发商学习到的经验和以及比较困难的部分。这里面有非常多反直觉的东西， 它和我们传统 WEB 开发有些区区别。

设备老化

这个是我觉得自己在从 WEB / Android 开发转型 OTT 开发面临的一个问题。电视和手机是完全不一样的消费场景。手机厂商每年会头发大量的资源做手机的更新，但是电视不一样。对于很多人，可能手机三年或者四年就计划换新，因为手机迭代的功能非常快，几年不换，就缺一些功能了。由于手机已经早已拜托了打电话单一功能的限制，变成了多功能的娱乐设备。很多人会用来看视频， 玩游戏，拍照等。

然而电视或者 OTT 盒子，它目前为止娱乐场景非常单一。你只能把它放到家里，而且时间比较单一，晚上或者周末。没有人出去旅游，拿一台自己的 FireTV stick 去酒店播放。所以他们的更新频率会慢道七八年，甚至10年多。没错，我们的数据反馈出有超过大部分用户依旧用着七年前的设备，超过十年的设备已经运行着。

平均更换周期： 根据市场调研公司 Circana（前身为 NPD Group）的最新数据，美国消费者平均每 6.6 年 会更换一次电视。
电视机“年龄”： 目前美国家庭中正在使用的电视，平均“年龄”大约为 5.2 年。值得注意的是，约有四分之一（25%）的电视使用时间已经超过了 7 年，这意味着这部分用户即将进入换机窗口期。

兼容性问题

随着设备更换迭代的问题，我们就必须面临兼容性的问题，10年 Android TV 或许都迭代了很多版本。如果使用 WEB 的话，你必须做好一些新 API 的兼容，比如我们关注在 Media 层，其中 MediaSource 在各个 Chrome version 的支持也不一样，有些 API 支持，有些 API 不支持，你最好能够有这个低在里面，确保能够捕获这些差异信息。

除了本身设备的老旧引起的兼容性问题，我们 OTT 面临的另外一个问题就是设备型号和设备厂商太多了。智能手机时代我们面临的最多就是 Android / iOS 阵营，而 OTT 时代，由于很多厂商的电视制造时间远比智能手机出现的长，比如

• Sony
• Samsung
• LGTV
• Hisense
• TCL

比如机顶盒厂商又完全不一样：

• Comcast
• Android TV
• FireTV

这些面临着传统 TV OS 和 智能 OS 的迭代更新，因此你会可能面临着 Android / Web 技术的夹杂，包括每个厂商的定制 SDK，想想肯定就非常头痛。

这些绝大多数厂商大多提供 WEB 技术栈的原因

• 迭代更加快速
• 兼容性问题适配更快
• 相对技术栈更为成熟

用户或许对性能体验要求没那么高

如果我们做手机 APP 的开发，大家都非常关注性能体验，比如什么首屏时间，用户起播时长等等。由于 OTT 设备本身老化和娱乐场景的单一，用户其实反而没有对极致性能体验有那么强烈的要求。

Performance < Stability

你视频进入起播0.5秒和你起播2秒，其实带来的优化效果不会有那么特备明显的增长。反而让用户能够完成整个视频 Session的重要性高过起播的优化。

我们观看一部剧集，其实是一个单一的事情，我不会边看剧集，然后再电视做其他的事情，我对目标的期望值就是能够顺利完成，所以我们尝试很多实验，stability 比如对错误的优化处理，远超过所谓某些体验测指标，带来的反馈更好。

用户问题追踪

这个问题是由于机型庞大带来的，如同我们收到一个用户反馈，关于无法播放的问题，但是你的大盘不会因此播放，它或许就是某个机型的兼容性问题。但是我们实际在上线前测试，不会一一覆盖，因此不可避免这样的问题。因此做好线上问题的追踪非常重要。

这里就涉及你如何进行快速维度的判断，播放问题最终都会落实到用户中断了播放，而给予播放中断维度非常有用

• 设备型号
• Chrome 版本
• 播放错误信息
• 视频编码
• 视频内容 ID

等等，这些能帮助你快速定位是否是规模性问题。

而你要构建一个完整的播放 Stage 列表，确保用户退出再什么 Stage，然后你要有一个基本 API Progress Pass score. 这样你能快速确认它中断在具体哪个 API 的执行下

总之 用户日志的设计是需要非常细致而又 Smart 的。