摘要：Android系统不断进化开发者优囮应用的手段也在变多。本文作者总结归纳了Android性能优化的原则讲解如何使用现有的工具去分析解决性能问题，并结合自身实践给出了常鼡的内存优化技巧

CSDN移动将持续为您优选移动开发的精华内容，共同探讨移动开发的技术热点话题涵盖移动应用、开发工具、移动游戏忣引擎、智能硬件、物联网等方方面面。如果您想投稿或寻求《近匠》报道，请发送邮件至tangxy#csdn.net（请把#改成@） 

本文出自：，作者：；译文絀自：译者：

几周前，我在Droidcon NYC上有过一次关于Android性能优化的演讲我在这个演讲中花费了大量的时间，因为我想通过真实的例子展现性能问題以及我是通过什么样的工具去发掘这些问题的。因为时间原因在演讲中我不得不舍弃一半的内容。在这篇文章中我会总结在演讲Φ我所讨论的所有内容，并且给出实例（ 观看演讲视频，需自备梯子）

现在我们来逐一讨论我在演讲中提及的一些重点内容，希望我嘚阐述足够的清晰首先，在我进行性能优化的时候我遵循如下原则：

每当我遇到性能问题或者尝试发现性能问题的时候，我会遵循如丅原则：

• 坚持性能测试——不要用你的眼睛去优化性能也许在你盯着同一个动画看了几次之后，你会开始相信它运行得越来越流畅了數据不会说谎。在优化你的代码前后使用我们将要介绍的一系列工具，去多次地测试你的App到底性能几何
• 使用低端设备——如果你想要伱想暴露你应用的性能问题，低端设备往往会更加的容易性能强大的设备往往不会太在意你应用上面的一些优化问题，且不是所有用户嘟在使用这些旗舰设备
• 权衡——性能的优化始终围绕着权衡这两个字。你在某一个点上的优化可能会造成另一点上出现问题在很多情況下，你会花大量的时间寻找并解决这些问题但造成这些问题的原因也可能使因为例如bitmaps的质量，或是你没有使用正确的数据结构去存储伱的数据所以你要时刻准备好作出一定的牺牲。

Systrace是一个非常好但却有可能被你忽视的工具这是因为开发者们往往不确定Systrace能够为他们提供什么样的信息。

Systrace会展示一个运行在手机上程序状况的概览这个工具提醒了我们手机其实是一个可以在同一时间完成很多工作的电脑。茬最近的一次SDK更新中这个工具在数据分析能力上得到了提升，用以帮助我们寻找性能问题之所在

下面让我们来看看Systrace长什么样子：

在视頻中，我向大家介绍了Systrace中不同区域的功能当然最有趣的还是Alerts和Frames两栏，它们展示了通过手机来的数据而生成出来的可视化分析结果让我們来选择最上方的alerts瞧瞧：

这个警告指出了，有一个View#draw()方法执行了比较长的时间我们可以在下面看到问题的描述，链接甚至是相关的视频。下面我们看Frames这一行可以看到这里展示了被绘制出来的每一帧，并且用绿、黄、红三颜色来区分它们在绘制时的性能我们选一个红色幀来瞅瞅：

在最下方，我们看到了与这一帧所相关的一些警告在这三个警告中，有一个是我们上面所提到的（View#draw()）接下来我们在这一帧處放大并在下方展开“Inflation during ListView recycling”这条警告：

我们可以看到警告部分的总耗时，32毫秒远高于了我们对保障60fps所需的16毫秒绘制时间。同时还有更多的ListView烸个条目的绘制时间大约是6毫秒每个条目，总共五个而Description描述项中的内容会帮助我们理解问题，甚至提供问题的解决方案回到我们上┅张图片，我们可以在“inflate”这一个块区处放大并且观察到底是哪些View在被填充过程中耗时比较严重。

下面是另外一个渲染过慢的实例：

在選择了某一帧之后我们可以按“m”键来高亮这一帧，并且在上方看到了这一部分的耗时如图，我们看到了这一阵的绘制总共耗时超过19毫秒而当我们展开这一帧唯一的一个警告时，我们发现了“Scheduling delay”这条错误

Scheduling delay（调度延迟）的意思就是一个线程在处理一块运算的时候，在佷长一段时间都没有被分配到CPU上面做运算从而导致这个线程在很长一段时间都没有完成工作。我们选择这一帧中最长的一块从而得到哽加详细的信息：

在红框区域内，我们看到了“Wall duration”他代表着这一区块的开始到结束的耗时。之所以叫作“Wall duration”是因为他就像是墙上的一個时钟，从线程的一开始就为你计时

但是，CPU Duration一项中显示了实际CPU在处理这一区块所消耗的时间

很显然，两个时间的差距还是非常大的整个区块耗时18毫秒，而在这之中CPU只消耗了4毫秒的时间去运算这就有点奇怪了，所以我们应该看一下在这整个过程之中CPU去干吗了。

可以看到所有四个线程都非常的繁忙。

选择其中的一个线程会告诉我们是哪个程序在占用他在这里是一个包名为com.udinic.keepbusyapp的程序。在这里由于另外一个程序占用CPU，导致了我们的程序未能获得足够的CPU国家语言资源监测与研究中心

但是这种情况其实是暂时的，因为被其他后台应用占鼡CPU的情况并不多见（- -）但仍有其他应用的线程或是主线程占用CPU。而Traceview也只能为我们提供一个概览他的深度是有限的。所以要找到我们app中箌底是什么让我们的CPU繁忙我们还要借助另一个工具——Traceview。

Traceview是一个性能测试工具展示了所有方法的运行时间。下面让我们来瞅瞅它是啥樣的：

这个工具可以从Android Device Monitor中打开也可以通过代码打开更多的消息信息请看。

下面让我们来看看每一列的含义：

• Name——方法名以及他们在上媔图表中所对应的颜色。
• Inclusive CPU Time——CPU在处理这个方法以及所有子方法（如被他调用的所有方法）的总耗时
• Calls+Recursion——这个方法被调用的次数，以及被遞归调用的次数
• CPU/Real time per Call——在处理这个方法时的CPU耗时的平均值以及实际耗时的平均值。另外的列展示了这个方法所有调用的累计耗时

我打开┅个滑动不太顺滑的应用。开启记录滑动一点后停止记录。展开getView()方法如下图：

这个方法被调用了12次，每次CPU会消耗3毫秒左右但是每次調用的总耗时却高达162毫秒！绝对有问题啊！

而看看这个方法的children，我们可以看到这其中的每个方法在耗时方面是如何分布的Thread.join()方法战局了98%的inclusive real time。这个方法在等待另一个线程结束的时候被调用在Children中另外一个方法就是Tread.start()方法，而之所以整个方法耗时很长我猜测是因为在getView()方法中启动叻线程并且在等待它的结束。

我们在getView()方法中并不能看到这个线程做了什么因为这段逻辑不在getView()方法之中。于是我找到了Thread.run()方法就是在线程被创建出来时候所运行的方法。而跟随这个方法一路向下我找到了问题的元凶。

我发现了BgService.doWork()方法的每次调用花费了将近14毫秒并且有四十個这东西！而且getView()中还有可能调用多次这个方法，这就解释了为什么getView()方法执行时间如此之长这个方法让CPU长时间的保持在了繁忙状态。而看看Exclusive CPU time我们可以看到他占据了80%的CPU时间！此外，根据Exclusive CPU time排序可以帮我们更好的定位那些耗时很长的方法，而他们很有可能就是造成性能问题的罪魁祸首

关注这些耗时方法，例如getView()View#onDraw()等方法，可以很好的帮助我们寻找为什么应用运行缓慢的原因但有些时候，还会有一些其他的东覀来占用宝贵的CPU国家语言资源监测与研究中心而这些国家语言资源监测与研究中心如果被运用在UI的绘制上，也许我们的应用会更加流畅Garbage Collector垃圾回收机制会不时的运行，回收那些没用的对象通常来讲这不会影响我们在前台运行的程序。但如果GC被运行的过于频繁他同样可鉯影响我们应用的执行效率。而我们该如何知道回收的是否过于频繁了呢…

Android Studio在最近的更新中给予了我们更加强大的工具去分析性能问题茬底部Android选项中的Memory选项卡，会显示有多大的数据在什么时候被分配到了堆内存之中它是长成这个样子的：

而当图表中出现一个小的下滑的時候，说明GC回收发生了他清除了不必要的对象并且腾出了一定的堆空间。而在这张图表的左侧有两个工具供我们使用Head dump和Allocation Tracker。

为了找出到底是什么正在占用我们的堆内存我们可以使用左边的heap dump按钮。他会提供一个堆内存占用情况的快照并且会在Android Studio中打开一个单独的报告界面。

在左侧我们看到一个图标展示了堆中所有的实例，按照类进行分组而对于每一个实例，会展示有多少个实例的对象被分配到堆中鉯及他们的所占用的空间（Shallow size浅尺寸），以及这些对象在内存中仍然占用的空间后者告诉了我们多少的内存空间将会被释放如果这些实例被释放。这个工具可以让我们直观的观察处内存是被如何占用的帮助我们分析我们使用的数据结构和对象之间的关系，以便发现问题并使用更加高效的数据结构解开和对象之间的关联，并且降低Ratained Memory的占用而最终目的，就是尽可能的降低我们的内存占用

回过头来看图表，我们发现MemoryActivity存在39个实例这对于一个Activity来说有点奇怪。在右边选择其中的一个实例会在下方看到所有的对这个实例的引用树状列表。

其中┅个是ListenersManager对象中的一个集合而观察这个activity的其他实例，就会他们都因为这个对象而被保留在了内存之中这也解释了为什么这些对象占用了洳此多的内存：

这个现象就叫做“内存泄露”，我们的activity已经被销毁但是他们的对象却因为始终被引用着而无法被垃圾回收。我们可以避免这种情况例如确保这些对象再被销毁后不会被其他对象一直引用着。在我们这个例子中在Activity被销毁后，ListernesManager并不需要保持着对这些对象的引用所以解决办法就是在onDestroy()回调方法中移除这些引用。

内存泄露以及其他较大的对象会在堆中占据很多的控件它们减少着可用内存的同時也频繁的造成垃圾回收。而垃圾回收又回造成CPU的繁忙而堆内存并不会变得更大，最终就会导致更悲剧的结果发生：OutOfMemoryException内存溢出并导致程序崩溃。

这个工具可以做所有Android Studio可以做的并且辨别可能出现的内存泄露，以及提供更加高级的搜索功能例如搜索所有大于2MB的Bitmap实例，或昰搜索所有

另外一个很好的工具是，是一个第三方库可以观察应用中的对象并且确保它们没有造成泄漏。而如果造成泄漏了会有一個推送来提醒你在哪里发生了什么。

我们可以在内存图表的左侧找到Allocation Tracker的启动和停止按钮他会生成一个在一定时间内被生成的所有实例的報告，并且按照类分型分组：

同时它还能通过美观的可视化界面告诉我们哪些方法或类拥有最多的实例。

利用这些信息我们可以找到哪些占用过多内存，引发过多次垃圾回收且又对耗时非常敏感的方法我们也可以利用这个工具找到很多短命的相同类的实例，从而可以栲虑使用对象池的思想去尽量的减少过多的实例被创建

以下是一些我写代码时候遵循的规律或是技巧：

• 枚举在性能问题上一直是一个被經常讨论的话题。这里是一个讨论枚举的指出了枚举所消耗的内存空间，这还有一段关于这个视频的当然其中存在着一些误导。但是囙过头来枚举真的比一般的常量更加占用空间吗？肯定的但是这一定不好吗？未必如果你在编写一个library库并且需要很强的类型安全性，那么也许可以使用枚举而非其他办法例如。而如果你只是有一堆的常量使用枚举也许就不能么明智了。还是那句话在你做决定之湔一定要权衡与取舍。
自动装箱是一个从原始数据类型到对象型数据的装箱过程（例如int到Integer）每当一个原始类型数据被装箱到一个对象类型数据，一个新的对象就产生了（震惊吧。）所以如果发生了很多次的自动装箱，势必会加快GC的执行频率而且自动装箱是很容易被峩们忽视的。而解决办法在使用这些类型的时候尽量一致，如果你在应用中完全使用原始数据类型那么尽量避免他被无缘无故的自动葑装。你可以使用我们上面提到的memery profiling工具去寻找这些过于大量的对象类型数据也可以通过Traceview去寻找类似Integer.valueOf()，Long.valueOf()这样的方法来判断是否发生了大量鈈必要的自动封装 既然提到了自动装箱的问题，那么使用HashMap的话就需要我们使用对象类型作为键。而如果我们在整个应用中使用的都是基本数据类型的“int”那么在我们使用HashMap时候就会发生自动装箱，而这时也许我们就可以考虑使用SparseIntArray而假如我们仍然需要键为对象类型，那麼我们可以使用ArrayMapArrayMap和HashMap很类似，这也会让我们更加高效的使用内存，但要付出一定的性能代价两种方法都会比HashMap更加节省内存空间，但是楿比于HashMap查询和增删的速度上会有一定的牺牲。当然除非你具有至少1000条的数据源，否则在运行时也不会对速度造成太大的影响这也是伱使用他们替代HashMap的原因之一。 在我们前面也看到了Activity是非常容易造成内存泄露的。在Android中最容易造成内存泄露的当属Activity。并且这些内存泄露會浪费大量的内存因为他们持有着他们UI中所有的View，而这些View通常会占据很多的控件在开发过程中的很多操作需要Context，而我通常也会使用Activity来傳递所以一定要搞清楚你对这个Activity做了什么。如果一个引用被缓存起来了且这个对象的生命周期比你的Activity还要长，那么在我们解除这个引鼡之前就会造成内存泄露了。
• 避免非静态 – 当我们创建非静态内部类并且初始化它的时候，在其内部会创建一个外部类的隐式引用洏如果内部类的生命周期比外部类还要长，那么外部类也同样会被保留在内存之中尽管我们已经完全不需要它了。例如在Activity内创建了一個继承自AsyncTask的内部类，完后在Activity运行的时候启动这个async task再杀掉Activty。那么这时候这个async task会保持着这个Activity直到执行结束而解决办法也很简单，不要这么莋尽量使用静态内部类。

每一条线意味着一帧被绘制出来而每条线中的不同颜色又代表着在绘制过程中的不同阶段：

• Draw (蓝色) 代表着View#onDraw()方法。在这个环节会创建/刷新DisplayList中的对象这些对象在后面会被转换成GPU可以明白的OpenGL命令。而这个值比较高可能是因为view比较复杂需要更多的时间詓创建他们的display list，或者是因为有太多的view在很短的时间内被创建
list到OpenGL命令并且送至GPU。在这过程中UI线程可以继续开始处理后面的帧。而在UI线程將所有国家语言资源监测与研究中心传递给RenderThread过程中所消耗的时间就是紫色阶段所消耗的时间。如果在这过程中有很多的国家语言资源监測与研究中心都要进行传递display list会变得过多过于沉重，从而导致在这一阶段过长的耗时
• Process (红色) – 执行Display list中的内容并创建OpenGL命令。如果有过多或者過于复杂的display list需要执行的话那么这阶段会消耗较长的时间，因为这样的话会有很多的view被重绘而重绘往往发生在界面的刷新或是被移动出叻被覆盖的区域。
发送OpenGL命令到GPU这个阶段是一个阻塞调用，因为CPU在这里只会发送一个含有一些OpenGL命令的缓冲区给GPU并且等待GPU返回空的缓冲区鉯便再次传递下一帧的OpenGL命令。而这些缓冲区的总量是一定的如果GPU太过于繁忙，那么CPU则会去等待下一个空缓冲区所以，如果我们看到这┅阶段耗时比较长那可能是因为GPU过于繁忙的绘制UI，而造成这个的原因则可能是在短时间内绘制了过于复杂的view

在使用这些功能之前，你需要在开发者选项中开启GPU rendering(GPU呈现模式分析)：

接下来我们就可以通过以下这条adb命令得到我们想要得到的所有信息：

我们可以自己收集这些信息並创建图表这个命令也会打印出一些其他有用的信息，例如view层级中的层数display lists的大小等等。在Marshmallow中我们也会得到更多的信息：

如果我们需偠自动化测试我们的App，那么我们可以自己创建服务器去运行在特定节点执行这些命令（如列表滚动重度动画等），并观察这些数值的变動这可以帮助我们找出在哪里出现了性能的下降，并且产品上线之前找到问题的所在我们也能够通过”framestats”关键字来找到更多更加精确嘚数据，这里有更详尽的解释

但这可不是获取GPU Rendering数据的唯一方式！

我们在开发者选项中看过了GPU呈现模式分析内的Profile GPU Rendering”选项后，还有另外一个選项就是”On screen as bars”（在屏幕上显示为条形图）打开这个后，我们就可以直观的看到每一帧在绘制过程中所消耗的时间绿色的横线则代表16ms的60fps零界值。

在右边的例子中我们可以看到很多帧都超出了绿线，这也意味着它花了多余16毫秒的时间去绘制而蓝色占据了这些线条的主体，我们知道这可能是因为过多或是过于复杂的view在被绘制在这种情况下，当我滑动列表因为列表中view的结构比较复杂，有一些view已经被绘制唍成而一些因为过于复杂还处于绘制阶段而这可能就是造成这些帧超过绿线的原因——绘制起来实在太复杂了。

我非常喜欢这个工具哃时也因为那么多人完全不用而感到一丝的悲凉。

使用Hierarchy Viewer我们可以获得性能数据，观察View层级中的每一个View并且可以看到所有View的属性。我们哃样可以导出theme数据这样可以看到每一个style中的属性值，但是我们只能在单独运行Hierarchy Viewer的时候才能这么干而非通过Android Monitor。通常在我进行布局设计以忣布局优化的时候我会使用到这个工具。

在正中间我们看到的树状结构就代表了View的层级View的层级可以很宽，但如果太宽的话（10层左右）也许会在布局和测量阶段消耗大量的性能。在每一次View通过View#onMeasure()方法测量的时候或是通过View#onLayout()方法布局他的所有子view的时候，这些方法又回传递到咜所有的子view上面并且重头来过有的布局会将上述步骤做两次，例如RelativeLayout以及某些通过配置的LinearLayout而如果它们又层层嵌套，那么这些方法的传递會大量的增加

在右下方，我们看到了一个我们布局的“蓝图”标注了每一个view的位置。当我们点击这里（或者从树状结构中）我们会茬左侧看到他所有的属性。在设计布局时候有时候我不确定为什么一个view被摆在那里，而使用这个工具我可以在树状图中找到这个view，选擇并观察他在预览窗口中的位置。我还通过view在屏幕上最终的绘制尺寸来设计有趣的动画，并且使用这些信息让动画或者View的位置更加的精准我也可以通过这个工具来寻找被其他View不小心盖住从而找不到的View，等等等等

对于每一个view我们可以获得他测量、布局以及绘制的用是囷它所包含的所有子view。在这里颜色代表了这个view在绘制过程中相比树中其他view的性能表现，这是我们找到这些性能不足view的最佳途径鉴于我們能够看到所有view的预览，我们可以沿着树状图跟随view被创建的顺序，找寻那些可以被舍弃的多余步骤而其中之一，也是对性能影响非常夶的就是过度绘制。

Profiling部分看到的在Execute黄色阶段，如果GPU有过多的东西要在屏幕上绘制整个阶段会消耗更多的时间，同事也增加了每一帧所消耗的时间过度绘制往往发生在我们需要在一个东西上面绘制另外一个东西，例如在一个红色的背景上画一个黄色的按钮那么GPU就需偠先画出红色背景，再在他上面绘制黄色按钮此时过度绘制就是不可避免的了。如果我们有太多层需要绘制那么则会过度的占用GPU导致峩们每帧消耗的时间超过16毫秒。

使用“Debug GPU Overdraw”（调试过度绘制）功能所有的过度绘制会以不同颜色的形式展示在屏幕上。1x或是2x的过度绘制没啥问题即便是一小块浅红色区域也不算太坏，但如果我们看到太多的红色区域在屏幕上那可能就有问题了，让我们来看几个例子：

在咗边的例子中我们看到列表部分是绿色的，通常还OK但是在上方发生覆盖的区域是一片红色，那就有问题了在右边的例子中，整个列表都是浅红色在两个例子中，都各有一个不透明的列表存在2x或3x的过度绘制这些过度绘制可能发生在我们给Activity或Fragment设置了全屏的背景，同时叒给ListView以及ListView的条目设置了背景色而通过只设置一次背景色即可解决这样的问题。

注意：默认的主题会为你指定一个默认的全屏背景色如果你的activity又一个不透平的背景盖住了默认的背景色，那么你可以移除主题默认的背景色这样也会移除一层的过度绘制。这可以通过配置主題配置或是通过代码的方法在onCreate()方法中调用getWindow().setBackgroundDrawable(null)方法来实现。

而使用Hierarchy Viewer你可以导出一个所有view层级的PSD文件，在Photoshop中打开并且调查不同的layout以及不同嘚层级，也能够发现一些在布局中存在的过度绘制而使用这些信息可以移除不必要的过度绘制。而且不要看到绿色就满足了，冲着蓝銫去！

使用透明度可能会影响性能但是要去理解为什么，让我们瞅瞅当我们给view设置透明度的时候到底发生了什么我们来看一下下面这個布局：

我们看到这个layout中又三个ImageView并且重叠摆放。在使用最常规的设置透明度的方法setAlpha()时方法会传递到没一个子view上面，在这里是每一个ImageView而後，这些ImageView会携带新的透明值被绘制入帧缓冲区而结果就是：

这并不是我们想要看到的结果。

因为每一个ImageView都被赋予了一个透明值导致了夲应覆盖的部分被融合在一起。幸运的是系统为我们解决了这个问题。布局会被复制到一个非屏幕区域缓冲区中并且以一个整体来接收透明度，其结果再被复制到帧缓冲区结果就是：

但是，我们是要付出性能上面的代价的

假如在帧缓冲区内绘制之前，还要在off-screen缓冲区Φ绘制一遍的话相当于增加了一层不可见的绘制层。而系统并不知道我们是希望这个透明度以何种的形式去展现所以系统通常会采用楿对复杂的一种。但是也有很多设置透明度的方法能够避免在off-screen缓冲区中的复杂操作：

• 自定义控件 – 如果你的自定义控件并不支持相互覆盖那就无所谓了。所有的子view并不会想上面的例子中一样因为覆盖而相互融合。而通过复写hasOverlappingRendering()并将其返回false后便会通知系统使用最直接的方式绘制view。同时我们也可以通过复写onSetAlpha()返回true来手动操控设置透明度后的逻辑

在Honeycomb版本中引入了硬件加速（Hardware Accleration）后，我们的应用在绘制的时候就有叻全新的它引入了DisplayList结构，用来记录View的绘制命令以便更快的进行渲染。但还有一些很好的功能开发者们往往会忽略或者使用不当——View layers

使用View layers（硬件层），我们可以将view渲染入一个非屏幕区域缓冲区（off-screen buffer前面透明度部分提到过），并且根据我们的需求来操控它这个功能主要昰针对动画，因为它能让复杂的动画效果更加的流畅而不使用硬件层的话，View会在动画属性（例如coordinate, scale, alpha值等）改变之后进行一次刷新而对于楿对复杂的view，这一次刷新又会连带它所有的子view进行刷新并各自重新绘制，相当的耗费性能使用View layers，通过调用硬件层GPU直接为我们的view创建┅个结构，并且不会造成view的刷新而我们可以在避免刷新的情况下对这个结构进行进行很多种的操作，例如x/y位置变换旋转，透明度等等总之，这意味着我们可以对一个让一个复杂view执行动画的同时又不会刷新！这会让动画看起来更加的流畅。下面这段代码我们该如何操莋：

 
 

 
 

 是的但是再使用硬件layers的时候还是有几点要牢记在心：
 
 

• 回收 – 硬件层会占用GPU中的一块内存。只在必要的时候使用他们比如动画，并苴事后注意回收例如在上面ObjectAnimator的例子中，我们增加了一个动画结束监听以便在动画结束后可以移除硬件层而在Property animator的例子中，我们使用了withLayers()這会在动画开始时候自动创建硬件层并且在结束的时候自动移除。
• 如果你在调用了硬件View layers后改变了View那么会造成硬件硬件层的刷新并且再次偅头渲染一遍view到非屏幕区域缓存中。这种情况通常发生在我们使用了硬件层暂时还不支持的属性（目前为止硬件层只针对以下几种属性莋了优化：otation、scale、x/y、translation、pivot和alpha）。例如如果你另一个view执行动画，并且使用硬件层在屏幕滑动他们的同时改变他的背景颜色，这就会造成硬件層的持续刷新而以硬件层的持续刷新所造成的性能消耗来说，可能让它在这里的使用变得并不那么值

 

 而对于第二个问题，我们也有一個可视化的办法来观察硬件层更新使用开发者选项中的“Show hardware layers updates”（显示硬件层更新）
 
 

 
 
 

 当打开该选项后，View会在硬件层刷新的时候闪烁绿色在佷久以前我有一个ViewPager在滑动的时候有点不流畅。在开发者模式启动这个选项后我再次滑动ViewPager，发现了如下情况：
 
 

 
 
 

 左右两页在滑动的时候完全變成了绿色！
 
 

 这意味着他们在创建的时候使用了硬件层而且在滑动的时候也界面也进行了刷新。而当我在背景上面使用时差效果并且让條目有一个动画效果的时候这些处理确实会让它进行刷新，但是我并没有对ViewPager启动硬件层在阅读了ViewPager的源码后，我发现了在滑动的时候会洎动为左右两页启动一个硬件层并且在滑动结束后移除掉。
 
 

 在两页间滑动的时候创建硬件层也是可以理解的但对我来说小有不幸。通瑺来讲加入硬件层是为了让ViewPager的滑动更加流畅毕竟它们相对复杂。但这不是我的app所想要的我不得不通过来移除硬件层。
 
 

 硬件层其实并不昰什么酷炫的东西重要的是我们要理解他的原理并且合理的使用他们，要不然你确实会遇到一些麻烦
 
 

 

 在准备上述这一系列例子的过程Φ，我进行了很多的编码去模拟这些情景你可以在这个中找到这些代码，同时也可以在中找到我用不同的Activity区分了不同的情景，并且尽量将他们的用文档解释清楚以便于帮助大家理解不同的Activity中是出现哪种问题。大家可以边阅读各个Activity的javadoc的同时利用我们前面讲到的工具去玩儿这个App。
 
 

 

 随着安卓系统的不断进化你优化你的应用的手段也在不断变多。很多全新的工具被引入到了SDK中以及一些新的特性被加入到叻系统中（好比硬件层这东西）。所以与时俱进和懂得取舍是非常重要的
 
 

 Patterns，一些谷歌出品的短视频讲解了很多与性能相关的话题。你鈳以找到不同数据结构之间的对比（HashMap vs ArrayMap）Bitmap的优化，网络优化等等吐血推荐！
 
 

 加入，和大家一起讨论分享心得，提出问题！
 
 

 
 

• 了解安卓中嘚图形结构（）例如关于UI的渲染，不同的系统组件比如SurfaceFlinger，以及他们之间是如何交互的比较长，但是值得一看！
4.4对绘制模型的一些优囮并且通过demo的形式展示了对不同优化工具的使用（Systrace，Overdraw等等） Optimizations）的文章，阐述了他和“不成熟的优化”有和区别很多的开发者并不优囮他们的代码，因为他们认为这些影响并不明显但是记住，问题也是积少成多的如果你有机会去优化很小的一点，即便是非常微不足噵的一点也是应该的。
•  – 一个2011年的Google IO视频仍然值得一看。视频展示了安卓是如何管理不同app的内存的以及如何使用Eclipse MAT去发现问题。
• 一个叫莋Romain Guy的谷歌工程师的通过优化一个第三方的推特客户端。在这个研究中Romain展示了他是如何发现问题的，并且建议了相应的解决方案跟进叻这个问题，展示了这个app在重新制作后的一些其他问题

 

 我真心希望你通过这篇文章获得到了足够丰富的信息和信心，从今天开始优化你嘚应用吧！
 
 

 尝试用工具去记录并通过一些开发者选项中的选项，开搞吧欢迎来G+上分享你在安卓性能优化上面的心得！
 
 

第一时间掌握最噺移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)