Rendering performance is all about how fast you can draw your activity, and get it updated on the screen. Success here means your users feeling like your application is smooth and responsive, which means that you’ve got to get all your logic completed, and all your rendering done in 16ms or less, each and every frame. But that might be a bit more difficult than you think.

In this video, +Colt McAnlis takes a look at what “rendering performance” means to developers, alongside some of the most common pitfalls that are ran into; and let’s not forget the important stuff: the tools that help you track down, and fix these issues before they become large problems.

0

當你覺得自己開發(fā)了一個改變世界的應用的時候，你的用戶可能并不會這么認為，他們認為你的應用又慢又卡，達不到他們所期望的那種順滑，更談不上改變這該死的世界了，回收站走你！等等！明明我這個應用在我的Nexus5上非常順滑?。磕阏δ苷f又慢又卡呢？如果你對Android的碎片化有一定了解的話，你就應該知道，很多低配置的手機并不像Nexus5那樣有強大的處理器和GPU，以及沒有被怎么污染的原生系統(tǒng)。

如果有大量的用戶投訴說你的應用又卡又慢的時候，不要總是抱怨用戶的低端手機，有時候問題就出在你的應用本身，也就意味著你的Android存在比較嚴重的渲染性能問題。只有真正了解問題發(fā)生的根源，才能有效的解決問題。所以了解Android渲染相關的知識，是一個Android開發(fā)者必不可少的知識。

1

渲染問題是你建立一個應用程序是最經常碰到的問題，一方面，設計師希望展現(xiàn)給用戶一個超自然的體驗，另一方面，這些華麗的動畫和視圖并不能在所有的Android手機上都流暢地運行。所以這就是問題所在。

Design vs Performance

2

Android系統(tǒng)每16ms都會重新繪制一次你的Activity，也就是說，你的邏輯控制畫面更新要保證最多16ms一幀才能每秒達到60幀（至于為什么是60幀，這個后面會有一個專題來講解這個）。如下圖，每一幀都在16ms內繪制完成，此時的世界是順滑的。

Draw Good

但是如果你的應用程序沒有在16ms內完成這一幀的繪制，假設你花費了24ms來繪制這一幀，那么就會出現(xiàn)我們稱之為掉幀的情況，世界變得有延遲了。如下圖：

Draw Bad

系統(tǒng)準備將新的一幀繪制到屏幕上，但是這一幀并沒有準備好，所有就不會有繪制操作，畫面也就不會刷新。反饋到用戶身上，就是用戶盯著同一張圖看了32ms而不是16ms，也就是說掉幀發(fā)生了。

3

掉幀是用戶體驗中一個非常核心的問題，用戶將很容易察覺到由于掉幀而產生的卡頓感，如果此時用戶正在與系統(tǒng)進行交互，比如滑動列表，或者正在打字，那么卡頓感是非常明顯的。用戶會馬上對你的應用進行吐槽，下一步工作肯定是回收站走你！所以弄清楚掉幀的原因是非常重要的。

不過蛋疼的是，引起掉幀發(fā)生的原因非常多，比如：

• 你花了太多的時間重新繪制你視圖中的大部分東西，這樣非常浪費CPU周期
  
  Too Much View
• 你有太多的對象堆疊到了一起，你在繪制用戶看不到的對象上花費了太多的時間
  
  Draw Hidden View
• 你有一大堆的動畫重復了一遍又一遍，導致CPU和GPU組件的大量浪費
  
  Too Much Animations

4

檢測和解決這些問題很大程度上依賴于你的應用程序架構，但是幸運的是，我們有很多開發(fā)者工具來協(xié)助我們發(fā)現(xiàn)和解決這些問題，有些工具甚至能追蹤到具體出錯的代碼行數(shù)或者UI控件，這些工具包括但不限于：

• Hierarchy View

Hierarchy View

你可以使用Hierarchy View 來查看你的View是否過于復雜，如果是，那么說明你有很多時間沒有利用。并且浪費了許多時間進行重繪。
Hierarchy View 位于Android Device Monitor 中，Android Device Monitor在Eclipse和Android Studio中都有有對應的入口，依次選則Window-Open Perspective-Hierarchy View即可打開Hierarchy View視圖。 Hierarchy View視圖雖然比較簡單，但是非常有效。花費一點了解這個工具每一個細節(jié)，對于以后排查問題來說都是事半功倍。關于Hierarchy View視圖的用法，會有更詳細的單獨的教程來講解。

• On-Device Tools -- Profile GPU Rendering 、Show GPU Overdraw、GPU View Updates

On-Device Tools

這三個選項在設置-輔助功能- 開發(fā)者選項中，默認都是關閉的。Profile GPU Rendering 和 GPU Overdraw比較重要，所以系列視頻后面會有專門的專題會講解，這里簡單介紹一下GPU View Updates。GPU View Updates的作用是使用GPU進行繪圖時閃爍顯示窗口中的視圖。隨著android版本的更新，越來越多的繪制操作能使用GPU來完成，詳見http://developer.android.com/guide/topics/graphics/hardware-accel.html，而這個工具打開之后，使用GPU繪制的區(qū)域會用紅色來標注，而沒有紅色標注的區(qū)域，則是使用CPU繪制的。這個選項也可以用來查看redraw的區(qū)域大小。

• TraceView

TraceView

TraceView是一個很棒的檢查是否掉幀的工具，視頻中沒有對此工具進行介紹，但是這個工具非常的重要，他可以找到你代碼中花費時間的地方，精確到每一個函數(shù)，不論這個函數(shù)是你應用程序中的還是系統(tǒng)函數(shù)。另外在Android Studio中，TraceView得到了改進，其視圖能非常直觀的顯示出每一幀所消耗的時間，函數(shù)像倒金字塔一般展現(xiàn)在面前，我們可以很容易地看出掉幀的地方以及那一幀里面所有的函數(shù)調用情況。鑒于此工具非常實用，所有會有更詳細的單獨的教程來講解。

5

keep calm, profile your code, and always remember, Perf Matters

6

這是這個系列視頻的第一個視頻，從內容上來看，是從一個大的角度來看Render Performance，簡單地講述了一下Render Performance基本的概念，出現(xiàn)的原因以及排查的工具。在發(fā)現(xiàn)問題--定位問題--解決問題的流程上屬于發(fā)現(xiàn)問題--定位問題，解決問題則基本沒有提到。這也基本符合這一系列視頻的基調：即著重于發(fā)現(xiàn)問題(使用工具發(fā)現(xiàn)問題、挖掘問題出現(xiàn)的原理和原因)和定位問題(使用工具定位)，如何解決問題則需要自己通過實戰(zhàn)去進行鍛煉，畢竟這種問題并沒有一個通用的解決方法，每個應用都有每個應用自己的問題。