1. 程式人生 > >與Cocos2dx作者王哲及其團隊技術討論會的一些筆記

與Cocos2dx作者王哲及其團隊技術討論會的一些筆記

Cocos2dx的作者王哲來到公司給大家做了一場技術答疑會

以下是我及我們專案組的一些Q&A

1. Cocos2dx 3.0版本在引擎退出時, 會有記憶體洩露

我:本來以為這個在rc1版本中發現的問題會在final版本中解決, 但實際上還是沒有解決. 本人使用的是Windows下的VLD的記憶體洩露檢測, 多年來這東西一直沒有誤報過, 雖然這個洩露不是很大, 但會干擾在這引擎上開發的邏輯的記憶體洩露查詢

王哲:Cocos2dx的記憶體洩露測試是在XCode下進行的, 藉助mac平臺的工具來做的, 他說, 雖然作業系統會在程序結束時會自動回收, 但還是會在patch版本解決這個問題.

2. Cocos2dx 3.0 中的getInstance設計問題

我:3.0中的singleton是使用自動new的方式來實現的, 物件都是分配在堆上, 而不是棧上. 這種方式的特點就是在singleton為空時, 自動new出來, 從而讓上層保證使用簡單. 但是弊端就是前一個問題說過的, 如果處理不當的話, 會導致記憶體洩露.

3.0中的Director在析構時, 會先刪除Configurator的一個配置類, 但是, Renderer在析構時, 又會使用到這個配置類, 呼叫配置類的單件, 從而導致配置類重新例項化. 之後, 就沒有管理配置類的析構, 所以發生記憶體洩露. 我嘗試修復這個問題. 但是因為getInstance本身的設計弊端,導致拆東牆補西牆, 東牆又倒掉的問題.

王哲: 已經發現這個問題, 會在未來版本加以修正

3. 為什麼不自帶更新系統

王哲: Cocos2dx引擎一開始設計是偏重於渲染器, 所以包括網路及其他部分都是屬於附屬. 現在開發團隊只有10個人, 所以精力也是有限的

另外, 每個公司和個人對更新系統的需求都不是一樣的. 不過引擎會在以後版本中的ResourceManager提供一些類似的功能

4. 幀率控制器

我: 遊戲一般分為固定幀率和可變幀率兩種更新方式. 前者在早期的日本遊戲中常見, 後者是3D遊戲及後期的遊戲中用的比較多. 在U3D中分別使用FixedUpdate和Update兩種方法來實現類似的功能. 但是在Cocos2dx中沒有實現類似的功能.

王哲: Cocos2dx裡因為要處理一些複雜的情況, 比如接聽電話之類的, 所以這裡仍然使用可變幀率來做.

我: 虛幻裡有一套更新演算法, 在幀率足時, 擊中處理一些垃圾回收, 記憶體釋放等耗時操作. 但是超過預設的閥值後, 停止佔用幀更新時間, 留給邏輯足夠的更新時間. 但是沒看到Cocos2dx內使用這種演算法

(其實王哲應該沒聽懂我說的意思)

王哲: 我嘗試在3.0的渲染器中支援多執行緒, 但是在某些情況會出現crash, 而且這種技術的加入會提高引擎的門檻, 所以未來會根據實際需要加入.

5. 為什麼不統一setResourceRootPath/setResourceDirectory 的介面?

這是我們專案的一個兄弟做下載更新時, 碰到的2.0中的一個問題. 王哲表示3.0已經做了1年半, 2.0的東西都忘記了, 但是在3.0中是統一的介面.

6. 如何看待雲風噴cocos2dx?

這是我們專案的一知乎粉提的問題. 王哲說, 雲風對C++很反感, 所以自己的程式碼及專案大部分都是C. 因此對cocos2dx這種C++引擎肯定會有些反感. 但是cocos2dx的使用率很高, 不能因為一兩個大佬的意見而改變cocos2dx本身的一些優勢

7. SpriteFrame和紋理的釋放問題, 為什麼不使用智慧指標?

王哲: 我做過一個測試, 智慧指標在移動裝置上跑的速度肯定是要慢於retain/release這種手動方式, 所以依然在3.0中採用retain/release方式.

我: 我們有某些資源需要常駐記憶體, 但是全域性方式的SpriteFrameCache和TextureCache會導致這個問題很難解決. 能否提供分組資源管理概念

王哲: 這個修改其實沒什麼難度, 論壇裡也有很多建議, 我們會考慮在新版本支援這些功能

8. Scene的介面不統一, 用錯還會crash

王哲: 這個問題確實存在, 我們會加以修正

9. 為什麼要對STL進行一些包裝, 而不是直接使用?

王哲: 因為要適用於retain/release模式( 此時, 我終於發現我們為什麼會出現第七個問題了)

10. string為什麼需要一種垃圾回收機制來進行回收, 而不是直接用string?

王哲: 這是一個歷史遺留問題, 為了相容objc版本的移植及風格

其他的一些資訊

CocoStudio是使用WPF寫的, 底層使用P/Invoke與C++引擎層進行互動. 有人提出這個編輯器要開源麼, 作者表示後期會考慮的, 但是因為程式碼很亂, 所以一開始沒有考慮開源

本人感受, 微軟的一切開發工具及程式碼的東西都是按商業模式做的, 根本不考慮開發者的利益. DX7到DX11, 說好的COM相容, 最後改的一塌糊塗. MFC那麼老掉牙的東西, 到VS2013都還在更新, 這不是禍害群主麼. XNA退不起來, Silverlight幹不過Flash. 更別說亂的一塌糊塗的WP, WindowsRT, WinPhone. 對於VisualStudio來說, 這是地球上做的最好的編輯器, 保留這個足矣, 但是也別太依賴即可. 擁抱開源, 珍惜生命, 遠離微軟

WP版的Cocos2dx支援是微軟設在西雅圖的一個叫OpenTech的公司來做的, 並非王哲團隊做的. 而且DirectX現在變成小眾API, 因此這公司採用AngleProject來用OpenGL模擬DirectX的介面, 當然效能上肯定有很大的損失

最後附上王哲團隊的照片以鑑真偽

image