Android系统Surface机制的SurfaceFlinger服务的线程模型分析

发表于 5年以前  | 总阅读数:2648 次

在前面两篇文章中,我们分析了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;
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

从前面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渲染线程和控制台事件监控线程的交互过程时,我们再分析这个成员函数的实现。

  1. 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渲染过程时,我们就详细分析这个成员函数的实现。

  2. SurfaceFlinger服务的UI渲染线程接下来调用SurfaceFlinger类的成员函数handlePageFlip来通知各个应用程序的Surface将接下来要渲染的图形缓冲区设置为当前激活的图形缓冲区,以便接下来可以渲染到硬件帧缓冲区中去。我们同样会在接下来的一篇文章中分析SurfaceFlinger服务的UI渲染过程时,详细分析这个成员函数的实现。

5. 如果SurfaceFlinger服务的UI渲染线程目前只有一个Surface需要渲染,并且SurfaceFlinger类在编译时,指定了USE_COMPOSITION_BYPASS宏,那么SurfaceFlinger类的成员函数threadLoop就会直接调用另外一个成员函数handleBypassLayer来将这个Surface直接渲染到硬件帧缓冲区中去。这是一个优化操作,避免执行接下来的Surface合成操作。

  1. 如果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;
                }
            }
        }
    }

这个函数定义在文件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;
                }

        ......
    };

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.h中。

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渲染线程的交互过程。

  1. 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();  
        }  
    };  

这个函数定义在文件frameworks/base/libs/surfaceflinger_client/Surface.cpp中。

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

这个函数定义在文件frameworks/base/libs/surfaceflinger_client/ISurfaceComposer.cpp中。

从这里就可以看出,BpSurfaceComposer类的成员函数signal所执行的操作就是向SurfaceFlinger服务发送一个类型为BnSurfaceComposer::SIGNAL的进程间通信请求,而SurfaceFlinger服务是在SurfaceFlinger类的成员函数signal中处理类型为BnSurfaceComposer::SIGNAL的进程间通信请求的,如下所示:

void SurfaceFlinger::signal() const {
        // this is the IPC call
        const_cast<SurfaceFlinger*>(this)->signalEvent();
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

SurfaceFlinger类的成员函数signal调用了另外一个成员函数signalEvent来进一步处理类型为BnSurfaceComposer::SIGNAL的进程间通信请求的,如下所示:

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

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

前面提到,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;
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/MessageQueue.cpp中。

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渲染线程的交互过程。

  1. 控制台事件监控线程与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;
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.cpp中。

从前面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();
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

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

这个函数定义在文件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;
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.cpp中。

当硬件帧缓冲区处于唤醒状态时,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;
        }
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.cpp中。

DisplayHardwareBase类的成员函数releaseScreen首先调用其成员变量mDisplayEventThread所描述的一个控制台事件监控线程的成员函数releaseScreen来执行释放系统显示屏的操作。如果释放成功,那么接下来就会继续将DisplayHardwareBase类的成员变量mScreenAcquired的值设置为false,以表示系统显示屏处于不可访问状态。

DisplayHardwareBase类的成员变量mDisplayEventThread的类型为DisplayEventThread,因此,接下来我们就继续分析DisplayEventThread的成员函数releaseScreen的实现,看看它是如何执行释放系统显示屏的操作的,如下所示:

status_t DisplayHardwareBase::DisplayEventThread::releaseScreen() const
    {
        mBarrier.open();
        return NO_ERROR;
    }

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.cpp中。

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

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

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

这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。

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

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.cpp中。

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

        ......
    };

这个函数定义在文件frameworks/base/services/surfaceflinger/DisplayHardware/DisplayHardwareBase.h中。

从前面的描述可以知道,当前正在执行的DisplayEventThreadBase类的成员函数acquireScreen的线程为SurfaceFlinger服务的UI渲染线程,由于硬件帧缓冲区唤醒之后,它就可以自动地获得系统的显示屏了,并且它不需要与SurfaceFlinger服务的控制台事件监控线程进行交互,因此,DisplayEventThreadBase类的成员函数acquireScreen什么也不用做,直接返回一个成功码NO_ERROR给调用者就可以了。

至此,我们就分析完成SurfaceFlinger服务的控制台事件监控线程与UI渲染线程的交互过程了,整个SurfaceFlinger服务的线程模型也分析完成了。理解了SurfaceFlinger服务的线程模型之后,在接下来的一篇文章中,我们就可以集中火力来分析SurfaceFlinger服务的UI渲染线程是如何将系统UI渲染到硬件帧缓冲区中去的了,敬请关注!

 相关推荐

刘强东夫妇:“移民美国”传言被驳斥

京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。

发布于:6月以前  |  808次阅读  |  详细内容 »

博主曝三大运营商,将集体采购百万台华为Mate60系列

日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。

发布于:6月以前  |  770次阅读  |  详细内容 »

ASML CEO警告:出口管制不是可行做法,不要“逼迫中国大陆创新”

据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。

发布于:6月以前  |  756次阅读  |  详细内容 »

抖音中长视频App青桃更名抖音精选,字节再发力对抗B站

今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。

发布于:6月以前  |  648次阅读  |  详细内容 »

威马CDO:中国每百户家庭仅17户有车

日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。

发布于:6月以前  |  589次阅读  |  详细内容 »

研究发现维生素 C 等抗氧化剂会刺激癌症生长和转移

近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。

发布于:6月以前  |  449次阅读  |  详细内容 »

苹果据称正引入3D打印技术,用以生产智能手表的钢质底盘

据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。

发布于:6月以前  |  446次阅读  |  详细内容 »

千万级抖音网红秀才账号被封禁

9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...

发布于:6月以前  |  445次阅读  |  详细内容 »

亚马逊股东起诉公司和贝索斯,称其在购买卫星发射服务时忽视了 SpaceX

9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。

发布于:6月以前  |  444次阅读  |  详细内容 »

苹果上线AppsbyApple网站,以推广自家应用程序

据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。

发布于:6月以前  |  442次阅读  |  详细内容 »

特斯拉美国降价引发投资者不满:“这是短期麻醉剂”

特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。

发布于:6月以前  |  441次阅读  |  详细内容 »

光刻机巨头阿斯麦:拿到许可,继续对华出口

据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。

发布于:6月以前  |  437次阅读  |  详细内容 »

马斯克与库克首次隔空合作:为苹果提供卫星服务

近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。

发布于:6月以前  |  430次阅读  |  详细内容 »

𝕏(推特)调整隐私政策,可拿用户发布的信息训练 AI 模型

据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。

发布于:6月以前  |  428次阅读  |  详细内容 »

荣耀CEO谈华为手机回归:替老同事们高兴,对行业也是好事

9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。

发布于:6月以前  |  423次阅读  |  详细内容 »

AI操控无人机能力超越人类冠军

《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。

发布于:6月以前  |  423次阅读  |  详细内容 »

AI生成的蘑菇科普书存在可致命错误

近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。

发布于:6月以前  |  420次阅读  |  详细内容 »

社交媒体平台𝕏计划收集用户生物识别数据与工作教育经历

社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”

发布于:6月以前  |  411次阅读  |  详细内容 »

国产扫地机器人热销欧洲,国产割草机器人抢占欧洲草坪

2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。

发布于:6月以前  |  406次阅读  |  详细内容 »

罗永浩吐槽iPhone15和14不会有区别,除了序列号变了

罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。

发布于:6月以前  |  398次阅读  |  详细内容 »
 目录