4.2.Android 硬件加速补充

逆水行舟用力撑,一篙松劲退千寻。这篇文章主要讲述4.2.Android 硬件加速补充相关的知识,希望能为你提供帮助。
具体源码分析在之后上传,因为涉及的东西特别多
 
参考https://hencoder.com/ui-1-8/
https://blog.csdn.net/OneDeveloper/article/details/79791302
https://www.jianshu.com/p/f1feafffc365
 
概念 在正式开始之前需要说明一下,作为绘制部分的最后一期,本期内容只是为了内容的完整性做一个补充,因为之前好几期的内容里都有涉及硬件加速的技术点,而一些读者因为不了解硬件加速而产生了一些疑问。所以仅仅从难度上来讲,这期的内容并不难,并且本期的大部分内容你都可以从这两个页面中找到:

  • Hardware Acceleration | Android Developers
https://developer.android.google.cn/guide/topics/graphics/hardware-accel.html
 
  • Google I/O 2011: Accelerated Android Rendering
https://www.youtube.com/watch?v=v9S5EO7CLjo
 
下面进入正题。
所谓硬件加速,指的是把某些计算工作交给专门的硬件来做,而不是和普通的计算工作一样交给 CPU 来处理。这样不仅减轻了 CPU 的压力,而且由于有了「专人」的处理,这份计算工作的速度也被加快了。这就是「硬件加速」。
而对于 Android 来说,硬件加速有它专属的意思:在 Android 里,硬件加速专指把 View 中绘制的计算工作交给 GPU 来处理。
进一步地再明确一下,这个「绘制的计算工作」指的就是把绘制方法中的那些  Canvas.drawXXX()  变成实际的像素这件事。
原理在硬件加速关闭的时候,Canvas  绘制的工作方式是:把要绘制的内容写进一个  Bitmap,然后在之后的渲染过程中,这个  Bitmap  的像素内容被直接用于渲染到屏幕。这种绘制方式的主要计算工作在于把绘制操作转换为像素的过程(例如由一句  Canvas.drawCircle()  来获得一个具体的圆的像素信息),这个过程的计算是由 CPU 来完成的。大致就像这样:
4.2.Android 硬件加速补充

文章图片

 
而在硬件加速开启时,Canvas  的工作方式改变了:它只是把绘制的内容转换为 GPU 的操作保存了下来,然后就把它交给 GPU,最终由 GPU 来完成实际的显示工作。大致是这样:
4.2.Android 硬件加速补充

文章图片

如图,在硬件加速开启时,CPU 做的事只是把绘制工作转换成 GPU 的操作,这个工作量相对来说是非常小的。
 
怎么就「加速」了?从上面的图中可以看出,硬件加速开启后,绘制的计算工作由 CPU 转交给了 GPU。不过这怎么就能起到「加速」作用,让绘制变快了呢?
硬件加速能够让绘制变快,主要有三个原因:
  1. 本来由 CPU 自己来做的事,分摊给了 GPU 一部分,自然可以提高效率;
  2. 相对于 CPU 来说,GPU 自身的设计本来就对于很多常见类型内容的计算(例如简单的圆形、简单的方形)具有优势;
  3. 由于绘制流程的不同,硬件加速在界面内容发生重绘的时候绘制流程可以得到优化,避免了一些重复操作,从而大幅提升绘制效率。
其中前两点可以总结为一句:用了 GPU,绘制就是快。原因很直观,不再多说。
 
关于第三点,它的原理我大致说一下:
  • 在硬件加速关闭时,绘制内容会被 CPU 转换成实际的像素,然后直接渲染到屏幕。具体来说,这个「实际的像素」,它是由 Bitmap来承载的(在硬件加速关闭的时候,Canvas 绘制的工作方式是:把要绘制的内容写进一个 Bitmap,然后在之后的渲染过程中,这个 Bitmap 的像素内容被直接用于渲染到屏幕)。在界面中的某个 View 由于内容发生改变而调用 invalidate() 方法时,如果没有开启硬件加速,那么为了正确计算 Bitmap 的像素,这个View的父 View、父View 的父View 乃至一直向上直到最顶级 View,以及所有和它相交的兄弟 View,都需要被调用 invalidate()来重绘。一个 View 的改变使得大半个界面甚至整个界面都重绘一遍,这个工作量是非常大的。
 
  • 而在硬件加速开启时,绘制的内容会被转换成 GPU 的操作保存下来(承载的形式称为 display list,对应的类也叫做 DisplayList),再转交给 GPU。由于所有的绘制内容都没有变成最终的像素,所以它们之间是相互独立的,那么在界面内容发生改变的时候,只要把发生了改变的 View 调用 invalidate() 方法以更新它所对应的 GPU 操作就好,至于它的父 View 和兄弟 View,只需要保持原样。那么这个工作量就很小了。
 
正是由于上面的原因,硬件加速不仅是由于 GPU 的引入而提高了绘制效率,还由于绘制机制的改变,而极大地提高了界面内容改变时的刷新效率。
 
这里有个点需要注意,不管有没有硬件加速,在屏幕上绘制 UI 的时候,还是需要重新绘制整个屏幕的内容,而不是单单绘制发生变化的内容部分,之所以加速,是因为有了 Display List 把相关的操作缓存下来,而不用每次再去重复操作了。
 
所以把上面的三条压缩总结一下,硬件加速更快的原因有两条:
  • 用了 GPU,绘制变快了;
  • 绘制机制的改变,导致界面内容改变时的刷新效率极大提高。
layer type在之前几期的内容里我提到过几次,如果你的绘制操作不支持硬件加速,你需要手动关闭硬件加速来绘制界面,关闭的方式是通过这行代码:
view.setLayerType(LAYER_TYPE_SOFTWARE, null);

 
硬件加速可以使用  setLayerType()  来关闭硬件加速,但这个方法其实是用来设置 View Layer 的:
  1. 参数为  LAYER_TYPE_SOFTWARE  时,使用软件来绘制 View Layer,绘制到一个 Bitmap,并顺便关闭硬件加速;
  2. 参数为  LAYER_TYPE_HARDWARE  时,使用 GPU 来绘制 View Layer,绘制到一个 OpenGL texture(如果硬件加速关闭,那么行为和  VIEW_TYPE_SOFTWARE  一致);
  3. 参数为  LAYER_TYPE_NONE  时,关闭 View Layer。
 
View Layer 可以加速无  invalidate()  时的刷新效率,但对于需要调用  invalidate()  的刷新无法加速。
View Layer 绘制所消耗的实际时间是比不使用 View Layer 时要高的,所以要慎重使用。
 
有不少人都有过疑问:什么是 layer type?如果这个方法是硬件加速的开关,那么它的参数为什么不是一个  LAYER_TYPE_SOFTWARE  来关闭硬件加速以及一个  LAYER_TYPE_HARDWARE  来打开硬件加速这么两个参数,而是三个参数,在  SOFTWARE  和  HARDWARE  之外还有一个  LAYER_TYPE_NONE?难道还能既不用软件绘制,也不用硬件绘制吗?
事实上,这个方法的本来作用并不是用来开关硬件加速的,只是当它的参数为  LAYER_TYPE_SOFTWARE  的时候,可以「顺便」把硬件加速关掉而已;并且除了这个方法之外,Android 并没有提供专门的 View 级别的硬件加速开关,所以它就「顺便」成了一个开关硬件加速的方法。
 
View Layer 是 View Layer,硬件加速是硬件加速,两者是两个概念,但是两者存在着交叉的地方。
所谓 View Layer,又称为离屏缓冲(Off-screen Buffer),它的作用是单独启用一块地方来绘制这个 View ,而不是使用软件绘制的 Bitmap 或者通过硬件加速的 GPU。这块「地方」可能是一块单独的  Bitmap,也可能是一块 OpenGL 的纹理(texture,OpenGL 的纹理可以简单理解为图像的意思),具体取决于硬件加速是否开启。
 
使用 setLayerType() 方法有什么好处呢,那就是在设置了 View Layer 之后,可以在原基础上(如果没有开启硬件加速,则在没有开启的基础上;如果开启了硬件加速,则在开启了的基础上),更进一步的将 View 的重绘效率提高。
 
采用什么来绘制 View 不是关键,关键在于当设置了 View Layer 的时候(非 NONE ),它的绘制会被缓存下来,就是使用了 Off-screen buffers,而且缓存的是最终的绘制结果,不是像硬件加速那样只是把 GPU 的操作保存下来再交给 GPU 去计算,因为在硬件加速开启时,需要绘制的内容会被转换成 GPU 的操作保存下来,承载的形式称为 display list,对应的类也叫做 DisplayList,再转交给 GPU,但是所有的绘制内容都没有变成最终的像素,因此每次绘制的时候,还是需要将 DisplayList 中保存的内容转换为最终的像素。
通过这样更进一步的缓存方式,View 的重绘效率进一步提高了:只要绘制的内容没有变,那么不论是 CPU 绘制(基于软件绘制模型)还是 GPU 绘制(硬件加速模型),它们都不用重新计算,而只要使用用之前缓存的绘制结果就可以了。
 
基于这样的原理,在进行移动、旋转等(无需调用  invalidate())的属性动画的时候开启 Hardware Layer 将会极大地提升动画的效率,因为在动画过程中 View 本身并没有发生改变,只是它的位置或角度改变了,而这种改变是可以由 GPU 通过简单计算就完成的,并不需要重绘整个 View。所以在这种动画的过程中开启 Hardware Layer,可以让本来就依靠硬件加速而变流畅了的动画变得更加流畅。实现方式大概是这样:
view.setLayerType(LAYER_TYPE_HARDWARE, null); ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180); animator.addListener(new AnimatorListenerAdapter() { @Override public void onAnimationEnd(Animator animation) { view.setLayerType(LAYER_TYPE_NONE, null); } }); animator.start();

 
或者如果是使用  ViewPropertyAnimator,那么更简单:
view.animate() .rotationY(90) .withLayer(); // withLayer() 可以自动完成上面这段代码的复杂操作

 
不过,一定要注意,只有你在对  translationX  translationY  rotation  alpha  等无需调用  invalidate()  的属性做动画的时候,这种方法才适用,因为这种方法本身利用的就是当界面不发生时,缓存未更新所带来的时间的节省。
所以简单地说——这种方式不适用于基于自定义属性绘制的动画。一定记得这句话。
 
另外,由于设置了 View Layer 后,View 在初次绘制时以及每次  invalidate()  后重绘时,需要进行两次的绘制工作(一次绘制到 Layer,一次从 Layer 绘制到显示屏),所以其实它的每次绘制的效率是被降低了的。所以一定要慎重使用 View Layer,在需要用到它的时候再去使用。
 
另外,除了用于关闭硬件加速和辅助属性动画这两项功能外,Layer 还可以用于给 View 增加一些绘制效果,例如设置一个  ColorMatrixColorFilter  来让 View 变成黑白的:
ColorMatrix colorMatrix = new ColorMatrix(); colorMatrix.setSaturation(0); Paint paint = new Paint(); paint.setColorFilter(new ColorMatrixColorFilter(colorMatrix)); view.setLayerType(LAYER_TYPE_HARDWARE, paint);

   
window硬件加速的开启和layer type的关系
  • canvas.savelayer不管是否开启了硬件加速,layer type设置如何,都可以创建一个bitmap,即离屏缓存。
 
  • 如果window硬件加速没有开启,
LAYER_TYPE_NONE,就表示不会创建drawing cache,不管是否invalidate,都会把view的绘制代码从头到尾执行一遍。
LAYER_TYPE_HARDWARE,和  LAYER_TYPE_SOFTWARE一样。
LAYER_TYPE_SOFTWARE,会创建drawing cache(buildDrawingCache),把绘制操作绘制到bitmap,
 
  • 如果window硬件加速开启
LAYER_TYPE_NONE,就表示不会创建hardware layer,就是硬件加速的绘制流程
LAYER_TYPE_HARDWARE,会绘制到一个hardware layer上,类似于bitmap,所以只要 除了那些不会调用invalidate的属性,其他属性修改后就会重绘。
LAYER_TYPE_SOFTWARE,会创建drawing cache(buildDrawingCache),把绘制操作绘制到bitmap
   
使用注意对所有的缓存来讲,都有一个缓存失效的可能性。任何时候如果在动画过程中调用view.invalidate(),那么layer就必须要重新渲染。经常的废弃hardware layers会比没有layers的情况下更糟糕,因为如同上面讲到的hardware layers在设置缓存时会有额外的开销。如果你需要经常的重新缓存layer,那就会有极大的损害。
这个问题也是非常容易出现的,因为动画经常有多个移动的部分。假如现在有一个三个部分移动的动画:
Parent ViewGroup—-> Child View1 (往左移动)—-> Child View2 (往右移动)—-> Child View3 (往上移动)

 
如果你只在父布局ViewGroup上设置一个layer,那就将经常的缓存失效,因为ViewGroup会随着子View不断地改变。然而对每个单独的子Views而言,他们只是在位移。这种情况下,最好是对每个子View上设置Hardware Layer(而不是在父布局上)。
再次重申,通常是对多个子View上适当的设置Hardware Layer,这样他们就不会在动画运行时失效。
 
几种layer type的性能表现
  1. 如果只是单纯的做动画,不动态修改 View 的内容,那么性能表现为 :Hardware Layer > = Software Layer > Normal Layer
  2. 如果做动画同时动态修改 View 的内容,那么性能表现为 :Normal Layer > Software Layer = Hardware Layer
  3. Hardware Layer 对动画性能确实有很大的提升,但是如果你用不好,那么还不如不用
  4. 如果通过 Systrace 发现你做动画的时候每一帧都在 buildDrawingCache/SW(主线程) 或者 buildLayer(渲染线程),那么请查看你的代码的逻辑
  5. 有些情况下是由于系统的原因,比如图片比 Cache 大,invalidate 逻辑问题,可以联系手机厂商进行一起修改
 
问题 如果子view是LAYER_TYPE_SOFTWARE,而父view不管是软硬件,在调用了setAlpah/setTranslationX后会怎么样?子view不会重绘,也就是不会重建drawingCache,
但其父view会重建displayList,或重绘
 
如果子view硬件加速,父view会怎么样,在调用了setAlpah/setTranslationX后?首先,如果子view是硬件加速,那么父view必然也是硬件加速,因为不能在软件绘制上绘制硬件图层,
子view及其父view都不会重建displaylist,虽然向上通知了各级父view,但这么做是为了把修改的属性同步给gpu。
  【4.2.Android 硬件加速补充】 

    推荐阅读