写这篇文章，其实对我来说，有点误人子弟，额呃，因为这篇写文章的角度不是对技术考量，而是从一位产品经理的角度思考着怎么把产品和功能做好，跨领域，嘿嘿，尝试一下我的思考 ：）
在写这篇文章之前，我已经谷歌了很多关于弹幕的实现方法，虽然大部分的文章介绍的很详细，但几乎都是从开发角度去思考问题，告诉我们借用代码怎么去实现效果，可是没说在该功能设计前的产品规划和怎样解决跟客户对接并让客户也了解其实现原理的言辞。这里我就不过多的讲怎么用技术代码去实现的过程，讲讲思考这个产品的定位和效果。
弹幕的数据获取方式：
简单总结一下开发技术实现的方法：
1：客户端里的定时器走HTTP“请求—响应”的方式获得数据，并刷新界面来达到效果；
2：直播软件一般是后台和客户端建立socket连接，来相互传输通信，从而达到实时显示的效果。
小结：这两种方法具体采取哪一种，是需要结合自身的需要和成本角度去取舍的
弹幕需求种类：
1：以快手、花椒等直播APP为例，这个是后台通过socket连接直接把弹幕数据推给客户端并实时显示；
2：以B站、爱奇艺等非直播类视频为例，可以快进后退，这就要做到视频帧率的时间点跟弹幕进行一一绑定。
小结：后面这种是客户端根据时间点向服务器请求数据，并缓存在本地，并和后面请求的数据相同id的弹幕进行数据过滤，自己加的弹幕，客户端这边请求后台之后自己插进去，做到实时显示。
结合实际的需求分析
其实我们要实现功能，看起来很难。因为我们不能做像B站那样炸开屏幕、五颜六色的弹幕，又不满足现有的效果，这就很头疼了，因为做新闻类的弹幕，“严肃大方非娱乐”是我们的实现效果的标尺，“炫酷大气吊炸天”则不符合我们对产品的思考。实现效果如图：
约束条件：
戴了一双镣铐跳舞，难免会别扭，还要求做出优雅的动作和轻盈似魔鬼的步伐，往往需要我们更从容的去面对眼前。
1：从下往上飘
2：一个弹道
3：不能覆盖
4：匀速运行
5：效果不能太突兀，自然稳重
计算速度
以上的束缚已经限定了我们，网上那些弹幕的方案是行不通的，我们只能在现有的基础上进行优化。
数据好拿，现在关键点在于怎么优雅的实现自上而下的弹幕，咱们还是从数据说话：
拿iPhone手机屏幕最多的4.7寸来说(6/6s/7的尺寸)， 弹幕区域(宽高比4：3)的高度是281，再减去上下边距，我们就用240的高度来计算，每条弹幕高度40，间距5，竖屏最多显示 260 / 45 = 6.8 约等于6，告诉我们，竖着区域，最多同时显示6条弹幕，那如果数据量小的情况下，是OK的没问题，假如要是被刷屏了，那弹幕要显示到什么时候，一条弹幕从出现到消失，移动6s时间（意思就是1s加载一个，其实这个速度比较适中），那1000条弹幕，那就吓人了，大概要花 1000s = 15.6分钟。(PS: 线上APP的时间是2s一条)
在狭小区域中显示这么多的弹幕。一种方法是隐瞒用户（这也是很多家这么干的），很多家弹幕都是这么整的，当并发量特别大的时候，只能选择性的过滤一些，但记住不能把当前手机用户刚刚发的那条也删了，这个过滤的工作，是后台和客户端一起合作选择性的过滤，
我自己做了一个demo，仅供参考，这是一个1s加载一个匀速运行的弹幕。其实这也就解决了产品经理的问题，现在，她要了解的就是这个速度怎么去控制，我的思考：可以后台控制速度，也可以客户端自己按照当前时间节点上弹幕的多少进行弹幕流速的控制，不管哪种都要求做到 “流畅不突兀”。如下：
弹幕流速的控制. GIF
数据的获取方式产品经理不用管，研究怎么控制流速就行了
上面的这个demo，比较简单，iOS端原理是：scrollView的滚动效果是一个动画，那么动画肯定会有一个执行时间和一个加速器参数，所以只要修改到这两个参数就可以达到想要的效果。
我的总结
弹幕比较少的时候，匀速每秒1个，运行还是挺流畅的。弹幕少的时候，想怎么整都无所谓，我们主要思考的解决同一个时间点上大量（比如一个时间点1000个弹幕）弹幕的显示问题，一下是我的思路：
分两种情况，1：直播视频 2：回看视频。第一种直播视频是比较好解决的，开一个socke链接，实时推送数据流，显示，具体显示逻辑，下面一同介绍。第二种，是我们大部分情况下思考的，因为我们公司的这个产品（保密就不说说哪款APP了），不会存在很多个直播，基本上都是视频回顾，那我就站到视频回顾的情形下说一说：
1：当用户来到这个稿件，就开始请求后台数据，把视频刚播放时的一段时间的弹幕全部都获取到，加以显示。我们这里就约定，每次请求数据是50条数据并缓存到本地，意思就是先展示最先50条数据的弹幕，当播放到第50条弹幕播放的时间点的时候，再去请求数据，再按照时间先后重新排序，过滤掉之前已经缓存相同id的弹幕。这样做的好处一时能减少用户的流量，二是减少我们公司的服务器压力，不会一次性全部都请求到，这样太浪费资源了，原则是：视频播放多少，接口就请求多少，弹幕就加载多少。
2：流速的控制。我写了一个demo，上面有流速的控制，从0 - X，可以控制，写这个demo的目的只是让产品经理感受一下在什么一个区间合适，不是靠猜测。弹幕多了的时候，可以稍微快一点，控制在每秒1 - 2个之间，平常就固定一秒一个就很好，保持匀速，加速减速就会显得有一点点的卡顿。
3：同一时间点大量的并发。后台根据当前用户的id，不能过滤掉当前用所发布的弹幕，而且要实时显示，其他的可以控制流量，根据其他家的做法，弹幕慢一点也没关系，更何况我们的弹道就只有一条，不控速不节流，是行不通的，当弹幕推挤到一定程度比如某个节点有1000条时，我们会抽取其中的少部分显示，其他的过滤掉（这个很合理，没什么不能的）。
4：弹幕和视频播放时间是绑定在一起的，发起弹幕的时候，会把当前播放时间一起给后台，拿到数据之后，客户端就监控视频播放时间就行了，这是简单的想法，具体的还需要讨教服务端同事们。
5：任何功能，都不可能脱离实际需求和效益高低。从开发难度和后台流量成本上来说，是可以实现的。
