寫這篇文章算柳，其實(shí)對(duì)我來說，有點(diǎn)誤人子弟泽台，額呃赏胚，因?yàn)檫@篇寫文章的角度不是對(duì)技術(shù)考量访娶，而是從一位產(chǎn)品經(jīng)理的角度思考著怎么把產(chǎn)品和功能做好，跨領(lǐng)域觉阅，嘿嘿震肮，嘗試一下我的思考 ：）
在寫這篇文章之前，我已經(jīng)谷歌了很多關(guān)于彈幕的實(shí)現(xiàn)方法留拾，雖然大部分的文章介紹的很詳細(xì)，但幾乎都是從開發(fā)角度去思考問題鲫尊，告訴我們借用代碼怎么去實(shí)現(xiàn)效果痴柔，可是沒說在該功能設(shè)計(jì)前的產(chǎn)品規(guī)劃和怎樣解決跟客戶對(duì)接并讓客戶也了解其實(shí)現(xiàn)原理的言辭。這里我就不過多的講怎么用技術(shù)代碼去實(shí)現(xiàn)的過程疫向，講講思考這個(gè)產(chǎn)品的定位和效果咳蔚。
彈幕的數(shù)據(jù)獲取方式：
簡(jiǎn)單總結(jié)一下開發(fā)技術(shù)實(shí)現(xiàn)的方法：
1：客戶端里的定時(shí)器走HTTP“請(qǐng)求—響應(yīng)”的方式獲得數(shù)據(jù)，并刷新界面來達(dá)到效果搔驼；
2：直播軟件一般是后臺(tái)和客戶端建立socket連接谈火，來相互傳輸通信，從而達(dá)到實(shí)時(shí)顯示的效果舌涨。
小結(jié)：這兩種方法具體采取哪一種糯耍，是需要結(jié)合自身的需要和成本角度去取舍的
彈幕需求種類：
1：以快手、花椒等直播APP為例，這個(gè)是后臺(tái)通過socket連接直接把彈幕數(shù)據(jù)推給客戶端并實(shí)時(shí)顯示温技；
2：以B站革为、愛奇藝等非直播類視頻為例，可以快進(jìn)后退舵鳞，這就要做到視頻幀率的時(shí)間點(diǎn)跟彈幕進(jìn)行一一綁定震檩。
小結(jié)：后面這種是客戶端根據(jù)時(shí)間點(diǎn)向服務(wù)器請(qǐng)求數(shù)據(jù)，并緩存在本地蜓堕，并和后面請(qǐng)求的數(shù)據(jù)相同id的彈幕進(jìn)行數(shù)據(jù)過濾抛虏，自己加的彈幕，客戶端這邊請(qǐng)求后臺(tái)之后自己插進(jìn)去套才，做到實(shí)時(shí)顯示迂猴。
結(jié)合實(shí)際的需求分析
其實(shí)我們要實(shí)現(xiàn)功能，看起來很難霜旧。因?yàn)槲覀儾荒茏鱿馚站那樣炸開屏幕错忱、五顏六色的彈幕，又不滿足現(xiàn)有的效果挂据，這就很頭疼了以清，因?yàn)樽鲂侣勵(lì)惖膹椖唬皣?yán)肅大方非娛樂”是我們的實(shí)現(xiàn)效果的標(biāo)尺崎逃，“炫酷大氣吊炸天”則不符合我們對(duì)產(chǎn)品的思考掷倔。實(shí)現(xiàn)效果如圖：
約束條件：
戴了一雙鐐銬跳舞，難免會(huì)別扭个绍，還要求做出優(yōu)雅的動(dòng)作和輕盈似魔鬼的步伐勒葱，往往需要我們更從容的去面對(duì)眼前。
1：從下往上飄
2：一個(gè)彈道
3：不能覆蓋
4：勻速運(yùn)行
5：效果不能太突兀巴柿，自然穩(wěn)重
計(jì)算速度
以上的束縛已經(jīng)限定了我們凛虽，網(wǎng)上那些彈幕的方案是行不通的，我們只能在現(xiàn)有的基礎(chǔ)上進(jìn)行優(yōu)化广恢。
數(shù)據(jù)好拿凯旋，現(xiàn)在關(guān)鍵點(diǎn)在于怎么優(yōu)雅的實(shí)現(xiàn)自上而下的彈幕，咱們還是從數(shù)據(jù)說話：
拿iPhone手機(jī)屏幕最多的4.7寸來說(6/6s/7的尺寸)钉迷， 彈幕區(qū)域(寬高比4：3)的高度是281至非，再減去上下邊距，我們就用240的高度來計(jì)算糠聪，每條彈幕高度40荒椭，間距5，豎屏最多顯示 260 / 45 = 6.8 約等于6舰蟆，告訴我們趣惠，豎著區(qū)域狸棍，最多同時(shí)顯示6條彈幕，那如果數(shù)據(jù)量小的情況下信卡，是OK的沒問題隔缀，假如要是被刷屏了，那彈幕要顯示到什么時(shí)候傍菇，一條彈幕從出現(xiàn)到消失猾瘸，移動(dòng)6s時(shí)間（意思就是1s加載一個(gè)，其實(shí)這個(gè)速度比較適中）丢习，那1000條彈幕牵触，那就嚇人了，大概要花 1000s = 15.6分鐘咐低。(PS: 線上APP的時(shí)間是2s一條)
在狹小區(qū)域中顯示這么多的彈幕揽思。一種方法是隱瞞用戶（這也是很多家這么干的），很多家彈幕都是這么整的见擦，當(dāng)并發(fā)量特別大的時(shí)候钉汗，只能選擇性的過濾一些，但記住不能把當(dāng)前手機(jī)用戶剛剛發(fā)的那條也刪了鲤屡，這個(gè)過濾的工作损痰，是后臺(tái)和客戶端一起合作選擇性的過濾，
我自己做了一個(gè)demo酒来，僅供參考卢未，這是一個(gè)1s加載一個(gè)勻速運(yùn)行的彈幕。其實(shí)這也就解決了產(chǎn)品經(jīng)理的問題堰汉，現(xiàn)在辽社，她要了解的就是這個(gè)速度怎么去控制，我的思考：可以后臺(tái)控制速度翘鸭，也可以客戶端自己按照當(dāng)前時(shí)間節(jié)點(diǎn)上彈幕的多少進(jìn)行彈幕流速的控制滴铅，不管哪種都要求做到 “流暢不突兀”就乓。如下：
彈幕流速的控制. GIF
數(shù)據(jù)的獲取方式產(chǎn)品經(jīng)理不用管失息，研究怎么控制流速就行了
上面的這個(gè)demo，比較簡(jiǎn)單档址，iOS端原理是：scrollView的滾動(dòng)效果是一個(gè)動(dòng)畫，那么動(dòng)畫肯定會(huì)有一個(gè)執(zhí)行時(shí)間和一個(gè)加速器參數(shù)邻梆，所以只要修改到這兩個(gè)參數(shù)就可以達(dá)到想要的效果守伸。
我的總結(jié)
彈幕比較少的時(shí)候，勻速每秒1個(gè)浦妄，運(yùn)行還是挺流暢的尼摹。彈幕少的時(shí)候见芹，想怎么整都無所謂，我們主要思考的解決同一個(gè)時(shí)間點(diǎn)上大量（比如一個(gè)時(shí)間點(diǎn)1000個(gè)彈幕）彈幕的顯示問題蠢涝，一下是我的思路：
分兩種情況玄呛，1：直播視頻 2：回看視頻。第一種直播視頻是比較好解決的和二，開一個(gè)socke鏈接徘铝，實(shí)時(shí)推送數(shù)據(jù)流，顯示惯吕，具體顯示邏輯惕它，下面一同介紹。第二種废登，是我們大部分情況下思考的淹魄，因?yàn)槲覀児镜倪@個(gè)產(chǎn)品（保密就不說說哪款A(yù)PP了），不會(huì)存在很多個(gè)直播堡距，基本上都是視頻回顧甲锡，那我就站到視頻回顧的情形下說一說：
1：當(dāng)用戶來到這個(gè)稿件，就開始請(qǐng)求后臺(tái)數(shù)據(jù)羽戒，把視頻剛播放時(shí)的一段時(shí)間的彈幕全部都獲取到缤沦，加以顯示。我們這里就約定半醉，每次請(qǐng)求數(shù)據(jù)是50條數(shù)據(jù)并緩存到本地疚俱，意思就是先展示最先50條數(shù)據(jù)的彈幕，當(dāng)播放到第50條彈幕播放的時(shí)間點(diǎn)的時(shí)候缩多，再去請(qǐng)求數(shù)據(jù)呆奕，再按照時(shí)間先后重新排序，過濾掉之前已經(jīng)緩存相同id的彈幕衬吆。這樣做的好處一時(shí)能減少用戶的流量梁钾，二是減少我們公司的服務(wù)器壓力，不會(huì)一次性全部都請(qǐng)求到逊抡，這樣太浪費(fèi)資源了姆泻，原則是：視頻播放多少，接口就請(qǐng)求多少冒嫡，彈幕就加載多少拇勃。
2：流速的控制。我寫了一個(gè)demo孝凌，上面有流速的控制方咆，從0 - X，可以控制蟀架，寫這個(gè)demo的目的只是讓產(chǎn)品經(jīng)理感受一下在什么一個(gè)區(qū)間合適瓣赂，不是靠猜測(cè)榆骚。彈幕多了的時(shí)候，可以稍微快一點(diǎn)煌集，控制在每秒1 - 2個(gè)之間妓肢，平常就固定一秒一個(gè)就很好，保持勻速苫纤，加速減速就會(huì)顯得有一點(diǎn)點(diǎn)的卡頓碉钠。
3：同一時(shí)間點(diǎn)大量的并發(fā)。后臺(tái)根據(jù)當(dāng)前用戶的id方面，不能過濾掉當(dāng)前用所發(fā)布的彈幕放钦，而且要實(shí)時(shí)顯示，其他的可以控制流量恭金，根據(jù)其他家的做法操禀，彈幕慢一點(diǎn)也沒關(guān)系，更何況我們的彈道就只有一條横腿，不控速不節(jié)流颓屑，是行不通的，當(dāng)彈幕推擠到一定程度比如某個(gè)節(jié)點(diǎn)有1000條時(shí)耿焊，我們會(huì)抽取其中的少部分顯示揪惦，其他的過濾掉（這個(gè)很合理，沒什么不能的）罗侯。
4：彈幕和視頻播放時(shí)間是綁定在一起的器腋，發(fā)起彈幕的時(shí)候，會(huì)把當(dāng)前播放時(shí)間一起給后臺(tái)钩杰，拿到數(shù)據(jù)之后纫塌，客戶端就監(jiān)控視頻播放時(shí)間就行了，這是簡(jiǎn)單的想法讲弄，具體的還需要討教服務(wù)端同事們措左。
5：任何功能，都不可能脫離實(shí)際需求和效益高低避除。從開發(fā)難度和后臺(tái)流量成本上來說怎披，是可以實(shí)現(xiàn)的。
