在面試問到你的應用程序是否卡頓，如何處理卡頓的，相信大家都會說，不要在主線程處理耗時操作，以及優化層次佈局等。其實這個答案沒錯，但是卻是有點空洞，面試官更想知道的應該是爲什麼在主線程耗時操作和佈局太複雜會造成會造成卡頓。
這裏先解釋一下屏幕刷新的幾個概念，CPU，GPU和屏幕
CPU:執行應用層的measure、layout和draw等操作，將繪製完成之後的操作提交給GPU。
GPU：會將CPU提供的數據，進一步處理，並將數據進行緩存。
屏幕：由一個個像素點組成，根據固定頻率（60HZ）從GPU裏面獲取緩存數據填充到像素點上。
爲什麼不能有深層嵌套和複雜的draw
GPU裏面的緩存也是包括兩個部分的一個是Back Buffer一個是Frame Buffer 使用雙緩衝機制，GPU只會往Back Buffer裏面寫入數據，從Frame Buffer裏面將緩存數據刷新到屏幕上，每到一個固定頻率 Back Buffer 和Frame Buffer角色互換。在CPU比較差或者繪製邏輯比較複雜，不能夠保證在16.6毫秒完成繪製，當應用正在往Back Buffer寫數據的時候，會爲Back Buffer加鎖，當刷新時間到了的時候會放棄此時buffer交換。
下面說一下爲什麼不能在主線程的耗時操作會導致頁面卡頓。
在Android 4.1之前沒有引入choreographer ,雖然繪製不是很複雜，消耗的時間也不長，但是下一次vsync信號馬上就好到了，所以還是存在丟幀的情況，因此在Android 4.1之後引入了choreographer這個類，這個類會緩存本次的繪製請求，並且通過JNI請求下一個vsync信號，vsync是SurfaceFiling實現的，當VSYNC信號來臨時會通過handler發送一個異步消息，到Message Queue隊列當中，如果此時主線程一直在做耗時操作導致，Message 消息一直得不到處理，就不會走後面的從Choreographer繪製流程的邏輯（從Choreographer緩存隊列裏面取出繪製請求），如果等異步消息執行完之後在執行繪製相關操作自然會卡頓掉幀，在這個過程中，爲了讓繪製操作消息級別提高用到了消息屏障，消息屏障只會處理異步消息，如果沒有異步消息就會handler消息就會睡眠。