背景
最近碰到一個動畫卡頓的問題乖订，花了比較多的精力進行解決，并從中總結(jié)出來一些分析的套路夺巩，特此進行分享货葬。
卡頓掉幀的現(xiàn)象：
正常的現(xiàn)象：
從現(xiàn)象可以看出，應用信息展開的時候劲够，有一定的卡頓震桶。
繪制原理
要在屏幕上顯示，其實要經(jīng)過一系列的過程征绎，Android 應用程序把經(jīng)過測量蹲姐、布局磨取、繪制后的 surface 緩存數(shù)據(jù)，通過進程通信的方式柴墩，把數(shù)據(jù)給到SurfaceFlinger 忙厌，SurfaceFlinger這把這些圖層的數(shù)據(jù)根據(jù)surface的排序進行混合，最后把混合之后的數(shù)據(jù)渲染到顯示屏幕上江咳， 通過 Android 的刷新機制來刷新數(shù)據(jù)羞延。也就是說應用層負責繪制，系統(tǒng)層負責渲染寒随，通過進程間通信把應用層需要繪制的數(shù)據(jù)傳遞到系統(tǒng)層服務评姨，系統(tǒng)層服務通過刷新機制把數(shù)據(jù)更新到屏幕上。
surfaceflinger在初始化時設(shè)置VnSync信號周期踩身，一般為16ms胀茵，之后監(jiān)聽Vnsync信號，在收到信號之后挟阻，重新走混合渲染流程琼娘。
開發(fā)app的性能目標就是保持60fps，這意味著每一幀你只有16ms≈1000/60的時間來處理所有的任務附鸽。Android系統(tǒng)每隔16ms發(fā)出VSYNC信號脱拼，觸發(fā)對UI進行渲染，如果每次渲染都成功坷备，這樣就能夠達到流暢的畫面所需要的60fps熄浓。
如果你的某個操作花費時間是24ms，系統(tǒng)在得到VSYNC信號的時候就無法進行正常渲染击你，這樣就發(fā)生了丟幀現(xiàn)象玉组。那么用戶在32ms內(nèi)看到的會是同一幀畫面。
丟幀情況 卡頓情況
0-10幀 流暢
10-20幀 較卡
20-40幀 很卡
40-60幀 卡死了
卡頓分析
通過systrace抓取launcher應用卡頓時候的信息丁侄，獲取的traceview惯雳，掉幀的的部分如下：
線程在traceview中的信息包括兩部分，線程運行狀態(tài)鸿摇，和線程運行方法棧石景。
通過顏色判斷線程運行狀態(tài)，各個顏色的含義為：
灰色：sleeping拙吉，線程休眠狀態(tài)
藍色：runnable潮孽，線程就緒狀態(tài)
綠色：running，線程運行狀態(tài)
從掉幀的的線程的運行狀態(tài)判斷筷黔，在掉幀的時候往史，UI線程狀態(tài)色顏色為長時間灰色，處于sleeping狀態(tài)佛舱。直接原因找到了椎例，找到導致卡頓的元兇近了一步挨决。
導致UI線程掛起的線程，一般也是將UI線程喚醒的線程订歪。
在traceview中雙擊UI線程結(jié)束休眠后脖祈，變成就緒的第一個狀態(tài)，也就是從灰色變成藍色的第一個狀態(tài)刷晋，可以發(fā)現(xiàn)盖高，導致掛起的線程的線程號為27005。
在traceview中搜索27005眼虱，可以知道此線程名為RenderThread喻奥，也就是硬件加速專門用來渲染的線程。
并且從圖中可看出在UI線程被喚醒前蒙幻，RenderThread線程剛剛執(zhí)行完syncFrameState方法映凳。
RenderThread的工作流程
RenderThread的工作流程可以參考 http://www.reibang.com/p/bc1c1d2fadd1
簡單的來說RenderThread的工作流程為：
1.將Main Thread維護的Display List同步到Render Thread維護的Display List去胆筒。這個同步過程由Render Thread執(zhí)行邮破，但是Main Thread會被阻塞住。
2.如果能夠完全地將Main Thread維護的Display List同步到Render Thread維護的Display List去仆救，那么Main Thread就會被喚醒抒和，此后Main Thread和Render Thread就互不干擾，各自操作各自內(nèi)部維護的Display List彤蔽；否則的話摧莽，Main Thread就會繼續(xù)阻塞，直到Render Thread完成應用程序窗口當前幀的渲染為止顿痪。
3.Render Thread在渲染應用程序窗口的Root Render Node的Display List之前镊辕，首先將那些設(shè)置了Layer的子Render Node的Display List渲染在各自的一個FBO上，接下來再一起將這些FBO以及那些沒有設(shè)置Layer的子Render Node的Display List一起渲染在Frame Buffer之上蚁袭，也就是渲染在從Surface Flinger請求回來的一個圖形緩沖區(qū)上征懈。這個圖形緩沖區(qū)最終會被提交給Surface Flinger合并以及顯示在屏幕上。
注意第二步：“如果能夠完全地將Main Thread維護的Display List同步到Render Thread維護的Display List去揩悄，那么Main Thread就會被喚醒”卖哎，這個就驗證了我們從traceview中看到的在RenderThread完成syncFrameState之后，UI線程被喚醒删性。
綜述
掉幀的根本原因是RenderThread的繪制時間過長亏娜。UI線程在Draw方法中，完成將數(shù)據(jù)放入displaylist之后會掛起蹬挺，等待Render Thread將displaylist的數(shù)據(jù)同步维贺，也就是完成syncFrameState方法。如果RenderThread一直在繪制巴帮，那么UI線程掛起的時間就會很長溯泣，整個繪制市場就會超過16ms群发，最終導致掉幀。
