目前已经完成了一个版本，却是引来了更多的思考。
主要要思考的问题有：
- 如何减少帧单位内的计算量
- 如何达到弹幕展示均衡
- 如何减少repaint/reflow
泳道的循环运动
为减少DOM增删带来资源损耗，初步设计每条泳道会有两条track，根据transform的X坐标实现循环运动。如下图所示：
(截图截得不好 ，Pool应该是固定不动的)
同时，之后如果要给弹幕监听事件，只需要委托给泳道只可以了，减少了大量的Listener。
优点：减少DOM增删操作，循环只需要更改transformX。
缺点：两条track必须固定宽度为泳池宽度，这样才能构成环路。
弹幕派发
如上篇所说，整个弹幕泳池会分为多个不相关联的泳道（Lane），目的是减少每帧的计算量，由原来的每帧要计算每个弹幕DOM的移动量降低为只需计算泳道的移动量。
而关于弹幕注入泳道的部分目前有两个解决方案：
首先两个方案都使用了Rxjs bufferTime和bufferCount管道来做弹幕入口，防止弹幕井喷。
#1 然后增加中心派发层，计算每个泳道的空闲情况，派发弹幕到指定的泳道
优点：能够中心统筹泳道，均衡每个泳道的弹幕数量
缺点：计算量集中在了中心派发层
#2 使用弹幕队列，由泳道各自计算各自的空闲情况，争夺队列弹幕。
优点：去中心化，降低中心计算量
缺点：泳道之间不能通讯，无法得知总体弹幕均衡情况，有机会出现一条泳道抢夺所有弹幕资源的情况。
结论
各有优点也各有缺点，因此也仍在思考这部分的设计。有新的解决方案再更新上来。