oo?/???? WWDC | 性能優(yōu)化終極生存指南

文章內(nèi)容整理自 Session 《Ultimate application performance survival guide》，可觀看視頻獲取第一用戶體驗(yàn)。

其實(shí)剛看到題目時，很好奇的，生存指南？而且還是終極生存指南。這是戶外生存挑戰(zhàn)么？

我們都知道應(yīng)用程序性能的重要性，不管是端側(cè)，還是服務(wù)側(cè)，高性能都是開發(fā)者們孜孜追求的目標(biāo)。對于端側(cè)來說，由于直接面向終端用戶，所以用戶體驗(yàn)的好壞直接影響到用戶是否選擇繼續(xù)使用你的產(chǎn)品，或者是否會經(jīng)常打開你的應(yīng)用。而應(yīng)用程序的性能直接影響到用戶體驗(yàn)。

性能優(yōu)化是一項(xiàng)長期而艱巨的任務(wù)，需要通過工具來跟蹤許多指標(biāo)。而這個 Seesion 就是為我們介紹了 Xcode 提供的五個主要工具，以幫助我們快速掌握這些工具以及一些固定的范式，從而提升我們應(yīng)用的性能。這五個工具是

• Xcode Organizer

• MetricKit

• Instruments

• XCTest

• App Store Connect API

Session 以性能指標(biāo)開始，逐步展開每個指標(biāo)中一些常見的問題及解決和預(yù)防的方法。

性能指標(biāo)

對于應(yīng)用程序而言，衡量其性能主要有 8 個關(guān)鍵指標(biāo)：電池使用情況、啟動時間、掛起率、內(nèi)存、磁盤寫入、滾動、終止和 MXSignposts。

每個指標(biāo)的衡量都有特定的范式和通用的工具集，下面一個一個來看。

電池使用

一個應(yīng)用是否耗電，決定了用戶是否要經(jīng)常打開這這個應(yīng)用。畢竟，如果應(yīng)用的耗電量過大，用戶在打開前就會有顧慮。iPhone 本身電池容量相比其它產(chǎn)商就小，也不是所有人都會帶個充電寶出門的。

我們可以在 iPhone 的設(shè)置的電池展示頁看到每個應(yīng)用的具體耗電情況。通過優(yōu)化電池壽命，用戶可以更長時間地使用設(shè)備和應(yīng)用。影響電池壽命有因素有很多，不過需要重點(diǎn)關(guān)注三個方面：

• CPU

• 網(wǎng)絡(luò)

• 位置

我們可以通過 Xcode 的 Energy Gauge 來跟蹤 CPU 的使用情況。

在 Debug 導(dǎo)航器中找到 Energy Gauge，這個面板中有兩個區(qū)域：

• 高 CPU 利用率：CPU 使用率大于 20%，以下情況會導(dǎo)致高 CPU 利用率

  • 繪制用戶界面

  • 處理網(wǎng)絡(luò)數(shù)據(jù)

  • 執(zhí)行計算

• CPU 喚醒開銷：CPU 從空閑狀態(tài)喚醒的區(qū)域，會有一定的消耗

可以通過以下工具到定位問題

• Instruments

  • 單擊面板右下角的 Time Profile進(jìn)入，可以查看查看熱狀態(tài)、CPU 使用情況和 profile 過程中的活動調(diào)用堆棧

• 位置能量模型

  • 衡量 Core Location 的影響，并確保應(yīng)用程序在不應(yīng)該使用的位置時不使用該位置

• MatricKit

  • 一個性能測試框架

  • 在需要更多日志記錄和上下文來調(diào)試時，可以使用這個框架

要使用 MatricKit，只需要在應(yīng)用中自定義一個類，并實(shí)現(xiàn) MXMetricManagerSubscriber 協(xié)議，并實(shí)現(xiàn)幾個固定的方法

借助蘋果的分析管道，就可以獲取到數(shù)據(jù)的簡單版本。

當(dāng)用戶同意分享性能數(shù)據(jù)后，數(shù)據(jù)會在蘋果的服務(wù)器上匯總，并通過諸如 Xcode Organizer 等工具反饋給開發(fā)者。之后，我們只需要打開 Organizer，就可以看到應(yīng)用各個版本的數(shù)據(jù)匯總。

通過不同的視圖，我們可以查看不同的信息，如 CPU 使用率高的區(qū)域、網(wǎng)絡(luò)流量等等。

另外，還可以通過 App Store Connect API 來獲取所有這些數(shù)據(jù)，數(shù)據(jù)會以 JSON 格式返回。

Hang Rate 和滑動

掛起是指應(yīng)用對用戶輸入或操作至少 250 毫秒沒有響應(yīng)。應(yīng)用程序中的掛起可能會導(dǎo)致用戶從應(yīng)用程序切換器強(qiáng)殺程序，并且是用戶在應(yīng)用程序中體驗(yàn)的主要障礙，應(yīng)優(yōu)先考慮。

而在滑動列表的過程中，則可能會出現(xiàn)卡頓問題，這會大大影響用戶的使用體驗(yàn)，這也是社區(qū)討論的一大重點(diǎn)，已有不少高質(zhì)量的文章來描述如絲般順滑的滑動體驗(yàn)。

我們可以在 Organizer 中查看掛起和滑動的指標(biāo)數(shù)據(jù)。如果圖表有上升趨勢

或者在滑動過程中，出現(xiàn)黃色或紅色色條，則表明存在問題，需要優(yōu)化。

我們可以使用 Instruments 通過使用線程狀態(tài)或系統(tǒng)調(diào)用跟蹤來檢測掛起的原因。線程狀態(tài)跟蹤工具顯示線程狀態(tài)的時間線以及操作系統(tǒng)安排線程運(yùn)行的時間。在詳細(xì)信息部分看到一個線程被阻塞了多長時間。

可以使用 XCTest 編寫一個性能測試來啟動和滑動應(yīng)用。在測試中，指定要測量 scrollDeceleration submetric，并且在代碼塊的主體中，以應(yīng)用程序中期望的滾動速度向上滑動。

另外，同樣借助 MetricKit，可以從用戶那里獲取到診斷信息。在出現(xiàn)滑動卡頓時，iOS 15 在 MetricKit 中引入了一個新的 API 來使用 MXSignpost 標(biāo)記自定義動畫。?

MXSignpost 是 MetricKit 附帶的包裝器 API，它允許標(biāo)記遙測的關(guān)鍵代碼部分。使用 MXSignpostAnimation-IntervalBegin API，將能夠標(biāo)記自定義動畫的開始。使用 MXSignpost 結(jié)束 API，可以標(biāo)記動畫的結(jié)束并在該時間間隔內(nèi)收集故障率遙測數(shù)據(jù)。這兩個函數(shù)不僅會捕獲此間隔的粒度性能數(shù)據(jù)，還會捕獲發(fā)生的任何故障。

磁盤

寫入磁盤可能會磨損用戶的 NAND，導(dǎo)致設(shè)備運(yùn)行狀況不佳。寫入也需要花費(fèi)大量時間，如果頻繁執(zhí)行，可能會導(dǎo)致糟糕的用戶體驗(yàn)和性能下降，因此對這些寫入進(jìn)行批處理非常重要。

使用 Instruments 中的文件活動模板來分析應(yīng)用程序。這會以系統(tǒng)調(diào)用的形式記錄文件系統(tǒng)的使用情況，因此可以輕松識別應(yīng)用程序代碼中訪問文件系統(tǒng)的位置。

有很多方法來限制寫入磁盤。常見的是批量寫入操作，使用 Core Data 處理頻繁更改的數(shù)據(jù)，以及避免快速創(chuàng)建和刪除文件。

還可以使用 XCTest 編寫性能測試來測量應(yīng)用程序的磁盤使用情況，以防止具有過多磁盤寫入的代碼在用戶設(shè)備上運(yùn)行。

如果已經(jīng)發(fā)布了具有高磁盤寫入的應(yīng)用程序版本，可以使用管理器來跟蹤其在用戶設(shè)備上的性能。

Disk Writes 指標(biāo)向展示了與之前發(fā)布的版本相比，應(yīng)用程序的當(dāng)前版本正在執(zhí)行的寫入次數(shù)的趨勢。圖中的尖峰表示應(yīng)用程序存在導(dǎo)致大量寫入的錯誤。應(yīng)該找出這些寫作的主要來源，理解它們，并尋找減少它們的方法。

在 Xcode 13 中，還可以獲得名為 Insights 的其他詳細(xì)信息， 這指明了一些簡單的優(yōu)化，可以通過這些優(yōu)化減少應(yīng)用程序中的一些寫入。

使用 MetricKit 來監(jiān)控應(yīng)用程序的磁盤使用情況，可以使用 MXSignpost 間隔對關(guān)鍵的磁盤寫入路徑進(jìn)行預(yù)估，以收集更細(xì)粒度的遙測數(shù)據(jù)，這可以幫助發(fā)現(xiàn)優(yōu)化的機(jī)會。

啟動時間和終止

啟動時間優(yōu)化也是一個熱門話題。啟動時間是用戶點(diǎn)擊應(yīng)用程序圖標(biāo)和應(yīng)用程序中呈現(xiàn)第一幀之間的時間量。如果用戶花很長時間等待應(yīng)用程序啟動，顯然會很影響用戶體驗(yàn)。同時可能會導(dǎo)致系統(tǒng)終止應(yīng)用程序。當(dāng)系統(tǒng)終止應(yīng)用程序后，用戶將從一開始就體驗(yàn)整個啟動流程，這比從后臺運(yùn)行狀態(tài)恢復(fù)花費(fèi)的時間要長得多。

進(jìn)程退出的原因有很多，例如達(dá)到并超過系統(tǒng)內(nèi)存限制或啟動超時。

進(jìn)入 Organizer 中，可以查看 啟動時間 和 新的 終止 項(xiàng)。查看啟動時間可以了解應(yīng)用程序在過去 16 個版本中的平均“第一幀時間”是多少，因此可以看到添加新功能之前的速度有多快。

在 “終止” 窗格中查看應(yīng)用程序因啟動需要多長時間而被系統(tǒng)終止的頻率。

通過使用 Instruments 中的 App Launch 模板來分析應(yīng)用程序的啟動時間來測試這個問題。這個模板運(yùn)行應(yīng)用程序五秒鐘，在此期間它收集時間配置文件和應(yīng)用程序啟動時發(fā)生的事情的線程狀態(tài)跟蹤，所以可以找出線程被阻塞的原因并修復(fù)它。

當(dāng)然，同樣可以通過 XCTest 和 MetricKit 來分析。

內(nèi)存

我們都知道應(yīng)用程序使用的內(nèi)存走過限制時，會被系統(tǒng)終止。我們可以在 Organizer 中查看內(nèi)存指標(biāo)。

可以使用 Instruments 中的 Leaks、Allocations 和 VM Tracker 模板來分析應(yīng)用程序的內(nèi)存使用情況。Leaks將檢查進(jìn)程的堆并檢查泄漏的內(nèi)存。Allocations將分析應(yīng)用程序的內(nèi)存生命周期。VM Tracker 會隨著時間的推移顯示應(yīng)用程序的虛擬內(nèi)存空間。

還可以使用 MetricKit 來獲取相同的信息并對其運(yùn)行自己的分析。

小結(jié)

性能優(yōu)化是一個永恒的主題。會有很多問題，也會有很多解決方案。在這方面，Xcode 提供的工具也很多，我們可以通過組合這些工具來分析定位問題，并具體問題具體分析解決。

推薦閱讀

? ?Swift 5.5 新特性搶先看，async/await 將重磅來襲
? ?iOS 恢復(fù)調(diào)用棧(適配iOS14)
? ?正經(jīng)分析iOS包大小優(yōu)化
? ?oo1/?.? 蘋果意外泄露 homeOS；AVE 漏洞可用于 iOS 系統(tǒng)越獄；HarmonyOS 2 正式發(fā)布

就差您點(diǎn)一下了 ??????