事情是這樣的....

開發(fā)的程序一直都能穩(wěn)定的打包，運(yùn)行。直到有一天，詭異的事情發(fā)生了，無論是Android還是Win包，啟動(dòng)程序立即閃退。UE沒有生成任何文件，沒有任何log，就好像不曾點(diǎn)擊過啟動(dòng)圖標(biāo)一樣。但在PIE模式下，一切正常。

一切都發(fā)生得太突然，太懵逼，突然這么來一下，還真是摸不著頭腦。后面靜下心來，從0開始。無論什么問題，不還得從哪些解決問題的方法入手嗎，線索少一點(diǎn)，并不代表不能開展工作了。

于是

第一步：還原現(xiàn)場(chǎng)，找到發(fā)生前和發(fā)生后項(xiàng)目中的差異。將時(shí)間回退，找出問題的時(shí)間節(jié)點(diǎn)，雖然這是一個(gè)笨方法，但不可否認(rèn)他很有效。經(jīng)過一番折騰，終于找到那些文件可能出現(xiàn)問題。（這時(shí)候版本管理工具就凸顯出特別重要的作用）

第二步：分析嫌疑人。既然找到嫌疑人，那肯定憑借多年的辦案經(jīng)驗(yàn)，按個(gè)分析。寫了這么些年代碼，錯(cuò)誤就擺在面前，還有版本管理工具輔助，找出問題不是分分鐘的事嗎？所有代碼都分析了一遍，沒得到結(jié)論，此時(shí)開始懷疑自己代碼的基礎(chǔ)功底了。

第三步：從0開始分析，既然啟動(dòng)就閃退，UE都還沒來得及工作。那會(huì)不會(huì)跟靜態(tài)變量初始化，靜態(tài)代碼塊等相關(guān)？所以開始著手仔細(xì)看靜態(tài)代碼相關(guān)，同樣毫無收獲，難道這個(gè)方向也錯(cuò)了嗎？

第四步：進(jìn)一步縮小嫌疑范圍。鎖定最終代碼文件。

結(jié)果：

由于調(diào)用UKismetSystemLibrary::LineTraceMultiForObjects進(jìn)行射線檢查需要用到TArray<TEnumAsByte<EObjectTypeQuery> >作為查詢數(shù)組，在我們的功能里面，這個(gè)數(shù)組又是固定的，就想著初始化一次就好。不用每次都新建，所以將該對(duì)象創(chuàng)建為靜態(tài)變量。代碼如下：

該對(duì)象為靜態(tài)對(duì)象，在程序啟動(dòng)時(shí)就會(huì)初始化。但進(jìn)一步到UEngineTypes::ConvertToObjectType里面去看，并非全為靜態(tài)，需要通過CDO訪問配置文件，從而才能得到對(duì)象。此時(shí)，UE還未初始化好，CDO UClass也不存在，直接閃退了。

按這個(gè)理，所有用到UClass的東西設(shè)置為靜態(tài)變量并初始化，應(yīng)該都會(huì)出現(xiàn)該問題，大家可以試試去。