一个美好的概念可以让策划无比幼稚和疯狂，

比如 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: 617754841@qq.com