神刀安全网

无线端的弹幕实现方案

无线端的弹幕实现方案

前段时间做了游戏的相关业务,其中弹幕相关的内容自成一块。弹幕已经不只是最初的视频弹幕了,战火已经烧到了评论区,烧到了手机淘宝的首页搜索结果。作为一种近几年迅速燃起的内容呈现形式,有必要适时引入,对于休闲化、娱乐化的业务更是如此。那么,要做出一个较为完整的弹幕效果来,需要哪几个部分呢?尤其是,在集团内部,怎么快速地搭建起一个可用的弹幕框架来?本文分3块来阐述。

弹幕渲染层

目前弹幕的呈现载体主要是Web、无线客户端。因为我们的工作主要针对无线端,所以本文主要以无线端为例——包括iOS,Android两类系统。

碰撞检测

弹幕无非是动画,是分布在时间轴上图像的连续运动。自然可以用Native的动画来实现。不过弹幕动画有一个重要的特征,即保持动画元素(sprites)尽可能少地碰撞,以使弹幕承载的信息能够清晰地传达,执行碰撞检测是必须的。但弹幕里的碰撞检测相对简单,因为弹幕的运动轨迹相对简单并且容易预测,所以只需要在一条弹幕将要显示之前,根据已经显示的弹幕(位置、速度、活跃的时间等)来确定他的运动轨迹。以尽最大可能地在其生命周期内不与已有弹幕冲突。

无线端的弹幕实现方案

弹幕的同步问题

弹幕不是超然而独立的,往往相伴业务场景而生,目前可见最多的场景是视频,直播或者录播皆有。到此时则涉及到一个时间同步的问题。比如,一位用户在看一段时间第314s的时候突然有感而发,发出了一条弹幕,自然希望其他观众能够在看到视频此刻看到他的弹幕。所以一条弹幕上屏的时间是需要明确的,想想那些年文不对题的字幕君吧。那么,如何实现呢?一般,可以为一条弹幕提供一个时间点delay,当到了这个时刻,由控制器把这条弹幕播放出去。但仅仅这些是不够的,因为视频还存在暂停,存在快进快退,所以你必须也为弹幕组件提供类似的接口,以期能和视频内容同步。其他的应用场景也是类似的。比如下面的样子(弹幕在向左运动):

弹幕的样式

弹幕的运动样式主要有两种,一种是横向的过场弹幕,一种是纵向的浮动弹幕。弹幕的内容形式不外乎一段文字或者图片,其中以文字为主。对于文字,则有文字的颜色、背景、字体、边框等属性,这一切必须是灵活可配的。当然实际应用中一个APP需要的是风格统一的、优雅美观的弹幕动画。所以弹幕的方向不要太混乱,不要有太多不一样的主题配置。你可以定义几类色调协调但样式不同的弹幕,然后由业务代码决定使用哪一种风格的弹幕。

渲染效率

性能直接关系到用户体验。在绝大多数场景中,锦上添花的弹幕往往伴随着具体的业务逻辑,业务逻辑会占用CPU——甚至很高的CPU,比如视频解码———所以弹幕动画应该尽可能地使用GPU渲染。为应对线上可能的大规模弹幕的情况,本地最好也能测试到大量弹幕的情况。可以使用一个定时器,模拟客户端频繁接受渲染弹幕的情况,看看实际中弹幕的性能究竟如何。

限流

弹幕稀稀疏疏地铺满半屏窗口,朦胧中犹抱琵琶半遮面的感觉,自然是最好的。但万一遇到弹幕决堤,内容疯狂涌来,那当如何应对?渲染内容层层堆叠,既看不清,又降低了系统应用性能,为此可以在业务或者组件中选择限流。

弹幕数据层

若不考虑弹幕在用户间共享,只需下图左侧的模块即可;若需引入弹幕共享、存储功能,则如下图右侧所示。

无线端的弹幕实现方案

但实际情况往往比这复杂。弹幕很多时候是实时的,最好使用长连接来传输数据。业务导向的项目,很少从零开始开发专门的弹幕服务通道,而是尽可能地应用已有的服务组件。淘宝在长连通道上有多个选择,但其功能又是不尽相同的。这种不同也会带来弹幕实现方案的不同。比如通道A支持订阅功能,消息会根据订阅关系分发;而通道B是单纯的通道,订阅关系由业务方维护,凡是发送到客户端的消息都会接收,所以流量需要业务服务端来控制。

经过服务端的必要性

仅仅使用长连接通道是不够的,还需引入业务服务器,其原因如下:

  • 如果长连通道不支持客户端发送消息,那么弹幕的发送要走其它的接口
  • 因业务原因,需要统一多个长连接通道,以便更好地做 多端同步,故引入中间服务器做协调
  • 一些业务相关的需求,不适合在长连接服务器上做,比如内容过滤、弹幕存储、服务端限流等

整体的数据流如下图所示:

无线端的弹幕实现方案

消息格式制定

通过长连接传输的弹幕消息会有一些附加数据需要考虑,比如弹幕的样式、出现的时间,随着业务的扩展,可能需要更多的辅助字段。所以弹幕消息必须能够向后兼容,一般可设置为message,version两个字段,message为纯粹的json字符串,version表示消息的版本号。先解析version,根据判断得到的version选择响应的解析样式。太多的附加信息会降低数据的利用率,此是需要权衡的地方。当然,如果针对的是在线视频业务,弹幕的流量相比于视频流而言,就显得不那么重要了。

自发的弹幕消息

主要有两种:

  1. 用户发送了弹幕消息后,通过网络发送消息的同时直接将弹幕数据上屏,以提升用户所见即所得的体验;当收到相同的弹幕消息后,将消息抛弃。
  2. 用户发送了弹幕消息后,通过正常的网络接收消息然后渲染呈现,这样会因延时损失一定的用户体验,但逻辑简单,并且可以控制所有弹幕数据。

弹幕服务层

主题维护

主题代表弹幕消息围绕的中心。在不同的业务场景中,主题的呈现方式可能是不同的。在视频直播业务中,主题代表了一个个直播房间,弹幕围绕着视频展开;在新闻咨询业务中,主题代表了一则则新闻,弹幕围绕着新闻展开。客户端与主题存在多对一的关系,如下图所示:

无线端的弹幕实现方案

用户U1、U2订阅了主题T1,用户U3、U4订阅了主题T2。由于处于不同的语境中,U1、U2发送的弹幕U3、U4应该是不能接收到的,反之亦然。很自然服务端需要维护一个用户到主题的映射表简单的实现是,客户端监测到用户进入特定主题之后,发送一条网络请求登记这样一条订阅;用户离开特定主题时发送网络请求注销登记。但由于实际客户端运行场景复杂,离开特定主题不一定来得及发送网络请求。补充方案是,由客户端每隔特定时间心跳一次,用以告知服务端维护映射表。一旦服务端一段时间没有监听到心跳信息,就取消映射表中的一条订阅。这里需要注意的是,服务端需要防止心跳的伪造,否则可能映射表可能会因攻击而混乱掉。一旦映射表正确建立,用户发送的弹幕消息就可以准确传达到相同主题的用户客户端了。

弹幕存储

对于直播等即时性业务,弹幕数据一般没有重播的必要;但是对于录播,则需要持久化弹幕,如是方能在其他用户看视频的时候看到其他人发出过的弹幕消息。持久化这类弹幕数据,必须在存储弹幕的时候带上弹幕对应的时间点。在用户进入了某一主题之后,批量返回给客户端对应的弹幕数据,由客户端将弹幕数据对应到视频业务响应的时间点上;如果此主题对应的弹幕数据很多,服务端可能实现做一定的筛选;对于录播同时新发送的弹幕,则由服务端记录并添加到对应的弹幕数据列表中。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 无线端的弹幕实现方案

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址