app卡死問題修復(fù)是非常困難的問題，對于release版本，他會被watchDog殺掉，在崩潰日志里面的堆棧通常是這樣：<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.xxxx.xxxx>:21665] failed to terminate gracefully after 5.0s，下面的堆棧信息通常無法分析出卡死的原因。
分享一些輔助分析方案：
1、通過經(jīng)驗分析，卡死通常由于死循環(huán)、死鎖、及運行過重任務(wù)導(dǎo)致。
2、無法復(fù)現(xiàn)時，使用dev工具比如DoKit，去抓取卡頓堆棧輔助分析，卡頓不意味著卡死。
3、開發(fā)機復(fù)現(xiàn)時，點擊代碼下方debug欄的pause，可以直接查看到當(dāng)前的堆棧，通過堆棧分析。
我復(fù)現(xiàn)的卡死由于死鎖導(dǎo)致：

private func fetchAuthorizationStatus() -> UNAuthorizationStatus? {
        var notificationSettings: UNNotificationSettings?
        let semaphore = DispatchSemaphore(value: 0)
        DispatchQueue.global().async {
            UNUserNotificationCenter.current().getNotificationSettings { setttings in
                notificationSettings = setttings
                semaphore.signal()
            }
        }
        semaphore.wait()
        return notificationSettings?.authorizationStatus
    }

以上代碼在iOS15、16上，getNotificationSettings的回調(diào)可能在主線程調(diào)用，當(dāng)fetchAuthorizationStatus在主線程調(diào)用時會導(dǎo)致死鎖。