Android 7.1 GUI系统-surfaceflinger（四）

ゝ一纸荒年。 2022-06-05 11:12 253阅读 0赞

surfaceflinger的启动：

[Android P 图形显示系统][Android P] [https://www.jianshu.com/u/f92447ae8445][https_www.jianshu.com_u_f92447ae8445]

Android GUI系统之SurfaceFlinger [https://blog.csdn.net/vviccc/article/details/104860616][https_blog.csdn.net_vviccc_article_details_104860616]

frameworks/native/services/surfaceflinger/surfaceflinger.rc
    service surfaceflinger /system/bin/surfaceflinger
        class core
        user system
        group graphics drmrpc readproc
        onrestart restart zygote
        writepid /dev/stune/foreground/tasks

surfaceflinger属于系统的底层支撑服务，应该在系统开机的早期就要起来，比如开机动画的绘制就要依赖surfaceflinger，从它的rc文件可知，这个服务的class是core，所以在解析init.rc时，通过class\_startcore就启动了所有class是core的服务。而且在surfaceflinger重启时，关键进程zygote也会重启。

插播截取的一段init.rc的代码看下究竟：

system/core/rootdir/init.rc
    //长按power键，Healthd会通过发一个property信号触发一个full boot，也即是当属性sys.boot_from_charger_mode满足了值为1时就会触发，接着会触发late-init 这个action。
    on property:sys.boot_from_charger_mode=1
    	class_stop charger
    	trigger late-init
    
    //late-init这个action，主要是挂载文件系统，然后触发boot。
    on late-init
    	trigger early-fs
    	trigger fs
    	trigger late-fs
    	trigger boot
    
    //在boot事件中，基础网络初始话，基本的kernel参数，系统服务和后台进程的权限设置等，最后启动class类型是core的系统服务。
    on boot
    	hostname localhost
    	write /proc/sys/vm/overcommit_memory 1
    	chmod 0664 /sys/module/lowmemorykiller/parameters/adj
    	chown system system /sys/power/state
    	class_start core

接着分析surfaceflinger的启动。

main\_surfaceflinger.cpp

int main(int, char**)@main_surfaceflinger.cpp {
    //下面这三行代码是一个独立的进程起来时，必须调用的，其中ps->startThreadPool()会间接调用到IPCThreadState::self()->joinThreadPool(mIsMain);最终让这个进程进入一个binder_loop的循环。
    	ProcessState::self()->setThreadPoolMaxThreadCount(4);
    	sp<ProcessState> ps(ProcessState::self());
    	ps->startThreadPool();
    //实例化一个surfaceflinger，就是new SurfaceFlinger();
    	sp<SurfaceFlinger> flinger = DisplayUtils::getInstance()→getSFInstance();
    //设置进程优先级，PRIORITY_URGENT_DISPLAY这是级别还是很高的。
    	setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
    //在client发起连接之前执行初始化。
    	flinger→init();
    //把surfaceflinger，GpuService注册到ServiceManager。
    	sp<IServiceManager> sm(defaultServiceManager());
    	sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false);
    	sp<GpuService> gpuservice = new GpuService();
    	sm->addService(String16(GpuService::SERVICE_NAME), gpuservice, false);
    //运行surfaceflinger，等待client的请求。
    	flinger->run();
    	return 0;
    }

SurfaceFlinger的构造函数中没有做太多事情，只是给变量赋了初始值，在它第一次被引用时会执行其onFirstRef函数。

void SurfaceFlinger::onFirstRef()@SurfaceFlinger.cpp{
    //初始化事件队列MessageQueue，
        mEventQueue.init(this);
    }

//这个MessageQueue.cpp是surfaceflinger自定义的，是消息循环处理机制的管理者，但是并不是系统标准的消息队列。

void MessageQueue::init(const sp<SurfaceFlinger>& flinger)@MessageQueue.cpp{
        mFlinger = flinger;
    //Looper是系统中通用的实现，system/core/libutils/looper.cpp
        mLooper = new Looper(true);
    //Handler也是surfaceflinger自定义的一个事件处理器，是MessageQueue.h的内部类，并不是通用的Handler。
        mHandler = new Handler(*this);
    }

//surfaceflinger的初始化，包括egl的运行环境的设置，跟vsync脉冲信号有关的EventThread等。这块内容不在这里做展开。

void SurfaceFlinger::init() @SurfaceFlinger.cpp{
    	mEGLDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    	eglInitialize(mEGLDisplay, NULL, NULL);
    	sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,
    		vsyncPhaseOffsetNs, true, "app");
    	mEventThread = new EventThread(vsyncSrc, *this);
    	mHwc = new HWComposer(this);
    	mHwc->setEventHandler(static_cast<HWComposer::EventHandler*>(this));
    	mEventControlThread = new EventControlThread(this);
    	mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);
    	initializeDisplays();
    }

接下来分析surfaceflinger的工作线程是怎么运行起来的。

void SurfaceFlinger::run() @SurfaceFlinger.cpp{
    //可以看到这里是一个无线循环。
        do {
            waitForEvent();
        } while (true);
    }

//进一步调用MessageQueue中的waitMessage。

void SurfaceFlinger::waitForEvent() @SurfaceFlinger.cpp{
        mEventQueue.waitMessage();
    }

//这里依然是死循环，永远不会跳出，即使发生了错误，这也可以理解，surfaceflinger是整个GUI系统的核心，如果它退出了，基本系统也就瘫了。

void MessageQueue::waitMessage() @MessageQueue.cpp{
        do {
            IPCThreadState::self()->flushCommands();
            int32_t ret = mLooper->pollOnce(-1);
            switch (ret) {
                case Looper::POLL_WAKE:
                case Looper::POLL_CALLBACK:
                    continue;
                case Looper::POLL_ERROR:
                    ALOGE("Looper::POLL_ERROR");
                    continue;
                case Looper::POLL_TIMEOUT:
                    // timeout (should not happen)
                    continue;
                default:
                    // should not happen
                    ALOGE("Looper::pollOnce() returned unknown status %d", ret);
                    continue;
            }
        } while (true);
    }

在上面的循环中，会通过mLooper->pollOnce(-1);不断的读取消息进行处理。前面说过这里的MessageQueue并不是android系统通用的消息队列，它是消息循环处理机制的管理者，在它的init函数中也看到，内部包含了looper和hander，Looper中的mMessageEnvelopes才是真正存储消息的地方，而这个handle也只是一个中介，并没有实际去处理发给surfaceflinger的消息请求，而是进一步回调了surfaceflinger的onMessageReceived方法。

void MessageQueue::Handler::handleMessage(const Message& message) @MessageQueue.cpp{
        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;
        }
    }

通过上面的分析，知道surfaceflinger的消息处理框架是通过MessageQueue把消息请求发送到Looper的mMessageEnvelopes队列，然后通过mLooper->pollOnce(-1);方法依次取出事件处理，其中的handle会把INVALIDATE，REFRESH这两类消息请求转给surfaceflinger做实质的处理。

应用程序向surfaceflinger发送的消息请求分同步、异步两种，异步推送就是消息发过去就直接返回了，不需要等待执行结果。接下来主要看下同步的请求是怎么处理的？

以前面的应用程序申请创建一个layer为例：

status_t Client::createSurface()@Client.cpp{
    	 class MessageCreateLayer : public MessageBase {
    		virtual bool handler() {
    			result = flinger->createLayer(name, client, w, h, format, flags,
    				handle, gbp);
    			return true;
    		}
    	}
    	sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(),…);
    	mFlinger->postMessageSync(msg);
    }

省略了很多代码，只关注消息处理相关的，这里通过postMessageSync发出一个同步消息，

status_t SurfaceFlinger::postMessageSync(const sp<MessageBase>& msg,
            nsecs_t reltime, uint32_t /* flags */) @SurfaceFlinger.cpp{
        status_t res = mEventQueue.postMessage(msg, reltime);
        if (res == NO_ERROR) {
            msg->wait();
        }
        return res;
    }

在上面的函数中，除了调用mEventQueue.postMessage把消息入队外，还调用了msg->wait();这个wait从字面意思也能看出是让调用者线程挂起了。

//下面的MessageQueue依然是surfaceflinger自定义的类。

MessageQueue.h
    class MessageBase : public MessageHandler{
    	void wait() const { barrier.wait(); }
    }

这里是使用barrier来实现的同步，这个barrier只在surfaceflinger中有使用，应该说是专门为surfaceflinger设计的，所以有必要去了解下它的实现原理：

frameworks/native/services/surfaceflinger/Barrier.h
    class Barrier
    {
    public:
        inline Barrier() : state(CLOSED) { }
        inline ~Barrier() { }
    //释放等待在这个barrier上的线程。
        void open() {
            Mutex::Autolock _l(lock);
            state = OPENED;
            cv.broadcast();
        }
    //重新设置barrier，wait方法会被block，直到open方法被调用。
        void close() {
            Mutex::Autolock _l(lock);
            state = CLOSED;
        }
    //这里会一直等待，直到barrier的状态是OPEN。
        void wait() const {
            Mutex::Autolock _l(lock);
            while (state == CLOSED) {
                cv.wait(lock);
            }
        }
    private:
        enum { OPENED, CLOSED };
        mutable     Mutex       lock;
        mutable     Condition   cv;
        volatile    int         state;
    };

可以看到barrier是基于Mutex和condition实现的一个模型。Mutex实际上是基于pthread接口的在封装，只要是涉及到对某个共享资源的访问，都可以认为是Mutex的问题领域；但是有时候对某一个共享资源的访问的目的，只是想判断它是不是满足了某个条件，比如state==CLOSED，并且什么时候满足这一条件是未知的，这种情况下，如果依然用Mutex来处理，就要一直去轮询，这显然是太浪费cpu资源了，所以才有了condition，但是condition本身并不完整，比如它没有指定具体的条件是什么，所以它需要被填充了具体条件才能真正的使用，这里的barrier就是一个填充了具体条件的condition，这里的具体条件就是state == CLOSED或者state == OPEN。

介绍完了Barrier的实现原理，再来看下它是怎么使用的，postMessageSync时调用了barrier.wait()把调用者线程挂起，那什么时候把它唤醒呢？一种可能的情况就是这个消息请求被处理了，就应该把调用者唤醒，让他继续执行未完成的工作。

所以要从消息处理的接口入手：

前面分析过，在MessageQueue的waitMessage中，是通过mLooper->pollOnce(-1);不断的读取消息进行处理的。

system/core/libutils/Looper.cpp
    int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) @Looper.cpp{
    	result = pollInner(timeoutMillis);
    }

//从pollInner看出，它调用了message的handle中的方法handleMessage。

int Looper::pollInner(int timeoutMillis) {
    	const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
    	sp<MessageHandler> handler = messageEnvelope.handler;
    	handler->handleMessage(message);
    }

所以要看发送的那条消息中的handler是哪里来的？

MessageCreateLayer继承自MessageBase(MessageQueue.cpp中)，

MessageQueue.cpp
    void MessageBase::handleMessage(const Message&) {
        this->handler();
        barrier.open();
    };

由于MessageBase的handler的方法是纯虚函数，所以这里调用的handle是子类的handler的方法，也即是MessageCreateLayer中的handler方法，这个方法会调用surfaceflinger来完成请求。

然后调用了barrier.open();唤醒被等待的线程。

分析了surfaceflinger的消息处理机制，再来看应用程序端是如何跟surfaceflinger通信的。

前面在分析BufferQueue时，引用过GLTest::SetUp()中一段代码，其中创建了SurfaceComposerClient实例，可以作为应用程序跟surfaceflinger通信的一个桥梁。

SurfaceComposerClient.cpp
    void SurfaceComposerClient::onFirstRef() {
        sp<ISurfaceComposer> sm(ComposerService::getComposerService());
        if (sm != 0) {
            sp<ISurfaceComposerClient> conn = sm->createConnection();
            if (conn != 0) {
                mClient = conn;
                mStatus = NO_ERROR;
            }
        }
    }

上面的实现中，首先获取surfaceflinger的句柄ISurfaceComposer，这个名字起的容易误解，surfaceflinger虽然注册在ServiceManager中的名字是“surfaceflinger”，但是其服务端实现的binder接口却是ISurfaceComposer，可以从它的继承关系得到验证：

class SurfaceFlinger : public BnSurfaceComposer,private Ibinder::DeathRecipient,
    	private HWComposer::EventHandler{}
    
    接着SurfaceComposerClient::onFirstRef() 分析，通过surfaceflinger的 createConnection返回一个ISurfaceComposerClient 实例，ISurfaceComposerClient对应的服务端是Client，
    sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
    	@SurfaceFlinger.cpp{
        sp<ISurfaceComposerClient> bclient;
        sp<Client> client(new Client(this));
        status_t err = client->initCheck();
        if (err == NO_ERROR) {
            bclient = client;
        }
        return bclient;
    }

这个Client才是surfaceflinger跟应用程序交互的纽带，比如应用程序申请surface的请求就是经过client传递到surfaceFlinger，可以任务client是surfaceflinger安排在应用程序中一个代理，任何有UI界面的应用程序在surfaceflinger中都有对应的Client实例，但是应用程序并没有直接使用Client，而是通过ISurfaceComposerClient，ISurfaceComposerClient是应用程序与Client之间的binder接口，所以应用程序端一个请求先是通过ISurfaceComposerClient，然后传到Client，client收到者请求后，没有让surfaceflinger马上执行，而是把让先投递到surfaceflinger的消息队列，然后让client所在的线程wait，因为surfaceflinger会处理所有应用程序的请求，不能来一个请求就就打断surfaceflinger正在执行的操作，最后SurfaceFlinger处理完成后，返回结果，唤醒wait的应用程序。

[Android P]: https://www.jianshu.com/p/824a9ddf68b9
[https_www.jianshu.com_u_f92447ae8445]: https://www.jianshu.com/u/f92447ae8445
[https_blog.csdn.net_vviccc_article_details_104860616]: https://blog.csdn.net/vviccc/article/details/104860616