主要內(nèi)容：

結(jié)合視頻觀看效果更佳代碼等繪制圖

1.卡頓到底如何優(yōu)化？需要掌握什么？
2.卡頓的核心原因是什么？那些因素會導(dǎo)致卡頓現(xiàn)象出現(xiàn)？
3.如何快速精準(zhǔn)的定位到卡頓事故點(diǎn)。
4.systrce對于事故原因分析的輔助。
5.ChoreographerHelper對于事故閾值的判斷。
6.卡頓生產(chǎn)案例解析。

首先回顧承接回顧上一篇文章，渲染對于卡頓的影響簡單的總結(jié)一下：

1.主線程Handler機(jī)制的影響：?因?yàn)檎w調(diào)用關(guān)系，測量，布局，繪制，UI線程里面處理。事件的整個采集過程 ，native采集事件信號上來傳送到APP當(dāng)中也是Main中間用了以后Handler.

2.渲染線程的渲染影響
3.APP與surfaceflinger的進(jìn)程影響

大概簡單的總結(jié)了上一篇內(nèi)容和視頻的內(nèi)容，本文承上啟下來講講卡頓方面的問題

一丶通常在面試中回答優(yōu)化的問題的正確資姿勢：

性能優(yōu)化看上去非常的高大上，但是其實(shí)就是“細(xì)節(jié)決定成敗”的概念。需要對原理性的東西了解清楚，每一步都有什么不一樣，針對每個步驟進(jìn)行細(xì)致化的優(yōu)化。性能優(yōu)化是一種思想，而不是一套具體的操作方法。比如:
我們發(fā)現(xiàn)問題（核心原理）→定位問題（原理實(shí)踐）→解決問題（原理實(shí)踐）

1.1卡頓影響的因素

1.2卡頓原理分析：
兩個單位運(yùn)行時間超過16.66ms就會跳幀。

16ms主要處理兩件事：將UI對象轉(zhuǎn)換多邊形和紋理；CPU傳遞數(shù)據(jù)到GPU,GPU進(jìn)行繪制。

二丶透過渲染原理分析導(dǎo)致卡頓的主客觀因素:

主觀因素

• 事件的運(yùn)行事件對于渲染有影響

• 測量，布局，draw當(dāng)中的代碼運(yùn)行速度會對于渲染有影響。

• 圖形的繪制過程。

客觀因素:

• JVM-GC STW

• 線程的阻塞

• 通信（Binder）

• IO

主線程上的影響

• 渲染的工作內(nèi)容：測量，布局。draw

• 事件的工作內(nèi)容：事件內(nèi)部的回調(diào)代碼

• 圖像的制作內(nèi)容：圖像布局，過度繪制

三丶systrace如何定位分析事故原因

1.事故類型的什么：

1.1.UI繪制導(dǎo)致的問題（測量，布局，繪制三個函數(shù)調(diào)用超時）
1.2.事件導(dǎo)致的調(diào)用超時
1.3.層級過多導(dǎo)致的繪制超時
1.4.GC導(dǎo)致的超時
1.5.IO導(dǎo)致的超時
1.6.通信（Binder）導(dǎo)致的超時

systrace是用做定位事故類型,運(yùn)行systrace。要在Pixel/Pixel XL上調(diào)試抖動問題，請從以下命令開始：

./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 9600

當(dāng)將明白用于GPU活動和顯示管道活動所需的附加跟蹤點(diǎn)時，你將能夠跟蹤從用戶輸入直到屏幕上顯示的幀。將緩沖區(qū)大小設(shè)為較大的值，以免丟失事件（通常表現(xiàn)為一些CPU在跟蹤記錄中的某個點(diǎn)之后不包括任何事件）。

在使用systrace的過程中，請記住，每個事件都是有CPU上的活動觸發(fā)的。

注意：硬件中斷不受CPU控制，且會在ftrace中觸發(fā)事件，不過向跟蹤日志的實(shí)際提交操作是由中斷處理程序完成的，如果你的中斷已到達(dá)，而（例如）某個其他不良驅(qū)動程序已停止中斷，則提交可能會延遲，因此CPU是關(guān)鍵要素。

因?yàn)?code>systrace構(gòu)建于ftrace之上，而ftrace在CPU上運(yùn)行，所有CPU的活動必須寫入用于記錄硬件變化情況的ftrace緩沖區(qū)。這意味著，如果你想知道顯示柵欄更改狀態(tài)的原因，則可以查看在狀態(tài)切換的準(zhǔn)確點(diǎn)CPU上運(yùn)行了那些活動（在CPU上運(yùn)行的某些活動在日志中觸發(fā)了這種更改）此概念是使用systrace分析性能的基礎(chǔ)

2.示例：工作幀

該示例介紹了正常界面管道的systrace。要按照示例操作，請下載跟蹤記錄的ZIP文件（包括本節(jié)提到的其他跟蹤記錄），將文件解壓，然后再瀏覽器中打開systrace_tutorial.html_文件。

注意：該systrace是一個大型文件；除非你在日常工作中使用systrace否則這個跟蹤揭露可可能更為完整，其中包含的信息比之前在單個跟蹤記錄中看到的要多。

對于一致的周期性工作負(fù)載（例如TouchLatency）界面管道包含了以下內(nèi)容：

1.surfaceFlinger中的EventThread會喚醒應(yīng)用的界面線程，表面該渲染新幀了。
2.應(yīng)用使用CPU和GPU資源在界面線程丶RenderThread?和hwuiTask中渲染幀。這是界面占用的大部分容量。
3.應(yīng)用通過Binder將渲染的幀發(fā)送到surfaceFlinger并進(jìn)入休眠狀態(tài)。
4.surfaceFlinger中的第二個EventThread喚醒surfaceFlinger以觸發(fā)構(gòu)圖和顯示輸出。如果surfaceFlinger確定沒有任何需要執(zhí)行，將返回休眠狀態(tài)。
5.surfaceFlinger通過HWC/HWC 2或者GL處理構(gòu)圖。HWC/HWC 2構(gòu)圖的速度更快且功率更低，但存在限制，具體取決于SOC。這個步驟通常需要4-6毫秒，但是可以與第二步同步進(jìn)行，因?yàn)锳ndroid應(yīng)用始終會進(jìn)行三重緩沖（雖然應(yīng)用始終會進(jìn)行三重緩沖，但是surfaceFlinger中可能只有一個待處理幀在等待，這樣它就看起來與雙從緩沖一樣。）
6.surfaceFlinger將通過供應(yīng)商驅(qū)動程序?qū)⒆罱K輸出調(diào)度到顯示部分，然后返回休眠狀態(tài)，等待EventThread喚醒。

四丶常見解決問題方案

1.布局優(yōu)化
常用標(biāo)簽：

• include（頭尾等同質(zhì)化嚴(yán)重的可復(fù)用xml最好做成一個獨(dú)立布局文件引用）

• merge(被include的具體布局根布局采用merge,作用是會加載時直接鑲?cè)氲礁覆季种?，和include配合使用。）

• viewstub(常規(guī)像密碼提示顯示框那些東西只有在需要特定條件下觸發(fā)才展示的用viewstub這個組件只有在狀態(tài)為visible時才加載

常用方案：調(diào)整布局結(jié)構(gòu)和背景色匹配

2.過度繪制

GPU過度繪制檢查可用手機(jī)開發(fā)者功能中自帶的檢測工具：開發(fā)者模式丶調(diào)試GPU過度繪制丶顯示過度繪制區(qū)域。

解決方案：
溢出布局中不必要的背景丶使視圖層次結(jié)構(gòu)扁平化丶裁剪不必要的繪制元素。

系統(tǒng)檢測工具應(yīng)用：

1.layout?Inspector-主要用作布局優(yōu)化
2.systrace
3.Looper機(jī)制
4.ChreographerHelper編舞者監(jiān)聽幀率-主要目的是看整個運(yùn)行情況定位到大塊，然后結(jié)合上面設(shè)定閾值進(jìn)行處理

五丶優(yōu)化思路與核心決策

1.如何判斷是否需要調(diào)整：

優(yōu)化的方案一定是空間或者是時間：假設(shè)20個Framengt,優(yōu)化每一個Frament到極致（數(shù)據(jù)能否少加載點(diǎn)？流程能否優(yōu)化？視覺能否優(yōu)化？20個Frament能否少加載一點(diǎn)，空間和時間那個重要流程上能否在優(yōu)化？）

2.方案上如何妥協(xié)：穩(wěn)定當(dāng)然是第一位，其次注意成本和用戶體驗(yàn)。