Android4.2.2 SurfaceFlinger之图形渲染queueBuffer实现和VSYNC的存在感

本文均属自己阅读源码的点滴总结，转账请注明出处谢谢。

欢迎和大家交流。qq:1037701636 email:[email protected]

Android源码版本Version：4.2.2; 硬件平台 全志A31

 

前一博文总结了Android4.2.2 SurfaceFlinger之图形缓存区申请与分配dequeueBuffer的实现，由于受到OpenGL Es的中介作用（内部实现图层绘制并写入到分配好的图形缓存中去），eglSwapBuffers()函数内部的实现就是如此。好了作为生产者以及使用dequeueBuffer获取了图形缓存并写入了绘图数据，这下就该是渲染的过程queueBuffer来看看他的实现：

status_t BufferQueue::queueBuffer(int buf,
        const QueueBufferInput& input, QueueBufferOutput* output) {
    ATRACE_CALL();
.......
{ // scope for the lock
        Mutex::Autolock lock(mMutex);
        if (mAbandoned) {
            ST_LOGE("queueBuffer: SurfaceTexture has been abandoned!");
            return NO_INIT;
        }
        int maxBufferCount = getMaxBufferCountLocked();
        if (buf < 0 || buf >= maxBufferCount) {
            ST_LOGE("queueBuffer: slot index out of range [0, %d]: %d",
                    maxBufferCount, buf);
            return -EINVAL;
        } else if (mSlots[buf].mBufferState != BufferSlot::DEQUEUED) {//非DEQUEUD，未被客户端获取
            ST_LOGE("queueBuffer: slot %d is not owned by the client "
                    "(state=%d)", buf, mSlots[buf].mBufferState);
            return -EINVAL;
        } else if (!mSlots[buf].mRequestBufferCalled) {
            ST_LOGE("queueBuffer: slot %d was enqueued without requesting a "
                    "buffer", buf);
            return -EINVAL;
        }

        const sp<GraphicBuffer>& graphicBuffer(mSlots[buf].mGraphicBuffer);
        Rect bufferRect(graphicBuffer->getWidth(), graphicBuffer->getHeight());
        Rect croppedCrop;
        crop.intersect(bufferRect, &croppedCrop);
        if (croppedCrop != crop) {
            ST_LOGE("queueBuffer: crop rect is not contained within the "
                    "buffer in slot %d", buf);
            return -EINVAL;
        }

        if (mSynchronousMode) {
            // In synchronous mode we queue all buffers in a FIFO.
            mQueue.push_back(buf);

            // Synchronous mode always signals that an additional frame should
            // be consumed.
            listener = mConsumerListener;//获取消费者监听
        } else {
            // In asynchronous mode we only keep the most recent buffer.
            if (mQueue.empty()) {
                mQueue.push_back(buf);

                // Asynchronous mode only signals that a frame should be
                // consumed if no previous frame was pending. If a frame were
                // pending then the consumer would have already been notified.
                listener = mConsumerListener;
            } else {
                Fifo::iterator front(mQueue.begin());
                // buffer currently queued is freed
                mSlots[*front].mBufferState = BufferSlot::FREE;
                // and we record the new buffer index in the queued list
                *front = buf;
            }
        }

        mSlots[buf].mTimestamp = timestamp;
        mSlots[buf].mCrop = crop;
        mSlots[buf].mTransform = transform;
        mSlots[buf].mFence = fence;

        switch (scalingMode) {
            case NATIVE_WINDOW_SCALING_MODE_FREEZE:
            case NATIVE_WINDOW_SCALING_MODE_SCALE_TO_WINDOW:
            case NATIVE_WINDOW_SCALING_MODE_SCALE_CROP:
                break;
            default:
                ST_LOGE("unknown scaling mode: %d (ignoring)", scalingMode);
                scalingMode = mSlots[buf].mScalingMode;
                break;
        }

        mSlots[buf].mBufferState = BufferSlot::QUEUED;
        mSlots[buf].mScalingMode = scalingMode;
        mFrameCounter++;
        mSlots[buf].mFrameNumber = mFrameCounter;

        mBufferHasBeenQueued = true;
        mDequeueCondition.broadcast();

        output->inflate(mDefaultWidth, mDefaultHeight, mTransformHint,
                mQueue.size());

        ATRACE_INT(mConsumerName.string(), mQueue.size());
    }
......
    if (listener != 0) {
        listener->onFrameAvailable();//发布当前帧可以给消费者
    }
}

 

step1: 根据bufferSlot[]的索引值找到对应的buffer后，对其做是否处于DEQUEUED状态，因为只有被客户端获取后才能去进一步的渲染。

 

step2:    sp<ConsumerListener> listener = mConsumerListener;

BufferQueue中的一个成员变量mConsumerListener是queueBuffer的主导，这个变量在哪里何时创建的呢，来看这里：

ConsumerBase::ConsumerBase(const sp<BufferQueue>& bufferQueue) :
        mAbandoned(false),
        mBufferQueue(bufferQueue) {
    // Choose a name using the PID and a process-unique ID.
    mName = String8::format("unnamed-%d-%d", getpid(), createProcessUniqueId());

    // Note that we can't create an sp<...>(this) in a ctor that will not keep a
    // reference once the ctor ends, as that would cause the refcount of 'this'
    // dropping to 0 at the end of the ctor.  Since all we need is a wp<...>
    // that's what we create.
    wp<BufferQueue::ConsumerListener> listener;
    sp<BufferQueue::ConsumerListener> proxy;
    listener = static_cast<BufferQueue::ConsumerListener*>(this);
    proxy = new BufferQueue::ProxyConsumerListener(listener);//新建一个监听代理

    status_t err = mBufferQueue->consumerConnect(proxy);//创建一个ConsumerListener代理
    if (err != NO_ERROR) {
        CB_LOGE("SurfaceTexture: error connecting to BufferQueue: %s (%d)",
                strerror(-err), err);
    } else {
        mBufferQueue->setConsumerName(mName);
    }
}

在ConsumerBase的构造函数之中，而该类被SurfaceTexture继承，且SurfaceFlinger在新建Layer时创建new SurfaceTexture时进行的。这里可以看到调用了一个consumerConnect函数：

status_t BufferQueue::consumerConnect(const sp<ConsumerListener>& consumerListener) {
.......
    mConsumerListener = consumerListener;

    return OK;
}

这里就看到了BufferQueue的成员变量mConsumerListener完成了赋值初始化，从调用可知，传入的proxy为BufferQueue的一个内部类ProxyConsumerListener，理解为消费者监听代理。

 而实际上的这个proxy自己也是有一个成员变量mConsumerListener即为上面传入的listener（这里的this是什么？，当初ConsumerBase是基于new SurfaceTexture()来构造 ，该类继承了ConsumerBase，故可以理解为这个this实际是SurfaceFLinger侧的SurfaceTexture对象)，为BufferQueue的内部类ConsumerListener。

BufferQueue::ProxyConsumerListener::ProxyConsumerListener(
        const wp<BufferQueue::ConsumerListener>& consumerListener):
        mConsumerListener(consumerListener) {}

 

step3:回到queueBuffer函数的最后listener->onFrameAvailable()

由于listener是ConsumerListener类，proxy是ProxyConsumerListener，且继承public与ConsumerListener，故通过上面的分析最终调用的是proxy->onFrameAvailable，最终来到这里：

void BufferQueue::ProxyConsumerListener::onFrameAvailable() {
    sp<BufferQueue::ConsumerListener> listener(mConsumerListener.promote());
    if (listener != NULL) {
        listener->onFrameAvailable();//调用消费者consumerbase的onFrameAvailable进行调用
    }
}

这里的mConsumerListerner成员对象其实是指向派生类对象ConsumerBase的基类指针，故最终回到了ConsumerBase的onFrameAvailable().

因此上面的理解应该是一个proxy监听代理，最终还是提交给消费者来处理，而最下层的消费者就是SurfaceTexture。

 

step4:由于SurfaceTexture没有重载，则调用的ConsumerBase如下：

void ConsumerBase::onFrameAvailable() {
    CB_LOGV("onFrameAvailable");

    sp<FrameAvailableListener> listener;
    { // scope for the lock
        Mutex::Autolock lock(mMutex);
        listener = mFrameAvailableListener;
    }

    if (listener != NULL) {
        CB_LOGV("actually calling onFrameAvailable");
        listener->onFrameAvailable();
    }
}

这里有出现了一个FrameAvailableListener类，帧可用监听类，那这个ConsumerBase的成员变量mFrameAvailableListener是在哪里初始化的呢，回到这里？

void Layer::onFirstRef()
{
    LayerBaseClient::onFirstRef();//基类LayerBaseClient
    struct FrameQueuedListener : public SurfaceTexture::FrameAvailableListener {//内部类继承FrameAvailableListener
        FrameQueuedListener(Layer* layer) : mLayer(layer) { }
    private:
        wp<Layer> mLayer;
        virtual void onFrameAvailable() {
            sp<Layer> that(mLayer.promote());
            if (that != 0) {
                that->onFrameQueued();//调用Layer的onFrameQueued
            }
        }
    };
    // Creates a custom BufferQueue for SurfaceTexture to use
    sp<BufferQueue> bq = new SurfaceTextureLayer();//新建一个SurfaceTextureLayer，即BufferQueue
    mSurfaceTexture = new SurfaceTexture(mTextureName, true,
            GL_TEXTURE_EXTERNAL_OES, false, bq);//新建的表面纹理
    mSurfaceTexture->setConsumerUsageBits(getEffectiveUsage(0));
    mSurfaceTexture->setFrameAvailableListener(new FrameQueuedListener(this));//新建立一个帧队列监听
    mSurfaceTexture->setSynchronousMode(true);//支持同步模式
#ifdef TARGET_DISABLE_TRIPLE_BUFFERING
#warning "disabling triple buffering"
    mSurfaceTexture->setDefaultMaxBufferCount(2);
#else
    mSurfaceTexture->setDefaultMaxBufferCount(3);
#endif
    const sp<const DisplayDevice> hw(mFlinger->getDefaultDisplayDevice());
    updateTransformHint(hw);
}

这里出现了一个和SurfaceTexture相关的帧可用监听设置函数setFrameAvailableListener：

void ConsumerBase::setFrameAvailableListener(
        const sp<FrameAvailableListener>& listener) {
    CB_LOGV("setFrameAvailableListener");
    Mutex::Autolock lock(mMutex);
    mFrameAvailableListener = listener;

这里可以看到listener = new FrameQueuedListener()对象，故最终调用的是FrameQueuedListener->onFrameAvailable()函数，而该类其实是Layer::onFirstRef的内部类FrameQueuedListener，该函数最终还是调用如下：

        virtual void onFrameAvailable() {
            sp<Layer> that(mLayer.promote());
            if (that != 0) {
                that->onFrameQueued();//调用Layer的onFrameQueued
            }
        }

而这个mLayer是在对象FrameQueuedListener传入的this参数，这个this就是传入的layer对象，故最终这个that->onFrameQueued就回到了Layer::onFrameQueued函数。

 

step5:回到了熟悉的Layer处的调用

void Layer::onFrameQueued() {
    android_atomic_inc(&mQueuedFrames);
    mFlinger->signalLayerUpdate();//发送给SF Layer图层更新
}

这里的结果很显然，一切还得有SurfaceFlinger来完成图形缓存区的渲染，发出图层更新的信号：

void SurfaceFlinger::signalLayerUpdate() {
    mEventQueue.invalidate();
}

mEventQueue又涉及到了SurfaceFLinger的消息处理机制，意味着又要触发一个Event的发生：

void MessageQueue::invalidate() {
#if INVALIDATE_ON_VSYNC
    mEvents->requestNextVsync();
#else
    mHandler->dispatchInvalidate();
#endif
}

这里执行requestNextVsync()函数，即请求下一个VSYNC。那么这个mEvents是什么呢？可以在这里看到被初始化

void MessageQueue::setEventThread(const sp<EventThread>& eventThread)
{
    mEventThread = eventThread;
    mEvents = eventThread->createEventConnection();//建立连接
   ....}

sp<EventThread::Connection> EventThread::createEventConnection() const {
    return new Connection(const_cast<EventThread*>(this));
}

这个函数内部新建了一个Connection类对象，该类是EventThread的内部类继承了BnDisplayEventConnection类。这里有必要深入的看看connection的构造过程：

EventThread::Connection::Connection(
        const sp<EventThread>& eventThread)
    : count(-1), mEventThread(eventThread), mChannel(new BitTube())
{
}

该类继承RefBase则执行onFirstRef()函数，看看他做了什么特别的事情：

void EventThread::Connection::onFirstRef() {
    // NOTE: mEventThread doesn't hold a strong reference on us
    mEventThread->registerDisplayEventConnection(this);//将随着eventthread新建的connection对象注册到mDisplayEventConnections
}

将这个新建出来的Connection对象this注册到显示事件中去：

status_t EventThread::registerDisplayEventConnection(
        const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    mDisplayEventConnections.add(connection);
    mCondition.broadcast();
    return NO_ERROR;
}

最终是将这个connection维护在了一个SortedVector< wp<Connection> > mDisplayEventConnections存储类中。

 

上述分析后，可知最终requestNextVsync调用的是Connection的requestNextVsync来完成的：

void EventThread::Connection::requestNextVsync() {
    mEventThread->requestNextVsync(this);
}

mEventThread是直接新建时传入的this，且为EventThread；故最终调用的是EventThread类的成员函数requestNextVsync()

 

step6:EventThread的requestNextVsync函数

void EventThread::requestNextVsync(
        const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    if (connection->count < 0) {
        connection->count = 0;
        mCondition.broadcast();//条件满足时，发出一个广播请求下一个VSYNC
    }
}

这里是将count清0，并触发一个进程锁的解锁，这个锁等待在EventThread的threadLoop()中，以EventThread::waitForEvent()函数的形式睡眠，下面来看部分代码：

Vector< sp<EventThread::Connection> > EventThread::waitForEvent(
        DisplayEventReceiver::Event* event){
        // find out connections waiting for events
        size_t count = mDisplayEventConnections.size();
        for (size_t i=0 ; i<count ; i++) {
            sp<Connection> connection(mDisplayEventConnections[i].promote());
            if (connection != NULL) {
                bool added = false;
                if (connection->count >= 0) {
                    // we need vsync events because at least
                    // one connection is waiting for it
                    waitForVSync = true;
                    if (timestamp) {
                        // we consume the event only if it's time
                        // (ie: we received a vsync event)
                        if (connection->count == 0) {
                            // fired this time around
                            connection->count = -1;
                            signalConnections.add(connection);
                            added = true;
                        } else if (connection->count == 1 ||
                                (vsyncCount % connection->count) == 0) {
                            // continuous event, and time to report it
                            signalConnections.add(connection);
                            added = true;
                        }
                    }
                }
while (signalConnections.isEmpty())............
}

在获得之前注册到mDisplayEventConnections数组之中connection对象，依据之前的requestNextVsync()，他会将count=0，故这里执行signalConnections.add(connection);

有了连击信号后，直接退出waitEvent()。

 

step7:到这里我们需要回到Android4.2.2 SurfaceFlinger的相关事件和消息处理机制这里，因为我们知道如果要渲染当前的图像，需要接受到底层硬件返回的一个VSYNC，而这里有HWComposer来完成（当然硬件不支持时会由一个VSyncThread来软件模拟）。

在SF运行时就会创建一个HWComposer：

    mHwc = new HWComposer(this,
            *static_cast<HWComposer::EventHandler *>(this));//新建一个软硬件合成器HWComposer

在HWComposer的构造函数内，可以看到向hwcomposer的HAL层注册了回调业务函数：

 if (mHwc) {//如果支持硬件hw
        ALOGI("Using %s version %u.%u", HWC_HARDWARE_COMPOSER,
              (hwcApiVersion(mHwc) >> 24) & 0xff,
              (hwcApiVersion(mHwc) >> 16) & 0xff);//1.1版本
        if (mHwc->registerProcs) {
            mCBContext->hwc = this;
            mCBContext->procs.invalidate = &hook_invalidate;
            mCBContext->procs.vsync = &hook_vsync;//相关hwc的回调函数初始化，用于向上层发出VSYNC信号
            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1))
                mCBContext->procs.hotplug = &hook_hotplug;
            else
                mCBContext->procs.hotplug = NULL;
            memset(mCBContext->procs.zero, 0, sizeof(mCBContext->procs.zero));
            mHwc->registerProcs(mHwc, &mCBContext->procs);//向HAL注册回调函数
        }

很容易的可以看到底层硬件产生一个硬件的VSYNC时，传入的回调函数即为hook_vsync。那么底层硬件又是如何反馈回这个VSYNC信号的呢？

 

step8: VSYNC的硬件信号捕获进程分析

在之前已经说到registerProcs会将回调函数进行注册，而这个不单单是注册这么简单，我们来看看：

static void hwc_registerProcs(struct hwc_composer_device_1* dev,
                              hwc_procs_t const* procs)
{
    ALOGI("%s", __FUNCTION__);
    hwc_context_t* ctx = (hwc_context_t*)(dev);
    if(!ctx) {
        ALOGE("%s: Invalid context", __FUNCTION__);
        return;
    }
    ctx->proc = procs;

    // Now that we have the functions needed, kick off
    // the uevent & vsync threads
    init_uevent_thread(ctx);
    init_vsync_thread(ctx);
}

果然这里出现了线程的存在感，即这里新建了两个线程而init_vsync_thread就是轮询捕获VSYNC的真正线程：

void init_vsync_thread(hwc_context_t* ctx)
{
    int ret;
    pthread_t vsync_thread;
    ALOGI("Initializing VSYNC Thread");
    ret = pthread_create(&vsync_thread, NULL, vsync_loop, (void*) ctx);
    if (ret) {
        ALOGE("%s: failed to create %s: %s", __FUNCTION__,
              HWC_VSYNC_THREAD_NAME, strerror(ret));
    }
}

这里创建了一个vsync_loop的线程函数，且传入的参数为回调函数的内容。进入线程后，基本就是和内核进行交互，捕获VSYNC，而且肯定是处于死循环中。

static void *vsync_loop(void *param)
{
    const char* vsync_timestamp_fb0 = "/sys/class/graphics/fb0/vsync_event";
    const char* vsync_timestamp_fb1 = "/sys/class/graphics/fb1/vsync_event";
    int dpy = HWC_DISPLAY_PRIMARY;
.....
do
{
        ctx->proc->vsync(ctx->proc, dpy, cur_timestamp);
}while(true);
}
}

从而属于SurfaceFlinger进程 一个VSYNC线程就在实时监听VSYNC的存在，并回调给vsync()函数，即注册的hook_sync().

 

step9: hook_sync()的作用

void HWComposer::hook_vsync(const struct hwc_procs* procs, int disp,
        int64_t timestamp) {
    cb_context* ctx = reinterpret_cast<cb_context*>(
            const_cast<hwc_procs_t*>(procs));
    ctx->hwc->vsync(disp, timestamp);
}

继续该函数的执行，回到了HWComposer中来执行

void HWComposer::vsync(int disp, int64_t timestamp) {
    ATRACE_INT("VSYNC", ++mVSyncCount&1);
    mEventHandler.onVSyncReceived(disp, timestamp);//调用SF的onVSyncReceived
    Mutex::Autolock _l(mLock);
    mLastHwVSync = timestamp;
}

而这里利用的mEventHandle是对象就是SurfaceFlinger对象，故转到SurfaceFlinger::onVSyncReceived函数来执行

void SurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {
    if (mEventThread == NULL) {
        // This is a temporary workaround for b/7145521.  A non-null pointer
        // does not mean EventThread has finished initializing, so this
        // is not a correct fix.
        ALOGW("WARNING: EventThread not started, ignoring vsync");
        return;
    }
    if (uint32_t(type) < DisplayDevice::NUM_DISPLAY_TYPES) {
        // we should only receive DisplayDevice::DisplayType from the vsync callback
        mEventThread->onVSyncReceived(type, timestamp);//发出一个VSYNC接收
    }
}

上面函数利用SF处的事件处理线程进一步执行，完成了对当前的VSYNC事件进行初始化，并提交一个broadcast，供相应的阻塞线程进行唤醒。

void EventThread::onVSyncReceived(int type, nsecs_t timestamp) {
    ALOGE_IF(type >= HWC_DISPLAY_TYPES_SUPPORTED,
            "received event for an invalid display (id=%d)", type);

    Mutex::Autolock _l(mLock);
    if (type < HWC_DISPLAY_TYPES_SUPPORTED) {
        mVSyncEvent[type].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
        mVSyncEvent[type].header.id = type;
        mVSyncEvent[type].header.timestamp = timestamp;
        mVSyncEvent[type].vsync.count++;
        mCondition.broadcast();
    }
}

唤醒的线程就是EventThread的waitEvent()函数，故回到step6处继续分析。

 

step10:VSYNC的事件处理

VSYNC的处理过程在Android4.2.2 SurfaceFlinger的相关事件和消息处理机制已经详细的分析过，这里不做过多的分析。要补充的是只有一个connection对象存在时，才会提交一个Event事件：

bool EventThread::threadLoop() {
    DisplayEventReceiver::Event event;
    Vector< sp<EventThread::Connection> > signalConnections;
    signalConnections = waitForEvent(&event);//轮询等待event的发生，一般是硬件的请求
const size_t count = signalConnections.size();
    for (size_t i=0 ; i<count ; i++) {
        const sp<Connection>& conn(signalConnections[i]);
        // now see if we still need to report this event
        status_t err = conn->postEvent(event);//发送事件，一般的硬件触发了事件的发生

很容易看到只有需要渲染的一个buffer发出connection时即让waitEvent从睡眠中醒过来mCondition.wait(mLock);

简单的几个分支情况如下：

1.如果没有VSYNC时，唤醒waitEvent()中的阻塞函数，且会执行psotEvent()，但是没有Event的相关信息。

2.如果只有VSYNC，则signalConnections不会被add相关的connection，只会继续睡眠，唤醒，睡眠。

3.从而只有在step6中那样，唤醒线程且添加对象connection到signalConnections里面，再次进入睡眠，等着VSYNC唤醒后直接退出循环，最终才会提交一次Event

 

step11: 最终事件被eventReceiver()回调后并发出一个消息，消息处理由下面的函数来处理

int MessageQueue::eventReceiver(int fd, int events) {
    ssize_t n;
    DisplayEventReceiver::Event buffer[8];
    while ((n = DisplayEventReceiver::getEvents(mEventTube, buffer, 8)) > 0) {//得到事件的数据
        for (int i=0 ; i<n ; i++) {
            if (buffer[i].header.type == DisplayEventReceiver::DISPLAY_EVENT_VSYNC) {
#if INVALIDATE_ON_VSYNC
                mHandler->dispatchInvalidate();
#else
                mHandler->dispatchRefresh();//刷新
#endif
                break;
            }
        }
    }
    return 1;
}

void MessageQueue::Handler::dispatchInvalidate() {
    if ((android_atomic_or(eventMaskInvalidate, &mEventMask) & eventMaskInvalidate) == 0) {
        mQueue.mLooper->sendMessage(this, Message(MessageQueue::INVALIDATE));
    }
}

发出的消息类型为INVALIDATE。

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;
    }
}

首先是执行INVALIDATE函数，先来看看他完成的任务，最终发现他还是提交给SurfaceFlinger来完成：

void SurfaceFlinger::onMessageReceived(int32_t what) {//收到消息
    ATRACE_CALL();
    switch (what) {
    case MessageQueue::INVALIDATE://SurfaceFlinger的处理
        handleMessageTransaction();
        handleMessageInvalidate();
        signalRefresh();
        break;
    case MessageQueue::REFRESH:
        handleMessageRefresh();
        break;
    }
}

上面的函数分别是对当前的绘图的信息发生变化时来做处理的，比如z轴发生变化，透传变化等等。

void SurfaceFlinger::handleMessageTransaction() {
    uint32_t transactionFlags = peekTransactionFlags(eTransactionMask);
    if (transactionFlags) {
        handleTransaction(transactionFlags);//事务处理
    }
}

void SurfaceFlinger::handleMessageInvalidate() {
    ATRACE_CALL();
    handlePageFlip();//
}

处理完后最终发出signalRefresh();信号来完成最终的绘图。

void SurfaceFlinger::signalRefresh() {
    mEventQueue.refresh();//刷新
}

void MessageQueue::refresh() {
#if INVALIDATE_ON_VSYNC
    mHandler->dispatchRefresh();
#else
    mEvents->requestNextVsync();
#endif
}

最终这里发出REFRESH类型的消息

void MessageQueue::Handler::dispatchRefresh() {
    if ((android_atomic_or(eventMaskRefresh, &mEventMask) & eventMaskRefresh) == 0) {
        mQueue.mLooper->sendMessage(this, Message(MessageQueue::REFRESH));
    }
}

而最终的处理同理还是由SurfaceFlinger::onMessageReceived(int32_t what)里的handleMessageRefresh()来完成处理：

void SurfaceFlinger::handleMessageRefresh() {//处理layer的刷新，实际是调用SF绘图
    ATRACE_CALL();
    preComposition();
    rebuildLayerStacks();
    setUpHWComposer();
    doDebugFlashRegions();
    doComposition();
    postComposition();//写入到FrameBuffer中
}

最终依旧上述函数完成绘图送显。

到这里就完成了queueBuffer的整个流程，细节上的东西比较多，讲的也比较粗。
 

补充：

SurfaceFlinger本地的窗口和应用侧的窗口的存在性，都依赖于SurfaceTextureClient类关联在一起。