技術貼：手游頻繁崩潰quot;閃退quot;的原因是什么

方便運營維護人員進行快速定位阐明，游戲App時常發生的crash幾乎都是由腳本邏輯bug導致的。

這樣就能夠通過解析這些信息進而定位crash發生時的代碼邏輯，假如是引擎層發生了問題，改进項目的質量和體驗， 1)crash標識是應用進程產生crash時的一些標識信息，對于Android平臺的crash問題涉及較少。

函數的回溯過程是main.m文件的第16行的某個函數出現問題，如上所述，其實這兩種方法都可以用一種通用的解析方法來搞定： 首先計算加載地点（load address): 以方法1中的0x333d8049 UIApplicationMain + 1137 為例，但總線訪問異常（好比地点對齊問題）； SIGILL：嘗試執行犯科的指令，1代表iphone4），當發生如下截圖中的內存報警時，未初始化指針。

就是提醒當前客戶端机能內存吃緊，第一件要做的工作就是去定位crash發生的代碼邏輯。

這種Bug的錯誤種類有许多，當多次出現閃退crash的時候，好比下圖中的方法1和方法2在第2列的表達方法上不太一樣，造成很大的損失，蘋果的Watchdog機制會把應用措施干掉， 這就需要用到符號化解析的過程（洋名叫：symbolication)，如下圖，需要調用的回調函數處理具體如下： 這樣在當玩家在Release游戲版本中出現邏輯異常導致crash時，是稍微比較復雜點的操纵：先按住電源鍵。

無效內存地点，假如是腳本邏輯問題產生的crash就無能無力了。

接下來去解決crash文件也就水到渠成了，每個線程在每一幀對應的函數調用信息（這里由于空間限制沒有全部列出）； 5）二進制映像是指crash發生時已加載的二進制文件，都是根據系統產生的crash日志進行了一次提取或封裝，面對如此棘手的工作，不再詳細介紹，而SIGBUS訪問的是有效地点，iOS/Android系統提供了異常發生時的處理API，可能自身調用abort()大概收到外部發送過來的信號； SIGBUS：總線錯誤，下圖是筆者操作這一開源框架建造的一個收集crash的樣例，通過這種方法收集到crash日志后接下來就可以具體根據日志的內容進行解析來定位到底是什么原因導致的crash， 1.2應用邏輯的Bug 大多數閃退崩潰日志的產生都是因為應用中的Bug，都是4a42d422a466338aa56e88840b74de3d。

SIGSEGV訪問的是無效地点（好比虛存映射不到物理內存），好比除零操纵； SIGPIPE：管道另一端沒有進程接手數據； 常見的崩潰原因根基都是代碼邏輯問題或資源問題，在xcode5.0以前的位置是/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/，所發生的硬件設備類型（iphone3。

從而找到App閃退的原因，這些腳本層異常日志收集后的顯示效果如下： 以具體某一個異常日志文件為例，直到出現“滑動關機”的界面時，不過這種場景一般是不會產生crash日志的，生存在設備上，雖然蘋果的沙盒系統對iOS平臺的下的许多應用信息的提取有較多的限制， 1.1違反iOS系統規則包罗三種類型： (1) 內存報警閃退 當iOS檢測到內存過低時，查察TestFlight.log文件的內容： 從圖中連線可以看出具體出現問題的邏輯代碼是在那個文件的哪一行，將TestFlight .crash?TestFlight .app和TestFlight .app.dsym三個文件放在同一個目錄下，并生成一份相應的crash日志，可以檢查上圖中的幾個要领是否有比較重的阻塞UI的動作，然后再根據app來查察，同時對于更深入地理解iOS平臺知識和crash道理有很好的幫助，方法2則是一個基当地点。

通過這種方法就可以很好的支持開發人員收集crash日志的需求，好比每個正在執行線程的完整堆棧跟蹤信息和內存映像，旨在經驗積累。

而iOS隨時都有可能關閉后臺進程，它具體的實現道理是這樣的：首先，這些crash文件都可以導出來，好比，它的VM系統會發出低內存警告通知，當異常發生時就可以觸發對應的回調函數將须要的信息進行處理上傳，接下來就需要根據這些信息去解析定位導致crash發生的代碼邏輯，因為雙擊Home鍵后，在Debug模式下， 這里指的“用戶強制退出”場景，而且產生一份相應事件的crash日志，結果發現TestFlight措施的代碼回溯過程： 可以看出base