近年来HTML5风起云涌，特别在移动端已经被更多的人熟识。H5跨平台，在线更新等特性，被人们津津乐道。然后就出现了各种H5的框架，甚至多达100种，真是让开发者眼花缭乱，笔者作为一个从事H5游戏开发一年的开发者，从我这一年的摸索，比较，最终选择cocos2d-x jsbinding(以下简称jsb)作为移动游戏开发框架，并在接下来的几篇博文中慢慢讲述一些我对这个框架的认识和感受。
就目前来讲，移动端的框架最火，最牛叉的非cocos2d-x莫属，甚至达到了每上10款手游，7款是cocos2d-x的境界。jsb作为cocos2d-x的javascript脚本调用版本，保持了cocos2d-x的稳定，高效率的同时，能和cocos2d-html5无缝结合，真正做到了一套代码，多个平台运行，并且在移动平台保持了100%原生效率的这样一个品质。可以说是目前html5在移动端最好的解决方案。现在类似的Hybird引擎有不少了，有uc的X-canvas，opera的sphinx,ludei,game closure,还有即将发布的youzi2d，这些引擎都有一个特点，硬件加速，因为现在Html5最大的瓶颈就是效率，那jsb和这些框架比起来，究竟怎么样呢？以下从我使用的角度来讲，列出了几点，个人意见，仅供参考。
1.执行效率。上面提到的效率问题，这个自然是jsb的重点。主要分为2块，一块是图形渲染的效率。还有一块是脚本执行效率。上述几款框架都宣传的是100%硬件加速，但是这里面的加速效果并不是相同的，jsb的图形渲染效率和cocos2d-x是等同的，以小米1手机为例，jsb同屏跑600个动画(没有用批渲染，真正的600次draw)，帧数在45帧左右，900个动画是35帧左右，同样的手机在跑sphinx下面的一个打飞机demo，帧数在48帧左右，打飞机中的同屏幕精灵不超过100个，x-canvas没有深入研究，但是跑过一个里面的切水果，切中的瞬间会有明显的卡顿，我不知道是不是渲染的问题，对x-canvas熟悉的童鞋也可以画上600个动画看看帧数。
js脚本效率这块，jsb用的是firefox的开源spidermonkey，android环境开启了JIT。实际用的情况是够用，但是要小心的用，特别是大的循环要避免，例如大配置文件循环。如果其他框架用的是google的V8引擎的话，会比spidermonkey要快，但是有一点，ios是不能开启JIT的，所以ios环境V8是用不了的，因为V8是强制开启JIT的。另外有一点是，jsb支持物理引擎，但这个也是用js来调用C++的chipmunk库的，这样保证了效率。
2.跨平台。得益于cocos2d-x，现在通吃市面上所有安卓机器，旧的如几年前的单核国产机，到现在最新的三星S4，ios自然是包括ip4以上的所有机型和所有pad。据说wp也马上要并入cocos2d-x主分支。除此之外，得益于cocos2d-html5，上述一套同样的js代码，还可以运行于支持H5的浏览器环境，手机端的浏览器只要是支持H5特性的都能跑，例如ios的safrai，chrome，uc，海豚浏览器，qq浏览器，但是移动浏览器的渲染能力有限，相对于native来说，性能差距还是不小的。
3.开源。MIT协议的开源引擎意味着什么？意味着你可以任意扩展你需要的底层接口，可以满足任意需求，只要原生能够实现。同时你可以打断点跟踪bug，这个打断点并不是要去修改cocos2d-x的代码，这么做的目的是为了能更高的了解底层库的运作方式，从而来优化调节我们调用的逻辑代码，还能快速定位bug，当然这个前提是你要对cocos2d-x的代码有一定的熟悉，好在cocos2d-x的源码写的非常优秀，就算是学习的角度来讲，也是非常值得看的。
4.本地打包。配好了环境以后（建议用mac环境）可以完成打包测试，发布等部署，加入第三方渠道SDK，完全由自己掌控。本地打包是相对于云端打包而言的，因为上述很多框架只能云端打包，云端打包方便是挺方便的，但是必须保证这个云端服务器是100%稳定的，不然到时候你想打包的时候服务器挂了，那你只能等待了。同时云端打包接入的第三方SDK是固定的，如果要加个云端没有提供SDK接口的渠道，那这个需求就实现不了了，所以个人认为云端打包比较适合个人开发者或者小型开发团队。
5.调试。调试是开发程序的重头戏，jsb的调试不太理想，手机端的调试只能打log，好在有cocos2d-html5。cocos2d-h5的api是向下兼容jsb的，可以这么说，95%的问题，在网页上用cocos2d-h5就可以解决，剩下的5%。。只能在手机上调了，这个看个人对这个2d-x这个框架的熟悉程度。据说下一个jsb版本可以断点调试了，源码中也已经有好多关于debug功能的代码，相信这个功能不远了。
6.原生接口。实际开发手游的时候需要很多和手机原生的接口，jsb在这里提供了CCEditbox(输入框),CCFileUtil(手机物理文件读取)，网络这块支持xmlHttpRequest,websocket。值得一提的是websocket还支持arrayBuffer格式，可以直接传输二进制数据，不用做额外的转换，除此之外的接口需要自己写了,比如获取网络状态（3G，wifi）,获取androidSD卡目录等等，这个看每个项目的具体需求来，因为jsb采用spidermonkey编译器，只要是C++可以调用到的接口，js都可以调用到。具体android可以用JNI和C++进行通信，然后C++再和js通信，ios是OC和C++混编的，所以接口写起来更加容易，之后的博文会详细介绍,网上这方面资料也很多。
7.源码保护。虽然是脚本，但是如果被人轻轻松松拿去看了，作为一个商业手游项目来讲，还是不太提倡的，特别是配置文件如果也采用的是js的话。。jsb除了常规的js压缩混淆外，还有个终极大杀器:bytecode。jsb通过一个工具将js脚本编译到spidermonkey直接读取的bytecode，这样既加快了脚本加载速度又解决了脚本的安全问题，就算你能想办法破解bytecode，破解完的还是混淆过的js脚本，利用价值大大降低。
8.社区活跃度。cocos2d-x的论坛（包括jsb）比较活跃的，每天有全球各种开发者讨论问题，jsb这块有核心开发者每天维护，基本上是有问必答，但是qq群好像不太活跃，可能大家都在埋头干活吧。
上面讲了这么多和其他H5框架的比较，再来说说和cocos2d-x本身的比较。
js是cocos2d-x支持的另一种语言lua一样，都是脚本语言，脚本语言最大的特点在于在线更新。在appstore这个审核至少1周的情况下，在线更新给了游戏很大的选择权利。虽然这种做法苹果并不是所推崇的，但是不管你信不信，现在新的手游越来越多的用到在线更新，灵活的版本发布用过了都说爽。除此之外，游戏逻辑脚本因为相对少的涉及C++，所以crash的几率相对比C++要少一些，至少目前的观察如此，当然前提是要有高的脚本代码质量，并不是因为脚本就可以随便乱写，一段js代码不同的写法甚至有10倍，100倍的性能差距。
相比兄弟脚本lua，js的优势是面向对象，和网页版。可能也有人说面向过程也可以同样写好游戏，这个确实没错，但是大多数开发者的思维还是面向对象为主。至于网页版，除了调试的方便，至少还多了一个平台，虽然现在手机网页这块支持的并不是太好。至于js的劣势，那就是js实在太灵活，所以相比lua的话还是要牺牲一点性能，另外js的编译器十分复杂，一般的人驾驭不了他的源码，但是按照api调用方法还是没什么问题的。
以上只是一点对jsb的认识，如果你正在项目框架选型的话，希望能够给你一点帮助。