上一篇文章分析了上层Window创建之后，native层会创建对应的Surface，以及SurfaceFlinger进程会创建对应Layer，所以应用层的窗口对应到SurfaceFlinger进程其实就是Layer。

AndroidQ上SurfaceFlinger能够创建四种类型的Layer，BufferQueueLayer，BufferStateLayer，ColorLayer，ContainerLayer，最常用的就是BufferQueueLayer

在创建BufferQueueLayer同时会创建一套生产者-消费者模型架构，核心是三个类：
IGraphicBufferProducer（生产者），
IGraphicBufferConsumer（消费者），
BufferQueue（buffer队列），
生产者提供图形数据，放入BufferQueue，消费者拿到图形数据进行合成，通常认为生产者为Surface，消费者为SurfaceFlinger，这篇文章就来分析一下生产者-消费者模型架构的搭建。
我们以BufferQueueLayer的创建为入口分析

BufferQueueLayer::onFirstRef

void BufferQueueLayer::onFirstRef() {BufferLayer::onFirstRef();sp<IGraphicBufferProducer> producer;sp<IGraphicBufferConsumer> consumer;//步骤1BufferQueue::createBufferQueue(&producer, &consumer, true);//步骤2mProducer = new MonitoredProducer(producer, mFlinger, this);{// Grab the SF state lock during this since it's the only safe way to access RenderEngineMutex::Autolock lock(mFlinger->mStateLock);//步骤3mConsumer =new BufferLayerConsumer(consumer, mFlinger->getRenderEngine(), mTextureName, this);}//步骤4mConsumer->setConsumerUsageBits(getEffectiveUsage(0));//步骤5mConsumer->setContentsChangedListener(this);mConsumer->setName(mName);// BufferQueueCore::mMaxDequeuedBufferCount is default to 1if (!mFlinger->isLayerTripleBufferingDisabled()) {mProducer->setMaxDequeuedBufferCount(2);}if (const auto display = mFlinger->getDefaultDisplayDevice()) {updateTransformHint(display);}if (mFlinger->mLayerExt) {mLayerType = mFlinger->mLayerExt->getLayerClass(mName.string());}
}

上面这个函数就是创建SurfaceFlinger生产者-消费者模型的核心代码，先看步骤1：createBufferQueue，从名字看就能知道是创建BufferQueue，并且将生产者producer和消费者consumer的地址传了过去，显然这两个对象也会在createBufferQueue中创建

createBufferQueue

void BufferQueue::createBufferQueue(sp<IGraphicBufferProducer>* outProducer,sp<IGraphicBufferConsumer>* outConsumer,bool consumerIsSurfaceFlinger) {sp<BufferQueueCore> core(new BufferQueueCore());sp<IGraphicBufferProducer> producer(new BufferQueueProducer(core, consumerIsSurfaceFlinger));sp<IGraphicBufferConsumer> consumer(new BufferQueueConsumer(core));*outProducer = producer;*outConsumer = consumer;
}

可以看到这个函数中并没有创建BufferQueue，而是创建的BufferQueueCore，可见BufferQueue的核心实现其实是依靠BufferQueueCore的，接着又创建了生产者的具体实现类BufferQueueProducer，消费者的具体实现类BufferQueueConsumer，并且这两个类都持有BufferQueueCore的引用，最后outProducer，outConsumer分别指向创建的生产者-消费者

我们再来看看BufferQueue中有一个很重要的监听器ProxyConsumerListener，

 class ProxyConsumerListener : public BnConsumerListener {public:explicit ProxyConsumerListener(const wp<ConsumerListener>& consumerListener);~ProxyConsumerListener() override;void onDisconnect() override;void onFrameAvailable(const BufferItem& item) override;void onFrameReplaced(const BufferItem& item) override;void onBuffersReleased() override;void onSidebandStreamChanged() override;void addAndGetFrameTimestamps(const NewFrameEventsEntry* newTimestamps,FrameEventHistoryDelta* outDelta) override;private:// mConsumerListener is a weak reference to the IConsumerListener.  This is// the raison d'etre of ProxyConsumerListener.wp<ConsumerListener> mConsumerListener;};

ProxyConsumerListener的最终父类是ConsumerListener，从名字能看出来ProxyConsumerListener是一个代理端，那么ConsumerListener的具体实现端在哪里呢？这个问题我们接着分析代码再看

步骤1的createBufferQueue函数已经看完了，接着看看步骤2：

mProducer = new MonitoredProducer(producer, mFlinger, this);

为生产者对象创建一个MonitoredProducer，这个类完全就是生产者的封装类，它里面的所有函数几乎都是通过传递进去的producer来完成的：

status_t MonitoredProducer::cancelBuffer(int slot, const sp<Fence>& fence) {return mProducer->cancelBuffer(slot, fence);
}int MonitoredProducer::query(int what, int* value) {return mProducer->query(what, value);
}status_t MonitoredProducer::connect(const sp<IProducerListener>& listener,int api, bool producerControlledByApp, QueueBufferOutput* output) {return mProducer->connect(listener, api, producerControlledByApp, output);
}status_t MonitoredProducer::disconnect(int api, DisconnectMode mode) {return mProducer->disconnect(api, mode);
}status_t MonitoredProducer::setSidebandStream(const sp<NativeHandle>& stream) {return mProducer->setSidebandStream(stream);
}void MonitoredProducer::allocateBuffers(uint32_t width, uint32_t height,PixelFormat format, uint64_t usage) {mProducer->allocateBuffers(width, height, format, usage);
}status_t MonitoredProducer::allowAllocation(bool allow) {return mProducer->allowAllocation(allow);
}

再接着看看步骤3：

mConsumer =new BufferLayerConsumer(consumer, mFlinger->getRenderEngine(), mTextureName, this);

这是为消费者创建包装类，先来看看BufferLayerConsumer这个类，继承ConsumerBase

class BufferLayerConsumer : public ConsumerBase

同时在初始化BufferLayerConsumer时调用了父类ConsumerBase的构造函数，将消费者对象传递了过去

BufferLayerConsumer::BufferLayerConsumer(const sp<IGraphicBufferConsumer>& bq,renderengine::RenderEngine& engine, uint32_t tex,Layer* layer): ConsumerBase(bq, false),......}

ConsumerBase是个重点，来看看：

class ConsumerBase : public virtual RefBase,protected ConsumerListener {

看到没有，继承ConsumerListener，前面我们说ProxyConsumerListener的最终父类是ConsumerListener，是作为代理端，那么ConsumerBase很可能就是具体实现端了，而ConsumerBase中又有BufferQueueConsumer消费者对象，所以ConsumerListener的一些具体实现是需要依靠BufferQueueConsumer的，比如onBuffersReleased函数，
ConsumerBase中还有一个比较重要的结构体监听器FrameAvailableListener

struct FrameAvailableListener : public virtual RefBase {// See IConsumerListener::onFrame{Available,Replaced}virtual void onFrameAvailable(const BufferItem& item) = 0;virtual void onFrameReplaced(const BufferItem& /* item */) {}};

这个监听器中有两个和ConsumerListener同名的函数，我们看看ConsumerBase对这两个函数的实现：

void ConsumerBase::onFrameAvailable(const BufferItem& item) {CB_LOGV("onFrameAvailable");sp<FrameAvailableListener> listener;{ // scope for the lockMutex::Autolock lock(mFrameAvailableMutex);listener = mFrameAvailableListener.promote();}if (listener != nullptr) {CB_LOGV("actually calling onFrameAvailable");listener->onFrameAvailable(item);}
}void ConsumerBase::onFrameReplaced(const BufferItem &item) {CB_LOGV("onFrameReplaced");sp<FrameAvailableListener> listener;{Mutex::Autolock lock(mFrameAvailableMutex);listener = mFrameAvailableListener.promote();}if (listener != nullptr) {CB_LOGV("actually calling onFrameReplaced");listener->onFrameReplaced(item);}
}

可以看到，ConsumerBase中这个两个函数具体实现就是调用
FrameAvailableListener的这两个函数，但现在暂时还不知道ConsumerBase的FrameAvailableListener从哪里传递过来的，以及FrameAvailableListener是由哪个类实现的

我们继续看看ConsumerBase的构造函数：

ConsumerBase::ConsumerBase(const sp<IGraphicBufferConsumer>& bufferQueue, bool controlledByApp) :mAbandoned(false),mConsumer(bufferQueue),mPrevFinalReleaseFence(Fence::NO_FENCE) {...wp<ConsumerListener> listener = static_cast<ConsumerListener*>(this);sp<IConsumerListener> proxy = new BufferQueue::ProxyConsumerListener(listener);status_t err = mConsumer->consumerConnect(proxy, controlledByApp);...
}

这里面创建了一个 BufferQueue::ProxyConsumerListener对象，并将ConsumerBase传递了过去，所以这里我们能确定了代理端 BufferQueue::ProxyConsumerListener的具体实现端就是ConsumerBase，接着调用了BufferQueueConsumer消费者的consumerConnect函数，又将BufferQueue::ProxyConsumerListener传递了过去，consumerConnect实现在BufferQueueConsumer.h中：

virtual status_t consumerConnect(const sp<IConsumerListener>& consumer,bool controlledByApp) {return connect(consumer, controlledByApp);}

又调用了自己的connect函数，这个函数实现在BufferQueueConsumer.cpp中：

status_t BufferQueueConsumer::connect(const sp<IConsumerListener>& consumerListener, bool controlledByApp) {ATRACE_CALL();if (consumerListener == nullptr) {BQ_LOGE("connect: consumerListener may not be NULL");return BAD_VALUE;}BQ_LOGV("connect: controlledByApp=%s",controlledByApp ? "true" : "false");std::lock_guard<std::mutex> lock(mCore->mMutex);if (mCore->mIsAbandoned) {BQ_LOGE("connect: BufferQueue has been abandoned");return NO_INIT;}mCore->mConsumerListener = consumerListener;mCore->mConsumerControlledByApp = controlledByApp;return NO_ERROR;
}

看到了吗，从ConsumerBase传递过来的 BufferQueue::ProxyConsumerListener最终赋值给了
BufferQueueCore的mConsumerListener，由此可知BufferQueue果然是一个空壳

监听器传来传去确实容易混乱，我们来总结一下监听器的调用流程，前面createBufferQueue中创建了BufferQueueCore，BufferQueueProducer，BufferQueueConsumer，并且生产者-消费者都持有BufferQueueCore的引用，那么当生产者有消息需要通知消费者时流程就是这样：
生产者调用BufferQueueCore的mConsumerListener某个监听函数，mConsumerListener调到了 BufferQueue::ProxyConsumerListener的同名监听函数， BufferQueue::ProxyConsumerListener这个类创建时接收了ConsumerListener的具体实现类ConsumerBase，所以调到了ConsumerBase的同名监听函数，ConsumerBase中又有消费者对象，所以又可以根据情况调到消费者中去，这样就实现了消费者对生产者的监听

到这里还剩下FrameAvailableListener监听器的具体实现类没有看到

接着分析代码，步骤1，2，3已经分析完了，步骤4没什么分析的，我们看看步骤5：

mConsumer->setContentsChangedListener(this);

通过setContentsChangedListener给消费者设置一个监听器，并且传递的是this，我们先看看当前类继承了哪个监听器，当前类是BufferQueueLayer别忘了：

class BufferQueueLayer : public BufferLayer, public BufferLayerConsumer::ContentsChangedListener {}

继承的是BufferLayerConsumer::ContentsChangedListener，继续看：

class BufferLayerConsumer : public ConsumerBase {
public:......struct ContentsChangedListener : public FrameAvailableListener {virtual void onSidebandStreamChanged() = 0;};

看到这里应该恍然大悟了，原来FrameAvailableListener的具体实现类是BufferQueueLayer，再回到setContentsChangedListener函数：

void BufferLayerConsumer::setContentsChangedListener(const wp<ContentsChangedListener>& listener) {setFrameAvailableListener(listener);Mutex::Autolock lock(mMutex);mContentsChangedListener = listener;
}

调用setFrameAvailableListener将这个监听器继续传递，这个函数BufferLayerConsumer并没有实现，调用的还是父类ConsumerBase的：

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

这个函数仅仅是将传递过来的监听器保存在自己的成员变量mFrameAvailableListener中，以便由生产者那边进行调用，另外setContentsChangedListener中同样将监听器保存在了BufferLayerConsumer的成员变量mContentsChangedListener中，
我们再来总结一下FrameAvailableListener中的onFrameAvailable函数的回调流程：
生产者dequeue一块buffer，应用程序进行绘制，绘制完成后queue此块buffer，此时生产者调用BufferQueueCore的mConsumerListener的onFrameAvailable回调函数，mConsumerListener其实是BufferQueue::ProxyConsumerListener，BufferQueue::ProxyConsumerListener在创建时又接收了ConsumerBase，所以调用到了ConsumerBase的onFrameAvailable中，ConsumerBase这里面又有一个成员变量mFrameAvailableListener，类型为BufferQueueLayer，所以最终是调用到了BufferQueueLayer的具体实现onFrameAvailable中，对这块已经绘制好的buffer进一步处理

到此生产者-消费者模型结构已经大致分析完毕，除了创建最重要的BufferQueueCore，BufferQueueProducer，BufferQueueConsumer，另外就是两个重要的监听器了ConsumerListener，FrameAvailableListener，这两个监听器传过来传过去的，有点容易混乱，需要多看代码。