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.