1分钟部署网站📞AI智能客服,大模型训练自有数据,简单好用,有效降低客服成本 广告
根据前文分析可知,Surface系统中的CB,其实是指SharedBuffer家族,它们是Surface系统中对生产者和消费者进行步调控制的中枢机构。先通过图8-24来观察整体的工作流程是怎样的。 :-: ![](http://img.blog.csdn.net/20150802163013569?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-24 SharedBuffer家族使用流程 为书写方便起见,我们简称: - SharedBufferServer为SBS。 - SharedBufferClient为SBC。 - SharedBufferStack为SBT。 其中SBC和SBS都是建立在同一个SBT上的,所以应先看SBT,下面代码列出了其中几个与读写控制有关的成员变量: **SharedBufferStack.h** ~~~ class SharedBufferStack{ ...... /* 虽然PageFlipping使用Front和Back两个Buffer就可以了,但是SBT的结构和相关算法 是支持多个缓冲的。另外,缓冲是按照块来获取的,也就是一次获得一块缓冲,每块缓冲用 一个编号表示(这一点在之前的分析已经介绍过了)。 */ int32_t head; int32_tavailable; //当前可用的空闲缓冲个数 int32_t queued; //SBC投递的脏缓冲个数 int32_tinUse; //SBS当前正在使用的缓冲编号 ......//上面这几个参数联合SBC中的tail,我称之为控制参数。 } ~~~ SBT创建好后,下面就是SBS和SBC的创建了,它们会做什么特殊工作吗? 1. SBS和SBC的创建 下面分别看SBS和SBC的创建,代码如下所示: **SharedBufferStack.cpp** ~~~ SharedBufferServer::SharedBufferServer(SharedClient*sharedClient, int surface, int num, int32_t identity) :SharedBufferBase(sharedClient, surface, num, identity) { mSharedStack->init(identity);//这个函数将设置inUse为-1 //下面设置SBT中的参数,我们关注前三个 mSharedStack->head = num-1; mSharedStack->available = num; mSharedStack->queued = 0; //设置完后,head=2-1=1,available=2,queued=0,inUse=-1 mSharedStack->reallocMask = 0; memset(mSharedStack->dirtyRegion, 0,sizeof(mSharedStack->dirtyRegion)); } ~~~ 再看SBC的创建,代码如下所示: **SharedBufferStack.cpp** ~~~ SharedBufferClient::SharedBufferClient(SharedClient*sharedClient, int surface, int num, int32_t identity) :SharedBufferBase(sharedClient, surface, num, identity), tail(0) { tail =computeTail(); //tail是SBC定义的变量,注意它不是SBT定义的。 } ~~~ 看computeTail函数的代码: **SharedBufferStack.cpp** ~~~ int32_t SharedBufferClient::computeTail() const { SharedBufferStack& stack( *mSharedStack ); int32_t newTail; int32_t avail; int32_t head; do { avail = stack.available; //available=2,head=1 head = stack.head; }while (stack.available != avail); newTail = head - avail + 1;//newTail=1-2+1=0 if(newTail < 0) { newTail += mNumBuffers; } elseif (newTail >= mNumBuffers) { newTail -= mNumBuffers; } return newTail;//计算得到newTail=0 } ~~~ 来看在SBC和SBS创建后,控制参数的变化,如图8-25所示: :-: ![](http://img.blog.csdn.net/20150802163038607?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-25 SBC/SBS创建后的示意图 2. SBC端流程的分析 下面看SBC端的工作流程。 (1)dequeue分析 先看SBC的dequeue函数: **SharedBufferStack.cpp** ~~~ ssize_t SharedBufferClient::dequeue() { SharedBufferStack& stack( *mSharedStack ); ...... //DequeueCondition函数对象 DequeueCondition condition(this); status_t err = waitForCondition(condition); //成功以后,available减1,表示当前可用的空闲buffer只有1个 if (android_atomic_dec(&stack.available) == 0) { ...... } int dequeued = tail; //tail值为0,所以dequeued的值为0。 //tail加1。如果超过2,则重新置为0,这表明tail的值在0,1间循环。 tail =((tail+1 >= mNumBuffers) ? 0 : tail+1); ...... //返回的这个dequeued值为零,也就是tail加1操作前的旧值。这一点请读者务必注意。 returndequeued; } ~~~ 其中DequeueCondition的操作函数很简单,代码如下所示: ~~~ bool SharedBufferClient::DequeueCondition::operator()(){ returnstack.available > 0;//只要available大于0就算满足条件,第一次进来肯定满足 } ~~~ 用图8-26来表示dequeue的结果: :-: ![](http://img.blog.csdn.net/20150802163105267?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-26 dequeue结果图 注意,在上图中,0号缓冲用虚线表示,SBC的dequeue函数的返回值用dequeued表示,它指向这个0号缓冲。正如代码中注释的那样,由于dequeued的值用的是tail的旧值,而tail是SBC定义的变量,不是SBT定义的变量,所以tail在SBS端是不可见的。这就带来了一个潜在危险,即0号缓冲不能保证当前是真正空闲的,因为SBS可能正在用它,怎么办?试看下面的lock。 (2)lock的分析 lock使用了LockCondition,其中传入的参数buf的值为0,也就是上图中的dequeue的值,代码如下所示: **SharedBufferStack.cpp** ~~~ status_t SharedBufferClient::lock(int buf) { LockCondition condition(this, buf); status_terr = waitForCondition(condition); returnerr; } ~~~ 看LockCondition的()函数: ~~~ boolSharedBufferClient::LockCondition::operator()() { /* 这个条件其实就是判断编号为buf的Buffer是不是被使用了。 buf值为0,head值为1,queued为0,inUse为-1 */ return(buf != stack.head || (stack.queued > 0 && stack.inUse!= buf)); } ~~~ 现在可以知道为什么SBC需要调用dequeue和lock函数了吗?原来: - dequeue只是根据本地变量tail计算一个本次应当使用的Buffer编号,其实也就是在0,1之间循环。上次用0号缓冲,那么这次就用1号缓冲。 - lock函数要确保这个编号的Buffer没有被SF当做FrontBuffer使用。 (3)queue的分析 Activity端在绘制完UI后,将把BackBuffer投递出去以显示。接着上面的流程,这个BackBuffer的编号是0。待Activity投递完后,才会调用signal函数触发SF消费,所以在此之前格局不会发生变化。试看投递用的queue函数,注意传入的buf参数为0,代码如下所示: **SharedBufferStack.cpp** ~~~ status_t SharedBufferClient::queue(int buf) { QueueUpdate update(this); status_t err = updateCondition( update ); ...... returnerr; } //直接看这个QueueUpdate函数对象 ssize_tSharedBufferClient::QueueUpdate::operator()() { android_atomic_inc(&stack.queued);//queued增加1,现在该值由零变为1 returnNO_ERROR; } ~~~ 至此,SBC端走完一个流程了,结果是什么?如图8-27所示: :-: ![](http://img.blog.csdn.net/20150802163251975?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-27 queue结果图 0号缓冲被移到queue的区域了,可目前还没有变量指向它。假设SBC端此后没有绘制UI的需求,那么它就会沉默一段时间。 3. SBS端的分析 SBS的第一个函数是retireAndLock,它使用了RetireUpdate函数对象,代码如下所示: **SharedBufferStack.cpp** ~~~ ssize_t SharedBufferServer::retireAndLock() { RetireUpdate update(this, mNumBuffers); ssize_t buf = updateCondition( update ); returnbuf; } ~~~ 这个RetireUpdate对象的代码如下所示: ~~~ ssize_tSharedBufferServer::RetireUpdate::operator()() { //先取得head值,为1 int32_t head = stack.head; //inUse被设置为1。表明要使用1吗?目前的脏缓冲应该是0才对 android_atomic_write(head, &stack.inUse); int32_tqueued; do { queued = stack.queued; //queued目前为1 if(queued == 0) { return NOT_ENOUGH_DATA; } //下面这个原子操作使得stack.queued减1. }while (android_atomic_cmpxchg(queued, queued-1, &stack.queued)); //while循环退出后,queued减1,又变为0。 //head值也在0,1间循环,现在head值变为0了 head =((head+1 >= numBuffers) ? 0 : head+1); //inUse被设置为0 android_atomic_write(head, &stack.inUse); // head值被设为0 android_atomic_write(head, &stack.head); // available加1,变成2. android_atomic_inc(&stack.available); returnhead;//返回0 } ~~~ retireAndLock的结果是什么呢?看看图8-28就知道了。 :-: ![](http://img.blog.csdn.net/20150802163200023?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-28 retireAndLock结果图 注意上面的available区域,1号缓冲右边的0号缓冲是用虚线表示的,这表示该0号缓冲实际上并不存在于available区域,但available的个数却变成2了。这样不会出错吗?当然不会,因为SBC的lock函数要确保这个缓冲没有被SBS使用。 我们来看SBS端最后一个函数,它调用了SBS的unlock,这个unlock使用了UnlockUpdate函数对象,就直接了解它好了,代码如下所示: **SharedBufferStack.cpp** ~~~ ssize_tSharedBufferServer::UnlockUpdate::operator()() { ...... android_atomic_write(-1, &stack.inUse);//inUse被设置为-1 returnNO_ERROR; } ~~~ unlock后最终的结果是什么呢?如图8-29所示: :-: ![](http://img.blog.csdn.net/20150802163326841?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center) 图8-29 unlock结果图 比较一下图8-29和图8-25,可能会发现两图中tail和head刚好反了,这就是PageFlip。另外,上面的函数大量使用了原子操作。原子操作的目的就是为了避免锁的使用。值得指出的是,updateConditon函数和waitForCondition函数都使用了Mutex,也就是说,上面这些函数对象又都是在Mutex锁的保护下执行的,为什么会这样呢?先来看一段代码: ~~~ 像下面这样的代码,如果有锁控制的话根本用不着一个while循环,因为有锁的保护,没有其他线程 能够修改stack.queued的值,所以用while来循环判断android_atomic_cmpxchg没有什么意义。 int32_tqueued; do { queued = stack.queued; if(queued == 0) { return NOT_ENOUGH_DATA; } }while (android_atomic_cmpxchg(queued, queued-1, &stack.queued)); ~~~ 对于上面这个问题,我目前还不知道答案,但对其也进行了修改,把函数对象放在锁外执行,结果在真机上运行没有出现任何异常现象。也许Google或哪位读者能给这个问题一个较好的解释。 为什么我对生产/消费的同步控制如此感兴趣呢?这和自己工作的经历有些关系。因为之前曾做过一个单写多读的跨进程缓冲类,也就是一个生产者,多个消费者。为了保证正确性和一定的效率,我们在算法上曾做了很多改进,但还是大量使用了锁,所以我很好奇Google是怎么做到的,这也体现了一个高手的内功修养。要是由读者自己来实现,结果会怎样呢?