苹果电视案例研究：我们如何保持领先地位，以及我们在此过程中学到的知识

今年早些时候，苹果公司在主题演讲中向全球观众分享了我们的PLUS7应用程序，以作为卓越典范，这是工程团队引人入胜的旅程的结晶。

当Apple宣布推出第四代Apple TV时，我们知道它将非常适合扩展我们的PLUS7产品。 Apple TV简单而优雅的体验非常适合以允许用户直接获得所需内容的方式进行设计。

基于我们对iOS和现有Apple框架的了解，开发tvOS应用程序的过程非常迅速，并且确实使我们的工程师能够在更大的屏幕上重新定义PLUS7观看体验方面取得突破。

迅速

随着Swift仍在不断发展，选择使用它并不是没有一定的风险和开销。经过评估，我们认为它已经足够成熟，可以在生产应用程序中使用，这将是我们前进的道路。尽管我们可以从iOS实现中重用Objective-C代码，但我们还是决定从头开始，并且tvOS构建中的代码是100％Swift。我们现在认为这一决定是一个好决定；甚至我们的测试版本也非常稳定，并且代码行比其iOS版本少得多。此外，我们现在可以在iOS版本的未来版本中使用可以说更好的Swift代码。

建造

我们最初有一个应用程序的原型版本，该应用程序是在业余时间构建的，没有设计团队的投入。最终，随着构建的进行，迭代了该版本。我们遇到的主要问题之一是与tvOS或位码不兼容的第三方SDK。有了一点点建议，我们就能解决其中的大多数问题，但我们用于视频广告的SDK除外。

在iOS和Android上，我们使用Google的IMA SDK进行视频广告，目前与tvOS不兼容。显然，在没有视频广告的情况下针对苹果电视推出PLUS7对我们的业务而言并不是可行的策略。因此，我们决定自己在Swift中实施VAST规范。我们看了一些（旧的）开源VAST实现，不幸的是结果证明不合适。乍一看，VAST实施看起来相当简单。

但是，事实证明，这比乍一看要复杂得多。视频包含“提示点”，这些提示指示何时播放广告时段。有三种类型的广告集：前片（在流之前播放），中片（每个视频在流中间播放几个）和后片（在流之后播放）。每个提示点都映射到一个广告“ pod”。广告连播由许多广告组成。因此，第一个预卷可能包含一个15秒的广告。第一个插播广告连播可能包含4个不同长度的广告（15到60秒之间），接下来的5个不同长度的广告，依此类推。

视频开始播放时，我们进行一次查询，该查询返回每个广告连播中的每个元素。但是，每个广告都是对广告服务器的递归广告调用，您必须不断查询它，直到获得实际的广告素材。第一台广告服务器可能没有内容，但会转到另一台广告服务器，依此类推。另外，遍历的每个广告服务器将为播放期间可能发生的每个事件（例如，播放，播放，暂停，停止等事件的每个四分位数）添加自己的跟踪URL。此外，沿着特定路径向下移动广告服务器可能会导致无限循环（！）或播放错误，在这种情况下，将应用特定规则。

正确执行VAST规范至关重要，因为我们的业务收入取决于此。在1.0版的开发上花费的大部分时间都花在了这项工作上。

视频播放器

在向用户提供无缝体验的同时播放内容和视频广告（是独立的视频流）并不是一件容易的事。每个视频广告都会提前获取，存储在列表中，然后传递给tvOS API提供的视频控制器。在每个广告序列之后，在不同的控制器中暂停和恢复内容。向前寻找一个或多个“提示点”意味着我们必须在广告连播中播放最后一组广告，依此类推：如果足够耐心的话，用户也可能会进入帖子列表。

我们会尽力提前获取所需的数据。只要我们有足够的信息来播放预告片，我们就会做，然后继续执行对特定广告的其余请求，以使用户不必等待每次广告播放时就发生这种情况。

用户界面

由于遥控器的特性，Apple TV体验具有一些独特的功能。我们的第一个迭代具有多个选项卡的网格视图和一个主视图/详细视图。它起作用了，但是有一个明显的缺点，就是必须过度垂直滚动才能简单地浏览。得到反馈（并亲自使用该应用程序）后，我们大大简化了导航，并在主屏幕上创建了多个水平滚动收集视图，并在“搜索”屏幕上快速过滤了已知内容。

结果：