Android系统Surface机制的SurfaceFlinger服务的线程模型分析
在前面两篇文章中，我们分析了SurfaceFlinger服务的启动过程以及SurfaceFlinger服务初始化硬件帧缓冲区的过程。从这两个过程可以知道，SurfaceFlinger服务在启动的过程中，一共涉及到了三种类型的线程，它们分别是Binder线程、UI渲染线程和控制台事件监控线程。在本文中，我们就将详细分SurfaceFlinger服务的线程模型，即上述三种类型的线程是如何运行和交互的。
从Android系统Surface制的SurfaceFlinger服务的启动过程分析一文可以知道，SurfaceFlinger服务是在System进程的主线程中启动的。System进程的主线程在启动系统的关键服务之前，会先启动一个Binder线程池。这样运行在System进程中的系统关系服务就可以与其它进程执行Binder进程间通信了。SurfaceFlinger服务虽然是由System进程的主线程来负责启动的，但是最终它会运行在一个独立的线程中。我们将这个独立的线程称为UI渲染线程，因为它负责渲染系统的UI。
从Android系统Surface制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析一文可以知道，SurfaceFlinger服务的UI渲染线程的启动的时候，会对系统的硬件帧缓冲区进行初始化。在初始化的过程，又会创建另外一个线程来监控硬件帧缓冲区的睡眠/唤醒状态切换事件。为了方便描述，我们这个线程称称为控制台事件监控线程。
上述的三种类型的线程的启动顺序，可以通过图1来描述，如下所示：
图1 SurfaceFlinger服务的线程模型
从图1就可以清楚地看到，System进程的主线程负责启动Binder线程池，以及UI渲染线程，而UI渲染线程又负责启动控制台事件监控线程。在这三种类型的线程中，UI渲染线程是主角，Binder线程和控制台事件监控线程是配角。Binder线程池是为了让其它进程，例如Android应用程序进程，可以与SurfaceFlinger服务进行Binder进程间通信的，有一部分通信所执行的操作便是让UI渲染线程更新系统的UI。控制台事件监控线程是为了监控硬件帧缓冲区的睡眠/唤醒状态切换事件的。一旦硬件帧缓冲区要进入睡眠或者唤醒状态，控制台事件监控线程都需要通知UI渲染线程，以便UI渲染线程可以执行关闭或者启动显示屏的操作。
接下来，为了弄清楚SurfaceFlinger服务的线程模型，我们就首先简要分析UI渲染线程的运行模型，接着再分析Binder线程与UI渲染线程的交互过程，最后分析控制台事件监控线程与UI渲染线程的交互过程。
1. UI渲染线程的运行模型
在前面Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划一文中提到，SurfaceFlinger服务的UI渲染线程有一个消息队列。当消息队列为空时，SurfaceFlinger服务的UI渲染线程就会进入睡眠等待状态。一旦SurfaceFlinger服务的Binder线程接收到其它进程发送过来的渲染UI的请求时，它就会往SurfaceFlinger服务的UI渲染线程的消息队列中发送一个消息，以便可以将SurfaceFlinger服务的UI渲染线程唤醒起来执行渲染的操作。同样，一旦SurfaceFlinger服务的控制台事件监控线程发现硬件帧缓冲区即将要进入睡眠或者唤醒状态时，它就会往SurfaceFlinger服务的UI渲染线程的消息队列中发送一个消息，以便SurfaceFlinger服务的UI渲染线程可以执行冻结或者解冻显示屏的操作。
从前面Android系统Surface制的SurfaceFlinger服务的启动过程分析一文又可以知道，SurfaceFlinger服务的UI渲染线程是以SurfaceFlinger类的成员函数threadLoop为线程执行体的，即SurfaceFlinger服务的UI渲染线程会不断地循环执行SurfaceFlinger类的成员函数threadLoop。接下来，我们就通过SurfaceFlinger类的成员函数threadLoop的实现来分析SurfaceFlinger服务的UI渲染线程的运行模型，如下所示：
- bool SurfaceFlinger::threadLoop()
- {
- waitForEvent();
- // check for transactions
- if (UNLIKELY(mConsoleSignals)) {
- handleConsoleEvents();
- }
- if (LIKELY(mTransactionCount == 0)) {
- // if we're in a global transaction, don't do anything.
- const uint32_t mask = eTransactionNeeded | eTraversalNeeded;
- uint32_t transactionFlags = getTransactionFlags(mask);
- if (LIKELY(transactionFlags)) {
- handleTransaction(transactionFlags);
- }
- }
- // post surfaces (if needed)
- handlePageFlip();
- const DisplayHardware& hw(graphicPlane(0).displayHardware());
- if (LIKELY(hw.canDraw() && !isFrozen())) {
- #ifdef USE_COMPOSITION_BYPASS
- if (handleBypassLayer()) {
- unlockClients();
- return true;
- }
- #endif
- // repaint the framebuffer (if needed)
- const int index = hw.getCurrentBufferIndex();
- GraphicLog& logger(GraphicLog::getInstance());
- logger.log(GraphicLog::SF_REPAINT, index);
- handleRepaint();
- // inform the h/w that we're done compositing
- logger.log(GraphicLog::SF_COMPOSITION_COMPLETE, index);
- hw.compositionComplete();
- logger.log(GraphicLog::SF_SWAP_BUFFERS, index);
- postFramebuffer();
- logger.log(GraphicLog::SF_REPAINT_DONE, index);
- } else {
- // pretend we did the post
- hw.compositionComplete();
- usleep(16667); // 60 fps period
- }
- return true;
- }
bool SurfaceFlinger::threadLoop()
{
waitForEvent();
// check for transactions
if (UNLIKELY(mConsoleSignals)) {
handleConsoleEvents();
}
if (LIKELY(mTransactionCount == 0)) {
// if we're in a global transaction, don't do anything.
const uint32_t mask = eTransactionNeeded | eTraversalNeeded;
uint32_t transactionFlags = getTransactionFlags(mask);
if (LIKELY(transactionFlags)) {
handleTransaction(transactionFlags);
}
}
// post surfaces (if needed)
handlePageFlip();
const DisplayHardware& hw(graphicPlane(0).displayHardware());
if (LIKELY(hw.canDraw() && !isFrozen())) {
#ifdef USE_COMPOSITION_BYPASS
if (handleBypassLayer()) {
unlockClients();
return true;
}
#endif
// repaint the framebuffer (if needed)
const int index = hw.getCurrentBufferIndex();
GraphicLog& logger(GraphicLog::getInstance());
logger.log(GraphicLog::SF_REPAINT, index);
handleRepaint();
// inform the h/w that we're done compositing
logger.log(GraphicLog::SF_COMPOSITION_COMPLETE, index);
hw.compositionComplete();
logger.log(GraphicLog::SF_SWAP_BUFFERS, index);
postFramebuffer();
logger.log(GraphicLog::SF_REPAINT_DONE, index);
} else {
// pretend we did the post
hw.compositionComplete();
usleep(16667); // 60 fps period
}
return true;
}从前面Android应用程序请求SurfaceFlinger服务渲染Surface的过程分析一文可以知道，SurfaceFlinger类的成员函数threadLoop的工作过程如下所示：
1. 调用SurfaceFlinger类的成员函数waitForEvent中检查SurfaceFlinger服务的UI渲染线程的消息队列是否为空。如果不为空，那么就会马上返回来执行其它的操作，否则的话，SurfaceFlinger服务的UI渲染线程就会进入睡眠等状态，直到被SurfaceFlinger服务的Binder线程或者控制台事件监控线程唤醒为止。
2. 当SurfaceFlinger服务的UI渲染线程被控制台事件监控线程唤醒时，SurfaceFlinger类的成员变量mConsoleSignals的值就会不等于0。在这种情况下，SurfaceFlinger类的成员函数threadLoop就会调用另外一个成员函数handleConsoleEvents来处理控制台事件。后面在分析SurfaceFlinger服务的UI渲染线程和控制台事件监控线程的交互过程时，我们再分析这个成员函数的实现。
3. SurfaceFlinger类的成员变量mTransactionCount用来描述SurfaceFlinger服务是否正在执行事务。如果SurfaceFlinger服务正在执行事务，那么SurfaceFlinger类的成员变量mTransactionCount的值就会大于0。怎么理解SurfaceFlinger服务所执行的事务是什么呢？这些事务是用来处理系统的显示属性的。这些属性划分为两种类型。一种类型是与整个显示屏属性相关的，例如屏幕旋转方向发生了变化，另一外类型是与某一个应用程序的Surface相关的，例如某一个Surface的大小或者Z轴位置发生了变化。一般来说，每当系统的显示属性发生了变化的时候，SurfaceFlinger服务的UI渲染线程都需要马上刷新系统UI，以便可以反映真实情况。但是，为了减少屏幕的闪烁，有时候可以将多个属性变化组合成一个事务来刷新系统UI。例如，我们可以在修改了一个Surface的大小和Z轴位置之后，才要求SurfaceFlinger服务的UI渲染线程去刷新系统UI，这样就可以减少一个刷新系统UI的操作。因此，只有当SurfaceFlinger类的成员变量mTransactionCount的值的等于0的时候，，SurfaceFlinger类的成员函数threadLoop才会判断系统的显示属性是否发生了变化。如果发生了变化，那么就会调用另外一个成员函数handleTransaction来进一步处理。在接下来的一篇文章中分析SurfaceFlinger服务的UI渲染过程时，我们就详细分析这个成员函数的实现。
4. SurfaceFlinger服务的UI渲染线程接下来调用SurfaceFlinger类的成员函数handlePageFlip来通知各个应用程序的Surface将接下来要渲染的图形缓冲区设置为当前激活的图形缓冲区，以便接下来可以渲染到硬件帧缓冲区中去。我们同样会在接下来的一篇文章中分析SurfaceFlinger服务的UI渲染过程时，详细分析这个成员函数的实现。
5. 如果SurfaceFlinger服务的UI渲染线程目前只有一个Surface需要渲染，并且SurfaceFlinger类在编译时，指定了USE_COMPOSITION_BYPASS宏，那么SurfaceFlinger类的成员函数threadLoop就会直接调用另外一个成员函数handleBypassLayer来将这个Surface直接渲染到硬件帧缓冲区中去。这是一个优化操作，避免执行接下来的Surface合成操作。
6. 如果SurfaceFlinger服务的UI渲染线程目前有多个Surface需要渲染，或者SurfaceFlinger类在编译时没指定USE_COMPOSITION_BYPASS宏，那么SurfaceFlinger类的成员函数threadLoop接下来就会调用另外一个成员函数handleRepaint来将各个Surface的图形缓冲区合成起来，以便接下来可以渲染到硬件帧缓冲区中去。Surface的合成操作比较复杂，因为它涉及到可见性计算等。我们同样会在接下来的一篇文章中分析SurfaceFlinger服务的UI渲染过程时，详细分析这个成员函数的实现。
7. 要渲染的各个Surface的图形缓冲区被合成之后，SurfaceFlinger类的成员函数threadLoop接下来前面获得的用来描述系统主显示屏的DisplayHardware对象hw的成员函数compositionComplete来通知HAL层Gralloc模块中的fb设备，以便这个fb设备可以在Surface合成操作完成时执行一些逻辑。这一步是可选的，取决于HAL层Gralloc模块中的fb设备是否需要接收这个Surface合成完成通知。
8. 上述步骤都执行完成之后，SurfaceFlinger类的成员函数threadLoop最后就可以调用SurfaceFlinger类的成员函数postFramebuffer来将合成后得到的图形缓冲区渲染到硬件帧缓冲区去了，这样就可以将系统的最新UI渲染出来，或者说刷新了系统的UI。
在本小节中，我们只关注第1步的处理过程，即SurfaceFlinger类的成员函数waitForEvent的实现，以便可以了解SurfaceFlinger服务的UI渲染线程是如何围绕它的消息队列来运行的。
SurfaceFlinger类的成员函数waitForEvent的实现如下所示：
- void SurfaceFlinger::waitForEvent()
- {
- while (true) {
- nsecs_t timeout = -1;
- const nsecs_t freezeDisplayTimeout = ms2ns(5000);
- if (UNLIKELY(isFrozen())) {
- // wait 5 seconds
- const nsecs_t now = systemTime();
- if (mFreezeDisplayTime == 0) {
- mFreezeDisplayTime = now;
- }
- nsecs_t waitTime = freezeDisplayTimeout - (now - mFreezeDisplayTime);
- timeout = waitTime>0 ? waitTime : 0;
- }
- sp<MessageBase> msg = mEventQueue.waitMessage(timeout);
- // see if we timed out
- if (isFrozen()) {
- const nsecs_t now = systemTime();
- nsecs_t frozenTime = (now - mFreezeDisplayTime);
- if (frozenTime >= freezeDisplayTimeout) {
- // we timed out and are still frozen
- LOGW("timeout expired mFreezeDisplay=%d, mFreezeCount=%d",
- mFreezeDisplay, mFreezeCount);
- mFreezeDisplayTime = 0;
- mFreezeCount = 0;
- mFreezeDisplay = false;
- }
- }
- if (msg != 0) {
- switch (msg->what) {
- case MessageQueue::INVALIDATE:
- // invalidate message, just return to the main loop
- return;
- }
- }
- }
- }
void SurfaceFlinger::waitForEvent()
{
while (true) {
nsecs_t timeout = -1;
const nsecs_t freezeDisplayTimeout = ms2ns(5000);
if (UNLIKELY(isFrozen())) {
// wait 5 seconds
const nsecs_t now = systemTime();
if (mFreezeDisplayTime == 0) {
mFreezeDisplayTime = now;
}
nsecs_t waitTime = freezeDisplayTimeout - (now - mFreezeDisplayTime);
timeout = waitTime>0 ? waitTime : 0;
}
sp<MessageBase> msg = mEventQueue.waitMessage(timeout);
// see if we timed out
if (isFrozen()) {
const nsecs_t now = systemTime();
nsecs_t frozenTime = (now - mFreezeDisplayTime);
if (frozenTime >= freezeDisplayTimeout) {
// we timed out and are still frozen
LOGW("timeout expired mFreezeDisplay=%d, mFreezeCount=%d",
mFreezeDisplay, mFreezeCount);
mFreezeDisplayTime = 0;
mFreezeCount = 0;
mFreezeDisplay = false;
}
}
if (msg != 0) {
switch (msg->what) {
case MessageQueue::INVALIDATE:
// invalidate message, just return to the main loop
return;
}
}
}
}这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。
在分析这个函数的实现之前，我们首先了解一下SurfaceFlinger类的三个成员变量mFreezeDisplay、mFreezeDisplayTime和mFreezeCount的含义。
外部进程，例如，应用程序进程，可以请求SurfaceFlinger服务将显示屏冻结，这时候SurfaceFlinger类的成员变量mFreezeDisplay的值就会等于true。当显示屏被冻结时，SurfaceFlinger服务同时也会记录被冻结的起始时间，记录在SurfaceFlinger类的成员变量mFreezeDisplayTime中。另一方面，SurfaceFlinger服务在修改某一个Surface的显示属性时，例如，修改它的大小时，如果发现显示屏此时正处于被冻结的状态，这时候就会将SurfaceFlinger类的成员变量mFreezeCount的值增加1，表示这个Surface也需要冻结显示屏。
从SurfaceFlinger类的成员函数threadLoop的实现可以知道，SurfaceFlinger服务都会调用SurfaceFlinger类的另外一个成员函数isFrozen来判断显示屏是否处于冻结状态。如果是的话，那么SurfaceFlinger服务是不可以执行渲染UI的操作的。SurfaceFlinger类的成员函数isFrozen的实现如下所示：
- class SurfaceFlinger :
- public BinderService<SurfaceFlinger>,
- public BnSurfaceComposer,
- protected Thread
- {
- ......
- private:
- ......
- inline bool isFrozen() const {
- return (mFreezeDisplay || mFreezeCount>0) && mBootFinished;
- }
- ......
- };
class SurfaceFlinger :
public BinderService<SurfaceFlinger>,
public BnSurfaceComposer,
protected Thread
{
......
private:
......
inline bool isFrozen() const {
return (mFreezeDisplay || mFreezeCount>0) && mBootFinished;
}
......
};SurfaceFlinger类的另外一个成员变量mBootFinished用来表示系统是否已经启动完成的。从前面Android系统的开机画面显示过程分析一文可以知道，当系统启动完成时，第三个开机画面，即开动动画，就会被停止，同时SurfaceFlinger类的成员变量mBootFinished的值会被设置为true。从SurfaceFlinger类的成员函数isFrozen的实现也可以看出，只有当系统启动完成之后，显示屏才会有冻结的概念。由于在系统启动的过程中，显示屏都是依次被三个开机画面独占的，而在独占的期间，不会出现同时去修改显示属性的问题，因此就不需要去冻结显示屏。
由于将显示屏冻结的目的一般是为了修改显示屏的显示属性，例如修改某一个Surface的大小或者修改显示并的旋转方向等，因此，通过SurfaceFlinger类的两个成员变量mFreezeDisplay和mFreezeCount，SurfaceFlinger服务就可以将多个显示属性变化合并在一起去渲染UI，避免单独为每一个显示属性变化执行一次UI渲染操作。单独为每一个显示属性变化执行一次UI渲染操作会出现什么情况呢？假如有两个显示属性是同时发生变化的，那么执行两次UI渲染操作就会可能导致冲突，从而造成一些画面上的误差。
理解了SurfaceFlinger类的三个成员变量mFreezeDisplay、mFreezeDisplayTime和mFreezeCount的含义之后，接下来我们就可以分析SurfaceFlinger类的成员函数waitForEvent的实现了。
当消息队列为空时，SurfaceFlinger服务的UI渲染线程每一次进行睡眠等待状态的默认时间被设置为5000毫秒，保存在变量freezeDisplayTimeout中。但是如果显示屏当前正处于冻结状态，那么这个等待的时间就会从默认值减去已经被冻结的时间。这样做的目的是避免显示屏长时间被冻结而导致UI不能被渲染，即相当于是将显示屏的最长冻结时间设置为5000毫秒。
最终得到的等待时间就保存在变量timeout中，接下来SurfaceFlinger类的成员函数waitForEvent就会调用成员变量mEventQueue所描述的一个消息队列的成员函数waitMessage来检查是否有新的消息需要处理。如果没有，那么SurfaceFlinger服务的UI渲染线程就会进入到睡眠等待状态中去，直到消息队列有新的消息需要处理或者等待超时为止。
SurfaceFlinger服务的UI渲染线程从SurfaceFlinger类的成员变量mEventQueue所描述的一个消息队列的成员函数waitMessage返回来时，如果有新的消息需要处理，那么变量msg就指向这个需要处理的新消息，即变量msg的值不等于0。目前SurfaceFlinger服务的UI渲染线程只处理一种类型为MessageQueue::INVALIDATE的消息，因此，变量msg所指向的消息的类型为MessageQueue::INVALIDATE时，SurfaceFlinger服务的UI渲染线程就会从SurfaceFlinger类的成员函数waitForEvent中返回到调用它的成员函数threadLoop中去，以便可以处理控制台事件或者渲染UI的操作。
注意，当SurfaceFlinger服务的UI渲染线程从SurfaceFlinger类的成员变量mEventQueue所描述的一个消息队列的成员函数waitMessage返回来时，如果这时候显示屏仍然处于冻结状态，那么SurfaceFlinger类的成员函数waitForEvent就需要检查显示屏的冻结时间是否已经大于等于5000毫秒。如果大于等于的话，那么就会自动对显示屏执行解冻操作，即分别将SurfaceFlinger类的成员变量mFreezeDisplayTime、mFreezeCount和mFreezeDisplay的值重置为0、0和false。
SurfaceFlinger类的成员变量mEventQueue所描述的一个消息队列的类型为MessageQueue，实现在文件frameworks/base/services/surfaceflinger/MessageQueue.cpp，它与Android应用程序线程的消息队列的实现思路是类似的，不过会更简单一些。简单来说，这个消息队列就是由一个消息列表以及一个条件变量组成。当消息列表为空时，调用MessageQueue类的成员函数waitMessage的线程就会在MessageQueue类内部的条件变量上进入睡眠等状态。而当其它线程向这个消息队列添加一个新消息的时候，就会通过MessageQueue类内部的条件变量来将前面正在等待的线程唤醒起来，以它可以将前面加入到它的消息队列中的新消息取出来处理。
至此，我们就分析完成SurfaceFlinger服务的UI渲染线程的运行模型了，在下一篇文章中我们还会继续详细分析这个线程是如何执行UI渲染操作的，接下来我们接着分析Binder线程与UI渲染线程的交互过程。
2. Binder线程与UI渲染线程的交互过程
前面提到，System进程在启动SurfaceFlinger服务之前，首先会启动一个Binder线程池。Binder线程池的启动过程可以参考Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析一文。System进程中的Binder线程池启动起来之后，其它进程，例如Android应用程序进程，就可以请求SurfaceFlinger服务来渲染系统的UI了。
以Android系统的开机动画应用程序bootanim为例，当它需要刷新自己的UI时，就会通过它所运行在的进程的SurfaceClient单例的成员函数signalServer来向SurfaceFlinger服务发送一个Binder进程间通信请求，这一点可以参考Android应用程序请求SurfaceFlinger服务渲染Surface的过程分析一文。接下来，我们就从SurfaceClient类的成员函数signalServer来分析SurfaceFlinger服务的Binder线程与UI渲染线程的交互过程。
SurfaceClient类的成员函数signalServer的实现如下所示：
- class SurfaceClient : public Singleton<SurfaceClient>
- {
- // all these attributes are constants
- sp<ISurfaceComposer> mComposerService;
- ......
- public:
- ......
- void signalServer() const {
- mComposerService->signal();
- }
- };
class SurfaceClient : public Singleton<SurfaceClient>
{
// all these attributes are constants
sp<ISurfaceComposer> mComposerService;
......
public:
......
void signalServer() const {
mComposerService->signal();
}
}; SurfaceClient类的成员变量mComposerService指向的是一个类型为BpSurfaceComposer的Binder代理对象，这个Binder代理对象引用了SurfaceFlinger服务，因此，SurfaceClient类的成员函数signalServer实际上就是通过BpSurfaceComposer类的成员函数signal来向SurfaceFlinger服务发送一个进程间通信请求。
BpSurfaceComposer类的成员函数signal的实现如下所示：
- class BpSurfaceComposer : public BpInterface<ISurfaceComposer>
- {
- public:
- ......
- virtual void signal() const
- {
- Parcel data, reply;
- data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
- remote()->transact(BnSurfaceComposer::SIGNAL, data, &reply, IBinder::FLAG_ONEWAY);
- }
- };
class BpSurfaceComposer : public BpInterface<ISurfaceComposer>
{
public:
......
virtual void signal() const
{
Parcel data, reply;
data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
remote()->transact(BnSurfaceComposer::SIGNAL, data, &reply, IBinder::FLAG_ONEWAY);
}
};从这里就可以看出，BpSurfaceComposer类的成员函数signal所执行的操作就是向SurfaceFlinger服务发送一个类型为BnSurfaceComposer::SIGNAL的进程间通信请求，而SurfaceFlinger服务是在SurfaceFlinger类的成员函数signal中处理类型为BnSurfaceComposer::SIGNAL的进程间通信请求的，如下所示：
- void SurfaceFlinger::signal() const {
- // this is the IPC call
- const_cast<SurfaceFlinger*>(this)->signalEvent();
- }
void SurfaceFlinger::signal() const {
// this is the IPC call
const_cast<SurfaceFlinger*>(this)->signalEvent();
}SurfaceFlinger类的成员函数signal调用了另外一个成员函数signalEvent来进一步处理类型为BnSurfaceComposer::SIGNAL的进程间通信请求的，如下所示：
- void SurfaceFlinger::signalEvent() {
- mEventQueue.invalidate();
- }
void SurfaceFlinger::signalEvent() {
mEventQueue.invalidate();
}前面提到，SurfaceFlinger类的成员变量mEventQueue指向的是SurfaceFlinger服务的UI渲染线程的消息队列，这个消息队列的类型为MessageQueue。SurfaceFlinger类的成员函数signalEvent要执行的操作便是向SurfaceFlinger服务的UI渲染线程的消息队列发送一个类型为MessageQueue::INVALIDATE的消息，这是通过调用MessageQueue类的成员函数invalidate来实现的，如下所示：
- status_t MessageQueue::invalidate() {
- Mutex::Autolock _l(mLock);
- mInvalidate = true;
- mCondition.signal();
- return NO_ERROR;
- }
status_t MessageQueue::invalidate() {
Mutex::Autolock _l(mLock);
mInvalidate = true;
mCondition.signal();
return NO_ERROR;
}MessageQueue类的成员函数invalidate并不是真的向SurfaceFlinger服务的UI渲染线程的消息队列发送一个消息，而是将MessageQueue的类成员变量mInvalidate的值设置为true，并且通过MessageQueue类的成员变量mCondition所描述的一个条件变量来将SurfaceFlinger服务的UI渲染线程唤醒。当SurfaceFlinger服务的UI渲染线程被唤醒时，就会检查MessageQueue的类成员变量mInvalidate是否为true。如果是的话，那么就会获得一个类型为MessageQueue::INVALIDATE的消息，这个消息最终是在SurfaceFlinger类的成员函数threadLoop中处理的，如前面第1部分的内容所示。
至此，我们就分析完成SurfaceFlinger服务的Binder线程与UI渲染线程的交互过程了，接下来我们再分析SurfaceFlinger服务的控制台事件监控线程与UI渲染线程的交互过程。
3. 控制台事件监控线程与UI渲染线程的交互过程
从前面Android系统Surface机制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析一文可以知道，SurfaceFlinger服务的控制台事件监控线程是以DisplayEventThread类的成员函数threadLoop为执行体的，即SurfaceFlinger服务的控制台事件监控线程会不断地循环调用DisplayEventThread类的成员函数threadLoop，以便可以监控硬件帧缓冲区的睡眠/唤醒状态切换事件。
DisplayEventThread类的成员函数threadLoop的实现如下所示：
- bool DisplayHardwareBase::DisplayEventThread::threadLoop()
- {
- int err = 0;
- char buf;
- int fd;
- fd = open(kSleepFileName, O_RDONLY, 0);
- do {
- err = read(fd, &buf, 1);
- } while (err < 0 && errno == EINTR);
- close(fd);
- LOGW_IF(err<0, "ANDROID_WAIT_FOR_FB_SLEEP failed (%s)", strerror(errno));
- if (err >= 0) {
- sp<SurfaceFlinger> flinger = mFlinger.promote();
- LOGD("About to give-up screen, flinger = %p", flinger.get());
- if (flinger != 0) {
- mBarrier.close();
- flinger->screenReleased(0);
- mBarrier.wait();
- }
- }
- fd = open(kWakeFileName, O_RDONLY, 0);
- do {
- err = read(fd, &buf, 1);
- } while (err < 0 && errno == EINTR);
- close(fd);
- LOGW_IF(err<0, "ANDROID_WAIT_FOR_FB_WAKE failed (%s)", strerror(errno));
- if (err >= 0) {
- sp<SurfaceFlinger> flinger = mFlinger.promote();
- LOGD("Screen about to return, flinger = %p", flinger.get());
- if (flinger != 0)
- flinger->screenAcquired(0);
- }
- return true;
- }
bool DisplayHardwareBase::DisplayEventThread::threadLoop()
{
int err = 0;
char buf;
int fd;
fd = open(kSleepFileName, O_RDONLY, 0);
do {
err = read(fd, &buf, 1);
} while (err < 0 && errno == EINTR);
close(fd);
LOGW_IF(err<0, "ANDROID_WAIT_FOR_FB_SLEEP failed (%s)", strerror(errno));
if (err >= 0) {
sp<SurfaceFlinger> flinger = mFlinger.promote();
LOGD("About to give-up screen, flinger = %p", flinger.get());
if (flinger != 0) {
mBarrier.close();
flinger->screenReleased(0);
mBarrier.wait();
}
}
fd = open(kWakeFileName, O_RDONLY, 0);
do {
err = read(fd, &buf, 1);
} while (err < 0 && errno == EINTR);
close(fd);
LOGW_IF(err<0, "ANDROID_WAIT_FOR_FB_WAKE failed (%s)", strerror(errno));
if (err >= 0) {
sp<SurfaceFlinger> flinger = mFlinger.promote();
LOGD("Screen about to return, flinger = %p", flinger.get());
if (flinger != 0)
flinger->screenAcquired(0);
}
return true;
}从前面Android系统Surface机制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析一文可以知道，DisplayEventThread类的成员变量kSleepFileName要么指向文件/sys/power/wait_for_fb_sleep，要么是指向文件/sys/android_power/wait_for_fb_sleep，而DisplayEventThread类的成员变量kWakeFileName要么指向文件/sys/power/wait_for_fb_wake，要么指向文件/sys/android_power/wait_for_fb_wake。
文件/sys/power/wait_for_fb_sleep和文件/sys/android_power/wait_for_fb_sleep是用来监控硬件帧缓冲区的睡眠事件的，而文件/sys/power/wait_for_fb_wake和文件/sys/android_power/wait_for_fb_wake是用来监控硬件帧缓冲区的唤醒事件的。文件/sys/power/wait_for_fb_sleep和文件/sys/power/wait_for_fb_wake是硬件帧缓冲区控制台提供的新式接口，而文件/sys/android_power/wait_for_fb_sleep和文件/sys/android_power/wait_for_fb_wake是件帧缓冲区控制台提供的旧式接口。
DisplayEventThread类的成员函数threadLoop首先是监控硬件帧缓冲区的睡眠事件，这是通过监控文件kSleepFileName的内容来实现的，即首先调用函数open来打开文件kSleepFileName，然后再调用函数read来检查这个文件是否有内容可读。当文件kSleepFileName有新的内容可读时，那么就说明硬件帧缓冲区要进入睡眠状态了，这时候SurfaceFlinger服务的控制台事件监控线程就需要通知UI渲染线程来释放系统的显示屏。
DisplayEventThread类的成员变量mFlinger指向了系统中的SurfaceFlinger服务，因此，DisplayEventThread类的成员函数threadLoop就可以调用它的成员函数screenReleased来通知SurfaceFlinger服务的UI渲染线程来释放系统的显示屏。由于DisplayEventThread类的成员变量mFlinger是一个类型为SurfaceFlinger的弱指针，因此，在使用它之前，首先要调用它的成员函数promote来将它升级为一个强指针flinger。如果升级成功，那么才说明它所指向的SurfaceFlinger服务还活着。弱指针升级为强指针的原理可以参考前面Android系统的智能指针（轻量级指针、强指针和弱指针）的实现原理分析一文。
SurfaceFlinger服务的控制台事件监控线程调用SurfaceFlinger类的成员函数screenReleased来通知UI渲染线程来释放系统的显示屏之后，就会通过DisplayEventThread类的成员变量mBarrier所描述的一个屏障的成员函数wait来进入到睡眠等待状态，直到被SurfaceFlinger服务的UI渲染线程唤醒为止。接下来，我们就通过SurfaceFlinger类的成员函数screenReleased来分析SurfaceFlinger服务的UI渲染线程是如何释放系统的显示屏以及唤醒控制台事件监控线程的。
SurfaceFlinger类的成员函数screenReleased的实现如下所示：
- void SurfaceFlinger::screenReleased(int dpy)
- {
- // this may be called by a signal handler, we can't do too much in here
- android_atomic_or(eConsoleReleased, &mConsoleSignals);
- signalEvent();
- }
void SurfaceFlinger::screenReleased(int dpy)
{
// this may be called by a signal handler, we can't do too much in here
android_atomic_or(eConsoleReleased, &mConsoleSignals);
signalEvent();
}SurfaceFlinger类的成员函数screenReleased的实现很简单，它首先将SurfaceFlinger类的成员变量mConsoleSignals的eConsoleReleased位设置为1，接着再通过SurfaceFlinger类的成员函数signalEvent来唤醒UI渲染线程。从前面第1部分的内容可知道，UI渲染线程被唤醒之后，就会调用SurfaceFlinger类的成员函数handleConsoleEvents来处理硬件帧缓冲区的睡眠事件。
SurfaceFlinger类的成员函数handleConsoleEvents处理硬件帧缓冲区的睡眠事件的代码如下所示：
- void SurfaceFlinger::handleConsoleEvents()
- {
- // something to do with the console
- const DisplayHardware& hw = graphicPlane(0).displayHardware();
- int what = android_atomic_and(0, &mConsoleSignals);
- ......
- if (mDeferReleaseConsole && hw.isScreenAcquired()) {
- // We got the release signal before the acquire signal
- mDeferReleaseConsole = false;
- hw.releaseScreen();
- }
- if (what & eConsoleReleased) {
- if (hw.isScreenAcquired()) {
- hw.releaseScreen();
- } else {
- mDeferReleaseConsole = true;
- }
- }
- mDirtyRegion.set(hw.bounds());
- }
void SurfaceFlinger::handleConsoleEvents()
{
// something to do with the console
const DisplayHardware& hw = graphicPlane(0).displayHardware();
int what = android_atomic_and(0, &mConsoleSignals);
......
if (mDeferReleaseConsole && hw.isScreenAcquired()) {
// We got the release signal before the acquire signal
mDeferReleaseConsole = false;
hw.releaseScreen();
}
if (what & eConsoleReleased) {
if (hw.isScreenAcquired()) {
hw.releaseScreen();
} else {
mDeferReleaseConsole = true;
}
}
mDirtyRegion.set(hw.bounds());
}这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。
SurfaceFlinger类的成员函数handleConsoleEvents处理硬件帧缓冲区睡眠事件的过程如下所示：
1. 首先检查SurfaceFlinger类的成员变量mDeferReleaseConsole的值是否等于true，并且系统显示屏当前是否处于可访问的状态。如果均是的话，那么就说明有一个延迟执行的释放系统显示屏的操作在等待执行，因此，这时候就会调用用来描述系统显示屏的一个DisplayHardware对象的成员函数releaseScreen来释放系统显示屏，并且将SurfaceFlinger类的成员变量mDeferReleaseConsole的值设置为false，表示这个延迟执行的释放系统显示屏的操作已经被执行了。
2 接着检查系统显示屏当前是否处于可访问的状态。如果是的话，那么就直接调用用来描述系统显示屏的一个DisplayHardware对象的成员函数releaseScreen来释放系统显示屏，否则的话，就会将SurfaceFlinger类的成员变量mDeferReleaseConsole的值设置为true，表示要延迟执行一个释放系统显示屏的操作，因为系统显示屏当前是处于释放的状态的。
3. 最后将系统显示屏的脏区域mDirtyRegion设置为整个显示屏的大小，表示接下来要刷新整个显示屏的UI，这是因为硬件帧缓冲区的状态发生了变化，即要从唤醒状态进入睡眠状态了。
判断系统显示屏是否处于可访问状态是通过调用DisplayHardware类的成员函数isScreenAcquired来实现的，而DisplayHardware类的成员函数isScreenAcquired是从父类DisplayHardwareBase类继承下来的，因此，接下来我们就继续分析DisplayHardwareBase类的成员函数isScreenAcquired的实现，如下所示：
- bool DisplayHardwareBase::isScreenAcquired() const
- {
- return mScreenAcquired;
- }
bool DisplayHardwareBase::isScreenAcquired() const
{
return mScreenAcquired;
}当硬件帧缓冲区处于唤醒状态时，SurfaceFlinger服务就可以访问系统显示屏，而硬件帧缓冲区处于是否处于唤醒状态是记录在DisplayHardwareBase类的成员变量mScreenAcquired中的，因此，当DisplayHardwareBase类的成员变量mScreenAcquired中的值等于true时，就表示SurfaceFlinger服务可以访问系统显示屏。
释放系统显示屏的操作是通过调用DisplayHardware类的成员函数releaseScreen来实现的，而DisplayHardware类的成员函数releaseScreen是从父类DisplayHardwareBase类继承下来的，因此，接下来我们就继续分析DisplayHardwareBase类的成员函数releaseScreen的实现，如下所示：
- void DisplayHardwareBase::releaseScreen() const
- {
- status_t err = mDisplayEventThread->releaseScreen();
- if (err >= 0) {
- mScreenAcquired = false;
- }
- }
void DisplayHardwareBase::releaseScreen() const
{
status_t err = mDisplayEventThread->releaseScreen();
if (err >= 0) {
mScreenAcquired = false;
}
}DisplayHardwareBase类的成员函数releaseScreen首先调用其成员变量mDisplayEventThread所描述的一个控制台事件监控线程的成员函数releaseScreen来执行释放系统显示屏的操作。如果释放成功，那么接下来就会继续将DisplayHardwareBase类的成员变量mScreenAcquired的值设置为false，以表示系统显示屏处于不可访问状态。
DisplayHardwareBase类的成员变量mDisplayEventThread的类型为DisplayEventThread，因此，接下来我们就继续分析DisplayEventThread的成员函数releaseScreen的实现，看看它是如何执行释放系统显示屏的操作的，如下所示：
- status_t DisplayHardwareBase::DisplayEventThread::releaseScreen() const
- {
- mBarrier.open();
- return NO_ERROR;
- }
status_t DisplayHardwareBase::DisplayEventThread::releaseScreen() const
{
mBarrier.open();
return NO_ERROR;
}DisplayEventThread类的成员函数releaseScreen的实现很简单，它只是将睡眠其成员变量mBarrier所描述的一个屏障的线程唤醒。从前面的描述可以知道，当前正在执行的DisplayEventThread类的成员函数releaseScreen的线程为SurfaceFlinger服务的UI渲染线程，而正在DisplayEventThread类成员变量mBarrier所描述的一个屏障的线程为SurfaceFlinger服务的控制台事件监控线程。因此，经过这一步之后，SurfaceFlinger服务的控制台事件监控线程就被唤醒了。
SurfaceFlinger服务的控制台事件监控线程被唤醒之后，回到DisplayEventThread类的成员函数threadLoop中，我们继续分析它是如何监控硬件帧缓冲区的唤醒事件的。
DisplayEventThread类的成员函数threadLoop是通过监控文件kWakeFileName的内容来监控硬件帧缓冲区的唤醒事件的，即首先调用函数open来打开文件kWakeFileName，然后再调用函数read来检查这个文件是否有内容可读。当文件kWakeFileName有新的内容可读时，那么就说明硬件帧缓冲区要进入唤醒状态了，这时候SurfaceFlinger服务的控制台事件监控线程就需要通知UI渲染线程来获取系统的显示屏，即将系统的显示屏的状态设置为可访问。
前面提到，DisplayEventThread类的成员变量mFlinger指向了系统中的SurfaceFlinger服务，因此，DisplayEventThread类的成员函数threadLoop就可以调用它的成员函数screenAcquired来通知SurfaceFlinger服务的UI渲染线程来将获取系统的显示屏。
SurfaceFlinger类的成员函数screenAcquired的实现如下所示：
- void SurfaceFlinger::screenAcquired(int dpy)
- {
- // this may be called by a signal handler, we can't do too much in here
- android_atomic_or(eConsoleAcquired, &mConsoleSignals);
- signalEvent();
- }
void SurfaceFlinger::screenAcquired(int dpy)
{
// this may be called by a signal handler, we can't do too much in here
android_atomic_or(eConsoleAcquired, &mConsoleSignals);
signalEvent();
}SurfaceFlinger类的成员函数screenAcquired的实现很简单，它首先将SurfaceFlinger类的成员变量mConsoleSignals的eConsoleAcquired位设置为1，接着再通过SurfaceFlinger类的成员函数signalEvent来唤醒UI渲染线程。从前面第1部分的内容可知道，UI渲染线程被唤醒之后，就会调用SurfaceFlinger类的成员函数handleConsoleEvents来处理硬件帧缓冲区的唤醒事件。
SurfaceFlinger类的成员函数handleConsoleEvents处理硬件帧缓冲区的唤醒事件的代码如下所示：
- void SurfaceFlinger::handleConsoleEvents()
- {
- // something to do with the console
- const DisplayHardware& hw = graphicPlane(0).displayHardware();
- int what = android_atomic_and(0, &mConsoleSignals);
- if (what & eConsoleAcquired) {
- hw.acquireScreen();
- // this is a temporary work-around, eventually this should be called
- // by the power-manager
- SurfaceFlinger::turnElectronBeamOn(mElectronBeamAnimationMode);
- }
- ......
- mDirtyRegion.set(hw.bounds());
- }
void SurfaceFlinger::handleConsoleEvents()
{
// something to do with the console
const DisplayHardware& hw = graphicPlane(0).displayHardware();
int what = android_atomic_and(0, &mConsoleSignals);
if (what & eConsoleAcquired) {
hw.acquireScreen();
// this is a temporary work-around, eventually this should be called
// by the power-manager
SurfaceFlinger::turnElectronBeamOn(mElectronBeamAnimationMode);
}
......
mDirtyRegion.set(hw.bounds());
}SurfaceFlinger类的成员函数handleConsoleEvents处理硬件帧缓冲区唤醒事件的过程如下所示：
1. 首先调用用来描述系统显示屏的一个DisplayHardware对象的成员函数acquireScreen来将系统显示屏的状态设置为可访问。
2. 接着再调用SurfaceFlinger类的静态成员函数turnElectronBeamOn来点亮屏幕。在点亮屏幕的时候，通过参数mElectronBeamAnimationMode来表示要显示一个屏幕点亮动画。
3. 最后将系统显示屏的脏区域mDirtyRegion设置为整个显示屏的大小，表示接下来要刷新整个显示屏的UI，这是因为硬件帧缓冲区的状态发生了变化，即要从睡眠状态进入唤醒状态了。
将系统显示屏的状态设置为可访问是通过调用DisplayHardware类的成员函数acquireScreen来实现的，而DisplayHardware类的成员函数acquireScreen是从父类DisplayHardwareBase类继承下来的，因此，接下来我们就继续分析DisplayHardwareBase类的成员函数acquireScreen的实现，如下所示：
- void DisplayHardwareBase::acquireScreen() const
- {
- status_t err = mDisplayEventThread->acquireScreen();
- if (err >= 0) {
- mScreenAcquired = true;
- }
- }
void DisplayHardwareBase::acquireScreen() const
{
status_t err = mDisplayEventThread->acquireScreen();
if (err >= 0) {
mScreenAcquired = true;
}
}DisplayHardwareBase类的成员函数acquireScreen首先调用其成员变量mDisplayEventThread所描述的一个控制台事件监控线程的成员函数acquireScreen来执行获取系统显示屏的操作。如果获取成功，那么接下来就会继续将DisplayHardwareBase类的成员变量mScreenAcquired的值设置为true，以表示系统显示屏处于可访问状态。
DisplayHardwareBase类的成员变量mDisplayEventThread的类型为DisplayEventThread，它的成员函数acquireScreen是从父类DisplayEventThreadBase继承下来的，因此，接下来我们就继续分析DisplayEventThreadBase的成员函数acquireScreen的实现，看看它是如何执行获取系统显示屏的操作的，如下所示：
- class DisplayHardwareBase
- {
- ......
- private:
- class DisplayEventThreadBase : public Thread {
- ......
- public:
- ......
- virtual status_t acquireScreen() const { return NO_ERROR; };
- ......
- };
- ......
- };
class DisplayHardwareBase
{
......
private:
class DisplayEventThreadBase : public Thread {
......
public:
......
virtual status_t acquireScreen() const { return NO_ERROR; };
......
};
......
};从前面的描述可以知道，当前正在执行的DisplayEventThreadBase类的成员函数acquireScreen的线程为SurfaceFlinger服务的UI渲染线程，由于硬件帧缓冲区唤醒之后，它就可以自动地获得系统的显示屏了，并且它不需要与SurfaceFlinger服务的控制台事件监控线程进行交互，因此，DisplayEventThreadBase类的成员函数acquireScreen什么也不用做，直接返回一个成功码NO_ERROR给调用者就可以了。
至此，我们就分析完成SurfaceFlinger服务的控制台事件监控线程与UI渲染线程的交互过程了，整个SurfaceFlinger服务的线程模型也分析完成了。理解了SurfaceFlinger服务的线程模型之后，在接下来的一篇文章中，我们就可以集中火力来分析SurfaceFlinger服务的UI渲染线程是如何将系统UI渲染到硬件帧缓冲区中去的了，敬请关注！
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
