Android性能優化課程翻譯（一）：渲染性能
渲染性能意味著你可以有多快的速度繪制你的activity并讓它在屏幕上刷新出來。這里的性能良好指的是你的用戶感覺你的應用程序是流暢的，并且是快速響應的，這意味著你必須在16ms甚至更少的時間來完成所有的邏輯和渲染操作，但實際上這可能比你想象的要困難一些。
內容概要
首先說明，這篇文章來自于Google在油Tube上的官方視頻教程之一，官方一共有十六個性能優化的視頻，我這里會一直翻譯完。如果英語不錯，可以KX上網去看看油Tube上的視頻，那里有英文字幕，假如你翻不了墻也沒事，北京GDG把這些視頻已經搬運到優酷上了：優酷的地址。
這個視頻中，Colt McAnlis將帶我們去看看“渲染性能”對開發者意味著什么。它可以讓我們開發者不掉進一些最常見的陷阱中，教我們不要忘記重要的東西：幫助我們跟蹤性能的工具，并且在這些性能問題變嚴重之前如何解決它們。
視頻翻譯
- 用戶體驗不佳
當你在構建下一個偉大的app時，你的用戶卻在抱怨這個軟件體驗不穩定。他們感覺到慢和界面的跳動，并且滑動也不像他們想象的那么平滑順手。
我的名字是 Colt McAnlis，這些抱怨聽起來，你的app有一個嚴重的渲染性能問題。但是別擔心，我們可以通過看看Android內部是如何工作的來修復這個問題。在 你構建一個app時，渲染性能是最常見的性能問題。一方面，你的設計師想給用戶最易用，最卓越的體驗；但另一方面，這些華麗的圖形和動畫可能不會在每一個 設備上都運行的很流暢。
- 渲染性能分析
讓我們看看渲染性能都是些什么吧。首先，你必須了解系統每隔16ms左右重繪你的activity，這意味著你的應用程序需要在16ms的幀中運行 完所有邏輯并更新到屏幕上，以達到每秒60幀的刷新速率。如果你錯過了這個16ms幀窗口，假如說你花費了24ms，就產生了一個我們稱之為丟棄的幀。也 就是說系統在嘗試屏幕上繪制一個新的畫面時，而你并沒有把這個畫面準備好，結果用戶就會在32毫秒內看到相同圖形而不是16毫秒。錯過幀的結果會讓用戶感 覺這是一個慢甚至糟糕的體驗。在動畫中出現一個丟棄幀會在平滑的體驗中看到一個跳躍，用戶可以很容易看出來。當這種情況發生時，如果用戶恰好正在與系統交 互，那將會變得更加糟糕。比如：用戶在拖動一個listview或輸入一些數據的時候。這使得用戶很快就開始抱怨了。
- 渲染性能低的原因
你錯過了16毫秒的幀窗口有很多種原因，例如，你可能花了太多時間去重繪大量的視圖層次（View hierarchy），這是很浪費CPU周期的。或者你可能繪制了太多的對象，在像素著色上浪費了寶貴的時間，然而這些對象對最終用戶而言都是不可見的。 又或者你重復一遍又一遍的在做大量的動畫，這會導致CPU和GPU大量的工作。
- 檢測和解決渲染性能問題
檢測和解決這些問題很大程度上是依賴于你是如何構建app的，但一般來說，還是可以使用有效的工具來跟蹤和識別是什么導致了錯誤。例如，你可以使用 Hierarchy Viewer來判斷你的activity是否過于復雜，因為這可能導致你花費太多時間去刷新和重繪。你也可以使用設備上的工具，例如：Profile GPU Rendering, Show GPU Overdraw 和 GPU View Updates，他們可以在你遇到問題時更好的了解你的應用程序.對于那些在使用CPU時出現的渲染bug，Traceview是一個很好的工具，它能幫 助你跟蹤是什么導致錯過一個16毫秒幀窗口。
- 保持冷靜，keep going
渲染性能是一個很容易出現的性能問題，但是不要因為它而停止做一個amazing app。看看Android性能模式的其他資源，不要忘記加入Google+社區哦(和諧的天朝是參與不了的，KX上網吧)。所以分析代碼時請保持冷靜，千萬要記住，性能很重要。
總結
不當的渲染是Android上大部分性能問題的根源。如果一個Activity需要16毫秒以上的時間來準備在屏幕上渲染下一幀，系統將放棄這一 幀。應用的用戶會感覺滑動不流暢，或者變換有延遲，從而導致體驗不好。McAnlis推薦了很多用于檢查此類問題的工具：Hierarchy Viewer、Traceview、Profile GPU Rendering、Debug GPU Overdraw和GPU View Updates。
建議盡量減少失效（invalidation）和布局（layout）的數量。前者可以用Developer Option Show GPU View Updates可視化地觀察，而后者可以使用Hierarchy Viewer來分析。
視頻原文
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.
So you’ve built the next great mobile app,but users are complaining that the experience isn’t always consistent.They’re calling it slow and hitchy.And they say that it doesn’t scroll as smoothly as they’d like.My name is Colt McAnlis, and it sounds like your app has a serious rendering performance problem.But don’t worry. We can fix this by taking a look at how Android is working under the hood.Rendering performance is the most common performance issue that you run into while building an app. On the one hand, your designers want to produce the most usable, transcendent experience for your users. But on the other hand, all those fancy graphics and transitions may not work well on every device.
So let’s take a look at what rendering performance is all about. Firstly, know that the system will attempt to redraw your activity every 16 milliseconds or so, which means that your application needs to run all the logic that updates the screen in that 16-millisecond frame in order to hit 60 frames per second. If you miss that window-let’s say you take 24 milliseconds , you start to get what we call a dropped frame. The system tried to draw a new picture on the screen, but one wasn’t ready yet. So it didn’t refresh anything. The user ends up seeing the same graphic for 32 milliseconds rather than for 16. This effect of missed frames is at the core of what a user would call a laggy or janky experience. Any animations that are going on during a dropped frame will see a jump in their smoothness, which users can easily see. It gets even worse when this effect happens while the users are interacting with the system— for example, dragging a ListView or typing in some data. This is what users quickly start to complain about.
There’s a whole group of reasons that you could miss your 16-millisecond frame window. For example, you may be spending too much time redrawing large parts of your View hierarchy, which wastes CPU cycles. Or you might be drawing too many objects on top of each other, which wastes valuable time coloring in pixels that aren’t visible to the final user. Or you could be doing a ton of animation over and over and over again, which can cause large amounts of churn on both your CPU and GPU components. Detecting and fixing these problems is highly dependent on how your app is built. But generally, it comes down to using the available tools to track down and identify what’s going wrong. For example, you can use Hierarchy Viewer to understand if your activity is too complex, which can lead to issues with spending too much time invalidating or wasting time redrawing. You can also use the On-Device Tools, like Profile GPU Rendering, Show GPU Overdraw, and GPU View Updates, to get a better sense of where in your application you’re running into problems. And for those tricky rendering bugs that manifest themselves in CPU code, Traceview is a great tool to track down what’s causing a missed 16-millisecond frame.
Rendering performance is one of the easiest performance problems to fall into, but don’t let that stop you from making an amazing app. Check out the rest of the Android Performance Patterns resources. And don’t forget to join our Google+ community. So keep calm, profile your code, and always remember, Perf Matters.