Android卡顿原理分析和SurfaceFlinger,Surface概念简述

本篇仅是简述,还在学习中,后续会慢慢完善。

Android 卡顿原理

Android早期相较于IOS卡顿较为严重,从4.4开始,特别是5.0版本以后,由于各方面的优化(系统的和CPU,GPU,内存的),系统的流畅程度已经有了很大提升。
其中Vsync的持续改进起到了一定的作用,Vsync称为垂直同步主要是为了解决显卡生成帧的速度和屏幕(显示系统的一种)刷新的频率不一致,也就是CPU,GPU处理准备画面的频率和Display设备刷新频率(一般是16ms)不一致的问题,有了Vsync可以让显示器输出稳定正确的画面。
如果 CPU、GPU 处理,生成帧的速度和 Display 刷新的速度不一致,在不使用vsync的情况下会出现屏幕正在刷新第二帧图像,但是显卡已经更新了第三帧图像,这时反映到屏幕上就会产生一部分是第二帧的图像,一部分是第三帧的图像(画面撕裂(screentearing))。有了vsync机制,每次屏幕刷新时通过Vsync通知更新帧,这样显示的画面就不会出现上面的问题。Vsync可以由硬件或者软件生成。

Display 是Android 对输出显示设备的一个抽象,一般指手机显示器,在Andrid 4.1 后优化SurfaceFlinger,支持更多外部输入设备,比如HDMI, Wifi Display 等等。Display的输入是过滤后的所有Window的Surface, 输出是和显示设备尺寸相同的Buffer, 这个Buffer 最终送到了硬件的FB设备,或者HDMI设备,或者远处的Wifi Display Sink设备进行显示。输入到输出这条路径上有SurfaceFlinger, OpenGL 和 HWComposer。

不使用Vsync:
Android卡顿原理分析和SurfaceFlinger,Surface概念简述_第1张图片
display展示第0帧的时候,GPU或者CPU准备第1帧显示的图片,第0帧结束时VSync信号到来,CPU或者GPU应该开始准备第2帧,但由于某些原因没有在Vsync处开始准备第二帧图像,Display再次展示时只能显示前一帧图像,反映到界面上会给用户卡顿的印象。

使用vsync:
Android卡顿原理分析和SurfaceFlinger,Surface概念简述_第2张图片

上面的图展示了使用Vsync时的正常情况,但是还有一种情况是cpu,gpu在vsync到来时开始工作,但是可能由于CPU或者gpu工作太繁重,导致cpu,gpu忙不过来,处理合成surface的时间会变长,也会导致不能按时处理完下一帧图片。
CPU,gpu忙不过来的情况:
Android卡顿原理分析和SurfaceFlinger,Surface概念简述_第3张图片
Display显示第0帧数据,CPU和GPU开始渲染第1帧画面,下一次Vsync到来之前完成了渲染,Display在第1个VSync后,正常显示第1帧;接着由于某些原因,cpu,gpu由于过忙没有及时地开始处理第2帧,VSync再次来时,由于第2帧数据还没有准备就绪,显示的还是第1帧,被Android开发组命名为“Jank”,当第2帧数据准备完成后,它并不会马上被显示,而是要等待下一个VSync。屏幕多显示了一次第1帧,如果频繁发生会导致卡顿。

为提高android的处理帧的效率,Android还提供了双缓冲,三缓冲方案:
Android卡顿原理分析和SurfaceFlinger,Surface概念简述_第4张图片
缓冲区是构建和存储帧的容器,Android的双缓冲模型中,一个缓存区显示1帧,而在另一个缓存区进行下一帧的处理。如上图缓冲器标记为“A”和“B”。当显示缓冲区A时,系统开始在缓冲区B中建立一个新帧,当准备好时,它们交换缓冲区,B被显示,并且A中的帧被清除并且处理新的帧。除此之外还有三缓冲结构等等,具体的我也没太研究所以还需要大家自己去看。

Android 系统每 16ms(更准确的是大概16.6ms) 就会发出一次 VSYNC信号触发ui更新。屏幕一秒大约刷新60次,所里处理合称一帧花费的时间在 16ms 内,画面会比较流畅。
如果在16ms内由于view的绘制逻辑过于复杂,就会导致本次绘制新内容不会成功,依然会显示上次绘制的内容,如果频繁发生16ms无法完成界面更新的问题,反映到软件影响是看着应用的界面会感觉卡顿。

SurfaceFlinger 简述

来自:http://www.cnblogs.com/samchen2009/p/3364327.html
SurfaceFlinger的作用主要是merge Surface,用于接受多个来源的图形显示数据,然后将他们合称发送到显示设备。

SurfaceFlinger 是一个独立的Service, 它接收所有Window的Surface作为输入,根据ZOrder, 透明度,大小,位置等参数,计算出每个Surface在最终合成图像中的位置,然后交由HWComposer或OpenGL生成最终的显示Buffer, 然后显示到特定的显示设备上。

在Android底层绘制系统中,SurfaceFlinger 为App进程创建具体的Surface, 在SurfaceFlinger里对应成Layer, 然后负责管理、合成显示。Layer是SurfaceFlinger 进行合成的基本操作单元。Layer是在应用请求创建Surface的时候在SurfaceFlinger内部创建,因此一个Surface对应一个 Layer, 但注意,Surface不一定对应于Window,Android中有些Surface并不跟某个Window相关,而是有程序直接创建,比如说 StrictMode, 一块红色的背景,用于提示示Java代码中的一些异常, 还有SurfaceView, 用于显示有硬件输出的视频内容等。

Surface 概述

Window在android不同地方有不同含义,这里主要讨论WindowManagerService中管理的Window。Window 是 Android 中窗口的宏观定义,主要是管理 View 的创建,以及与 ViewRootImpl 的交互,将 Activity 与 View 解耦。

看下图:
Android卡顿原理分析和SurfaceFlinger,Surface概念简述_第5张图片

Surface的创建由谁发起呢,App要显示自己的内容,会发起Surface创建请求,WindowManagerService, 负责接收APP请求,向SurfaceFlinger发起具体的请求创建Surface。Window与Surface一一对应。 Surface负责记录每个时刻Window的内容。在Android的SurfaceFlinger实现里,通常一个Surface有两块 Buffer, 一块用于绘画,一块用于显示,两个Buffer按照固定的频率进行交换,从而实现Window的动态刷新。

一个窗口界面包含多个View组成View hierachy的树形结构,只有最顶层的DecorView才对WMS可见,这个DecorView在WMS中有一个对应的WindowState,在SurfaceFlinger有对应的Layer。

Layer是SurfaceFlinger 进行合成的基本操作单元。Layer在应用请求创建Surface的时候在SurfaceFlinger内部创建,因此一个Surface对应一个 Layer, 但注意,Surface不一定对应于Window,Android中有些Surface并不跟某个Window相关,而是有程序直接创建,例如SurfaceView, 用于显示有硬件输出的视频内容等。

一个应用程序有多个窗口界面(Activity),可以包含多个Surface,每个window又对应一个Surface,Display每次显示的是多个Window融合后的效果。Surface内部对应一块屏幕缓冲区,窗口中所有的View共享一块缓冲区,所以窗口中的任何view最终都是绘制在Surface对应的buffer(屏幕缓冲区)上的。Android的View必须在主线程更新,是由于窗口中所有的View共享一块缓冲区,如果异步可更新,会造成数据的不同步。
Handle onto a raw buffer that is being managed by the screen compositor.
Surface持有一个被屏幕合成器管理的原始缓冲区,所以所有绘制的内容最终都会保存到这个缓冲区中。

Surface定义在ViewRootImpl中的成员,定义时已经实例化了:
final Surface mSurface = new Surface();
ViewRootImpl的个数与addView的调用次数相关,一个Activity可以多次调用addView, 也就是说一个Activity可以有多个Surface.
Surface 内部持有一个Canvas,可以利用这个Canvas绘制。

你可能感兴趣的:(Android音视频学习,Android,音视频处理学习专题)