喔！不~ 安桌 (Android) 當機了！ (UNITY 3.5.0f5 + 雙核手機)

Dear All:
這幾天將遊戲的測試版本放上Google Play，測試一下市場的反應如何以及順便QA一下(小團隊很難顧及所有Anroid機種)，看看在Android上是不是跟其他公司所說的問題很多。

• Day1：一切好像很順利... (心中有顆大石頭好像快放下了)
• Day2 ： HTC手機數量暴增... (心裡想，還好不是Samsung的，爽...)
• Day3 ： 咦？Samsung GS2突然上升
• Day4 ： 靠...HTC被超越了，Samsung GS2爆量... (心頭一驚！掐指一算，完蛋了)

其實在Release前，就知道在GS2上會發生 "不定期的當機" 或 "自動關閉"的狀況。當時僥倖的想，用GS2的因該不會這麼多人吧！真的是萬萬沒想到...，事情永遠不是 "笨的人所想的那樣"。這一刻，我突然想到某位網路 "J大神" 曾說 “哪個遊戲，不當機”。恩~有道理！心情頓時好了很多，沒關係在放一下好了。

慘劇發生！當我開啟反安裝的統計頁面時，GS2的 “安裝曲線” 與 “反安裝曲線” 成正比！

好吧！看來不修不行了！還是得面對這個問題，雖然我知道這可能是UNITY 3.5.0f5本身的問題。因為經過觀察，只要Dual Core CPU的Android手機不管是哪一個版本2.3.3、2.3.4 ~ 3.2、4.0.2全都有相同的問題。

經過一番的搜尋及縮小範圍，最後鎖定在遊戲中的一個閃電特效上！如下圖：

遊戲 ：“擂台王 (KungFuGo) 港譯：孫悟空大戰眾群魔” 劫圖

“就是這道光、就是這道光”，每次當機前都發生在閃電施放的 “前”、“後”。但問題來了，不管怎麼檢查這特效的編輯與製程都是對的。心中一直浮現 “因該是UNITY 3.5.0f5新Particle System的問題吧！”。但迫在眉睫，等UNITY改要等到甚麼時候？

最後根據經驗，懷疑一個系統設計的做法：“特效系統為了減少記憶體用量，所以把Cache的Queue刪除，讓每個特效使用時才Create、播完就Delete”。經過測試，遊戲整體跑起來很順，不因Object.Instantiate這樣的使用方式讓遊戲發生 “停頓” 的感覺。

但誰曉得會這樣？就在把系統改回Queue的實作後，當機的問題就解決了！

所以個人結論：

我認為UNITY 3.5.0f5在Android上，如果在Frame與Frame之間快速使用Object.Instantiate、Object.Destroy可能有Threading的問題，導致Dual Core CPU手機上不定期的當機Bug。(PS: 強調，Single Core CPU完全沒發生過當機)

作者：Bric Lin, Email: ericlin09@gmail.com

曾任職台灣某遊戲公司研發Game Engine，為書籍“OGRE 入門指南”的譯者之一，專攻Rendering技術與遊戲開發，目前為獨立開發團隊CocosPlay主程式