SurfaceView 和TextureView是Android提供的支持异步线程渲染的控件,虽然都是异步渲染,但不论在使用方式上还是在底层实现原理上都是有差异的。
SurfaceView在内部是直接创建一个独立于当前Activity的Surface,此Surface默认处于Activity Surface的下面,然后在Activity上对应位置挖一个相应大小的透明窟窿,使下面的SurfaceView的内容能够展示出来。
而TextureView 的内容是正常渲染到当前Activity的Surface上的。其内部是基于SurfaceTexture实现的,当渲染侧渲染完成后,SurfaceTexture会将渲染内容以纹理的形式上传到GPU,接着由TextureView将纹理渲染到当前Activity的视图树中。
在使用上,SurfaceView 和TextureView 都提供了Canvas接口给应用侧进行异步渲染,但SurfaceView 可以由应用指定Canvas是否走硬件加速流程,而TextureView 提供的TextureView.lockCanvas()
和TextureView.lockCanvas(Rect dirty)
接口返回的Canvas都是非硬件加速的,因此渲染指令的执行完全是由CPU执行的,虽然是异步线程,但是在渲染复杂内容时,一方面单帧渲染耗时高导致渲染帧率低,另一方面会消耗大量CPU资源,导致应用整体卡顿以及设备发热、掉电等问题。
解决方案
使用方式和普通TextureView 接本一致,lockCanvas()
获取的Canvas在Android 28以上平台具有硬件加速能力。需要注意的是lockCanvas(Rect dirty)
方法不可用(直接返回null)。
内部实现是创建了一个Surface,作为图形生产者,消费者侧连接了TextureView 的SurfaceTexture,使用此Surface对外提供硬件加速接口。
渲染性能对比
测试工程: TextureViewPlayground - Github
测试设备: Google Pixel 7
绘制内容: 每一帧绘制相同的30笔不透明/半透明的stroke path 绘制结果:

统计内容:
- 每一帧的渲染时长(只统计所有drawPath方法的执行总耗时,不包含lockCanvas和unlockCanvasAndPost方法执行耗时):
- CPU使用率
统计结果:
TextureView | HwTextureView | |
---|---|---|
渲染时长 | 10ms | 1ms |
CPU | 13ms | 8ms |
TextureView测试数据


HwTextureView测试数据

