认识cocos2d-x jsbinding

近年来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的认识,如果你正在项目框架选型的话,希望能够给你一点帮助。

 

上一篇:HTML5 localStorage本地存储


下一篇:Java 常用对象-基本类型的封装类