經過將近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
參考：
http://www.cocoachina.com/bbs/read.php?tid-271244.html
http://quick.cocos.org/?p=1707