Android显示系统之SurfaceFlinger(一)

快来打我* 2022-10-02 01:56 238阅读 0赞

## 1.1 SurfaceFlinger的启动 ##

SurfaceFlinger的启动和ServiceManager有点类似，它们都属于系统的底层支撑服务，必需在设备开机的早期就运行起来。

/\*frameworks/base/cmds/system\_server/library/System\_init.cpp\*/

extern "C" status\_t  system\_init()

\{…

property\_get("system\_init.startsurfaceflinger", propBuf,"1");

if (strcmp(propBuf,"1") == 0) \{

SurfaceFlinger::instantiate();

\}…

这个System\_init.cpp会被编译到libsystem\_server库中，然后由SystemServer在JNI层进行加载调用，从而启动包括SurfaceFlinger、SensorService等在内的系统服务。

和AudioFlinger/AudioPolicyService看到的情况一样，它调用instantiate来创建一个binder server，名称为“SurfaceFlinger”。而且强指针的特性让它在第一次被引用时会调用onFirstRef：

void SurfaceFlinger::onFirstRef()

mEventQueue.init(this);

run("SurfaceFlinger", PRIORITY\_URGENT\_DISPLAY);

mReadyToRunBarrier.wait();

成员变量mEventQueue是一个MessageQueue，我们在进程章节已经详细分析过它与Looper、Handler等类的使用，大家可以先回头参考下(虽然Java层的这些类与SurfaceFlinger中用到的有一定差异，但其本质原理是一样的)。既然有消息队列，那就一定会有配套的事件处理器Handler以及循环体Looper，这些是在MessageQueue::init函数中创建的，即：

/\*frameworks/native/services/surfaceflinger/MessageQueue.cpp\*/

void MessageQueue::init(const sp<SurfaceFlinger>& flinger)

mFlinger = flinger;

mLooper = newLooper(true);

mHandler = newHandler(\*this);

也就是说这个MessageQueue类不但提供了消息队列，其内部还囊括了消息的处理机制，可以说是个“大杂烩”。那么这个Looper会在什么时候运行起来呢？显然SurfaceFlinger需要先自行创建一个新的线程来承载这一“业务”，否则就会阻塞SystemServer的主线程，这一点和AudioFlinger有一定差异。函数最后的mReadyToRunBarrier.wait()也可以证明这一点——mReadyToRunBarrier在等待一个事件，在事件没有发生前其所在的线程就会处于等待状态。这是Android系统里两个线程间的一种典型交互方式。举个例子来说，A线程将启动B线程，并且A接下来的工作会依赖于B进行。换句话说，A必顺要等到B说“好了，我已经ok”了，它才能继续往下走，否则就会出错。由此可见，SurfaceFlinger新启动的这个线程中一定还会调用mReadyToRunBarrier。

这样我们也能推断出SurfaceFlinger一定是继承自Thread线程类的，如下所示：

class SurfaceFlinger :

publicBinderService<SurfaceFlinger>,

…

protected Thread

所以上面代码中可以调用Thread::run()方法，进而启动一个名为“SurfaceFlinger”的线程，优先级别为PRIORITY\_URGENT\_DISPLAY。这个优先级是在ThreadDefs.h中定义的，如下表所示：

表格 11‑1 Android系统的线程优先级定义

<table style="color:rgb(0,0,0); font-family:Arial; font-size:14.399999618530273px; line-height:26px"> 
 <tbody> 
 <tr> 
 <td style="background-color:rgb(191,191,191)"> Priority </td> 
 <td style="background-color:rgb(191,191,191)"> Value </td> 
 <td style="background-color:rgb(191,191,191)"> Description </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_LOWEST </td> 
 <td> 19 </td> 
 <td> 可以使用最后的 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_BACKGROUND </td> 
 <td> 10 </td> 
 <td> 用于background tasks </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_NORMAL </td> 
 <td> 0 </td> 
 <td> 大部分线程都以这个优先级运行 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_FOREGROUND </td> 
 <td> -2 </td> 
 <td> 用户正在交互的线程 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_DISPLAY </td> 
 <td> -4 </td> 
 <td> UI主线程 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_URGENT_DISPLAY </td> 
 <td> -8 </td> 
 <td> 这个值由HAL_PRIORITY_URGENT_DISPLAY来指定，当前版本中是-8。只在部分紧急状态下使用 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_AUDIO </td> 
 <td> -16 </td> 
 <td> 正常情况下的声音线程 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_URGENT_AUDIO </td> 
 <td> -19 </td> 
 <td> 声音线程(通常情况不用) </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_HIGHEST </td> 
 <td> -20 </td> 
 <td> 最高优先级，禁止使用 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_DEFAULT </td> 
 <td> 0 </td> 
 <td> 默认情况下就是ANDROID_PRIORITY_NORMAL </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_MORE_FAVORABLE </td> 
 <td> -1 </td> 
 <td> 在上述优先级的基础上，用于加大优先级 </td> 
 </tr> 
 <tr> 
 <td> ANDROID_PRIORITY_LESS_FAVORABLE </td> 
 <td> +1 </td> 
 <td> 在上述优先级的基础上，用于减小优先级 </td> 
 </tr> 
 </tbody> 
</table>

数值越大的，优先级越小。因为各等级间的数值并不是连续的，我们可以通过ANDROID\_PRIORITY\_MORE\_FAVORABLE(-1)来适当地提高优先级，或者是利用ANDROID\_PRIORITY\_LESS\_FAVORABLE(+1)来降低优先级。

由此可见，SurfaceFlinger工作线程所采用的优先级是相对较高的。这样做是必然的，因为屏幕显示无疑是人机交互中最直观的用户体验，任何滞后的响应速度都将大大降低产品的吸引力。

在执行了run()以后，Thread会自动调用threadLoop()接口，即：

bool SurfaceFlinger::threadLoop()

waitForEvent();

return true;

相当简洁的两句话，所有SurfaceFlinger接下来要执行的工作都涵括在这里了。其中waitForEvent()是SurfaceFlinger中的成员函数，它进一步调用mEventQueue.waitMessage():

void MessageQueue::waitMessage() \{

do \{

IPCThreadState::self()->flushCommands();

int32\_t ret =mLooper->pollOnce(-1);

switch (ret) \{

caseALOOPER\_POLL\_WAKE:

caseALOOPER\_POLL\_CALLBACK:

continue;

caseALOOPER\_POLL\_ERROR:

ALOGE("ALOOPER\_POLL\_ERROR");

caseALOOPER\_POLL\_TIMEOUT:

// timeout (should not happen)

continue;

default:

// should nothappen

ALOGE("Looper::pollOnce() returned unknown status %d", ret);

continue;

\} while (true);

可以看到程序在这里进入了一个死循环，而且即便pollOnce的执行结果是ALOOPER\_POLL\_TIMEOUT，也同样不会跳出循环。这是Android系统在对待系统级严重错误时的一种普遍态度——一旦发生，就没救了，听天由命吧。。。

下面这句将在内部调用MessageQueue::mHandler来处理消息：

mLooper->pollOnce(-1);

这样子就构建了一个简洁而又完整的循环消息处理框架，SurfaceFlinger就是基于这个框架完成来自系统中各个程序的显示请求的。大家可能会有疑问，mHandler是由MessageQueue直接通过new Handler()生成的，这样的话如何能处理特定的SurfaceFlinger消息请求呢？个人感觉有这个困惑是由于Handler类取名不当引起的。实际上此Handler并非我们经常看到的那个Handler，这里的Handler是MessageQueue中自定义的一个事件处理器，也就是说它是专门为SurfaceFlinger设计的。

/\*frameworks/native/services/surfaceflinger/MessageQueue.cpp\*/

void MessageQueue::Handler::handleMessage(const Message&message) \{

switch (message.what) \{

case INVALIDATE:

android\_atomic\_and(~eventMaskInvalidate, &mEventMask);

mQueue.mFlinger->onMessageReceived(message.what);

break;

case REFRESH:

android\_atomic\_and(~eventMaskRefresh, &mEventMask);

mQueue.mFlinger->onMessageReceived(message.what);

break;

如上代码段所示，mHandler当收到INVALIDATE和REFRESH请求时，进一步回调了SurfaceFlinger中的onMessageReceived。等于是绕了一个大圈，又回到SurfaceFlinger中了——这或许也是我们在分析Android源码时经常碰到的情况J。

不过我们到目前为止还是没看到SurfaceFlinger是如何通知SystemServer线程解除等待的。这个工作是在下面的函数完成的：

status\_t SurfaceFlinger::readyToRun()

\{…

mReadyToRunBarrier.open();//好了，现在可以解禁线程A了

函数readyToRun是在一个线程进入run循环前调用的，它为SurfaceFlinger的正常工作提供了各种必要的基础。我们在后续小节还会看到其中的更多内容，这里先分析与消息处理有关的部分。前面所说的mReadyToRunBarrier果然在这里又被调用了，open()是告诉所有正在等待的线程可以继续运行了。Barrier类内部实际上也是使用了Condition::broadcast()、Condition::wait()等常规互斥方法，只是加了一层封装而已。