iOS中閃退即使在上線也是容易出現(xiàn)崩潰現(xiàn)象的.以下是個人在工作中對崩潰或異?，F(xiàn)象的總結(jié)和經(jīng)驗.上線后的bug是能很好的在devicedata下直接下載出來的，這種iOS本身支持。但是還沒上線的app如何快速定位，以下是最近開發(fā)的一些經(jīng)驗和體會

• 設(shè)備型號有關(guān)

  這上面的崩潰跟操作系統(tǒng)的位數(shù)有關(guān)如5s后6之后的區(qū)別，5以前的是32位操作機，6之后是64位操作機.這有什么問題呢？比如后臺傳入的長整型iOS端如果接收不正確的情況會截取就會不正確.產(chǎn)生這種情況的時候你可能需要考慮類型轉(zhuǎn)換的問題.

• iOS系統(tǒng)版本有關(guān)

  部分機型正常部分系統(tǒng)版本不正常,這是需要仔細(xì)檢查版本測試這種往往很容易重現(xiàn).多測系統(tǒng)版本基本能發(fā)現(xiàn)并解決.常見的是部分第三方在版本上的不足，sdk不支持啊多見

• 關(guān)于高頻率的偶然事件，那么這種算是必然事件，亟待修復(fù).這種不太好定位.

  這種情況基本是跟用戶操作后產(chǎn)生的本地數(shù)據(jù)有關(guān),因為必然是操作后就會出現(xiàn)這樣的隱患,然后就去仔細(xì)檢查本地數(shù)據(jù)是否有異常情況.如果本地數(shù)據(jù)沒有問題,先別急這時還是可能跟它有關(guān),仔細(xì)想想數(shù)據(jù)的流向中間會經(jīng)過其它的哪些節(jié)點，而那些往往就是產(chǎn)生崩潰的根本原因.比如之前就遇到過失敗任務(wù)的上傳就需要經(jīng)緯度，但是開機瞬間經(jīng)緯度很可能還沒來得及回調(diào).產(chǎn)生崩潰,甚至重現(xiàn)不了（那是不知道這個原因）因為自己在測試時失敗任務(wù)上傳時只是斷了網(wǎng)并沒有關(guān)掉app，因此在做失敗任務(wù)上傳時一定切記不僅僅測斷網(wǎng)的時候，還關(guān)掉app的情況.

• 編程上邏輯的順序問題

  多見于業(yè)務(wù)邏輯上的疏漏還有在多線程下的異步控制不到位.這種問題最好不要直接改，可以比對著設(shè)計流程圖來校驗仔細(xì)一點，沒有設(shè)計文檔流程那那還不趕快去畫，照著清晰的思路去理才是關(guān)鍵

• 直接閃退

  使用各種xib的方式不正確，不太明白通過xib的方式和代碼的方式上的區(qū)別（模板模式的應(yīng)用生命周期）.
  使用拖拽的方式綁定多個事件？不存在的對象？不存在的方法？
  這種問題多是自己作死吧

• 隱晦的bug
  系統(tǒng)方法的調(diào)用在不同項目中出現(xiàn)奇怪的結(jié)果?
  仔細(xì)檢查項目中兩者的代碼配置書寫,如果無誤.看看是不是有人用了黑魔法（可怕的全局搜索）吧.

• 界面上的異常

xcode自帶圖書那個可以看到層級關(guān)系.以及控件的位置是否正確
界面上正常響應(yīng)不了交互,UIimageview是否開啟了允許交互設(shè)置
視圖的遮擋，透明度，ishidden都會失去交互

重要步驟的流程如果需要可自己配合后臺做日志管理,簡單點就用第三方吧,不過目前極光友盟只能收集到oc中的異常,bugly能收集到swift的但信息是不全的意味著你還是看不出來是哪里錯了,最終方案打個包讓人家繼續(xù)用著唄，為自己的每個ipa和版本制作符號表，集成bugly進行收集信息,這樣crash直接定位到出錯代碼.但是小心逆向喲，逆向工程師必爭之地就是符號表，因此在上線之前測試階段可以配置符號表，上架的時候還是刪除符號表配置，并且刪掉bugly的攔截,看到最后了的撿到了唄
2020.9.15補充
使用memory graph 可定位內(nèi)存分配過大的庫
profile leaks 可檢測內(nèi)存暴漲 根據(jù)大致思路定位問題根源，使用一些第三方庫是否過于古老

• 屢試不爽的定位bug 通過刪代碼測試找到問題代碼（有版本控制的可以這樣搞）
  策略上通過定位段代碼 不好找的可以通過一半代碼刪一半檢測方式定位到