H5游戏开发的架构总结(一) 客户端
1.关于游戏引擎
在15年3月开始准备做h5游戏的时候，首先遇到的问题就是引擎选型的问题。
当时市面上的2d引擎主要有3个:白鹭egret,layabox和cocos2d-js。
一方面，是因为我以前用cocos2d-x(c++)做了一年多的手游客户端，所以，很自然就选择了cocos2d-js。另一方面，是因为当时市面上其他两个引擎的成功项目还不多。
cocos引擎的每一次版本更新，我们都会第一时间在我们的游戏里面进行测试。
如果发现游戏在android手机上的性能有明显提升，我们就会跟着引擎版本一起升级。站在巨人的肩膀上，我们可以事半功倍。
从15年3月的v3.5，到15年9月的v3.8，到15年11月的v3.9，直到最近16年7月的v3.12。我们一共更新了3次游戏引擎！
PS:js-tests里面的OpenGl Test直到v3.12才在android真机上能看到运行效果，泪流满面！
2.关于数据加密和通信协议
因为是强联网游戏，所以只能是websocket。因为我们原来的手游客户端和服务器之前是tcpsocket，传输的内容是sha1加密过的自定义格式的二进制数据。
所以项目的第一个难点就是怎么用js实现json字符串的二进制编码和解码，以及sha1加密和解密。
TODO:其实没有必要每一条上下行都加密和编码解码，这会造成客户端和服务器端cpu压力过大。只需要保护一些重要的事件(如登录、充值、扣金币等)即可！
游戏的第一个demo做好了，上线一测试，问题来了：有些android手机的默认浏览器根本不支持websocket！
最开始我的解决办法比较简单粗暴，不支持就弹提示："你的手机浏览器不支持websocket，请换chrome浏览器！"
市场表示接受不了：真实玩家都跑了！除了公司的测试人员，谁都不会为了玩一个h5游戏还去专门下载一个浏览器！更何况除了浏览器，还有微信和qq，怎么破？
最终的解决办法，就是通信层从websocket改成websocket+http双协议，对外封装成Net。业务层对websocket的调用都改成对Net的调用。
Net默认连websocket，如果不支持，就自动切换到http长轮询。不管是websocket还是http，传输的内容还是之前加密过的二进制数据。
虽然http的长轮询在实时战斗的时候，会有卡顿，但是聊胜于无，至少这部分玩家能进到游戏里面，可以玩单机副本，和其他系统。不会因为不支持websocket而进不来！
根据我们的数据分析统计，这部分玩家居然有10%。可能不同渠道导入的用户，这个值会有不同！而且随着时间的推移，这个比例应该越来越少！
PS:不支持websocket的android手机，跟IE6一样令人讨厌，都是阻碍生产力发展的，必将被历史淘汰！
3.关于android和微信
中国的市场现状就是,H5游戏必须考虑android手机，必须考虑微信和qq这两个传播渠道。只关注用pc浏览器开发和苹果手机测试没问题，是不明智的，也是对公司的不负责任。
开发的时候可以用pc浏览器调试，但是发布之前必须在android手机的微信里面，打开游戏看是否有兼容性问题，同时确认流畅度。
如果pc和苹果手机都能跑到50~60帧,但是android的微信就只有10多帧，那就必须在图片尺寸和动画效果等方面做取舍。
我们的标准是保证游戏在android中端机的微信里面打开，最低25帧。
今年4月份微信的浏览器内核自动从webkit升级成Blink，这是对H5整个行业的重大利好！
窃以为，白鹭、layabox和cocos2d，包括unity，虚幻，这几个游戏引擎之争，现在来看，都是在争VR和3D，但是最终是看谁对奇葩辈出的android的全覆盖支持最好，谁就能最终占领中国乃至全球市场！
4.关于音乐和音效播放
cocos2d-js引擎自带的CocosDension有bug，不能同时播放一个以上的音乐。而且在中低端的android的微信里面，声音品质会变差（像破锣一样发呲）
我们的解决方案就是引入第三方的howler.js
5.关于资源分场景加载
cocos2d-js默认的resource.js里面，所有资源都是在一个数组里面，所以预加载的时候必须全部都加载完了才能进游戏！刚开始开发的时候，这样没有问题。
但是到了后期，随着系统的增加，资源文件也越来越多，对第一次玩游戏的玩家来说，因为浏览器没有缓冲，需要全部加载，在wifi环境都需要等待1分钟以上，这会导致大量的新玩家流失！
我们的解决办法是，分场景加载资源。在resource.js里面，将资源按场景分成N个数组，每次加载某个场景的时候，只预加载对应数组里面的资源。
6.关于json文件压缩
随着游戏开发的进行，场景越来越多，ccs生成的json文件也越来越多，同时各种地图、商品、道具、奖励等数据的完善，对应的json文件内容越来越多，文件大小越来越大！
最后游戏发布的时候，发现居然有70个场景json文件，合计1.3M。有27个配置json文件，合计755K。等待这几十个文件加载的时间可不短！
解决办法，引入第三方的jszip，可以将多个json文件合并成一个zip，文件大小只有原来的8%。
写了个python脚本，把ccs和configs两个目录下的json文件先转成一个一行，再用jszip打包成2个zip文件，游戏一开始先用jszip加载这两个zip，解压的json放到全局数组里面。
注意这里面有个坑，策划的excel里面不能出现半角逗号，否则jszip打包会报错。强制策划不输入半角逗号不太合理，解决办法是go生成json的时候替换半角逗号为全角逗号。
然后复写了引擎的cc.loader.loadJson这个函数，对打包的json文件特殊处理(不用额外发起http请求，直接从全局数组里面拿)有了5、6这两步的优化，现在新手在第一次Loading页只需要等待4秒就能进入游戏。
7.关于混淆
cocos封装了google的混淆编译脚本，但是这里面有个坑：就是加了--advance参数之后，所有变量名都会被混淆，包括object的内部函数名称和变量。
解决办法就是在你不想混淆的函数或者变量（object{}对外暴露的public函数和变量 以及 引用的第三方库的函数 ）前面加上一行：
/** @expose */
注意：千万不要xxx.yyy 和 xxx['yyy'] 混着用!否则加/** @expose */也没用，必须全部统一成其中一种写法！
8.关于上线发布流程和cdn缓存
1)本地运行publish.sh：本地混淆编译，本地测试publish/html5/index.html是否正常
2)本地运行oline_t1.sh：根据当前时间生成版本号,publish/html5目录下的res和game.min.js和index.html里面的相对路径都改成http://cdn域名/版本号的文件地址,
将res和game.min.js加上版本号之后，上传cdn服务器。更新测试服t1的index.html,通知测试！
3)本地运行online_s1.sh：更新正式服s1上的index.html。发布完毕。
说明:
1)客户端和服务器端程序员都是mac开发环境，每人的机子上都有一套完整的前后端游戏环境。本地开发，本地调试，没有问题之后通过git提交代码到公司内网git服务器。这样可以最大限度保证多人协作的同时，互不影响开发进度！
2)因为cdn加了时间版本号，所以每一次的发布都是马上生效，不需要等缓存过期。也不担心多人各自发布覆盖对方的代码。发步完马上可以查看效果，大大提高生产效率。以cdn的空间换效率，非常划算！
3)python的fab包是个好东西，可以远程登录服务器执行shell命令，实现本地一键发布。不需要在服务器上通过git的钩子来实现自动发布！
9.关于断线重连(websocket)
1)客户端每隔58秒有一个心跳上行，保持与服务器的链接
2)多标签的浏览器在切换tab或者浏览器进入后台的时候或者断网，都会导致心跳失效
3)每次客户端发送上行的时候，先判断Net.isConnect()是否为true。如果false就先保存上行事件和数据，然后重连，然后重新登录，然后发送保存的上行事件和数据。这些都是在后台进行，如果重连失败则弹出提示，点击确认之后刷新页面。
10.关于运营商的域名劫持和移动端js加弹出广告
运营商耍流氓，中国又是一个"法制"国家，除了上https，没有别的办法！
我们选择的是沃通的超安SSL，单域一年4888元 http://www.wosign.com/price.htm
11.关于客户端AI
1）NPC碰到障碍物之后会固定角度转向，避免卡死在角落。其他时间会随机转向。
2) 自动添加NPC，保证房间内NPC的最低数量
3）同一时刻只有一个NPC处于追踪玩家状态，有定时器触发追踪者的选角切换
H5游戏开发的架构总结(二) 服务器端