Google I/O 2011, Android Accelerated Rendering
Google I/O上关于的Android 3.0 Honeycomb 硬件加速绘图的介绍:
PPT:http://www.slideshare.net/romainguy/google-io-2011-android-accelerated-rendering
YouTube:http://www.youtube.com/watch?v=v9S5EO7CLjo
主要内容介绍(因为没有字幕,部分听不清楚的地方只能靠自己的猜测,可能有错误的地方):
- 在Honeycomb之前,使用到GPU的地方包括OpenGL(直接使用NDK或者Java的Wrapper),Live Wallpaper(内部使用Render Script,其实也是间接使用OpenGL,但是相关API直到Honeycomb才开放),Window Compositing(窗口混合,也就说把多个窗口的Surface进行Alpha混合输出到屏幕的Surface上面);但是最常见的UI组件的绘制,使用的2D绘图引擎Skia是没有使用GPU加速的。
- 在Honeycomb上面,UI组件的绘制,也就是Canvas API,使用了OpenGLRenderer作为Backend,从而利用GPU进行加速。(在这里不太清楚是Skia内部支持OpenGL作为Backend,还是使用新的2D绘图引擎取代Skia,个人猜测应该是前者)
- 因为OpenGL实际上只支持多边形绘制和贴图,所以利用OpenGL做2D绘图,实际上是在内部生成一个多边形构成的平面,然后把背景图,前景图,线段,文字生成的位图贴在上面。
- 要使App支持硬件加速,需要在Mainifest中进行设置,可以分别对App,Activity,Window,View这几个级别单独进行设置,不过不支持在关闭整个Window硬件加速的情况下开启其中的View的硬件加速,只支持相反的情况,可以在开启整个Window硬件加速的情况下关闭其中部分View的硬件加速。View和Canvas支持运行时查询是否支持硬件加速。
- 不是所有的Canvas API都支持硬件加速,部分比较不常用的API是没有硬件加速支持的。
- 新的UI组件渲染模型引入了DisplayList来减少一个View被invalidate时所需要的重绘操作。
- 使用Layer(内部位图缓存)可以加速部分绘图操作,当这些绘图不是因为本身的内容更新引起的,而是因为View被移动,旋转,透明度改变或者加入特效等引起的(也就说View本身的DisplayList没有被改变,而是View的Parent的DisplayList被改变)。
- 如果是Hardware Layer,它实际是分配在显存的Texture,GPU重绘一个Texture的速度非常的快,但是Layer的使用可能造成内存的过度使用和在View本身更新的情况下反而绘制较慢(等于先绘制到缓存然后再拷贝缓存),演示了一个例子当对一个View进行动画时才开启Layer,动画结束后关闭。
- Tips and Tricks:
- 减少View的层次,尽量使组件树扁平化
- setAlpha操作的成本很高
- 尽量重用Paint,Bitmap对象
- 不要频繁改变Bitmap对象
- 不要频繁改变Path对象
- 避免不必要的绘制
- 使用DDMS和Traceview做Profiling
回复