1.硬件加速的使用

1.1 硬件加速的控制级别

     从Android3.0开始，Android 2D的绘制流程就设计为能够更好地支持硬件加速。使用GPU的View在Canvas上进行画的操作时都会使用硬件加速。

    启用硬件加速的最简单方法就是为整个系统打开硬件加速的全局设置。如果你的程序是标准View或者是Drawable 则硬件加速的全局设这并不会造成不良的影响。然而硬件加速并不支持所有2D画的操作，所以开启硬件加速可能会对使用自定义组件的应用程序造成影响，问题常常表现在不可见的元素异常和错误的像素渲染，为了解决这个问题Android可以让你选择启动或者禁用以下级别的硬件加速：Application  Activity Window 和 View 。

1. Application级别

在你的Android Manifest文件中添加 <application> 属性标记，以便为整个应用程序使用硬件加速。

<applicationandroid:hardwareAccelerated="true" …>

2. Activity级别

       如果你的应用程序不能在Application应用级别表现良好的话，则可以使用对Activity进行单独控制。要启动或者禁用一个Activity的硬件加速，你可以使用activity的android:hardwareAccelerated属性。下面的一个列子使整个Application启用硬件加速，但是对一个Activity禁止使用硬件加速。

<application android:hardwareAccelerated="true">   

 <activity …/>   <activity android:hardwareAccelerated="false" />

</application>

3. Window级别

    如果你需要更细粒度的控制，你可以通过如下代码给window进行加速。

getWindow().setFlags(   WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,   

WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

注意：现阶段你不能在Window级别对它禁用硬件加速。

4. View级别

        我们可以对单独的View在运行时阶段禁用硬件加速。我们可以使用如下代码：

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

注意：现阶段不能够在View级别进行硬件加速。

1.2 判断一个View是否已经启用了硬件加速

       有时候我们需要知道一个应用程序是否已经启用了硬件加速，特别是针对一些自定义控件。因为你的应用程序做了很多自定义“画”的操作，但并不是所有的过程都支持新的“画”的渲染过程。

有两种不同的方法来检查Application是否启用了硬件加速：

1. 使用View.isHardwareAccelerated() 如果返回true则可以说明这个View所在的窗口已经启用了硬件加速。

2. Canvas.isHardwareAccelerated() 如果返回true则说明这个Canvas已经启用了硬件加速。

        如果你必须要在你的绘画代码中进行是否已经加速的检查，如果可能的话请使用Canvas.isHardwareAccelerated()来代替View.isHardwareAccelerated()。当一个View是存在于一个已经加速的Window上时，任然可以使用没有硬件加速的Canvas进行绘画，这场发生在，比如，当我们把一个View画到Bitmap上然后用作缓存。

2.Android的绘制模型

当开启了硬件加速，Android框架将会使用一种新的绘制模型，这种模型将会使用显示列表把你的应用显示到屏幕上。要完全理解显示列表和他们如何影响你的应用程序，理解Android如何在非硬件加速的情况下如何绘制Views是很有必要的，下面将分别介绍软件加速和硬件加速。

2.1基于软件的绘制模型

在基于软件绘制模型中，View的绘制遵循以下两步：1.使整个控件层级无效。2.对层级进行绘制。

        当一个应用程序需要更新它UI的一部分时，它将会调用内容发生改变的View的invalidate()方法（或者invalidate的变体）。Invalidate的消息按照View的层级关系向上传递用以计算需要重画的部分（即脏区域）。然后Android系统会对和脏区域有交集的所有View进行绘制，不幸的是这种模型中有两个缺点：

       1. 在这种模型中当在不同的层进行画的时候，会额外执行很多代码。例如一个Button是位于另外一个View之上，当对Button调用 Invalidate()时，Android就会对这个View进行重绘，即便这个View没有发生任何变化。

        2. 第二个问题是这种绘制模型会隐藏你Application中的Bug。因为Android系统会对和脏区域有交集的View进行重绘，在这种情况下如果一个view的内容发生了改变，即便这个View的Invalidate()的方法并没有得到调用，它也可能被重绘。你便会依赖调用了invalidate()的其他的控件以便获得正确的行为，因此每当你的Application发生改变时，这种行为多要随之发生改变。也是基于次因，在你的自定义控件中你必须不断地调用invalidate()方法，当你的数据或者是状态会影响View的绘制代码时。

注意：Android的View当它们的属性发生改变时会自动的调用Invalidate()。比如，你改变一个 Textview的背景或者是它的文本。

2.2 基于硬件加速模型

       Android 系统仍然通过invalidate()和draw()去请求屏幕更新和重新渲染，但是实际处理画的方式是不同的。不是立即执行画的命令，Android而会将所有画的命令记录在一个显示列表里面，这个显示列表包含了输出的View层级的绘制代码。还有一个优化就是Android在显示列表中只会记录和更新显示层级中通过调用invalidate()函数被标记为“脏”的view。没有被请求刷新的view可以通过重新请求先前的显示列表以便重画。新的绘制模型包括有三个步骤：1.禁用整个View层级。2.记录和更新显示列表。3.绘制显示列表。