cocos2d-x代碼質量如何？

01-23

在問題有哪些遊戲引擎的源碼值得一讀？有前輩提到Cocos2d-x的代碼質量不好。
究竟是那方面需要改進呢？

1. API兼容問題

1.x和2.x：早期版本的cocos2d-x API是跟隨cocos2d-iphone同步的。也就是說，當時目標方便已有的cocos2d-iphone遊戲移植出cocos2d-x版本，把cocos2d-iphone用戶轉化到cocos2d-x上面來。很多人反饋引擎里大量使用宏的問題，也是在這個階段發生的，因為需要大量去模擬Objective-C的語言特性。但是從2.x最後的結果來看，這個階段的目標達成了。

3.x：如前面網友所說，招募了Ricardo Quesada加入觸控之後，為了提高逼格，對絕大多數API重新設計，使之符合英文語法習慣。當時有兩種策略，第一種是每次改一點，第二種是一次修改到位，然後很長時間不需要再改。最後我決定採用第二種方案，長痛不如短痛。3.0的大規模修改之後，雖然被老用戶大量吐槽，但cocos2d-x在海外的市場佔有率的確大大提升了。另外, 從3.x開始和cocos2d-iphone斷開同步，並進行超越。從目前來看，達成了這個目標，cocos2d-x已經成為cocos2d系列裡面的主幹。

4.x及未來：我承諾，在API、namespace、以及文件目錄結構方面，未來版本會在3.x基礎不會再做大規模的改動。因為需要改的，在3.0裡面已經修改完成。

2. 開發效率問題

觸控內部也知道studio雖然有很多公司正在使用，但並不算成功。但很抱歉，上個月發布的Cocos Studio 2.0總算比1.x要好一些了，但具體反饋情況還需繼續觀察。

我的策略是，類似於Flash的工作流，Flash Pro -&> Flash Develop -&> Package，把cocos的工作流設計為 Studio -&> Code IDE -&> AnySDK (optional) -&> Package的過程

3. 3D支持

大家可以到Github上看一下我們新開源的3D遊戲 chukong/FantasyWarrior3D · GitHub，採用Lua開發。

4. 質量

代碼質量方面，我們在兩年前就開始用持續集成測試了。大家如果到 Pull Requests · cocos2d/cocos2d-x · GitHub 上面看，但凡issue後面打個綠勾的，就是這個pull request代碼改動在持續集成編譯(ios, android, windows, linux, mac)上編譯通過，而打紅叉的就是編譯失敗不會被merge到主倉庫。

發布版質量方面，隨著代碼規模增加，即使同樣的bug率，對大家而言直接感受就是bug數量增多了。這問題在上個月開始已經建立了QA團隊來解決。以前都是引擎開發團隊自己寫自己寫單元測試例來測的，但以現在的團隊規模，沒有專職的QA組就搞不定了

5. 開發者大會

一方面，如果從觸控商業和投資者關係的角度來看，自然會理解為什麼在開發者大會上需要找一堆使用了cocos2d-x做出top10遊戲的知名遊戲公司，以及全球巨頭合作夥伴來了，沒有眾多合作夥伴、沒有觸控，cocos2d-x就不可能一直開源發展到今天，為無數公司提高效率降低成本；

另一方面，多數聽眾的確需要從知名遊戲公司身上學習到人家的遊戲開發設計經驗。我們邀請了cocos2d-x上的知名遊戲開發商如刀塔傳奇、Line、Square Enix、Aiming等來分享經驗，人家也不是來刷臉空談的。

樓上有的朋友說who care，真正who care的只有下午的合夥夥伴場，但遊戲場和技術場就擠到爆，遊戲場我自己進去後都只能站最後面，到技術場一開門就被堵在外面，好不容易擠進去只能坐地上。如果各位虛心聽的話，有很多可學習取經的內容。

6. 技術支持

對於處於中長尾的多數遊戲開發者而言，cocos的技術支持力量已經捉襟見肘了。最早的時候都是我、小明、林順直接在論壇和微博上做技術支持，那時候大家還算滿意。但現在我們已經完全忙不過來了，多項目管理、內部流程、商業合作，就把引擎的幾個創始人的精力全部拖進去。

Q4我會重新梳理技術支持組的人員和目標，增加技術支持人員，在中英文論壇上給大家提供更好的技術支持服務。

7. 其他

首先，今天國內排行榜首的的手機遊戲有60%～70%，日本和韓國30%～40，微信遊戲56%是用cocos2d-x開發的。所以cocos2d-x的質量不是絕對完美，但能保證相對較高。

其次，我做了很大的努力，嘗試平衡開源和商業之間的關係，在對開發者完全免費，免費框架、免費工具、免費技術支持、讓大家滿意的情況下，同時：

- 必須投資人還有個交代，

- 必須面對國外10多年公司歷史的競爭對手（cocos2d-x的歷史只有4年），

- 必須面對網路上的冷嘲熱諷，

我必須要面對這些么？其實我出去隨便拿點投資自己做個遊戲，賺得不會比現在差，也省得現在晚上7點半了還沒吃晚飯，餓著肚子在這裡回知乎的帖子。

我努力達成的願景是：

- 做出國內最好的開源項目（達成）

- 做出世界一流的開源項目（達成，github c++類項目長期全球前十）

- 對開發者真正永久免費（達成，對未來也比較自信）

- 對上游服務如廣告、支付、統計、雲服務、推送等進行收費或分成，回報投資者（已接近，未達成）

希望大家能給予理解和支持。不管有多少人嘲笑，我們仍然會一步一步把2D功能做完善，把3D功能和3D編輯器落地實現了。李書福做吉利汽車的時候不也是無數人嘲笑么，華為海思剛開始作晶元也被人嘲笑，技術落後並不可怕，可怕的是已經沒有了挑戰和超越的信心。

從cocos2dx 1.x開始接觸這個引擎，已經用了兩年。

當前的項目基於cocos2dx 2.0beta。

很多同學提到的內容已經不屬於代碼質量問題了，因此我的觀點也分為兩部分，先說代碼部分問題，後說引擎本身相關問題。

————————————————————————————————

首先是代碼相關的問題：

API改動：

從2.x到3.x，幾乎所有東西都改了，但名字還叫cocos2dx。

這是所有cocos2dx老用戶心中的痛。可能是官方在招募了cocos2d作者後為了短時間內提升逼格而這麼做的，好處是3.x逼格確實提升了，壞處就是2.x升級到3.x非常困難。看看其他童鞋的回答就知道了，大家的怨念有多深。對了，出版cocos2dx相關教程書籍的也都哭了。

因此如果你想學習cocos2dx，買來的書上面的例子都過時了，不要奇怪。

各種奇怪的錯誤：

是的什麼引擎都會有奇怪的問題，但是cocos2dx的問題明顯多很多，而且官方解決問題的態度明顯更不負責。

cocos2dx沒事就會更新個版本，alpha0,1, beta0,1 , rc0, 1像模像樣的。

我有收集癖，每個版本我都會下載下來編譯，甚至發布到手機試試。

但是這些大部分跑都跑不起來，經常上個版本是對的，這個版本又錯了，beta版還是對的，正式版又錯了。。。

關於 plist：

從3.x代碼及相關工具來看，官方是準備廢棄 plist 的，改用 json.

返回常量引用問題：

這一點在3.x基本都改了。

各種奇怪的宏：

這一點確實影響閱讀，但時間久了也還算能習慣，不算太大的問題。

————————————————————————————

之後的部分為引擎本身的問題，想使用cocos2dx開發遊戲的同學可以看下。

周邊工具不完善：

這一點是該引擎的硬傷，官方在不斷推CocoStudio, CocosIDE，但這兩個東西BUG多的感人。

昨天出了cocos引擎，說是整合了，我開開心心去下載，700多M的安裝包，我心想難道做成Unity編輯器或者Unreal Editor了？安裝後一看，桌面上多了幾個快捷方式，包括CocoStudio和CocosIDE。。。敢情是這麼個整合法。。。

——————————————————————————————

好吧，這個問題已經完全變成對cocos引擎的評價了，而非代碼質量評價。

我刪除了對代碼質量的總評，畢竟這是個主觀的內容。

個人當然是希望cocos走的更好，但僅靠希望是沒有用的。

cocos目前的形勢已經非常嚴峻了，尤其是暢銷榜新秀都是3D遊戲。

選擇更好的2D還是加強對3D的支持，我才疏學淺，不好定論，但就目前來說，3D方面Unity是碾壓cocos的。

希望作者多體會下開發者的需求，僅憑腦殘粉們的高潮是不夠的。

已為作者點贊，任重道遠。

——————————————————————————————————

2015年1月14日更新

已跳槽，還是用cocos2dx，我才是真愛

講幾個槽點吧.....

API兼容問題

我曾經嘗試過把某大型手游項目從1.x升級到2.x，發現大部分API都改了。最要命的是某些API不僅僅是命名改了，連調用方式都變了......

然後我大概花了兩個多月才折騰出一個穩定版本......

然後3.x出了，我看了下源代碼後，驚喜地發現除非重寫，否則不可能升級到3.x......

跨平台編譯問題

某個2.x的項目需要在windows phone平台上面編譯，我照著編譯文檔又折騰了一下，結果VS報了一萬多個錯誤。

當時我就跪了......

另外也嘗試過安卓下編譯。因為我們需要一些第三方庫加入到遊戲中，然後就發現從1.x到3.x，基本上每個大版本的更新都會改項目結構，原來那些編譯參數和makefile都得重新搞一次......

對以上兩個問題，官方的態度是：老遊戲請盡量不要升級舊版本引擎。

好吧........

開發效率問題

前面兩個問題雖然也不小，但畢竟也不是天天會遇到的。開發效率問題才是真正的硬傷。

Cocos2D始終缺乏一個好用的編輯器和開發IDE。當然他們確實意識到了這個問題，也推出了好幾套工具比如說CocosBuilder，CocosIDE等等工具，但是這些工具到目前為止還是處於碎片化的狀態，缺乏有效整合。

反觀Unity3D，從一開始就把他們的引擎打造成編輯器+IDE集成的形式，開發效率可以說已經全面超越Cocos2D了。（雖然他們也bug一堆）

3D支持太少

隨著手機硬體的進步，遊戲3D化是未來的趨勢。不得不說，Cocos2D目前還沒有把自己當成一個3D引擎來發展。但是看一下PC上遊戲的發展史就知道，即便是2D遊戲也會逐漸引入一些3D的建模和效果，長此以往，Cocos2D有被邊緣化的危險。

其實邊緣化的趨勢早就已經開始了：據前一段時間的統計，世界範圍內cocos2d的市場份額正在不斷下跌。中國範圍內cocos2d雖然還保持在50%－60%左右，但從長期的角度來看也是無法扭轉下跌趨勢的。這一段具體的出處我就不貼了，各位google一下就知道。

利益相關：

某MMO手機遊戲主程，cocos2D三年用戶，提交過一些代碼，目前退坑保平安。

因為都是一個圈子裡面的，抬頭不見低頭見，有的話實在不好意思說，就匿了，大家理解下。覺得我說得有道理，麻煩點個贊就成。

Update:

剛剛看了Cocos引擎的發布會，感覺觸控的這幫傢伙們終於把資源投到正確的地方了....前面黑了他們這麼多總算可以說幾句好話了（笑）。把Cocos2D改成Cocos引擎，看起來的確要學U3D了，至少從目前得到的資料看起來他們的確正在嘗試解決我提出的後兩個問題。具體效果如何，還沒用過新引擎暫時不作評論。

不過這麼一來商業化看起來也是不可避免的趨勢。當然這不是壞事，大家都要吃飯的嘛。如果有好用的引擎能大大節省開發者的時間，為此掏點錢也無妨。

最後還是希望觸控的大大們多完善些功能，少改點API....如果實在要改麻煩還是能給一個向前兼容的方案比較好.....跪謝了......

Update 2:

今天試用了cocos引擎......

用一句話概括就是，設計邏輯上先天不足，只照顧到了程序員而沒有照顧到不懂程序的策劃和美術，沒有js支持是硬傷，前景堪憂。

還有很長的路要走啊。

記得雲大在skynet群里說粒子那部分，他用300行代碼就搞定了，可是cocos2dx寫了上千行。。。。

//當初看他們聊的本菜鳥，還特地複製了下聊天記錄，不是截圖。部分內容有刪節，大家看看就好

//我不知道這樣貼聊天記錄是不是合適

@唐任你要的出處~

雲風

國內另外幾個山寨的也是用 cocos 抄的, fps 更低

香蕉周刊
2014/7/7 20:20:30

cc 為了降低門檻做了很多很sb的東西

雲風
2014/7/7 20:20:38

粒子多了不流暢

2014/7/7 20:20:51

雲鳳你們e2d有粒子系統嘛

雲風
2014/7/7 20:21:05

這種東西一個下午就做了

雲風
2014/7/7 20:21:08

需要自己做

ejoy2d/particle.c at master · cloudwu/ejoy2d · GitHub

就是 300 行代碼而已

雲風
2014/7/7 20:22:38

一個下午做不完嗎?

其實就是翻譯的 cocos 里的 cocos2d-x/CCParticleSystem.cpp at v3 · cocos2d/cocos2d-x · GitHub

不是優化版,是重新用 C 實現了一遍而已

cocos2d-x/CCParticleSystem.cpp at v3 · cocos2d/cocos2d-x · GitHub　1176 行

雲風
2014/7/7 20:25:40

ejoy2d/particle.c at master · cloudwu/ejoy2d · GitHub　321 行

完全一致的

雲風
2014/7/7 20:26:03

這個設計的很糟糕

雲風
2014/7/7 20:26:19

不應該這麼做粒子系統的,　我們只是為了兼容而已

雲風
粒子不應該用 sin cos 這些三角函數做

香蕉周刊
2014/7/7 20:27:43

為什麼

雲風
2014/7/7 20:27:46

這是初中數學水平設計的

廣州-牧
2014/7/7 20:27:56

那應該用啥

廣州-clear
2014/7/7 20:27:56

雲風
2014/7/7 20:27:57

上過大學的都知道用矩陣

雲風
2014/7/7 20:28:17

2d 3d 只是矩陣的維度不同而已,演算法是一致的

雲風
2014/7/7 20:30:00

而且 cocos 那個裡面還用角度,　然後每次算的時候都轉成弧度,　算完再轉成角度
雲風
當時我都看得無力吐槽

只說用的比較廣泛的2.x，從代碼質量上只有吐槽的份了：

1 到處是莫名其妙的宏

2 各種未定義行為，感覺稍微正規點高校出來的學生都不會出現這種問題

3 使用c++但是沒用任何模板，給對象綁定函數也沒法使用任何函數對象

個人看法基本上就是一個打著C++幌子，使用C編寫的模仿OC的東西

我是來感謝觸控團隊和 cocos2d-x 引擎的，沒有觸控在這個開源引擎上的投入的話，我和許多我所認識的小公司將會舉步維艱。

我是在14年初開始使用cocos2d-x，在次之前使用 Adobe AIR 做手游的開發， Adobe AIR 的全封閉環境和堆積如山的 jira bug list 讓我們團隊實在無力吐槽。更要命的是沒有完善的適合手機的UI系統（Starling是一個真坑），當時項目開發的速度非常緩慢，許多基礎的渲染實現都需要手敲AGAL（敲到每天吐血三升）。

我們把當時的項目運維結束之後，果斷決定遷移框架和工具鏈。同時看了Unity3D 和 Cocos2d-x。由於進入的時間關係，我是從 Cocos2d-x v3.0 beta 開始接觸 Cocos的，所以這可能就是在我眼中 Cocos2d-x滿滿都是美好的原因。U3D 和 cc2d-x 想比之下，開發效率相差不是一點半點。 cc2d-x 的真正魅力在於 lua-binding + 完整的命令行工具鏈。我們現在的項目，採用 cc2d-x 作虛擬機，moonscript 做代碼編寫環境，lua 做代碼執行環境， busted 做單元測試環境，加上自動化的編譯鏈和測試鏈。開發效率有了本質的飛躍。從而使我們能夠把主要的精力傾注在產品的體驗上。

遊戲啊遊戲，失去了可玩性的話，還算什麼遊戲呢？

在12年的時候，我也嘗試使用過 cc2d-x，但是由於圖像的載入依賴文件後綴名等一系列不太專業的實現缺陷而沒有使用 cc2d-x。所以一年以後，看到 v3.0 的重構力度時，我真心佩服觸控實在下了大血本。 v3 的實現結構給我的感覺就是一個字：「專業」。v3 的可擴展性很強，代碼之間的耦合性大幅降低，在遇到需要對cpp的實現進行修改時，我發現修改都可以被控制在一小代碼片段中（開心）。

另外，想多嘴說一下對 cocos 的 GUI 工具的看法，我覺得這是一個很大的悖論：一方面沒有簡單易用的GUI的話，cc2d-x無法快速普及。另一方面要滿足做出專業的精品化的遊戲產品，觸控的GUI團隊在這方面缺乏積累（這是U3D的優勢）。這樣的話會不會導致，在未來可見的幾年中，GUI將處於一個玩具的位置呢？這樣的話，將會損耗觸控的商業模式。

那麼如果真面臨這樣的情況的話，是否能夠給GUI用戶一個可以預期的退出點，讓小白用戶經歷了GUI之後，變得更加專業呢？如果小白用戶通過GUI能夠升華的話，是否能夠把他們引導到雲伺服器平台上呢？這樣對開發者和觸控都將是雙贏的。

我覺得所有在回答里吐槽的同學，真不如去github上push幾個request來的更痛快。

—————————————我是華麗的分割線——————————————

開源項目本身就是一個開放的社區，創始群體的本意是希望大家共同來建設和維護。如果覺得有改進的空間，fork出來一個版本，push一些你覺得不爽的request就好了。而不是繼續當伸手黨在那裡無責任吐槽。而這些吐槽的本意在我看來更像是，「啊啊啊，這個開源項目我用的好不爽啊，誰來幫忙改一下啊！」，請自行腦補那種愛吐槽自己團隊工作的奇葩。

其實這個問題還可以延伸到：linux的代碼質量如何，openssl的代碼質量如何等各類問題。任何開源項目局部的代碼質量肯定不是盡善盡美，肯定都有其修改的空間，而這個不斷完善的過程也是社區發展的動力與基石。openssl還爆過心臟出血這麼坑爹的安全性bug,也沒見幾個徹底拋棄了openssl的，有問題修復了，繼續前進就好，沒有必要糾結在那裡停滯不前。

看到答案里有轉雲風同學吐槽的文章的，我覺得雲風同學在微博等地方持續吐槽cocos2dx的這種情況，只能讓我聯想到郭德綱相聲里常說的一句話"同行是冤家"，而程序員這個熱愛分享與自由的群體本不應該是這個樣子，雲風大大完全可以用他多年的積累幫忙完善這個社區，比如他寫的那個粒子部分的代碼，我覺得依然有優化的空間，但是又能怎樣呢？還專門建個分支以挑釁式的證明自己的牛逼，我覺得這個態度挺low的，push一下就知道問題不只是這1個cpp就能解決的，很多時候需要融合在引擎里，兼容性沒有問題才算最好。

從我參與過的和觀察過的開源項目來看，一個開源社區想做大，非常非常不容易，創始群體不僅要孜孜不倦的維護，也一定走過了一條非常孤寂的道路才能把社區做到如此水平，我在寫一些開源項目的時候，經常會遇到如下對話。

同事：「你老寫這玩意兒圖啥啊？」

我：「給大家搭建一個更好的平台啊」

同事：「平台搭好了，你落著啥好處了?」

我：「呵呵，誒，對面新開了家麵館聽說不錯，你可以去試試~。」

這就是做開源的同學，在天朝經常遇到窘境。

cocos2dx開源項目本身提高了所有開發者或者說遊戲程序員的附加值。更重要的是降低了手機遊戲開發的製作門檻。

從資本層面講，資本更希望項目是閉源的，這樣才能提高進入門檻，讓自己的收益最大化（參考Intel和AMD）。

而開源項目則是很多混跡於閉源大公司的程序員同學為了提高自己的附加值，搞出來的項目。這剛好是程序員群體追求分享精神，追求自由的一種表現。所以我欣賞 Stallman，欣賞 linus，也欣賞王哲。

對於題主的答案我覺得

cocos2dx無論代碼質量如何，至少是社區規模較大，且持續更新頻率最高且開源的項目，我覺得從這幾點來看，如果想搞手機遊戲開發，都值得一看。

遊戲引擎，如果是閉源的，我覺得那才是有點兒坑，unity的loading的底層載入方式你只能通過開大會給你透露的一點點信息來獲取，想優化都無從下手。雖然他出demo飛快，但是遊戲開發中的優化移植或者加個新feature如果能自己掌控，那對於開發者來說效果會更好，而不是我向引擎方提反饋，引擎方根據自己的時間來安排修改。這一點unreal做的不錯，至少給全代碼。

利益相關：cocos2dx使用中，unity,unreal各類引擎研究愛好者。

對這個引擎的底層實現研究的不多，所以我這裡只是從一個使用者的角度簡單說幾點吧：

1. 資源管理過於簡單，缺少資源預先載入和分組管理這些常用功能，引擎的資源管理基本上就是一個文件路徑加上一個引用計數；

2. 抽象層次混亂，對於使用者來說像sprite這樣在抽象層次上已經是較高的了，在裡面直接使用底層opengl里的概念設計方法，比如設置Blend Func；

3. 類的命名不自然，比如MenuItemFont，第一次接觸的時候我差點以為這就是一個Font類；

4. 大量的使用了宏，這個應該是因為Object C里很多的語言特性在C++里沒有，所以只好用宏模擬了，這些宏的存在很影響閱讀。

我是從2.0開始用的，精靈渲染的各種混合錯誤就不說了，各種奇葩的所謂設計模式更是讓人抓狂。3.0正式版發布後，通過vld發現引擎卸載時有內存泄露，已經刪掉的配置系統單件實例在其他模塊卸載時又被重新new出來。當面問過@王哲，說在ios下沒有泄露，即便有，操作系統在退出時也會釋放，超級無語。

一個跨平台引擎，編輯器框架居然使用了超級冷門的微軟的wpf。

現在已經全面轉向u3d，心情好多了

@王哲

其實不反對COCOS去追求3D，但實際上我覺得更應該把握好2D市場份額。

簡單來說，目前的2D引擎在API的可用性方面還有較大的提高空間的情況下，就貿然的去做3D相關內容是一個錯誤的選擇。

開發過3D遊戲的同學都清楚，實際上不是寫一套解析3D數據格式，將3D對象渲染出來就是3D引擎了。它最核心的內容是一個編輯器。就跟unity與虛幻做的一樣。這不是一蹴而就的。這需要豐富的產品經驗與解決方案，你現在就想去搶佔他的市場份額是不現實的。

而單單從做出來的studio我就可以發現，實際上cocos團隊並無更深層次這方面經驗可談。實際並沒有了解到一個開發人員的真正需求所在。一個簡單的例子，早期我在選擇ui編輯器的時候是考慮過studio的，但是後來我發現她並不支持我自己自定義的plist。也就是說我無法自由的選擇我的材質合成規則。這是我無法忍受的。

所以我個人認為cocos團隊更應該做好的是2D方向的介面設計與功能完善（嘈點太多，我實在無力吐槽）。就我個人而言已經在考慮放棄cocos的邊緣了。因為unity已經開始大範圍的支持2d部分（雖然他不是免費的，也不是開源的）。但是一個公司的策略並不是一層不變的。我相信當有一天它（unity）改變了他的商業策略後，對cocos的衝擊將是明顯的。

一般代碼質量不太好也不會去作死，但是cocos2dx作的一手好死，2.x到3.x，一堆api和函數名全變個底朝天。怎麼個變法？就是你上網上找的例子代碼90%都是2.x的，你用3.x絕對報一堆的錯誤，然後你要去找新的名字是什麼，一點點代碼還好，但是如果是已經完工的項目想升級版本，呵呵呵呵呵呵呵呵呵呵。

代碼裡面各種蛋疼的地方我就不詳細吐槽了，但是物理引擎封裝的我簡直要吐血身亡。本來別人有的比較核心的功能非要去屏蔽掉，結果想用都用不了，摔！

一個有追求的程序員應該對自己的產出有著近乎完美的追求，就算不那麼苛刻，能不能發布版本的時候認真一點！3.2的正式版本居然生成的工程文件裡面把android工程的build path寫錯路徑了！我還鬱悶了好久為什麼空白的項目都有配置錯誤。我覺得一個東西的用心程度可見一斑。

如果cocos按Entity,Component,System這樣流行的遊戲開發方式來做就好了。

不過如果這樣做，cocos可能就不是一個小白的工具了，也許就不會這麼流行了。

不過cocos經常在不同實現方案中選擇較差的方案，應該是歷史問題或者其他問題。

這真是個奇怪的現象，大家普遍都覺得cc2dx的代碼不好，但他卻是發展最快的開源引擎，而且大家也只是邊罵邊用，沒有自己花心思去再度開發新引擎，這恐怕這還是和急功近利的手游市場脫不了關係。

仔細讀過了Cocos2dx大部分的代碼，感覺維護引擎的人的水平參差不齊

印象比較深刻的就是CCTableView的初期版本，一開始以為是福音，打開代碼一看各種問題

UI方面，沒有一個統一的框架，CC系列UI Widget系列UI External系列UI共存，該刪的代碼還是要刪

如果說外圍的東西寫的不是很用心的話，咱看看核心的代碼，一個是消息機制，EventDispatcher，職責實在太多，耦合性挺高的，並不是一個簡簡單單的消息機制，再往前推，CCNotificationCenter，這個裡面的代碼把我嚇尿了，每次觸發一個消息，create一個數組把整個監聽者列表拷貝一份，然後讓它自動delete，就為了解決觸發消息時動態增刪監聽者這麼一個異常，EventDispatcher雖然這方面沒這麼笨，但這代碼看上去也是怪冗餘的

再說一個CCNode，3.0之後往裡面添加了物理的功能，這顯然並不合理，一大堆預處理把代碼的可讀性降到最低，雖然說CCNode中的物理需要設置才會生效，但從面向對象的角度看，不應該在Node中，這樣強迫所有的Item，Scene，Sprite等等全部擁有這個物理屬性，但實際上遊戲中需要物理屬性的對象，非常少。

然後其他各種影響效率的，不是最佳寫法的小細節，還有冗餘，也蠻多的，就點到為止吧

我之前是寫flash3d引擎的。想學習一下opengl。然後我就看了一下cocos2d-x的源碼。

關於c++語法的問題我就不說了，因為我自己本身也不會。只說引擎方面，現在我記得住的。

1、批處理那裡，不應該更新所有的，頂點數據是支持更新一部分。

2、矩陣應該用四維矩陣，位移、旋轉、縮放都應該是基於矩陣的，而不是用三角函數轉換然後填充到一個三維矩陣，再由三維矩陣轉換成四維矩陣上傳到顯卡。

3、個人覺得整個render就是多餘的。

4、還有一些其它七七八八，記不清了，當時看的時候給我的感覺就是引擎不應該這麼寫。有些地方性能損耗其實挺大的。

我們使用cocos2d-x結合titanium做跨平台的行情圖（股票）。有點大炮打鳥打鳥的感覺。坑真的遇到不少，因為3.x概念變了，我們沒法升級到3.x。最想說的是，因為是單例模式，沒法在兩個glview上畫兩個行情圖。說到代碼質量，還是不錯的。而且通過自己的努力，2.x可以通過arm64編譯。

哈哈，樓上都把我想吐槽的吐的差不多了...

我來吐槽下cocos code ide。

一個字：卡（間歇性的卡，抓狂...），兩個字：奔潰（一直開1、2個小時就會掛掉）！

一個高逼格的開發工具真不能和這兩點沾邊！！

這種直接影響用戶體驗的問題為何一直沒有相關領導 @王哲重視，如果連這種問題都解決不了的話，那這個ide就沒有存在的必要了！！！

作為項目一開始用2.x後來要轉到3.x的人來說，我只想跟官方說你過來，我保證不打死你！奶奶的，2.x本來就存在很多bug，然後你現在跟我說2.x不維護了，讓我直接升級的3.x版本，但是3.x的API改動那麼大，你有想過我移植的感受么？！

另外官方版本發布不夠嚴謹，有時用新版本創建的新項目連編譯都編譯不過。

用得不多，去年間間斷斷的玩過一個月。第一天就發現cocos2d-x引擎一個明顯的內存泄漏問題，然後一看源碼，當時就想把這引擎刪了

Cocos引擎先不說了，工具鏈這一塊還有很大的提升空間，cocos studio1.6這個牛逼編輯器，打開一個稍微複雜一點工程幾分鐘，我想來想去也只大量使用循環才有可能做到這麼慢了。

我用手機打完這些字，它還是黑的一片。不知道新版如何

我只說一點: 代碼耦合太嚴重,當初,cocos3d還只是測試的時候,我們打算自己實現3D部分,然後發現,基本上改不懂,看似簡答的東西牽一髮動全身.

3.x真心比之前好多了,如果不考慮移植問題的話,至少代碼結構比之前好很多,但是工程組織覺得有些欠妥.

代碼組織不規範以後細說，各個時期代碼都有，先佔坑。

目前使用版本

const char* cocos2dVersion()

{

return "2.2.3";

}

獲取控制項尺寸，不同控制項有不同寫法 getContentSize, getDimensions,getSize,getTextureRect(). 很不爽

代碼功耗是否太大有待證實，設備的發熱量很大。