【Vue-baberrage弹幕插件重制(3)】中心分派和竞争获取的思考

目前已经完成了一个版本,却是引来了更多的思考。
主要要思考的问题有:

  1. 如何减少帧单位内的计算量
  2. 如何达到弹幕展示均衡
  3. 如何减少repaint/reflow
    

    泳道的循环运动

    为减少DOM增删带来资源损耗,初步设计每条泳道会有两条track,根据transform的X坐标实现循环运动。如下图所示:
    1
    1
    1
    1
    (截图截得不好 ,Pool应该是固定不动的)

同时,之后如果要给弹幕监听事件,只需要委托给泳道只可以了,减少了大量的Listener。

优点:减少DOM增删操作,循环只需要更改transformX。
缺点:两条track必须固定宽度为泳池宽度,这样才能构成环路。

弹幕派发

如上篇所说,整个弹幕泳池会分为多个不相关联的泳道(Lane),目的是减少每帧的计算量,由原来的每帧要计算每个弹幕DOM的移动量降低为只需计算泳道的移动量。
而关于弹幕注入泳道的部分目前有两个解决方案:

首先两个方案都使用了Rxjs bufferTime和bufferCount管道来做弹幕入口,防止弹幕井喷。

#1 然后增加中心派发层,计算每个泳道的空闲情况,派发弹幕到指定的泳道

5

优点:能够中心统筹泳道,均衡每个泳道的弹幕数量
缺点:计算量集中在了中心派发层

#2 使用弹幕队列,由泳道各自计算各自的空闲情况,争夺队列弹幕。

6

优点:去中心化,降低中心计算量
缺点:泳道之间不能通讯,无法得知总体弹幕均衡情况,有机会出现一条泳道抢夺所有弹幕资源的情况。

结论

各有优点也各有缺点,因此也仍在思考这部分的设计。有新的解决方案再更新上来。