新西方互动视频的挪动端架构设计

Zoey

网络视频办事形式，阅历了点播、直播、互动直播的开展进程。传统的一端收录、一端播放，交流依托文字评论的形式，用户参预感不强。而互动视频技术，允许收看方实时参预互动，拥有即时性和互动性，经过加强反馈、剧情参预、内容探究等形式为观众带来丰硕的观看体验，并能经过互动发明内容和价值，因此更能吸引受众。
与常见的文娱视频不同，线上教育畛域，会更需求孩子和教师进行实时的互动。互动视频中针对 K十二 教育的特殊场景做的专门优化，能够为不同窗员提供共同的学习体验。
本文将对新西方互动视频零碎的挪动端架构设计做一个总结，包孕过程当中的技术演进以及后续的优化构想。
一、设计思绪与总体架构
1.1 模块拆分和设计
为了肯定互动视频反对的功用模块，咱们从挪动真个角度，梳理了如下需要：
可以按照互动视频场景需求，有选择地使用播放器原本的根底才能，完成包罗倍速、快进/快退等播放管制功用；
获得并了解所定义接口协定的内容，创立运转时需求的节点，更新节点的形态，以及驱动节点的变动；
按照播放过程当中通过的节点，实时渲染入列表，并反对随时的跨节点活动；
播放功用高度可用，反对包罗课件/视频/音频等多种播放素材。
按照以上的需要，咱们对总体的功用模块进行了划分和根本设计：


在下面拆分的模块中，播放内核架构在依赖组件上，次要提供节点的协定数据申请、解析包装、缓存以及中心的播控、节点流转等功用，依赖组件则是提供了播放、日志上报、录音、测评等更根底的功用。
1.2 剧情轴与节点流转
下面咱们为了知足根本功用和需要，进行了模块的拆分和设计。这些功用模块，驱动着互动视频中的各种节点在一个固定的时序上进行流转。


咱们定义一个剧轴线，剧轴线由节点横向铺满。
在知足目前需要的条件下，节点自身被设计成多品种型，例如视频/图片/课件/音频/答题等，其中视频/图片/音频等多媒体节点，自身自带时间轴属性，这种型的节点，在零碎外部，也被定义为 Base 节点。与 Base 节点对应的是 Active 节点，Active 节点反对多节点/循环节点的繁杂跳滚动作，同时承载用户的交互行动并输入交互后果，而下一节点的跳转对象就由该交互后果抉择。
1.3 混合节点设计
在放弃扩展才能的设计准则下，Active 节点的本能机能可由原生或者 H5 来进行承接。而为了反对 H5 作为容器的条件下，节点的流转仍然能够由一致的节点管制模块来进行协调，需求建设一个 H5 与原生的交互通道，并确立对应的交互协定。


在下面的设计中，节点管制模块接纳遵守自管制协定的信息，原生节点间接与之交互，而 H5 节点，则是经过 Bridge 通讯协定，进行直接交互。这类管制协定的一致化，能够允许节点管制模块处置非原生节点的流转，虽然目前零碎中已反对节点属性仅为原生/H5，但准则上保存了足够的扩展性。
二、播放技术优化
2.1 视频秒播计划
无论是直播或点播，视频是不是可以流利播放会间接影响到用户的观看感触。所以在互动视频的设计中，视频播放功用的流利度，是重点斟酌的内容。在互动视频一期的时分，咱们采用资源全量下载的计划，在剧情试图进入某一个场景节点的时分，提前获得一切该节点的资源信息，并等候资源下载终了之后，才进入该场景，这类计划的益处是显著的，在单个场景履行的外部，用户能够获取最为极致的流利体验，但存在的弊病也一样无奈疏忽，在场景资源较大的状况下，用户等候下载资源的时间太长，会致使较差的体验。
为理解决这个问题，咱们在二期中针对性设计了秒播计划。


在这个计划中，视频被视为一个个分段，当申请数据的时分，播放器不间接与外界进行网络交互，而是经过当地搭建的 HTTP 办事器进行直达。该办事器模块会剖析视频流申请对象，从中获得当次申请的数据 Range，并按照该 Range 到内存找寻缓存，假如找寻不到将会从磁盘缓存中查找，一样查找不到后，就会从网络中拉取。
这类分段的数据申请形式，能够灵敏的响应播放器播控层的管制，在播控操作播放进度，申请 Range 产生大幅度腾跃性变化的时分，传统的视频流申请按照战略不同，可能会抛弃长渡过短的视频数据，也可能泛起反复下载同一段视频数据的状况。而 HTTP 当地办事自定义强，经过完成在获得到缓存之后，实时调剂网络申请视频数据 Range 的形式，加强了灵敏性，也进步了数据的可复用性。
2.2 节点预加载技术
秒播计划进步了数据的可复用性，但若视频是初次播放的状况，无论是内存又或者磁盘，都没有该视频的缓存数据。这类状况下，该视频的播放流利性，无奈失掉足够的包管。针对这类状况，设计了节点的预加载技术，在场景节点尚无在咱们的剧情轴中铺开以前，就会染指其外部的资源下载过程。


视频轴列表，次要分为两品种型，一种是线性列表，此外一种则是树状列表。针对线性列表，采用预缓存一切节点的计划，包管了线性互动视频的播放流利性，而针对树状列表，则按照以后场景节点来获得下一层的一切节点，并进行缓存，而因为树状列表的状况多样性，没有阅历的节点数据常沦为有效数据，所以每次进入一个新的场景节点，都会做有效资源的革除以管制缓存的过快增长。
当进入一个新的场景节点的时分，假如判别该节点资源已下载终了，会间接对当地的节点数据进行加载，并展现该节点。而假如该节点资源暂未缓存，会间接对其进行展现，并将在展现过程当中下载的资源缓存在当地，以备下次使用。
三、平台 SDK 化驱动的技术变迁
3.1 SDK 的分层设计
在业务开展的过程当中，互动视频在阅历多个迭代之后，不乱性有了一定水平的加强。在基于业务的斟酌下，需求将这个零碎从原本的运用外部进行抽离，并封装成 SDK，供其余业务部门疾速接入使用。而因为以前的架构设计虽然最大水平斟酌了外部功用的可扩展性，但在例如接口隔离，代码解耦等方面并无做到最佳，所以这里从新进行了一次模块设计。


在下面的架构中，SDK 总体被划分为 3 个层级。最底下的 Service 层级是提供最根底功用例如录音、测评、数据解析、视图 layout 的模块，第二个层级则是原先的互动视频的播放内核，处置互动视频的包罗节点跳转、数据下载缓存、播控等功用，而最顶部的层级则是接口层，这一个层级的泛起次要是为了联系 SDK 外部完成与详细业务方代码的耦合瓜葛，同时帮忙 SDK 在需求进行外部代码大幅改变的时分维持内部接口的不乱性。
3.2 打包与散发
SDK 化之后此外一个需求斟酌的就是二进制包的输入问题。目前的阶段，SDK 发版频率较低，打包效力也对比高，暂没有云端流程化打包的须要性。所以在目前的设计中，打包零碎依赖 cocoapod 的插件机制来进行，在 cocoapod-package 的原有功用上做进一步扩展。


目前的插件完成了当地打包的条件下，同时反对了近程更新 tag 号，自定义注入组件等功用，并反对一定的后续扩展才能。
四、总结
互动视频零碎从概念登程，逐渐落实到工程的代码上；从需要登程，逐渐落实到模块拆分以及后续的 SDK 封装发放上。在架构的设计上，并不是变化无穷，需要的变化驱动设计的变卦，中心思想是在设计中保存足够的扩展才能。
在后续的优化上，混合节点是一个值得讨论的标的目的，目前零碎中 Active 节点反对原生和 H5 节点的才能，能够尝试扩展到反对相似 Weex、Flutter、ReactiveNative 等混合开发的框架上，在机能和开发效力上做出衡量取舍的同时，为业务提供更多可能性。
作者:陈超邦
出处:http://mp.weixin.qq.com/s/1nDUdqADRl5T2iF-ZelRPA