在討論 Android 性能問題的時候，卡頓、響應(yīng)速度、 ANR 這三個性能相關(guān)的知識點通常會放到一起來講，因為引起卡頓、響應(yīng)慢、ANR 的原因類似，只不過根據(jù)重要程度，被人為分成了卡頓、響應(yīng)慢、ANR 三種，所以我們可以定義廣義上的卡頓，包含了卡頓、響應(yīng)慢和 ANR 三種，所以如果用戶反饋說手機(jī)卡頓或者 App 卡頓，大部分情況下都是廣義上的卡頓，需要搞清楚，到底出現(xiàn)了哪一種問題

如果是動畫播放卡頓、列表滑動卡頓這種，我們一般定義為 狹義的卡頓，對應(yīng)的英文描述我覺得應(yīng)該是 Jank；如果是應(yīng)用啟動慢、亮滅屏慢、場景切換慢，我們一般定義為 響應(yīng)慢 ，對應(yīng)的英文描述我覺得應(yīng)該是 Slow ；如果是發(fā)生了 ANR，那就是 應(yīng)用無響應(yīng)問題 。三種情況所對應(yīng)的分析方法和解決方法不太一樣，所以需要分開來講

另外在 App 或者廠商內(nèi)部，卡頓、響應(yīng)速度、 ANR 這幾個性能指標(biāo)都是有單獨的標(biāo)準(zhǔn)的，比如 掉幀率、啟動速度、 ANR 率等，所以針對這些性能問題的分析和優(yōu)化能力，對開發(fā)者來說就非常重要了

本文是響應(yīng)速度系列的第一篇，主要是講響應(yīng)速度相關(guān)的理論知識，包括性能工程概述、響應(yīng)速度涉及到的知識點、響應(yīng)速度的分析方法和套路等

關(guān)于卡頓的文章可以參考這一篇 Systrace 流暢性實戰(zhàn) 1 ：了解卡頓原理 ^[1] ，ANR 的文章后續(xù)會介紹，本文主要是講響應(yīng)速度相關(guān)的基本原理

Systrace (Perfetto) 工具的基本使用如果還不是很熟悉，那么需要優(yōu)先去補(bǔ)一下 Systrace 基礎(chǔ)知識系列 ^[2]，本文假設(shè)你已經(jīng)熟悉 Systrace (Perfetto) 的使用了

0. 性能工程

在介紹響應(yīng)速度的原理之前，這里先放一段 < 性能之巔 > 這本書中對于性能的描述，具體來說就是方法論，非常貼合本文的主題，也強(qiáng)烈推薦各位搞性能優(yōu)化的同學(xué)，把這本書作為手頭常讀的方法論書籍：

性能是充滿挑戰(zhàn)的

系統(tǒng)性能工程是一個充滿挑戰(zhàn)的領(lǐng)域，具體原因有很多，其中包括以下事實，系統(tǒng)性能是主觀的、復(fù)雜的，而且常常是多問題并存的

性能是主觀的

1. 技術(shù)學(xué)科往往是客觀的，太多的業(yè)界人士審視問題非黑即白。在進(jìn)行軟件故障查找的時候，判斷 bug 是否存在或 bug 是否修復(fù)就是這樣。bug 的出現(xiàn)總是伴隨著錯誤信息，錯誤信息通常容易解讀，進(jìn)而你就明白錯誤為什么會出現(xiàn)了
2. 與此不同，性能常常是主觀性的。開始著手性能問題的時候，對問題是否存在的判斷都有可能是模糊的，在問題被修復(fù)的時候也同樣，被一個用戶認(rèn)為是 “不好” 的性能，另一個用戶可能認(rèn)為是 “好” 的

系統(tǒng)是復(fù)雜的

1. 除了主觀性之外，性能工程作為一門充滿了挑戰(zhàn)的學(xué)科，除了因為系統(tǒng)的復(fù)雜性，還因為對于性能，我們常常缺少一個明確的分析起點。有時我們只是從猜測開始，比如，責(zé)怪網(wǎng)絡(luò)，而性能分析必須對這是不是一個正確的方向做出判斷
2. 性能問題可能出在子系統(tǒng)之間復(fù)雜的互聯(lián)上，即便這些子系統(tǒng)隔離時表現(xiàn)得都很好。也可能由于連鎖故障（cascading failure）出現(xiàn)性能問題，這指的是一個出現(xiàn)故障的組件會導(dǎo)致其他組件產(chǎn)生性能問題。要理解這些產(chǎn)生的問題，你必須理清組件之間的關(guān)系，還要了解它們是怎樣協(xié)作的
3. 瓶頸往往是復(fù)雜的，還會以意想不到的方式互相聯(lián)系。修復(fù)了一個問題可能只是把瓶頸推向了系統(tǒng)里的其他地方，導(dǎo)致系統(tǒng)的整體性能并沒有得到期望的提升。
4. 除了系統(tǒng)的復(fù)雜性之外，生產(chǎn)環(huán)境負(fù)載的復(fù)雜特性也可能會導(dǎo)致性能問題。在實驗室環(huán)境很難重現(xiàn)這類情況，或者只能間歇式地重現(xiàn)
5. 解決復(fù)雜的性能問題常常需要全局性的方法。整個系統(tǒng) —— 包括自身內(nèi)部和外部的交互 —— 都可能需要被調(diào)查研究。這項工作要求有非常廣泛的技能，一般不太可能集中在一人身上，這促使性能工程成為一門多變的并且充滿智力挑戰(zhàn)的工作

可能有多個問題并存

1. 找到一個性能問題點往往并不是問題本身，在復(fù)雜的軟件中通常會有多個問題
2. 性能分析的又一個難點：真正的任務(wù)不是尋找問題，而是辨別問題或者說是辨別哪些問題是最重要的
3. 要做到這一點，性能分析必須量化（quantify）問題的重要程度。某些性能問題可能并不適用于你的工作負(fù)載或者只在非常小的程度上適用。理想情況下，你不僅要量化問題，還要估計每個問題修復(fù)后能帶來的增速。當(dāng)管理層審查工程或運(yùn)維資源的開銷緣由時，這類信息尤其有用。
4. 有一個指標(biāo)非常適合用來量化性能，那就是 延時（latency）

-- 以上幾段內(nèi)容摘錄自 < 性能之巔 >

1. 響應(yīng)速度概述

響應(yīng)速度是應(yīng)用 App 性能的重要指標(biāo)之一。響應(yīng)慢通常表現(xiàn)為點擊效果延遲、操作等待或白屏?xí)r間長等，主要場景包括：

• 應(yīng)用啟動場景，包括冷啟動、熱啟動、溫啟動等
• 界面跳轉(zhuǎn)場景，包括應(yīng)用內(nèi)頁面跳轉(zhuǎn)、App 之間跳轉(zhuǎn)
• 其他非跳轉(zhuǎn)的點擊場景（開關(guān)、彈窗、長按、控件選擇、單擊、雙擊等）
• 亮滅屏、開關(guān)機(jī)、解鎖、人臉識別、拍照、視頻加載等場景

從原理上來說，響應(yīng)速度場景往往是由一個 input 事件（以 Message 的形式給到需要處理的應(yīng)用主線程）觸發(fā)（比如點擊、長按、電源鍵、指紋等），由一個或者多個 Message 的執(zhí)行結(jié)束為結(jié)尾，而這些 Message 中一般都有關(guān)鍵的界面繪制相關(guān)的 Message 。衡量一個場景的響應(yīng)速度，我們通常從事件觸發(fā)開始計時，到應(yīng)用處理完成計時結(jié)束，這一段時間就稱為響應(yīng)時間。

如下圖所示，響應(yīng)速度的問題，通常就是這些 Message 的某個執(zhí)行超過預(yù)期（主觀），導(dǎo)致最終完成的時間長于用戶期待的時間

Android 消息機(jī)制由于響應(yīng)速度是一個比較主觀的性能指標(biāo)（而流暢度就是一個很精確的指標(biāo)，掉一幀就是掉一幀），而且根據(jù)角色的不同，對這個性能指標(biāo)的判定也不同，比如 Android 系統(tǒng)開發(fā)者和應(yīng)用開發(fā)者以及測試同學(xué)，對 應(yīng)用冷啟動 的起點和終點就有不同的判定：

1. 系統(tǒng)開發(fā)者 往往從 input 中斷開始看，部分以應(yīng)用第一幀為結(jié)束點（因為比較好計算），部分以應(yīng)用加載完成為結(jié)束點（比較主觀，除非結(jié)束點比較容易通過工具去判斷），主要是以優(yōu)化應(yīng)用的整體性能為主，涉及到的方面就比較廣，包括 input 事件傳遞、SystemServer、SurfaceFlinger、Kernel 、Launcher 等
2. App 開發(fā)者 一般從 Application 的 onCreate 或者 attachContext 開始看，大部分以界面完全加載或者用戶可操作為結(jié)束點，因為是自己的應(yīng)用，結(jié)束點在代碼里面可以主動加，主要還是以優(yōu)化應(yīng)用自身的啟動速度為主，市面上講啟動速度優(yōu)化的，大部分是講這部分
3. 測試同學(xué) 則更多從用戶的真實體驗角度來看，以桌面點擊應(yīng)用圖標(biāo)且應(yīng)用圖標(biāo)變色為第一幀，內(nèi)容完全加載為結(jié)束點。測試過程一般使用 高速相機(jī) 自動化，通過機(jī)械手和圖形識別技術(shù)，可以自動進(jìn)行響應(yīng)速度測試并抓取相關(guān)的測試數(shù)據(jù)

2. 響應(yīng)速度問題分析思路

2.1 分清起點和終點

分析響應(yīng)速度，最重要的是要找到起點和終點，上一節(jié)講到，不同角色的開發(fā)者，對這個性能指標(biāo)的判定起點和終點都不一樣；而且這個指標(biāo)有很主觀的成分，所以在開始的時候，就要跟各方來確定好起點和終點，具體的數(shù)值標(biāo)準(zhǔn)，下面一些手段可以幫助大家來確定

1. 競品分析。一般來說，響應(yīng)速度這個指標(biāo)都會有一個對標(biāo)的競品，競品手機(jī)或者競品 App，相同的條件下，競品手機(jī)或者競品 App 從點擊到響應(yīng)花費了多少時間，可以作為一個標(biāo)準(zhǔn)
2. 對比前一個版本。有時候系統(tǒng)進(jìn)行大版本升級或者 App 進(jìn)行版本迭代，那么上一個版本的數(shù)據(jù)就可以拿來作為標(biāo)準(zhǔn)進(jìn)行對比

一般來說，起點都比較好確定，無非是一個點擊事件或者一個自定義的觸發(fā)事件；而終點的確定就比較麻煩，比如如何確定一個復(fù)雜的 App （比如淘寶）啟動完成的時間點，用 Systrace 的第一幀或者 Log 輸出的 Displayed 時間或者 onWindowFocusChange 回調(diào)的時間顯然是不準(zhǔn)確的。目前市面上使用高速相機(jī) 圖像識別來做是一個比較主流的做法

2.2 響應(yīng)速度常見問題

2.2.1 Android 系統(tǒng)自身原因?qū)е马憫?yīng)慢

下面這些列舉的是 Android 系統(tǒng)自身的原因，與 Android 機(jī)器的性能有比較大的關(guān)系，性能越差，越容易出現(xiàn)響應(yīng)速度問題。下面就列出了 Android 系統(tǒng)原因?qū)е碌?App 響應(yīng)速度出現(xiàn)問題的原因，以及這個時候 App 端在 Systrace 中的表現(xiàn)

CPU 頻率不足

App 端的表現(xiàn)：主線程處于 Running 狀態(tài)，但是執(zhí)行耗時變長

CPU 大小核調(diào)度：關(guān)鍵任務(wù)跑到了小核

App 端的表現(xiàn)：Systrace 看主線程處于 Running 狀態(tài)，但是執(zhí)行耗時變長

SystemServer 繁忙，主要影響

1. 響應(yīng) App 主線程 Binder 調(diào)用處理耗時
1. App 端的表現(xiàn)：Systrace 看主線程處于 Sleep 狀態(tài)，在等待 Binder 調(diào)用返回
2. 應(yīng)用啟動過程邏輯處理耗時
1. App 端的表現(xiàn)：Systrace 看主線程處于 Sleep 狀態(tài)，在等待 Binder 調(diào)用返回

SurfaceFlinger 繁忙

主要影響應(yīng)用的渲染線程的 dequeueBuffer、queueBuffer

1. App 端的表現(xiàn)：Systrace 看應(yīng)用渲染線程的 dequeueBuffer、queueBuffer 處于 Binder 等待狀態(tài)

系統(tǒng)低內(nèi)存 ^[3]

低內(nèi)存的時候，很大概率出現(xiàn)下面幾種情況，都會對 SystemServer 和應(yīng)用有影響

1. 低內(nèi)存的時候，有些應(yīng)用會頻繁被殺和啟動，而應(yīng)用啟動時一個重操作，會占用 CPU 資源，導(dǎo)致前臺 App 啟動變慢
1. App 端的表現(xiàn)：Systrace 看應(yīng)用主線程 Runnable 狀態(tài)變多，Running 狀態(tài)變少，整體函數(shù)執(zhí)行耗時增加
2. 低內(nèi)存的時候，, 很容易觸發(fā)各個進(jìn)程的 GC , , 用于內(nèi)存回收的 HeapTaskDeamon、kswapd0 出現(xiàn)非常頻繁
1. App 端的表現(xiàn)：Systrace 看應(yīng)用主線程 Runnable 狀態(tài)變多，Running 狀態(tài)變少，整體函數(shù)執(zhí)行耗時增加
3. 低內(nèi)存會導(dǎo)致磁盤 IO 變多，如果頻繁進(jìn)行磁盤 IO , 由于磁盤 IO 很慢，那么主線程會有很多進(jìn)程處于等 IO 的狀態(tài)，也就是我們經(jīng)?？吹降?Uninterruptible Sleep
1. App 端的表現(xiàn)：Systrace 看應(yīng)用主線程 Uninterruptible Sleep 和 Uninterruptible Sleep - IO 狀態(tài)變多，Running 狀態(tài)變少，整體函數(shù)執(zhí)行耗時增加

系統(tǒng)觸發(fā)溫控

頻率被限制：由于溫度過高，CPU 最高頻率被限制

App 端的表現(xiàn)：主線程處于 Running 狀態(tài)，但是執(zhí)行耗時變長

整機(jī) CPU 繁忙

可能有多個高負(fù)載進(jìn)程同時在運(yùn)行，或者有單個進(jìn)程負(fù)載過高跑滿了 CPU

App 端的表現(xiàn)：從 Systrace 來看，CPU 區(qū)域的任務(wù)非常滿，所有的核心上都有任務(wù)在執(zhí)行，App 的主線程和渲染線程多處于 Runnable 狀態(tài)，或者頻繁在 Runnable 和 Running 之間切換

2.2.2 應(yīng)用自身原因?qū)е马憫?yīng)慢

應(yīng)用自身原因主要是應(yīng)用啟動時候的組件初始化、View 初始化、數(shù)據(jù)初始化耗時等，具體包括：

1. Application.onCreate：應(yīng)用自身的邏輯 三方 SDK 初始化耗時
2. Activity 的生命周期函數(shù)：onStart、onCreate、onResume 耗時
3. Services 的生命周期函數(shù)耗時
4. Broadcast 的 onReceive 耗時
5. ContentProvider 初始化耗時（注意已經(jīng)被濫用）
6. 界面布局初始化：measure、layout、draw 等耗時
7. 渲染線程初始化：setSurface、queueBuffer、dequeueBuffer、Textureupload 等耗時
8. Activity 跳轉(zhuǎn)：從 SplashActivity 到 MainActivity 耗時
9. 應(yīng)用向主線程 post 的耗時 Message 耗時
10. 主線程或者渲染線程等待子線程數(shù)據(jù)更新耗時
11. 主線程或者渲染線程等待子進(jìn)程程數(shù)據(jù)更新耗時
12. 主線程或者渲染線程等待網(wǎng)絡(luò)數(shù)據(jù)更新耗時
13. 主線程或者渲染線程 binder 調(diào)用耗時
14. WebView 初始化耗時
15. 初次運(yùn)行 JIT 耗時

2.3 響應(yīng)速度問題分析套路（以 Systrace 為主）

2.3.1 確認(rèn)前提條件

確認(rèn)前提條件 (老化，數(shù)據(jù)量、下載等)、操作步驟、問題現(xiàn)象，本地復(fù)現(xiàn)步驟

2.3.2 需要明確測試標(biāo)準(zhǔn)

1. 啟動時間的起點是哪里
2. 啟動時機(jī)的終點是哪里

2.3.3 抓取所需的日志信息

主要包括 Systrace、常規(guī) log 、視頻、截圖等

2.3.4 分析 Systrace

首先進(jìn)行 Systrace 分析，大概找出差異的點

2.3.4.1 分析耗時差異

首先查看應(yīng)用耗時點，分析對比機(jī)差異，這里可以把應(yīng)用啟動階段分成好幾段來看，來對比分析是哪部分時間增加

1. Application 創(chuàng)建
2. Activity 創(chuàng)建
3. 第一個 doFrame
4. 后續(xù)內(nèi)容加載
5. 應(yīng)用自己的 Message

2.3.4.2 分析應(yīng)用耗時的點

1. 是否某一段方法自身執(zhí)行耗時比較久（Running 狀態(tài)） --> 應(yīng)用自身問題
2. 主線程是否有大段 Running 狀態(tài)，但是底下沒有任何堆棧 --> 應(yīng)用自身問題，加 TraceTag 或者使用 TraceView 來找到對應(yīng)的代碼邏輯
3. 是否在等 Binder 耗時比較久（Sleep 狀態(tài)） --> 檢測 Binder 服務(wù)端，一般是 SystemServer
4. 是否在等待子線程返回數(shù)據(jù)（Sleep 狀態(tài)） --> 應(yīng)用自身問題，通過查看 wakeup 信息，來找到依賴的子線程
5. 是否在等待子進(jìn)程返回數(shù)據(jù)（Sleep 狀態(tài)） --> 應(yīng)用自身問題，通過查看 wakeup 信息，來找到依賴的子進(jìn)程或者其他進(jìn)程 (一般是 ContentProvider 所在的進(jìn)程)
6. 是否有大量的 Runnable --> 系統(tǒng)問題，查看 CPU 部分，看看是否已經(jīng)跑滿
7. 是否有大量的 IO 等待（Uninterruptible Sleep | WakeKill - Block I/O） --> 檢查系統(tǒng)是否已經(jīng)低內(nèi)存 ^[4]
8. RenderThread 是否執(zhí)行 dequeueBuffer 和 queueBuffer 耗時 --> 查看 SurfaceFlinger

2.3.4.3 排查系統(tǒng)問題

如果分析是系統(tǒng)的問題，則根據(jù)上面耗時的點，查看系統(tǒng)對應(yīng)的部分，一般情況要優(yōu)先查看系統(tǒng)是否異常，參考上面列出的的系統(tǒng)原因，主要看下面四個區(qū)域（Systrace）

1. Kernel 區(qū)域 ^[5]
1. 查看關(guān)鍵任務(wù)是否跑在了小核 --> 一般小核是 0-3（也有特例），如果啟動時候的關(guān)鍵任務(wù)跑到了小核，執(zhí)行速度也會變慢
2. 查看頻率是否沒有跑滿 --> 表現(xiàn)是核心頻率沒有達(dá)到最大值，比如最大值是 2.8Ghz，但是只跑到了 1.8Ghz，那么可能是有問題的
3. 查看 CPU 使用率，是否已經(jīng)跑滿了 --> 表現(xiàn)是 CPU 區(qū)域八個核心上，任務(wù)和任務(wù)之間沒有空隙
4. 查看是否處于低內(nèi)存狀態(tài) ^[6]，比如是否應(yīng)用進(jìn)程狀態(tài)有大量的 Uninterruptible Sleep | WakeKill - Block I/O、HeapTaskDeamon 任務(wù)執(zhí)行頻繁、kswapd0 任務(wù)執(zhí)行頻繁等
2. SystemServer 進(jìn)程區(qū)域 ^[7]
1. input 事件讀取和分發(fā)是否有異常 --> 表現(xiàn)是 input 事件傳遞耗時，比較少見
2. binder 執(zhí)行是否耗時 --> 表現(xiàn)是 SystemServer 對應(yīng)的 Binder 執(zhí)行代碼邏輯耗時
3. binder 等 am、wm 鎖是否耗時 --> 表現(xiàn)是 SystemServer 對應(yīng)的 Binder 都在等待鎖，可以通過 wakeup 信息跟蹤等鎖情況，分析等鎖是不是由于應(yīng)用導(dǎo)致的
4. 是否有應(yīng)用頻繁啟動或者被殺 --> 在 Systrace 中查看 startProcess，或者查看 Event Log
3. SurfaceFlinger 進(jìn)程區(qū)域 ^[8]
1. dequeueBuffer 和 queueBuffer 是否執(zhí)行耗時 --> 表現(xiàn)是 SurfaceFlinger 的對應(yīng)的 Binder 執(zhí)行 dequeueBuffer 和 queueBuffer 耗時
2. 主線程是否執(zhí)行耗時 --> 表現(xiàn)是 SurfaceFlinger 主線程耗時，可能是在執(zhí)行其他的任務(wù)
4. Launcher 進(jìn)程區(qū)域（冷熱啟動場景）
1. Launcher 進(jìn)程處理點擊事件是否耗時 --> 表現(xiàn)在處理 input 事件耗時
2. Launcher 自身 pause 是否耗時 --> 表現(xiàn)在執(zhí)行 onPause 耗時
3. Launcher 應(yīng)用啟動動畫是否耗時或者卡頓 --> 表現(xiàn)在動畫耗時或者卡頓

2.3.4.4 初步分析有懷疑的點之后

1. 如果是系統(tǒng)的原因，首先需要看應(yīng)用自身是否能規(guī)避，如果不能規(guī)避，則轉(zhuǎn)給系統(tǒng)來處理
2. 如果是應(yīng)用自身的原因，可以使用 TraceView（AS 自帶的 CPU Profiler）、Simple Perf 等繼續(xù)查看更加詳細(xì)的函數(shù)調(diào)用信息，也可以使用 TraceFix 插件 ^[9]，插入更多的 TraceTag 之后，重新抓取 Systrace 來對比分析

2.3.4.5 問題可能有很多個原因

1. 首先要把影響最大的因素找出來優(yōu)化，影響比較小的因素可以先忽略
2. 有些問題需要系統(tǒng)的配合才能解決，這時候需要跟系統(tǒng)一起進(jìn)行調(diào)優(yōu)（比如各大 App 廠商就會有專門跟手機(jī)廠商打交道的，手機(jī)廠商會以 SDK 的形式，暴露部分系統(tǒng)接口給 App 來使用，比如 Oppo 、華為、Vivo 等）
3. 有些問題影響很小或者無解，這時候需要跟測試同學(xué)溝通清楚
4. 有些問題是重復(fù)問題或不同平臺的相同，可以在 Bug 庫中搜索是否有案例

End

本篇文章主要是一個響應(yīng)速度基礎(chǔ)知識方面的一個普及，其中涉及到大量的系統(tǒng)知識，不熟悉的同學(xué)可以跟著 Systrace 基礎(chǔ)知識系列 ^[10] 過一下

系列文章

1. Systrace 響應(yīng)速度實戰(zhàn) 1 ：了解響應(yīng)速度原理 ^[11]
2. Systrace 響應(yīng)速度實戰(zhàn) 2 ：響應(yīng)速度實戰(zhàn)分析 - 以啟動速度為例 ^[12]
3. Systrace 響應(yīng)速度實戰(zhàn) 3 ：響應(yīng)速度延伸知識 ^[13]
4. Systrace 基礎(chǔ)知識系列 - 放個鏈接在這里方便大家直接點過去 ^[14]

參考文章

1. Android 應(yīng)用啟動全流程分析 ^[15]
2. https://juejin.cn/post/6907493155659055111
3. https://blog.csdn.net/guolin_blog/article/details/108026357
4. https://developer.android.google.cn/topic/libraries/app-startup
5. https://www.androidperformance.com/2019/11/18/Android-App-Lunch-Optimize/
6. https://android.googlesource.com/platform/system/extras/ /master/simpleperf/doc/android_application_profiling.md

參考資料

[1]Systrace 流暢性實戰(zhàn) 1 ：了解卡頓原理: https://www.androidperformance.com/2021/04/24/android-systrace-smooth-in-action-1/

[2]Systrace 基礎(chǔ)知識系列: https://www.androidperformance.com/2019/05/26/Android_Systrace_0/

[3]系統(tǒng)低內(nèi)存: https://www.androidperformance.com/2019/09/18/Android-Jank-Due-To-Low-Memory/

[4]低內(nèi)存: https://www.androidperformance.com/2019/09/18/Android-Jank-Due-To-Low-Memory/#影響主線程-IO-操作

[5]Kernel 區(qū)域: https://www.androidperformance.com/2019/12/21/Android-Systrace-CPU/

[6]低內(nèi)存: https://www.androidperformance.com/2019/09/18/Android-Jank-Due-To-Low-Memory/

[7]SystemServer 進(jìn)程區(qū)域: https://www.androidperformance.com/2019/06/29/Android-Systrace-SystemServer/

[8]SurfaceFlinger 進(jìn)程區(qū)域: https://www.androidperformance.com/2020/02/14/Android-Systrace-SurfaceFlinger/

[9]TraceFix 插件: https://github.com/Gracker/TraceFix

[10]Systrace 基礎(chǔ)知識系列: https://www.androidperformance.com/2019/05/26/Android_Systrace_0/

[11]Systrace 響應(yīng)速度實戰(zhàn) 1 ：了解響應(yīng)速度原理: https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-1/

[12]Systrace 響應(yīng)速度實戰(zhàn) 2 ：響應(yīng)速度實戰(zhàn)分析 - 以啟動速度為例: https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-2/

[13]Systrace 響應(yīng)速度實戰(zhàn) 3 ：響應(yīng)速度延伸知識: https://www.androidperformance.com/2021/09/13/android-systrace-Responsiveness-in-action-3/

[14]Systrace 基礎(chǔ)知識系列 - 放個鏈接在這里方便大家直接點過去: https://www.androidperformance.com/2019/05/26/Android_Systrace_0/

[15]Android 應(yīng)用啟動全流程分析: https://www.jianshu.com/p/37370c1d17fc

[16]關(guān)于我: https://www.androidperformance.com/about/

[17]博客內(nèi)容導(dǎo)航: https://androidperformance.com/2019/12/01/BlogMap/

[18]優(yōu)秀博客文章記錄 - Android 性能優(yōu)化必知必會: https://androidperformance.com/2018/05/07/Android-performance-optimization-skills-and-tools/

ce" data-signature="分享 Android 系統(tǒng)和 App 的性能優(yōu)化知識、開發(fā)技巧、Android 開發(fā)工具、性能優(yōu)化工具、Android