WebSocket 的後記

標籤：替代   電腦   顯示   封裝   協議   通訊   sock   簡單   web   

一個美好的概念可以讓策劃無比幼稚和瘋狂，

比如 H5 改變世界呀，小程式替代 APP 呀，現在即時通訊也被公司裡的他們認為 so easy 了。

這很尷尬好吧，WebSocket（以下簡稱 ws） 的痛點並不在於它本身好伐啦...

 

它對後端技術要求除了面對大型使用者群，暫時沒什麼關係。

本質上它還是一個連結，只是以前用完就斷了，ws 不斷開，雙方任意傳輸，這樣有了即時通訊。

看上去好像挺簡單且非常好用的原理，那是對後端的連結技術而言啦，

真正實現 ws 應用還擁有以下痛點的說：

 

1. 通訊協定。

達成 ws 連結後，使用者雙方將使用的是另一套通訊協定了。

類似於 http，一方先說我是誰我要進來了，另一方說好的你是合法的進來吧，然後才能進入並告訴對方我進來了，這樣才算完成了初步的判斷。

而 http 有近 600 種判斷，雖然我們手寫不用那麼多，但何嘗不是件頭疼的事。

2. 遊戲(應用)封裝重寫。

不是所有遊戲都封裝的很好（實在慚愧，主要開發時間不夠，只能借鑒了），再 new 一個 person 就可以雙人遊戲了。

我們面對的更多的還是封裝的極其不佳的源碼，這就意味著我們得看完源碼後再自己重新封裝重寫，也是項目中最耗時的部分。

3. 遊戲事件介面化。

封裝對技術含量的要求是非常非常高的，而我接觸的遊戲並不多，物件導向編程也還是個渣渣…

 

4. 通訊方式。

個人總結的 ws 應用通訊方式有四種：

a. 單人操控主機(一個發一個收)，

b. 多人操控主機(多了判斷各種狀態)，

c. 雙人操控彼此(此時已沒有主機概念，所有的通訊都要判斷)，

d. 多人操控彼此(參見世面上的手遊)。

以上實現難度從易到難排列。

5. 互動。

為了讓客戶得到更好的體驗，所有通訊都需要有反饋，存在各種提示，有的還需要介面設計，如人滿/已結束等等。

另一方面則是，邀請其他人共同玩耍的形式，顯示二維碼還是轉寄等等

6. 與策劃溝通問題。

其實策劃並不能清楚認識到上述痛點究竟難在哪，

所以這就和公司商務程序相關了，是策劃主導需求技術來否決，還是先實現再策劃等這種問題又老生常談了

7. 開發時間。

我的觀念一直都是，所有需求都能做，只是時間問題。

修電腦的可以做 CPU 嗎，當然可以，但只給兩周那就呵呵了，我有句 MMP 不知當講不當講。或者經曆過兩三次項目後再談縮短周期的事吧。

 

最不理想的開發體驗是，忙忙碌碌但第二天想不起前一天做過的事，無論是解決方案還是靈光一現都沒能記錄下來。

而相對寬鬆的時間，能讓開發人員有能多時間去思考，去權衡哪種方案更優，能清晰感受到代碼從無到有的過程和魅力。

 

以上…

WebSocket 是個很大的領域，並不僅僅代表一個不中斷的超連結而已。

所以，各位加油吧。E-mail: [email protected]

WebSocket 的後記