彈幕渲染層
彈幕資料通道
彈幕服務邏輯
目前彈幕的呈現載體主要是web、無線客戶端。因為我們的工作主要針對無線端，所以本文主要以無線端為例——包括ios，android兩類系統。
碰撞檢測
彈幕無非是動畫，是分布在時間軸上影象的連續運動。自然可以用native的動畫來實現。不過彈幕動畫有乙個重要的特徵，即保持動畫元素(sprites)盡可能少地碰撞，以使彈幕承載的資訊能夠清晰地傳達，執行碰撞檢測是必須的。但彈幕裡的碰撞檢測相對簡單，因為彈幕的運動軌跡相對簡單並且容易**，所以只需要在一條彈幕將要顯示之前，根據已經顯示的彈幕(位置、速度、活躍的時間等)來確定他的運動軌跡。以盡最大可能地在其生命週期內不與已有彈幕衝突。
彈幕的同步問題
彈幕的樣式
渲染效率
限流彈幕稀稀疏疏地鋪滿半屏視窗，朦朧中猶抱琵琶半遮面的感覺，自然是最好的。但萬一遇到彈幕決堤，內容瘋狂湧來，那當如何應對？渲染內容層層堆疊，既看不清，又降低了系統應用效能，為此可以在業務或者元件中選擇限流。
若不考慮彈幕在使用者間共享，只需下圖左側的模組即可；若需引入彈幕共享、儲存功能，則如下圖右側所示。
但實際情況往往比這複雜。彈幕很多時候是實時的，最好使用長連線來傳輸資料。業務導向的專案，很少從零開始開發專門的彈幕服務通道，而是盡可能地應用已有的服務元件。**在長連通道上有多個選擇，但其功能又是不盡相同的。這種不同也會帶來彈幕實現方案的不同。比如通道a支援訂閱功能，訊息會根據訂閱關係分發；而通道b是單純的通道，訂閱關係由業務方維護，凡是傳送到客戶端的訊息都會接收，所以流量需要業務服務端來控制。
經過服務端的必要性
僅僅使用長連線通道是不夠的，還需引入業務伺服器，其原因如下：
整體的資料流如下圖所示：
訊息格式制定
自發的彈幕訊息
主要有兩種：
使用者傳送了彈幕訊息後，通過網路傳送訊息的同時直接將彈幕資料上屏，以提公升使用者所見即所得的體驗；當收到相同的彈幕訊息後，將訊息拋棄。
使用者傳送了彈幕訊息後，通過正常的網路接收訊息然後渲染呈現，這樣會因延時損失一定的使用者體驗，但邏輯簡單，並且可以控制所有彈幕資料。
主題維護
使用者u1、u2訂閱了主題t1，使用者u3、u4訂閱了主題t2。由於處於不同的語境中，u1、u2傳送的彈幕u3、u4應該是不能接收到的，反之亦然。很自然服務端需要維護乙個使用者到主題的對映表簡單的實現是，客戶端監測到使用者進入特定主題之後，傳送一條網路請求登記這樣一條訂閱知識；使用者離開特定主題時傳送網路請求登出登記。但由於實際客戶端執行場景複雜，離開特定主題不一定來得及傳送網路請求。補充方案是，由客戶端每隔特定時間心跳一次，用以告知服務端維護對映表。一旦服務端一段時間沒有監聽到心跳資訊，就取消對映表中的一條訂閱。這裡需要注意的是，服務端需要防止心跳的偽造，否則可能對映表可能會因攻擊而混亂掉。一旦對映表正確建立，使用者傳送的彈幕訊息就可以準確傳達到相同主題的使用者客戶端了。
彈幕儲存
彈幕的實現
一 前言 今天瀏覽某 看到乙個活動頁有內嵌的彈幕模組 圖一 但是看到移動的彈幕重疊很多，不忍直視啊。突然想起很久之前自己寫寫過類似的彈幕，就翻出來看了一下，呵，也是不忍直視的，最後再附上當年的效果以及 二 大話幾點 5 彈幕的後台實現可以通過websocket實現，當然也可以借助node實現。當使用...
彈幕功能的實現
在做專案的時候用到了彈幕功能 彈幕的字型大小和顏色也都是隨機的，奉上 html 彈幕 css tool switch container switch type checkbox type radio tool switch container labeljs switch 彈幕 switch la...
彈幕的實現（純前端）
一 前言 今天瀏覽某 看到乙個活動頁有內嵌的彈幕模組 圖一 但是看到移動的彈幕重疊很多，不忍直視啊。突然想起很久之前自己寫寫過類似的彈幕，就翻出來看了一下，呵，也是不忍直視的，最後再附上當年的效果以及 二 大話幾點 5 彈幕的後台實現可以通過websocket實現，當然也可以借助node實現。當使用...