一、互动视频概念

互动视频介于视频与游戏之间，围绕剧情，兼顾游戏性。核心是通过互动，让用户有能力参与到剧情发展中去。

互动视频交互案例

优酷正在搭建支撑互动剧生产与播放的技术平台。客户端作为呈现互动视频的重要载体，核心职责就是定义一套协议标准，并基于此搭建互动引擎，以便快速而灵活地支持互动剧的播放。

二、优酷如何做互动视频？

互动视频平台的建立，需要考虑如下方面：

1）如何表达普通视频与互动视频的关系，划分出两者的功能边界；

2）如何充分利用原有的基础视频服务，支撑起互动视频播放服务；

3）如何设计一套客户端技术框架，让互动和播放协同高效地运转。

概念与模型的建立

针对传统的视频内容，优酷内部实质上已经有了一套在行的概念，包括剧（show）、集（video/episode）等，然而面对互动视频这种新的业务形式，仅有这些概念是不够的。为保证整个业务上下游能够顺畅的沟通，优酷需要基于原有概念模型，扩展出一套互动视频的领域概念模型。

领域概念的建立需要考虑如下因素:

1）能够准确地表达领域知识，传递核心概念，界定功能边界；

2）概念术语需要简单明了，让参与的各方角色达成一致的理解；

3）需要避免与已有概念冲突，最好能够复用或拓展已有的概念。

首先我们梳理了互动视频业务涉及到的各方角色。这些角色不仅包含内容生产者、内容消费者，还包含设计实现整个平台能力的产品、开发、UED、运营、测试等。

互动视频涉及到的角色

其次我们协同各个参与角色，讨论确定了互动视频中的概念及术语，并建立起与普通视频概念的映射关系。

领域概念与模型图

更完整的概念描述，可以参考技术标准。

概念能够反映逻辑或基本功能，比如：

1）剧的概念保持不变，在普通视频和互动视频中，用来描述通过一定关系组织起来的视频集合；

2）（互动视频）片段与（普通视频）集在视频实体上是一致的，可接受播放器的播放/暂停等控制；

3）互动视频的播放需要由一个“互动引擎”驱动，而非单纯地由联播、推荐等业务逻辑驱动；

4）视频片段的播放顺序，可由“互动脚本”描述，根据用户的操作行为或产生的数据来推进；

5）视频片段上，可以投放互动行为，交互界面可以由不同的技术方案承载。

优酷端侧工程的兼容性考量

在考虑将互动视频落地到优酷 App 中时，我们考虑了如下几点：

1）互动视频虽然与常规视频有所区别，但播放的基本元素都是视频，所以理论上可以复用已有的基础设施，包括播控、分享、评论、倍速、清晰度等一系列功能，鉴于播放页上已经实现了这些功能，所以我们决定在已有的播放页上做扩展，充分利用已有的轮子，使用优酷播放页已有的统一播放器业务框架选配业务能力；

2）我们希望尽量少地侵入已有业务，一种应对思路是，沿用以前在播放页打开视频的接口，最朴素的一种情况是传递一个视频 ID 即可打开互动视频。这要求除了播放页，其他业务场景可以不去理解“互动视频”这样一个新概念，在进入播放页之前，用户在形式上可以不知道某个视频 ID 是否是互动视频；

3）老版本的 App 并不支持互动视频。虽然可以通过版本定投，将互动视频限定在新版本中，但是如果新版本的用户分享视频到了老的 App 上，就会产生异常。一般做法是，当互动视频投放到老的 App 中时，会播放一个“打底”视频。

App 在进入播放页后，且在真正播放视频内容之前，有一次播放服务请求。利用这次请求判断互动视频，进而进入互动引擎的逻辑分支，能够方便地解决上述 3 个问题。

互动视频起播流程图

上图中展示了在进入播放页，通过视频 ID 访问播放服务之后，判断是否为互动视频，如果是，则加载互动引擎，驱动互动视频播放。在老版本的 App 中，代码并不会判断播放服务中新增的字段，只会走原有逻辑，即播放视频 ID 对应的“打底”视频。

互动视频端侧的交互性考量

除了需要串通工程上的链路，用户交互上也有一些需要特殊处理的地方。普通视频播放时，除了暂停/倍速等操作形式外，不会在剧情内容上与用户产生交互，弱交互的普通视频在小屏幕上展示没有太大问题，然而对于强剧情交互的互动视频而言，小屏会降低用户的使用体验。为了给互动视频带来沉浸式的体验，我们在播放页小屏状态时，会中断视频的自动播放，并通过文案引导用户打开全屏播放。

三、客户端互动引擎

领域概念的界定、播放流程的确定，都为进一步设计客户端 SDK 准备好了前提。那么，如何支持互动视频需要的特殊功能？如何保证这些功能需要具备的扩展性？这些，就是上文中提到的“互动引擎”所需回答的内容。

互动引擎（Interactive Engine）

为确定互动引擎需要支持的功能模块，我们结合整个技术体系，从端侧角度，梳理了如下需求：

1）能够根据互动视频场景需要，有选择地使用播放器原有的基础能力，屏蔽播控方面的差异；

2）能够获取并理解“脚本协议”内容，创建运行时需要的视频节点，更新节点的状态，驱动节点的变化；

3）展示的互动界面能够动态下发，渲染模块要具备复用性，既可以用来实现节点，也能用于实现事件；

4）需要支持展示剧情大图，并能将用户的播放进度定位到大图上，以避免用户在互动剧中迷失。

技术需求驱动了功能模块的展开，整体模块图如下：

技术体系及功能模块

双虚线上面是内容平台与服务端，下方蓝底区域为互动引擎及其模块。互动引擎架构在统一播放器业务框架之上，关于统一播放器业务框架，可以简单地理解为播放器上面的业务插件管理器，利用它可以方便地插拔播放器上层的业务。此处不再赘述。

剧情主轴: 节点与事件

上文描述了引擎在功能模块上的垂直划分，这些功能模块通过统一调度运行在时序上。为描述这种时序，我们认为互动视频有一个剧情主轴，剧情主轴填充自视频节点，而在主轴之上，可以配置提供互动的事件点。模型如下图所示：

内容主轴与其上行为

剧情主轴由节点横向铺满，节点的生命周期由互动引擎控制。为了兼容后续可能的变化，节点被设计成拥有多种状态。当前主要的节点是视频节点，视频节点除了具备节点的基本属性、能够管理视频状态之外，还能够触发产生互动界面。互动界面是承载用户行为的主要形式，它通过节点上的事件（Event）触发，扩展（Extension）是互动界面的承载方式，它包含了一套协议接口与几种默认的实现：

Event 及 Extension 设计

通过统一协议，可以屏蔽 Extension 的实现细节。目前主要使用 Weex 来实现。互动视频中的 Weex 页面往往与视频内容相关，所以其实现中还包含 UI 适配逻辑以及用于调试的 Debug 逻辑，此处不再赘述。

大图设计: 模型与调试

剧情大图是为了避免用户在互动视频中迷失所设计的视频片段关系展示形式。模版化的剧情大图目前主要有 2 种展示模式：a. 将剧情树上的所有视频片段都展示出来（左），b. 只展示用户当前剧情路径上直接关联的节点（右）：

两种模版化剧情大图示意

将剧情节点全部展示的好处是，所有视频节点一览无余，不会有隐藏的节点，用户拥有更强的控制感；但这种方式会存在 2 点不足：1. 大图画布必须支持水平垂直方向的滑动，用户的操作会变得复杂；2. 画布的内容左小右大，呈现（反）▶ 形状，当视频节点比较多时，有效内容占比较低。优酷使用了单轴滑动的剧情图（右），横屏全屏时上下滑动，竖屏全屏时左右滑动。

剧情图数据结构的本质是有向无环图。为简化图的处理，我们抽象出了专门处理图的抽象工具类，以实现遍历、过滤、转换等常规功能。在具体 UI 上，iOS 使用 UICollectionView 来实现，Android 使用 RecyclerView 实现。

为降低当前路径剧情图开发过程中调试的难度，我们开发了相应的可视化工具，能够在 PC/Mac 上展示出完整的大图信息，如下所示：

剧情大图(左侧)-调试工具图(右侧)

其他技术与功能点

在技术设计上：我们从概念出发，逐步落地到优酷工程及代码上；从需求出发，逐步落实到模块及功能的拆分上。业务架构的设计，降低了后续一系列技术迭代的实现成本，如支持横竖全屏、预览模式等。我们也验证了互动引擎对其他类型节点支持的有效性。

一个互动章里可能会多次更新播放的视频片段，为不打断用户的观影体验，视频的预加载是必须的。优酷优化了视频预加载逻辑，能够在视频播放的合适时机，预加载后续的视频节点，以此来达到视频片段之间无缝衔接的效果。

作者 | 阿里文娱无线开发专家拂铭

创作场景

优酷互动视频技术设计揭秘