理解Android硬件加速原理的小白文

硬件加速，直观上说就是依赖GPU实现图形绘制加速，软硬件加速的区别主要是图形的绘制究竟是GPU来处理还是CPU，如果是GPU，就认为是硬件加速绘制，反之，软件绘制。在Android中也是如此，不过相对于普通的软件绘制，硬件加速还做了其他方面优化，不仅仅限定在绘制方面，绘制之前，在如何构建绘制区域上，硬件加速也做出了很大优化，因此硬件加速特性可以从下面两部分来分析：

1、前期策略：如何构建需要绘制的区域本文地址

2、后期绘制：单独渲染线程，依赖GPU进行绘制

无论是软件绘制还是硬件加速，绘制内存的分配都是类似的，都是需要请求SurfaceFlinger服务分配一块内存，只不过硬件加速有可能从FrameBuffer硬件缓冲区直接分配内存（SurfaceFlinger一直这么干的），两者的绘制都是在APP端，绘制完成之后同样需要通知SurfaceFlinger进行合成，在这个流程上没有任何区别，真正的区别在于在APP端如何完成UI数据绘制，本文就直观的了解下两者的区别，会涉及部分源码，但不求甚解。

软硬件加速的分歧点

大概从Android 4.+开始，默认情况下都是支持跟开启了硬件加速的，也存在手机支持硬件加速，但是部分API不支持硬件加速的情况，如果使用了这些API，就需要主关闭硬件加速，或者在View层，或者在Activity层，比如Canvas的clipPath等。但是，View的绘制是软件加速实现的还是硬件加速实现的，一般在开发的时候并不可见，那图形绘制的时候，软硬件的分歧点究竟在哪呢？举个例子，有个View需要重绘，一般会调用View的invalidate，触发重绘，跟着这条线走，去查一下分歧点。

视图重绘

从上面的调用流程可以看出，视图重绘最后会进入ViewRootImpl的draw，这里有个判断点是软硬件加速的分歧点,简化后如下

ViewRootImpl.java

private void draw(boolean fullRedrawNeeded) {

    ...

    if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {

        <!--关键点1 是否开启硬件加速-->

        if (mAttachInfo.m