hwc2 surfaceflinger启动流程分析

本文详细分析了Android系统中SurfaceFlinger如何通过HWComposer加载HWC2服务,并深入到HAL层的启动流程,包括SurfaceFlinger的init、HWComposer的构造、loadHwcModule、Composer的创建、registerCallback、composer@2.1-service的加载,以及HAL层的HWCSession初始化和内核通信机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

先还是大体的来看下流程图,这个比hwc1复杂了好多,不是太好理解:
在这里插入图片描述

1.SurfaceFlinger.init

        "Starting with vr flinger active is not currently supported.");
    mRealHwc = new HWComposer(false);
    mHwc = mRealHwc;
    mHwc->setEventHandler(static_cast<HWComposer::EventHandler*>(this));

    Mutex::Autolock _l(mStateLock);

在这里只关注hwcomposer实例生成的具体过程,上面代码主要二个作用:
1.生成一个HWComposer实例
2.生成实例后,注意消息回调函数。是surfaceflinger与composer Hidl服务层通信的唯一通道

2.HWComposer

HWComposer::HWComposer(bool useVrComposer)
    : mHwcDevice(),
      mDisplayData(2),
      mFreeDisplaySlots(),
      mHwcDisplaySlots(),
      mCBContext(),
      mEventHandler(nullptr),
      mVSyncCounts(),
      mRemainingHwcVirtualDisplays(0)
{
   
    for (size_t i=0 ; i<HWC_NUM_PHYSICAL_DISPLAY_TYPES ; i++) {
   
        mLastHwVSync[i] = 0;
        mVSyncCounts[i] = 0;
    }

    loadHwcModule(useVrComposer);
}

来看看其构造函数,除了初始化一些基本的成员变量。剩下的就是loadHwcModule这个API的调用了,这个调用就是获取hwc2的实例

3.loadHwcModule

文件:HWComposer.cpp

void HWComposer::loadHwcModule(bool useVrComposer)
{
   
    ALOGV("loadHwcModule");
    //获取HWC2::Device类实例,这是这个函数的唯一作用
    mHwcDevice = std::make_unique<HWC2::Device>(useVrComposer);
    mRemainingHwcVirtualDisplays = mHwcDevice->getMaxVirtualDisplayCount();
}

4.HWC2::Device

文件:hwc2.cpp

Device::Device(bool useVrComposer)
  : mComposer(std::make_unique<Hwc2::Composer>(useVrComposer)),
    mCapabilities(),
    mDisplays(),
    mHotplug(),
    mPendingHotplugs(),
    mRefresh(),
    mPendingRefreshes(),
    mVsync(),
    mPendingVsyncs()
{
   
    loadCapabilities();
    registerCallbacks();
}

这个函数比较重要的有二个:
1.mComposer成员的初始化
2.向composer HIDL服务注册回调函数registerCallbacks

5.Composer

文件:ComposerHal.cpp

Composer::Composer(bool useVrComposer)
    : mWriter(kWriterInitialSize),
      mIsUsingVrComposer(useVrComposer)
{
   
    if (mIsUsingVrComposer) {
   
        mComposer = IComposer::getService("vr");
    } else {
   
        mComposer = IComposer::getService(); // use default name
    }

    if (mComposer == nullptr) {
   
        LOG_ALWAYS_FATAL("failed to get hwcomposer service");
    }

    mComposer->createClient(
            [&](const auto& tmpError, const auto& tmpClient)
            {
   
                if (tmpError == Error::NONE) {
   
                    mClient = tmpClient;
                }
            });
    if (mClient 
<think>好的,我现在需要回答用户关于SurfaceFlinger和DisplayManagerService在安卓启动流程中处于哪一层的问题。首先,我要回顾一下之前提供的安卓启动流程,确保自己理解各个阶段。 用户之前的提问是关于安卓启动流程的,我详细介绍了从Bootloader到Launcher的六个阶段。现在用户进一步询问SurfaceFlinger和DisplayManagerService具体属于哪一层。我需要明确这两个服务在启动过程中的位置。 首先,我需要确认SurfaceFlinger和DisplayManagerService的作用。SurfaceFlinger是负责图形合成的服务,将各个应用的窗口内容合成到屏幕上。DisplayManagerService则管理显示设备,比如屏幕的配置、分辨率、多屏显示等。 接下来,回顾之前的启动阶段:Init进程阶段会启动一些核心服务,包括surfaceflingerservicemanager。而System Server阶段会启动各种系统服务,比如ActivityManagerService、WindowManagerService、PowerManagerService和DisplayManagerService等。 因此,SurfaceFlinger是在Init进程阶段由init.rc脚本启动的,属于较早期的服务,因为它需要为后续的图形界面提供基础。而DisplayManagerService则是在System Server阶段由SystemServer进程启动的,属于系统服务层,可能在较后的阶段启动,因为它依赖于其他服务的存在,比如可能需要ActivityManagerService或WindowManagerService已经就绪。 需要验证这个理解是否正确。查阅Android官方文档或相关资料,确认SurfaceFlinger确实在Init阶段启动,而DisplayManagerService属于System Server的一部分。例如,AOSP的文档指出,Init进程会解析init.rc文件,启动关键服务如SurfaceFlinger,而System Server则负责启动其他系统服务,包括DisplayManagerService。 另外,用户可能想知道这两个服务在启动流程中的依赖关系。例如,SurfaceFlinger作为图形合成的核心,必须在显示驱动加载之后启动,而DisplayManagerService可能需要SurfaceFlinger已经运行才能管理显示设备。因此,启动顺序上SurfaceFlinger早于DisplayManagerService。 还需要注意是否有例外情况或不同的Android版本之间的差异。例如,在较新的Android版本中,启动流程是否有变化,或者某些服务是否被合并或拆分。但根据目前的知识,SurfaceFlinger属于Init阶段,DisplayManagerService属于System Server阶段,这一点应该是稳定的。 总结:SurfaceFlinger在Init进程阶段启动,属于系统底层服务;DisplayManagerService在System Server阶段启动,属于系统服务层。需要将这些信息清晰、有条理地传达给用户,并确保术语准确,避免混淆。</think>以下是关于SurfaceFlinger与DisplayManagerService在安卓启动流程中的层级归属及详细解析: --- ### **一、归属层级** 1. **SurfaceFlinger** - **启动阶段**:**Init进程阶段**(用户空间初始化的早期阶段) - **层级**:**系统底层图形服务** - **关键依赖**:Linux内核显示驱动(如DRM/KMS)、硬件帧缓冲(Framebuffer) 2. **DisplayManagerService** - **启动阶段**:**System Server阶段**(系统服务初始化阶段) - **层级**:**Android框架层系统服务** - **关键依赖**:SurfaceFlinger、WindowManagerService、硬件抽象层(HAL) --- ### **二、启动流程详解** #### **1. SurfaceFlinger启动路径** - **触发时机**: Init进程解析`init.rc`脚本时启动,属于**用户空间最早启动的核心服务之一**。 - **具体流程**: 1. **Init进程阶段**: - 挂载`/system`、`/vendor`分区后,加载`init.rc`配置。 - 执行`start surfaceflinger`命令,启动SurfaceFlinger服务。 2. **初始化任务**: - 绑定到**Binder通信框架**(成为系统服务)。 - 通过HAL层调用**Gralloc(图形内存分配器)**,初始化硬件合成器(如HWC)。 - 创建**EventThread**处理VSync信号,管理帧率同步。 - **典型日志标记**: ```bash adb logcat -s SurfaceFlinger # 查看启动日志 ``` #### **2. DisplayManagerService启动路径** - **触发时机**: 在System Server进程中启动,属于**Android框架层的核心服务**。 - **具体流程**: 1. **System Server阶段**: - Zygote孵化SystemServer进程后,调用`startBootstrapServices()`方法。 - 在`startCoreServices()`阶段初始化DisplayManagerService2. **初始化任务**: - 注册到**ServiceManager**,提供显示管理接口。 - 通过Binder IPC与SurfaceFlinger交互,获取物理显示配置(如分辨率、刷新率)。 - 监听显示设备热插拔事件(如HDMI连接)。 - **依赖关系**: - **必须等待SurfaceFlinger就绪**,否则无法获取显示硬件信息。 - 需与WindowManagerService协作,管理窗口与显示的逻辑映射。 --- ### **三、两者协作关系** 1. **启动顺序**: ```plaintext SurfaceFlinger(Init阶段) → DisplayManagerService(System Server阶段) ``` 2. **功能协作**: - **SurfaceFlinger**:负责**物理显示合成**(将图层数据提交给GPU/HWC)。 - **DisplayManagerService**:负责**逻辑显示管理**(多屏配置、虚拟显示、显示模式切换)。 3. **通信方式**: - 通过Binder IPC传递显示配置参数(如`DisplayState`)。 - SurfaceFlinger通过`HWComposer`上报硬件显示状态(如连接/断开)。 --- ### **四、调试与问题定位** #### **1. SurfaceFlinger常见问题** - **黑屏/闪屏**: - 检查内核显示驱动是否加载(`dmesg | grep "drm"`)。 - 验证SurfaceFlinger日志是否正常绑定HWC(`adb shell dumpsys SurfaceFlinger`)。 - **性能问题**: - 使用`systrace`分析帧合成耗时(关注`VSYNC-app/sf`信号)。 #### **2. DisplayManagerService常见问题** - **显示配置错误**: - 检查`config.xml`中的默认显示配置(如`/system/etc/displayconfig/`)。 - 查看DisplayManagerService的当前状态: ```bash adb shell dumpsys display # 显示所有已注册的显示设备 ``` - **多屏显示异常**: - 验证`DisplayDeviceRepository`是否正确识别外接显示器。 --- ### **五、扩展知识** - **Android图形架构演进**: - **Android 12**:引入`CompositionEngine`重构合成逻辑,减少对SurfaceFlinger的直接依赖。 - **Android 13**:支持**动态刷新率切换**(DisplayManagerServiceSurfaceFlinger协同实现)。 - **替代方案**: - 部分定制ROM(如MIUI)可能重写DisplayManagerService的逻辑,支持自定义显示模式。 --- 通过理解这两个服务的层级定位,可以更高效地分析显示相关问题(如开机动画卡顿、多屏适配异常),并针对性地优化系统启动流程或显示渲染性能。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

bruk_spp

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值