什么是卡頓？

App 在使用過程中出現(xiàn)了一段時(shí)間的阻塞浴麻，其表現(xiàn)為在用戶觸摸屏幕后得问，需要等待一段時(shí)間 App 才有響應(yīng)，在這段時(shí)間內(nèi)用戶都無法進(jìn)行其它操作软免，屏幕上的內(nèi)容也沒有任何的更新椭赋，正如上述示例所示。

為什么要治理卡頓或杠？

1. 用戶會(huì)不耐煩主動(dòng)退出應(yīng)用或超出系統(tǒng)閾值而發(fā)生崩潰哪怔；而這種體驗(yàn)對(duì)用戶的傷害其實(shí)比普通的崩潰更加嚴(yán)重
2. 持續(xù)的卡頓可能導(dǎo)致用戶退出并轉(zhuǎn)去使用其他應(yīng)用
3. 甚至可能會(huì)卸載應(yīng)用并在 App 商店留下不好的評(píng)論，直接關(guān)系到用戶留存率向抢、DAU 和 DNU 等各項(xiàng)產(chǎn)品數(shù)據(jù)认境。

因此卡頓目前已成為 iOS 最重要的性能指標(biāo)之一，治理并減少 App 的卡頓率變得尤其關(guān)鍵挟鸠。

卡頓分析

正常情況下叉信，iOS 默認(rèn)顯示頻率是 60Hz，所以 GPU 渲染只要達(dá)到 60fps 就不會(huì)產(chǎn)生卡頓艘希；以 60fps 為例硼身，vSync 會(huì)每 16ms(1/60) 觸發(fā)一次渲染，假如在 16ms 內(nèi)沒有準(zhǔn)備好下一幀數(shù)據(jù)就會(huì)使畫面停留在上一幀覆享，就造成了掉幀或卡頓現(xiàn)象

由于 UIKit 是非線程安全的佳遂，因此一切與 UI 相關(guān)的操作都必須放在主線程執(zhí)行，系統(tǒng)會(huì)每 16ms 將 UI 的變化計(jì)算重新繪制撒顿，渲染至屏幕上丑罪。如果 UI 刷新的間隔能小于 16ms，那么用戶是不會(huì)感到卡頓的凤壁。但是如果在主線程進(jìn)行了一些耗時(shí)操作吩屹，阻礙了 UI 的刷新，那么就會(huì)產(chǎn)生卡頓拧抖，甚至是卡死煤搜。

主線程對(duì)任務(wù)的處理是基于 Runloop 機(jī)制，如下圖所示唧席。Runloop 支持并提供給外部注冊(cè) 6 個(gè)時(shí)機(jī)的事件回調(diào)擦盾，分別是：

• RunloopEntry
• RunloopBeforeTimers
• RunloopBeforeSources
• RunloopBeforeWaiting
• RunloopAfterWaiting
• RunloopExit

其流轉(zhuǎn)關(guān)系如下圖所示嘲驾。Runloop 在沒有任務(wù)需要處理的時(shí)候就會(huì)進(jìn)入休眠狀態(tài)，直至有信號(hào)將其喚醒厌衙，它又會(huì)去處理新的任務(wù)距淫。

在日常開發(fā)中绞绒，UIEvent事件婶希、Timer事件以及dispatch主線程塊任務(wù)都是在 Runloop 循環(huán)機(jī)制的驅(qū)動(dòng)下完成的。一旦我們?cè)谥骶€程中的任一個(gè)環(huán)節(jié)進(jìn)行了一個(gè)耗時(shí)的操作蓬衡，或者因?yàn)殒i使用不當(dāng)造成了主線程因等待而阻塞喻杈，那么主線程就會(huì)因?yàn)闊o法執(zhí)行Core Animation回調(diào)而造成界面無法刷新。而用戶的交互又依賴于UIEvent事件的傳遞和響應(yīng)狰晚，該流程也必須在主線程中完成筒饰。所以主線程的阻塞會(huì)導(dǎo)致應(yīng)用 UI 和交互雙雙阻塞，這也是導(dǎo)致卡頓的根本原因壁晒。

實(shí)際在日常開發(fā)中通常造成卡頓的原因主要是以下幾種：

• 主線程執(zhí)行耗時(shí)的任務(wù)（CPU 密集型任務(wù)）瓷们，比如調(diào)用UIGraphicsGetCurrentContext等接口在 CPU 上進(jìn)行繪制計(jì)算；
• 主線程等待繁忙的子線程或低優(yōu)先級(jí)的后臺(tái)線程任務(wù)而導(dǎo)致阻塞秒咐，比如在主線程使用queue.sync同步派發(fā)任務(wù)或使用semaphore.wait()將異步調(diào)用轉(zhuǎn)化為同步調(diào)用等谬晕；
• 主線程等待系統(tǒng)資源，比如使用Data(contentsOf:)進(jìn)行 IO 讀取等携取；

如何排查卡頓攒钳？

在 iOS 16 和 Xcode 14 以前，Apple 提供了 Instruments雷滋、MetricKit 以及 Xcode Organizer 等工具供開發(fā)者在不同開發(fā)階段進(jìn)行 App 性能的統(tǒng)計(jì)分析不撑，但是針對(duì)卡頓的排查分析十分有限。值得高興的是今年 Apple 在 iOS 16 和 Xcode 14 上更新了一些幫助開發(fā)者在不同開發(fā)階段進(jìn)行排查和分析卡頓的工具晤斩。它們分別是：

• Thread Performance Checker
• Hang detection in Instruments
• On-Device Hang Detection
• Xcode Reports Organizer

Thread Performance Checker

首先是開發(fā)階段焕檬，當(dāng)我們?cè)谑褂?Xcode 進(jìn)行真機(jī)調(diào)試時(shí)，可以在 Edit Scheme -> Run -> Diagnostics 選項(xiàng)卡中開啟 Thread Performance Checker澳泵。（Xcode 14 默認(rèn)開啟）

開啟 Thread Performance Checker 后揩页，Xcode 如果檢測(cè)到 App 在運(yùn)行時(shí)，有例如線程優(yōu)先級(jí)反轉(zhuǎn)和非 UI 工作在主線程運(yùn)行等問題時(shí)就會(huì)在 Xcode 問題導(dǎo)航欄中提示該卡頓風(fēng)險(xiǎn)警告烹俗。這可以幫助我們?cè)陂_發(fā)初期就能發(fā)現(xiàn)并去解決隱含的卡頓風(fēng)險(xiǎn)問題爆侣。

Instruments

Xcode 14 的 Timer Profiler 工具分析 App 重現(xiàn)的卡頓問題時(shí)，可以驚喜地發(fā)現(xiàn)新的 Timer Profiler 在檢測(cè)到 App 有卡頓問題時(shí)就會(huì)在軌道時(shí)間線上展示紅色的 Hang 標(biāo)記幢妄，該標(biāo)記的長(zhǎng)度代表了卡頓的時(shí)間間隔兔仰。然后，我們可以通過點(diǎn)擊三次 Hang 標(biāo)記過濾出該卡頓時(shí)間間隔區(qū)間內(nèi)的所有事件并展開詳細(xì)的線程軌道視圖蕉鸳，以方便查看其它線程的繁忙情況乎赴。如下圖所示忍法，可以看到主線程在這段時(shí)間內(nèi)屬于空閑狀態(tài)，而有一個(gè) worker 子線程在這段時(shí)間內(nèi)卻屬于繁忙狀態(tài)榕吼，可見應(yīng)該是主線程在等待該子線程完成任務(wù)饿序。這與上述 Thread Performance Checker 中展示的卡頓風(fēng)險(xiǎn)警告遙相呼應(yīng)，最后我們可以展開 Timer Profiler 下方的調(diào)用堆棧分析當(dāng)時(shí)子線程的堆棧信息羹蚣，結(jié)合實(shí)際上下文并最終解決主線程阻塞問題原探。

值得一提的是上述的 Instruments 中卡頓檢測(cè)與標(biāo)記在 Timer Profiler 和 CPU Profiler 工具中同樣都是默認(rèn)可用的，另外也可以在其它 Trace 模版中添加 Hang tracing 跟其他工具結(jié)合進(jìn)行測(cè)試顽素，不過需要注意的是單獨(dú)的 Hang tracing 只能檢測(cè)到運(yùn)行期間是否發(fā)生了卡頓以及卡頓時(shí)長(zhǎng)咽弦，并沒有實(shí)際的堆棧信息，所以在實(shí)際利用 Instruments 排查卡頓時(shí)還是建議優(yōu)先使用 Timer Profiler 進(jìn)行分析胁出。

On-Device Detection

前面討論了可利用 Thread Performance Checker 和 Instruments 中的卡頓檢測(cè)工具來幫助我們發(fā)現(xiàn)并定位問題型型，其實(shí)可以發(fā)現(xiàn)這兩個(gè)工具都是線下的定位手段。雖然我們可能在開發(fā)階段已經(jīng)做足了相對(duì)完整的測(cè)試全蝶，并取得了較好的測(cè)試覆蓋率闹蒜，但是在后續(xù)的 Beta 測(cè)試階段和線上發(fā)布階段中也有可能會(huì)出現(xiàn)自己沒考慮到的卡頓問題的路徑。這時(shí)候用戶設(shè)備都是無法連接到 Xcode 進(jìn)行線下調(diào)試的抑淫，所以就非常依賴線上的工具進(jìn)行定位問題绷落。談到線上工具，首先值得高興的是今年 Apple 在 iOS 16 的開發(fā)者設(shè)置中引入了 Hang Detection（卡頓檢測(cè)）功能丈冬，為 App 運(yùn)行時(shí)提供實(shí)時(shí)的卡頓檢測(cè)通知并診斷的能力嘱函，不過這只適用于由開發(fā)證書簽名的以及通過 TestFlight 分發(fā)的應(yīng)用，換言之就是該功能只能統(tǒng)計(jì)通過 Xcode 安裝的 Debug 包和通過 TestFlight 安裝的 Release 包埂蕊，而通過 AppStore 安裝的應(yīng)用或企業(yè)包則不能被統(tǒng)計(jì)

功能具體打開方式： Settings -> Developer -> Hang Detection往弓，并切換 Enable Hang Detection 開關(guān)狀態(tài)到開啟狀態(tài)。開啟后可以看到以下三部分：

Hang Threshold：可設(shè)置卡斷檢測(cè)的閾值蓄氧，目前只有 250ms函似、500ms、1000ms 和 2000ms 四個(gè)可選喉童；
Monitored Apps：展示可監(jiān)控的 App 列表撇寞；（注意：只展示由開發(fā)證書簽名的和通過 TestFlight 安裝的應(yīng)用，企業(yè)證書簽名無法適用）
Avalable Hang Logs：展示了收到卡頓警告通知時(shí)診斷所產(chǎn)生的卡頓日志列表堂氯，這個(gè)后續(xù)我們排查具體問題時(shí)會(huì)用到蔑担；

MetricKit

然后說回到線上工具，值得一提的是 MetricKit 框架咽白，它是 Apple 在 iOS 13 發(fā)布的用于收集和診斷性能的工具啤握，其中就包括卡頓指標(biāo)。不過它始終只是一個(gè)框架晶框，線上使用時(shí)還需要人為接入它并上報(bào)相關(guān)診斷數(shù)據(jù)才能進(jìn)行系統(tǒng)性地分析排抬，不過其實(shí)蘋果也考慮到了這點(diǎn)懂从，也一并在 Xcode Organizer 中加入相應(yīng)的指標(biāo)分析能力

Xcode Organizer

最后當(dāng) App 發(fā)布到正式環(huán)境以后，后續(xù)我們就可以通過 Xcode Organizer 來分析線上版本 App 的性能指標(biāo)蹲蒲。Xcode 14 以前 Organizer 只提供了卡頓率這種經(jīng)過系統(tǒng)性分析后的數(shù)據(jù)指標(biāo)番甩，并沒有提供諸如包含堆棧信息的卡頓報(bào)告來幫助排查定位，功能上相對(duì)雞肋届搁。不過在 Xcode 14 上 Organizer 終于支持了 Hang Reports缘薛，它能收集并上報(bào)線上用戶在遇到卡頓時(shí)系統(tǒng)所產(chǎn)生的診斷報(bào)告數(shù)據(jù)（前提是用戶同意了與 App 開發(fā)者共享應(yīng)用分析）。如下圖咖祭，Xcode 14 Organizer 的 Reports 分類中新增加了 Hang Reports 欄目掩宜。左起第二欄展示問題的聚合列表蔫骂，問題按用戶影響程度進(jìn)行排序么翰；第三欄展示了具體問題的堆棧信息，可幫助開發(fā)者分析定位卡頓原因辽旋；第四欄展示了具體問題的匯總統(tǒng)計(jì)信息浩嫌，比如發(fā)生卡頓的數(shù)量，操作系統(tǒng)和設(shè)備分布比例等补胚。

例如上圖所示码耐，我們觀察到 Hangs Reports 的問題列表中最頂部的問題占了該版本卡頓問題的 21%，問題相當(dāng)嚴(yán)重溶其。我們可以嘗試解決該問題骚腥，選中該問題并展開查看具體的堆棧信息，最終可以推斷出該問題是因?yàn)樵谥骶€程同步讀取磁盤文件而引起阻塞瓶逃。這里補(bǔ)充說明下上述堆棧信息是經(jīng)過符號(hào)化后的結(jié)果束铭，具體只要用戶在 App 上傳到 App Store 時(shí)一并上傳符號(hào)信息，報(bào)告中的堆棧信息就能自動(dòng)符號(hào)化了厢绝。

如何解決卡頓契沫？

在分析和定位到了具體的卡頓原因之后，我們就可以著手解決問題了昔汉。面對(duì)大多日常開發(fā)中的常見問題我們可以有以下通用解決方案：

• 將 CPU 密集型工作遷移到子線程隊(duì)列處理懈万，降低主線程繁忙的概率；
• 避免主線程等待子線程的場(chǎng)景靶病，盡量使用異步子線程處理任務(wù)会通，完成后通知回調(diào)到主線程的方式；
• 特別需要注意的是在主線程上訪問一些原子變量或使用鎖（例如 pthread_rwlock_t）訪問數(shù)據(jù)時(shí)娄周，可能會(huì)與其它子線程同時(shí)競(jìng)爭(zhēng)鎖涕侈，當(dāng)其它子線程先獲取到鎖時(shí)，主線程就會(huì)因?yàn)榈却枞パ剩员M量避免在主線程頻繁的訪問原子變量和鎖驾凶，即使不可避免的要在主線程上使用鎖牙甫，推薦優(yōu)先使用能夠提升線程優(yōu)先級(jí)的鎖（例如pthread_mutex和os_unfair_lock），能夠避免發(fā)生優(yōu)先級(jí)反轉(zhuǎn)問題调违。
• 避免在主線程同步讀取磁盤或網(wǎng)絡(luò)數(shù)據(jù)窟哺，可通過在后臺(tái)線程代替處理，待 IO 操作完成后再回調(diào)主線程技肩；

參考資料：
1且轨、 apple session 10082
2、 iOS 穩(wěn)定性問題治理：卡死崩潰監(jiān)控原理及最佳實(shí)踐
3虚婿、利用 Xcode 和設(shè)備上的檢測(cè)工具排查卡頓