2013-01-11 41 views
1

我正在構建一款iOS遊戲,我注意到遊戲在XCode調試器中正常運行時表現良好。但是,當我從樂器(產品 - >配置文件追蹤泄漏)中運行它時,遊戲會在儀器顯示左邊欄中的「分析過程」時凍結。之後,由於遊戲中被分析的某些部分凍結而其他部分繼續運行,遊戲將其所有狀態混淆。在分析儀器過程的同時,ios遊戲不同步 - 我該如何避免這種情況?

這是我可以/需要解決的問題,還是足以確保遊戲在發佈中運行?

如果需要修復,我需要做些什麼才能使它工作?

更新1:

所以我們找到了問題 - 同樣的問題repros即使我們在玩遊戲,按home鍵,然後點擊遊戲圖標並繼續播放。

問題是我們的大部分工作都是在update方法中完成的,它依賴於(ccTime)dt參數的值。 dt的值通常爲0.1秒,偶爾會在0.5秒以內)。當我們暫停時(通過點擊主頁按鈕,或者儀器暫停遊戲拍攝快照)並繼續播放時,dt的值爲幾個秒!這會讓我們所有的計算超出範圍。

我們試圖修復該問題的臨時(但醜陋的)解決方法:在更新方法的開始,我們補充一點:

if(dt > 1) 
    return; 

而且它現在將按預期 - 不出去的同步。然而,這不是一個永久性的解決方案,因爲dt的值有時候合理地接近1秒,並且在資源緊縮的情況下,這可能導致口吃(或更糟糕)。

我們還考慮存儲DT的前值的另一(同樣醜陋的)解決方案,然後在更新方法檢查:

if(dt > 10 * prevDt) 
{ 
    return; 
} 

我們打過電話的applicationDidEnterBackgroundunscheduleUpdateAppDelegate.m,並呼籲scheduleUpdateapplicationWillEnterForeground方法,但該方法無效。

處理由於外部暫停導致不穩定的時間值更新的最佳方法是什麼?

感謝 阿南德

+0

爲什麼當您檢測到遊戲被暫停時,您只是將遊戲置於暫停狀態?恢復之後,您只需重置計時器,三角洲不會高得離譜 – Toad

回答

2

我對Cocos2D的工作原理了解不多,但是如果您已經用完了選項,我會簡單地將增量時間限制在較高的範圍內。無論使用什麼更新方法,德爾塔時間,我會做以下。

double delta = (dt > 0.5) : (0.5) ? (dt); 

使用delta而不是dt從該點開始。結果是任何具有超過半秒的增量的幀將被限制爲0.5秒的增量。你不想跳過幀,因爲那樣你可能會跳過連續的很多幀,這對用戶是不利的;他們可能會認爲該應用程序崩潰或什麼。然而,你不想運行一個大的三角洲的框架,因爲那麼依賴於三角洲的對象和力量會在該框架上倍增很多倍,從而阻止你捕捉碰撞和東西。所以,我們通過簡單地將值降低來避免遊戲完全被篡改,而不會跳過幀。

消極的一點是,當您的幀速率降至每秒2幀時,應用程序將顯得移動得更慢。你失去了基於時間的更新方法的好處,即當引擎負擔過重時,總能讓遊戲以明確定義的速度運行。老實說,如果你長時間以每秒2幀的速度運行,你就有更大的問題需要擔心。我不認爲用戶會注意到,如果遊戲只在每個人都知道的情況下呈現一次,那麼每秒對象的移動速度會稍微慢一些。

2

不幸的是,這是一個問題,這是沒有答案肯定;至少不是無法訪問您的系統來運行各種檢查。

配置文件中的失敗可能是因爲您的遊戲運行緊張循環,其中以不可預測的方式讓您感到不安並且由於時間或資源問題而導致遊戲崩潰(這些時間問題不會隨着調試器以相同的方式)。如果是這樣的話,你可能不會做太多的事情。或者可能是因爲您的代碼存在問題。問題是要弄清楚哪一種情況是非常困難的。儘管可能最好假設問題出現在代碼中,但需要進一步調查。

要做的第一件事,如果你還沒有做過,就運行靜態分析工具(從Xcode的產品菜單中分析)。仔細考慮每個提出的錯誤,並努力消除所有這些錯誤。有時他們可能看起來很明顯,你認爲你可以忽略它們,但是有些刺激表明它們是一個更深層次問題的症狀。

如果你還沒有嘗試過,嘗試運行儀器來檢查殭屍。如果分配工具失敗,這種情況很可能也會失敗,但是如果有一些陳舊的引用來解除分配的對象,可能會導致您遇到的問題。您可以嘗試的另一個工具是性能分析器,以檢查您的應用程序花費大部分時間的位置。對於您未知的資源分配可能存在一些非常重要的問題。如果您無法運行內存分析器,則很難確定是否屬於這種情況,但使用性能分析器時,可能會發現應用程序在某個應用程序中掛起的時間太長,不要。

最後 - 如果一切都失敗了,這可能是一個大錘破解堅果 - 也可能不會提供解決方案。如果您不使用ARC,請考慮將您的應用程序轉換爲使用它需要多長時間(儘管如此,請務必先創建一個分支)。對於Apple對象分配/解除分配的算法非常有效,如果您有微妙的內存管理錯誤,它們很可能會被自動引用計數消除。

+0

非常感謝您 - 將嘗試您的建議。 – Anand

+0

我嘗試了一些建議,但到目前爲止沒有多少運氣 - 我的應用程序在泄漏儀之外運行時運行良好。我還驗證了(通過在工具中使用不同的快照)我的應用程序的每個部分都運行無泄漏。唯一存在問題的時間是應用程序在泄漏儀器內運行時分析過程。我想決定在提交之前必須投入多少資金來解決這個問題 - 這是否會導致拒絕或值得提交的某種/可能的原因? – Anand

相關問題