Android系统Surface机制的SurfaceFlinger服务的线程模型分析.pdfVIP

Android 系统Surface 机制的 SurfaceFlinger 服务的线程模型分析 在前面两篇文章中，我们分析了SurfaceFlinger 服务的启动过程以及SurfaceFlinger 服务初始 化硬件帧缓冲区的过程。从这两个过程可以知道，SurfaceFlinger 服务在启动的过程中，一 共涉及到了三种类型的线程，它们分别是Binder 线程、UI 渲染线程和控制台事件监控线程。 在本文中，我们就将详细分SurfaceFlinger 服务的线程模型，即上述三种类型的线程是如何 运行和交互的。 从 一文可以知道，SurfaceFlinger 服务是在 System 进程的主线程中启动的。 System 进程的主线程在启动系统的关键服务之前，会先启动一个Binder 线程池。这样运行 在 System 进程中的系统关系服务就可以与其它进程执行 Binder 进程间通信了。 SurfaceFlinger 服务虽然是由System 进程的主线程来负责启动的，但是最终它会运行在一个 独立的线程中。我们将这个独立的线程称为UI 渲染线程，因为它负责渲染系统的UI 。 从 一文可以知道，SurfaceFlinger 服务的UI 渲染线程的启动的时候，会对系统 的硬件帧缓冲区进行初始化。在初始化的过程，又会创建另外一个线程来监控硬件帧缓冲区 的睡眠/唤醒状态切换事件。为了方便描述，我们这个线程称称为控制台事件监控线程。 上述的三种类型的线程的启动顺序，可以通过图1 来描述，如下所示： 从图1 就可以清楚地看到，System 进程的主线程负责启动Binder 线程池，以及UI 渲染线程， 而UI 渲染线程又负责启动控制台事件监控线程。在这三种类型的线程中，UI 渲染线程是主 角，Binder 线程和控制台事件监控线程是配角。Binder 线程池是为了让其它进程，例如 Android 应用程序进程，可以与 SurfaceFlinger 服务进行Binder 进程间通信的，有一部分通 信所执行的操作便是让UI 渲染线程更新系统的UI 。控制台事件监控线程是为了监控硬件帧 缓冲区的睡眠/唤醒状态切换事件的。一旦硬件帧缓冲区要进入睡眠或者唤醒状态，控制台 事件监控线程都需要通知 UI 渲染线程，以便UI 渲染线程可以执行关闭或者启动显示屏的 操作。 1 接下来，为了弄清楚SurfaceFlinger 服务的线程模型，我们就首先简要分析UI 渲染 线程的运行模型，接着再分析Binder 线程与UI 渲染线程的交互过程，最后分析控制台事件 监控线程与UI 渲染线程的交互过程。 1. UI 渲染线程的运行模型 在前面 一文中提到，SurfaceFlinger 服务的UI 渲染线程有一个消息队列。当消 息队列为空时，SurfaceFlinger 服务的UI 渲染线程就会进入睡眠等待状态。一旦SurfaceFlinger 服务的 Binder 线程接收到其它进程发送过来的渲染UI 的请求时，它就会往SurfaceFlinger 服务的UI 渲染线程的消息队列中发送一个消息，以便可以将SurfaceFlinger 服务的UI 渲染 线程唤醒起来执行渲染的操作。同样，一旦SurfaceFlinger 服务的控制台事件监控线程发现 硬件帧缓冲区即将要进入睡眠或者唤醒状态时，它就会往SurfaceFlinger 服务的UI 渲染线程 的消息队列中发送一个消息，以便SurfaceFlinger 服务的UI 渲染线程可以执行冻结或者解冻 显示屏的操作。 从前面 一文又可以知道，SurfaceFlinger 服务的 UI 渲染线程是以 SurfaceFlinger 类的成员函数threadLoop 为线程执行体的，即 SurfaceFlinger 服务的UI 渲染线程会不断地 循环执行SurfaceFlinger 类的成员函数threadLoop 。接下来，我们就通过SurfaceFlinger 类的 成员函数threadLoop 的实现来分析SurfaceFlinger 服务的UI 渲染线程的运行模型，如下所 示： [cpp] view plain copy 在CODE 上查看代码片派生到我的代码片 bool Surf