经过将近1个月的分别摸索，最终还是选定了使用cocos2dx + lua的开发模式，虽然我最初的想法是由我和另一个程序分别研究下原生cocos2dx和quick，我是负责quick这块，最后我的结论也是推荐使用quick，但是由于最终客户端的开发可能不是由我主导，所以我尊重同伴的选择，采用cocos2dx+lua来开发客户端。虽然最后抛弃了quick，但是我还是把quick的一些特点简单罗列了下，分享给也需要做客户端技术选型的朋友：
quick
1、在cocos2dx的基础上增加了一个更加方便的lua框架
2、增加了若干游戏必备的sdk到lua的绑定，比如一个物理引擎chipmunk2D还有luajit
3、跟ios交互需要的object-c到lua还有跟android交互的java到lua的类
带来哪些优势：
1、减少封装cocos类到lua的过程，这是一个很大量的工作
2、网上有很多关于quick的热更新机制，应该可以拿来修改就使用，减少掉自己决定哪些内容需要热更新的时间，因为quick热更新基本就是全代码更新
3、调试速度比cocos要快一些，因为有quick-player，cocos也有调试的模拟器，但是跟quick-player差距还是很大的，同时调试lua不需要编译
劣势：
1、quick的文档或者教程基本没有，大量是依附cocos的教程来的，需要自己花费很多时间去了解cocos
2、quick2.2.1-quick2.2.5每个版本都修改了cocos的底层代码，导致版本之间差异很大，无法升级是小事，更重要的是有很多概念可能跟cocos有所区别，理解困惑。quick3x目前只有quick3.2和quick3.3；quick3.2同样对cocos底层代码有改动，在使用上依然很烦恼，quick3.3rc0没有改动底层代码，却跟之前版本的quick接口有很多不同，导致很多开发者抱怨。举个例子，比如quick自己的ui控件跟cocos的有差异，优化了渲染的过程，在同一个场景中不能使用quick和cocos的两种控件，只能使用一种，同样，触摸机制也不能使用cocos和quick两种。
个人建议：
使用quick最新版的quick3.3rc1，虽然rc不是最终的release版本，但是几乎不会有大改动了，之后只需要跟着github上修改bug就可以了。
原因：
1、cocos3X渲染性能比2要好很多，必然使用3X，无论是否用quick
2、quick已经被cocos收购，目测之后quick会和cocos合并成同一个东西，使用quick可以享受cocos的最佳lua封装，而不用自己去做
3、优秀的程序员就是要解决问题的，虽然quick的资料少，但正好是一个挑战，给了我们很大的空间，很多事情，指望别人先做，是永远没办法超越别人的，我们做第一个吃番茄的人，弄出来的经验可以分享给别人，无论死活与否，这都是宝贵的经验
4、用3.3rc1的原因是因为从这个版本开始quick对cocos3X的支持才算是完整，quick3只有3.2和3.3两个版本，3.2存在很多问题，因为他是quick支持cocos3x的第一个版本，但第二个版本3.3会吸取第一个版本的很多教训。而且3.3rc1已经可以很好的实现对ios64位的支持了，更好的说明文档和文件组织结构
如何去解决劣势：
1、对于上面劣势的第一点。需要用一段时间去拆分quick的api，规划quick的API模块，进行两天一次的API拆析，总结研究一天，一起从代码层面交流半天，然后自己再下去消化半天。初步安排是第一天规模各自分析模块，第二天各自拆析模块并安排讲解顺序，第三天下午由一个人先讲解他的模块，晚上由另一个人讲解他的模块，之后是重复第二天和第三天的过程。
2、对于劣势的第二点。看quick的发展势头，确实存在无法跟随cocos更新的情况，而且自己基于当前版本quick编写的代码很可能再之后quick更新后无法使用，但是由于目前第一次使用cocos作为手游开发，所以下一个项目或者说以后的情况还使不使用quick甚至是cocos都不一定，所以当然是用目前最好的方案来做。
github：
https://github.com/dualface/v3quick
论坛：
http://www.cocoachina.com/bbs/thread.php?fid-56.html
参考：
原文链接：https://www.f2er.com/cocos2dx/345639.html