Android性能优化典范之Render Performance

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

当你觉得自己开发了一个改变世界的应用的时候，你的用户可能并不会这么认为，他们认为你的应用又慢又卡，达不到他们所期望的那种顺滑，更谈不上改变这该死的世界了，回收站走你！等等！明明我这个应用在我的Nexus5上非常顺滑啊？你咋能说又慢又卡呢？如果你对Android的碎片化有一定了解的话，你就应该知道，很多低配置的手机并不像Nexus5那样有强大的处理器和GPU，以及没有被怎么污染的原生系统。

如果有大量的用户投诉说你的应用又卡又慢的时候，不要总是抱怨用户的低端手机，有时候问题就出在你的应用本身，也就意味着你的Android存在比较严重的渲染性能问题。只有真正了解问题发生的根源，才能有效的解决问题。所以了解Android渲染相关的知识，是一个Android开发者必不可少的知识。

1

渲染问题是你建立一个应用程序是最经常碰到的问题，一方面，设计师希望展现给用户一个超自然的体验，另一方面，这些华丽的动画和视图并不能在所有的Android手机上都流畅地运行。所以这就是问题所在。

Design vs Performance

2

Android系统每16ms都会重新绘制一次你的Activity，也就是说，你的逻辑控制画面更新要保证最多16ms一帧才能每秒达到60帧（至于为什么是60帧，这个后面会有一个专题来讲解这个）。如下图，每一帧都在16ms内绘制完成，此时的世界是顺滑的。

Draw Good

但是如果你的应用程序没有在16ms内完成这一帧的绘制，假设你花费了24ms来绘制这一帧，那么就会出现我们称之为掉帧的情况，世界变得有延迟了。如下图：

Draw Bad

系统准备将新的一帧绘制到屏幕上，但是这一帧并没有准备好，所有就不会有绘制操作，画面也就不会刷新。反馈到用户身上，就是用户盯着同一张图看了32ms而不是16ms，也就是说掉帧发生了。

3

掉帧是用户体验中一个非常核心的问题，用户将很容易察觉到由于掉帧而产生的卡顿感，如果此时用户正在与系统进行交互，比如滑动列表，或者正在打字，那么卡顿感是非常明显的。用户会马上对你的应用进行吐槽，下一步工作肯定是回收站走你！所以弄清楚掉帧的原因是非常重要的。

不过蛋疼的是，引起掉帧发生的原因非常多，比如：

• 你花了太多的时间重新绘制你视图中的大部分东西，这样非常浪费CPU周期
  
  

  Too Much View
• 你有太多的对象堆叠到了一起，你在绘制用户看不到的对象上花费了太多的时间
  
  

  Draw Hidden View
• 你有一大堆的动画重复了一遍又一遍，导致CPU和GPU组件的大量浪费
  
  

  Too Much Animations

4

检测和解决这些问题很大程度上依赖于你的应用程序架构，但是幸运的是，我们有很多开发者工具来协助我们发现和解决这些问题，有些工具甚至能追踪到具体出错的代码行数或者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视图虽然比较简单，但是非常有效。花费一点了解这个工具每一个细节，对于以后排查问题来说都是事半功倍。关于Hierarchy View视图的用法，会有更详细的单独的教程来讲解。

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

On-Device Tools

这三个选项在设置-辅助功能- 开发者选项中，默认都是关闭的。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绘制的区域会用红色来标注，而没有红色标注的区域，则是使用CPU绘制的。这个选项也可以用来查看redraw的区域大小。

• TraceView

TraceView

TraceView是一个很棒的检查是否掉帧的工具，视频中没有对此工具进行介绍，但是这个工具非常的重要，他可以找到你代码中花费时间的地方，精确到每一个函数，不论这个函数是你应用程序中的还是系统函数。另外在Android Studio中，TraceView得到了改进，其视图能非常直观的显示出每一帧所消耗的时间，函数像倒金字塔一般展现在面前，我们可以很容易地看出掉帧的地方以及那一帧里面所有的函数调用情况。鉴于此工具非常实用，所有会有更详细的单独的教程来讲解。

5

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

6

这是这个系列视频的第一个视频，从内容上来看，是从一个大的角度来看Render Performance，简单地讲述了一下Render Performance基本的概念，出现的原因以及排查的工具。在发现问题--定位问题--解决问题的流程上属于发现问题--定位问题，解决问题则基本没有提到。这也基本符合这一系列视频的基调：即着重于发现问题(使用工具发现问题、挖掘问题出现的原理和原因)和定位问题(使用工具定位)，如何解决问题则需要自己通过实战去进行锻炼，毕竟这种问题并没有一个通用的解决方法，每个应用都有每个应用自己的问题。