Android GUI之SurfaceFlinger_android13 surfaceflinger

Android GUI之surfaceFlinger

本文内容来源与网络

0 网址

https://www.jianshu.com/p/20435433f677
https://blog.csdn.net/haigand/article/details/90489336

1 图像系统说明

转载
https://www.jianshu.com/p/20435433f677

1）linux内核提供统一的设备驱动，/dev/graphics/fb*
2) Android HAL 提供2个接口 Gralloc & fb
fb 负责打开framebuffer，提供接口操作。gralloc负责管理帧缓冲区的分配和释放。
composer是HAL中另一个重要的功能，它主要是给厂商定制UI合成。SurfaceFlinger中负责HWComposer会用到这个功能。
而且关键是HWComposer还负责产生VSync信号，这是本期SurfaceFlinger的重点。
3）由于OpenGL是一套通用的库（大部分就是接口），所以它需要一个本地的实现。andorid平台OpenGL有2个本地窗口，FrameBufferNativeWindow & Surface。
4）OpenGL可以有软件 或者依托于硬件实现，具体的运行状态，就是由EGL来配置。
5）SurfaceFlinger持有一个成员数组mDisplays来支持各种显示设备。DisplayDevices在初始化的时候调用EGL来搭建OpenGL的环境

1-1 Gralloc与Framebuffer

Linux内核提供了统一的framebuffer显示驱动。Framebuffer是内核系统提供的图形硬件的抽象描述，称为buffer是因为它也占用了系统存储空间的一部分，是一块包含屏幕显示信息的缓冲区。
Framebuffer借助于Linux文件系统向上层应用提供了统一而高效的操作接口，让用户空间运行的程序比较容易地适配多种显示设备。
Android系统中，framebuffer提供的设备节点为/dev/graphics/fb或者/dev/fb，其中fb0表示第一个主显示屏幕，必须存在，当前系统实现中只用到了一个显示屏。
显示系统使用HAL层间接引用底层架构，从而操作帧缓冲区。而完成这一中介任务的就是Gralloc.

Gralloc对应的模块是由FramebufferNativeWindow在构造函数加载的，Gralloc包括fb和gralloc两个设备，前者负责打开内核中的Framebuffer、初始化配置,并提供了post、setSwapInterval等操作接口。后者则管理帧缓冲区的分配和释放。

1-2 本地窗口（Native Window）

Native Window为OpenGL与本地窗口系统之间搭建了桥梁。整个ＧGUI系统至少需要两种本地窗口：
（1）面向管理者（SurfaceFlinger）
SurfaceFlinger是系统中所有UI界面的管理者，需要直接或间接的持有“本地窗口”，此本地窗口是FramebufferNativeWindow。
（2）面向应用程序
这类本地窗口是Surface。

2 SurfaceFlinger

转载
https://www.cnblogs.com/blogs-of-lxl/p/11272756.html
https://www.cnblogs.com/1996swg/p/9790209.html
https://blog.csdn.net/haigand/article/details/90489336

相关类图

因为SurfaceFlinger 要管理多个应用程序的多个窗口界面，为了进行管理它提供了一个Client 类，每个来请求服务的应用程序就对应了一个Client 。

为应用程序创建一个 Client 以后，下面需要做的就是为这个 Client 分配 Surface ， Flinger 为每个 Client 提供了 8M的空间，包括控制信息和存储内容的 buffer 。
创建 Layer 的过程，首先是由这个应用程序的 Client 根据应用程序的 pid 生成一个唯一的 layer ID ，然后根据大小，位置，格式啊之类的信息创建出 Layer 。在 Layer 里面有一个嵌套的 Surface 类，它主要包含一个 ISurfaceFlingerClient::Surface_data_t ，包含了这个 Surace 的统一标识符以及 buffer信息等，提供给应用程序使用。最后应用程序会根据返回来的 ISurface 信息等创建自己的一个 Surface 。

Android 提供了 4 种类型的 layer 供选择，每个 layer 对应一种类型的窗口，并对应这种窗口相应的操作：

Layer ， LayerBlur ， LayerBuffer ，LayerDim 。
Norm Layer 是 Android 种使用最多的一种 Layer ，一般的应用程序在创建 surface 的时候都是采用的这样的 layer ，了解 Normal Layer 可以让我们知道 Android 进行 display 过程中的一些基础原理。 Normal Layer 为每个 Surface 分配两个 buffer ： front buffer 和 back buffer ，这个前后是相对的概念，他们是可以进行 Flip 的。 Front buffer 用于 SurfaceFlinger 进行显示，而 Back buffer 用于应用程序进行画图，当 Back buffer 填满数据 (dirty) 以后，就会 flip， back buffer 就变成了 front buffer 用于显示，而 front buffer 就变成了 back buffer 用来画图，这两个 buffer 的大小是根据 surface 的大小格式动态变化的。

LayerBuffer 也是将来必定会用到的一个 Layer ，个人觉得也是最复杂的一个 layer ，它不具备 render buffer ，主要用在 camera preview / video playback 上。它提供了两种实现方式，一种就是 post buffer ，另外一种就是我们前面提到的 overlay ， Overlay 的接口实际上就是在这个 layer 上实现的。不管是 overlay 还是 post buffer 都是指这个 layer 的数据来源自其他地方，只是 post buffer 是通过软件的方式最后还是将这个 layer merge 主的 FB，而 overlay 则是通过硬件 merge 的方式来实现。与这个 layer 紧密联系在一起的是 ISurface 这个接口

SurfaceFlinger 是一个线程类，它继承了 Thread 类。当创建 SurfaceFlinger这个服务的时候会启动一个 SurfaceFlinger 监听线程，这个线程会一直等待事件的发生，比如说需要进行 sruface flip ，或者说窗口位置大小发生了变化等等，一旦产生这些事件，SurfaceComposerClient 就会通过 IBinder 发出信号，这个线程就会结束等待处理这些事件，处理完成以后会继续等待，如此循环。

在对 Surface 进行画图之前必须锁定 Surface 的 layer ，实际上就是锁定了 Layer_cblk_t 里的 swapstate 这个变量。SurfaceComposerClient 通过 swapsate 的值来确定要使用哪个 buffer 画图。所以应用程序先调用 lockSurface() 锁定 layer 的 swapstate ，并获得画图的 buffer 然后就可以在上面进行画图了，完成以后就会调用unlockSurfaceAndPost() 来通知 SurfaceFlinger 进行 Flip。或者仅仅调用 unlockSurface() 而不通知 SurfaceFlinger 。
SurfaceFlinger 只是执行 Windows manager 的指令，由 Windows manager 来决定什么时候改变大小，位置，设置 透明度，以及如何调整 layer 之间的顺序， SurfaceFlinger 仅仅只是执行它的指令。
surfaceFlinger线程处理

2-1 SurfaceFlinger 初始化

/frameworks/native/services/surfaceflinger/main_surfaceflinger.cpp 入口文件

int main(int, char**) {
    signal(SIGPIPE, SIG_IGN);

    hardware::configureRpcThreadpool(1 /* maxThreads */,
            false /* callerWillJoin */);

    startGraphicsAllocatorService();

    // When SF is launched in its own process, limit the number of
    // binder threads to 4.
    ProcessState::self()->setThreadPoolMaxThreadCount(4);

    // start the thread pool
    sp<ProcessState> ps(ProcessState::self());
    ps->startThreadPool();
    sp<SurfaceFlinger> flinger = surfaceflinger::createSurfaceFlinger();

    setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
..........................
    // SurfaceFlinger类正式初始化
    // initialize before clients can connect
    flinger->init();
    // publish surface flinger
    sp<IServiceManager> sm(defaultServiceManager());
    sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false,
                   IServiceManager::DUMP_FLAG_PRIORITY_CRITICAL | IServiceManager::DUMP_FLAG_PROTO);
    startDisplayService(); // dependency on SF getting registered above

    if (SurfaceFlinger::setSchedFifo(true) != NO_ERROR) {
        ALOGW("Couldn't set to SCHED_FIFO: %s", strerror(errno));
    }
    // run surface flinger in this thread
    flinger->run();

    return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

这里设置的binder线程只有四个

再看SurfaceFlinger.cpp

void SurfaceFlinger::onFirstRef()
{
    mEventQueue.init(this);
}
void MessageQueue::init(const sp<surfaceflinger>& flinger)
{
    mFlinger = flinger;
    mLooper = new Looper(true);
    mHandler = new Handler(*this);
}
1
2
3
4
5
6
7
8
9
10

此处MessageQueue不是常见的消息队列，在surfaceFlinger目录单独编写，mEventQueue更像是消息循环机制的管理者，其中包含了一个looper，一个handler。looper中的mMessageEnvelopes这个容器才是真正存储消息的地方.　handler也不是常见的那个handler，而是Messagequeue中自定义的一个事件处理器，是专门为surfaceflinger设计的，handler收到消息，进一步回调surfaceflinger中的onMessageReceived。

void MessageQueue::Handler::handleMessage(constMessage& message) {
         switch(message.what) {
                   caseINVALIDATE:
                            mQueue.mFlinger->onMessageReceived(message.what);
1
2
3
4

接着是surfaceFlinger::init，方法主要实现的功能：

初始化EGL
创建HWComposer
初始化非虚拟显示屏
启动EventThreada线程
启动开机动画

void SurfaceFlinger::init() {
    ALOGI(  "SurfaceFlinger's main thread ready to run. "
            "Initializing graphics H/W...");
    Mutex::Autolock _l(mStateLock);

    // Get a RenderEngine for the given display / config (can't fail)
    // TODO(b/77156734): We need to stop casting and use HAL types when possible.
    // Sending maxFrameBufferAcquiredBuffers as the cache size is tightly tuned to single-display.
    mCompositionEngine->setRenderEngine(renderengine::RenderEngine::create(
            renderengine::RenderEngineCreationArgs::Builder()
                .setPixelFormat(static_cast<int32_t>(defaultCompositionPixelFormat))
                .setImageCacheSize(maxFrameBufferAcquiredBuffers)
                .setUseColorManagerment(useColorManagement)
                .setEnableProtectedContext(enable_protected_contents(false))
                .setPrecacheToneMapperShaderOnly(false)
                .setSupportsBackgroundBlur(mSupportsBlur)
                .setContextPriority(useContextPriority
                        ? renderengine::RenderEngine::ContextPriority::HIGH
                        : renderengine::RenderEngine::ContextPriority::MEDIUM)
                .build()));
    mCompositionEngine->setTimeStats(mTimeStats);

    mCompositionEngine->setHwComposer(getFactory().createHWComposer(getBE().mHwcServiceName));
1   mCompositionEngine->getHwComposer().setConfiguration(this, getBE().mComposerSequenceId);

    // Process any initial hotplug and resulting display changes.
2   processDisplayHotplugEventsLocked();
    const auto display = getDefaultDisplayDeviceLocked();


    if (useVrFlinger) {
        auto vrFlingerRequestDisplayCallback = [this](bool requestDisplay) {
            static_cast<void>(schedule([=] {
                ALOGI("VR request display mode: requestDisplay=%d", requestDisplay);
                mVrFlingerRequestsDisplay = requestDisplay;
                signalTransaction();
            }));
        };
        mVrFlinger = dvr::VrFlinger::Create(getHwComposer().getComposer(),
                                            getHwComposer()
                                                    .fromPhysicalDisplayId(*display->getId())
                                                    .value_or(0),
                                            vrFlingerRequestDisplayCallback);
        if (!mVrFlinger) {
            ALOGE("Failed to start vrflinger");
        }
    }

    // initialize our drawing state
    mDrawingState = mCurrentState;

    // set initial conditions (e.g. unblank default device)
    initializeDisplays();

    char primeShaderCache[PROPERTY_VALUE_MAX];
    property_get("service.sf.prime_shader_cache", primeShaderCache, "1");
    if (atoi(primeShaderCache)) {
        getRenderEngine().primeCache();
    }

    // Inform native graphics APIs whether the present timestamp is supported:

    const bool presentFenceReliable =
            !getHwComposer().hasCapability(hal::Capability::PRESENT_FENCE_IS_NOT_RELIABLE);
    mStartPropertySetThread = getFactory().createStartPropertySetThread(presentFenceReliable);

    if (mStartPropertySetThread->Start() != NO_ERROR) {
        ALOGE("Run StartPropertySetThread failed!");
    }

    ALOGV("Done initializing");
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

1 处创建HWComposer和处理
SurfaceFlinger::run，进入消息循环
2 的 processDisplayHotplugEventsLocked(); 处理任何初始热插拔和显示更改的结果，在此方法中主要有调用 initScheduler(displayId)：

void SurfaceFlinger::initScheduler(DisplayId primaryDisplayId) {
    if (mScheduler) {
        // In practice it's not allowed to hotplug in/out the primary display once it's been
        // connected during startup, but some tests do it, so just warn and return.
        ALOGW("Can't re-init scheduler");
        return;
    }

    auto currentConfig = HwcConfigIndexType(getHwComposer().getActiveConfigIndex(primaryDisplayId));
    mRefreshRateConfigs =
            std::make_unique<scheduler::RefreshRateConfigs>(getHwComposer().getConfigs(
                                                                    primaryDisplayId),
                                                            currentConfig);
    mRefreshRateStats =
            std::make_unique<scheduler::RefreshRateStats>(*mRefreshRateConfigs, *mTimeStats,
                                                          currentConfig, hal::PowerMode::OFF);
    mRefreshRateStats->setConfigMode(currentConfig);

    mPhaseConfiguration = getFactory().createPhaseConfiguration(*mRefreshRateConfigs);

　　 // 处创建Scheduler对象
    // start the EventThread
    mScheduler =
            getFactory().createScheduler([this](bool enabled) { setPrimaryVsyncEnabled(enabled); },
                                         *mRefreshRateConfigs, *this);
    //创建app链接 和 sf链接
1   mAppConnectionHandle =
            mScheduler->createConnection("app", mPhaseConfiguration->getCurrentOffsets().late.app,
                                         impl::EventThread::InterceptVSyncsCallback());
    mSfConnectionHandle =
            mScheduler->createConnection("sf", mPhaseConfiguration->getCurrentOffsets().late.sf,
                                         [this](nsecs_t timestamp) {
                                             mInterceptor->saveVSyncEvent(timestamp);
                                         });

    mEventQueue->setEventConnection(mScheduler->getEventConnection(mSfConnectionHandle));
    mVSyncModulator.emplace(*mScheduler, mAppConnectionHandle, mSfConnectionHandle,
                            mPhaseConfiguration->getCurrentOffsets());

    mRegionSamplingThread =
            new RegionSamplingThread(*this, *mScheduler,
                                     RegionSamplingThread::EnvironmentTimingTunables());

    const nsecs_t vsyncPeriod =
            mRefreshRateConfigs->getRefreshRateFromConfigId(currentConfig).getVsyncPeriod();
    mScheduler->onPrimaryDisplayConfigChanged(mAppConnectionHandle, primaryDisplayId.value,
                                              currentConfig, vsyncPeriod);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

创建了DispSyncSource对象，且构造方法传入了四个值，dispSync对象，phaseOffset偏移量，traceVsync为true，name就是 app或 sf

Scheduler::ConnectionHandle Scheduler::createConnection(
         const char* connectionName, nsecs_t phaseOffsetNs,
         impl::EventThread::InterceptVSyncsCallback interceptCallback) {
     auto vsyncSource = makePrimaryDispSyncSource(connectionName, phaseOffsetNs);   
     auto eventThread = std::make_unique<impl::EventThread>(std::move(vsyncSource), std::move(interceptCallback));  
     return createConnection(std::move(eventThread));
}
1
2
3
4
5
6
7

创建EventThread对象，传入sf 或 app 相关联的vsyncSource对象:

void SurfaceFlinger::run() {
    do {
        waitForEvent();
    } while (true);
}
1
2
3
4
5

2-2 SurfaceFlinger合成layer

Android 组合各个 layer 并送到 FB 显示的具体过程
handleConsoleEvent
当接收到 signal 或者 singalEvent 事件以后，线程就停止等待开始对 Client 的请求进行处理，第一个步骤是 handleConsoleEvent ，这个步骤我看了下和 /dev/console 这个设备有关，它会取得屏幕或者释放屏幕，只有取得屏幕的时候才能够在屏幕上画图。

handleTransaction
前面提到过，窗口状态的改变只能在一个 Transaction 中进行。因为窗口状态的改变可能造成本窗口和其他窗口的可见区域变化，所以就必须重新来计算窗口的可见区域。在这个处理子过程中 Android 会根据标志位来对所有 layer 进行遍历，一旦发现哪个窗口的状态发生了变化就设置标志位以在将来重新计算这个窗口的可见区域。在完成所有子 layer 的遍历以后， Android 还会根据标志位来处理主 layer ，举个例子，比如说传感器感应到手机横过来了，会将窗口横向显示，此时就要重新设置主 layer 的方向。

handlePageFlip
这里会处理每个窗口 surface buffer 之间的翻转，根据 layer_state_t 的 swapsate 来决定是否要翻转，当 swapsate 的值是 eNextFlipPending 是就会翻转。处理完翻转以后它会重新计算每个 layer的可见区域，这个重新计算的过程我还没看太明白，但大致是一个这么的过程：

从 Z 值最大的 layer 开始计算，也就是说从最上层的 layer 计算，去掉本身的透明区域和覆盖在它上面的不透明区域，得到的就是这个 layer 的可见区域。然后这个 layer 的不透明区域就会累加到不透明覆盖区域，这个 layer 的可见区域会放入到主 layer 的可见区域，然后计算下一个 layer ，直到计算完所有的 layer 的可见区域。这中间的计算是通过定义在 skia 中的一种与或非的图形逻辑运算实现的，类似我们数学中的与或非逻辑图。

handleRepaint
计算出每个 layer 的可见区域以后，这一步就是将所有可见区域的内容画到主 layer 的相应部分了，也就是说将各个 surface buffer 里面相应的内容拷贝到主 layer 相应的 buffer ，其中可能还涉及到alpha 运算，像素的翻转，旋转等等操作，这里就像我前面说的可以用硬件来实现也可以用软件来实现。在使用软件的 opengl 做计算的过程中还会用到 PixFlinger 来做像素的合成，这部分内容我还没时间来细看。

postFrameBuffer
最后的任务就是翻转主 layer 的两个 buffer ，将刚刚写入的内容放入 FB 内显示了。