如何应对Android面试官 -> WindowManagerService 启动流程分析

前言


image.png

本章主要从上面几个角度来讲解 WindowManagerService;

相关概念


介绍 WMS 之前,我们先来介绍几个相关的概念;

WMS 存在于 system_server 系统服务进程,view 存在于 app 进程,所有的窗口最终都是通过 wms 来进行管理,为了方便管理,app 和 wms 之间添加了 WindowManager,用来在应用与 wms 之间的管理接口,管理窗口顺序,消息等。

Activity 与 Window 相关概念

  • Activity 只负责生命周期和事件处理;
  • Window 只控制视图;
  • 一个 Activity 包含一个 Window,如果 Activity 没有 Window,那就相当于 Service;
  • AMS 统一调度所有应用程序的 Activity;
  • WMS 控制所有 Window 的显示与隐藏以及要显示的位置;

Window

『Window』表明它是和窗口相关的,“窗口”是一个抽象的概念,从用户的角度来讲,它是一个“界面”;从SurfaceFlinger 的角度来看,它是一个 Layer,承载着和界面有关的数据和属性;从 WMS 角度来看,它是一个WindowState,用于管理和界面有关的状态;添加一个 Window 的过程,就是分配一块 Surface 的过程;

  • 表示一个窗口的概念,是所有 View 的直接管理者,任何视图都通过 Window 呈现(点击事件由 Window->DecorView->View; Activity 的 setContentView 底层通过 Window 完成);
  • Window是一个抽象类,具体且唯一的实现是 PhoneWindow;
  • 创建 Window 需要通过 WindowManager 创建;
  • WindowManager 是外界访问 Window 的入口;
  • Window 具体实现位于 WindowManagerService 中;
  • WindowManager 和 WindowManagerService 的交互是通过 IPC 完成;
  • 定义窗口样式和行为的抽象基类,用于作为顶层的 view 加到 WindowManager 中,其实现类是 PhoneWindow
  • 每个 Window 都需要指定一个 Type(应用窗口、子窗口、系统窗口)。Activity 对应的窗口是应用窗口;PopupWindow,ContextMenu,OptionMenu 是常用的子窗口;像 Toast 和系统警告提示框(如ANR)就是系窗口,还有很多应用的悬浮框也属于系统窗口类型;

image.png

Android上对 Window 进行了弱化,主要是 View;

WindowManager

用来在应用与window之间的管理接口,管理窗口顺序,消息等;

WindowManagerService

简称 WMS,WindowManagerService 管理窗口的创建、更新和删除、显示顺序等,是 WindowManager 这个管理接口的真正的实现类。它运行在 system_server 进程,作为服务端,客户端(应用程序)通过 IPC 调用和它进行交互;

  • Z-ordered的维护函数;
  • 输入法管理;
  • AddWindew/RemoveWindow;
  • Layout;
<think> 嗯,用户的问题是关于Android系统从按下电源键到背光处理的完整流程,涉及多个系统层级和组件。首先需要梳理整个流程的步骤,然后分模块解释每个组件的作用。 用户提供的引用内容很有帮助。引用[1]和[2]提到了Android的系统架构,特别是Framework层的各个ManagerService,如WindowManager、PowerManagerService等。引用[2]详细描述了屏幕唤醒的流程,从InputReader捕获事件到PowerManagerService调用内核唤醒的过程。引用[3]则补充了Loader层和Linux内核层的启动流程。这些信息有助于构建整个流程的框架。 接下来需要确定流程的起点。物理按键触发中断,Kernel层的驱动处理事件,通过Input子系统传递到用户空间。这里需要说明EventHub如何读取设备节点,InputReader如何解析事件并分发给InputDispatcher。InputDispatcher将事件发送给焦点窗口,但电源键事件比较特殊,会直接交给PowerManagerService处理。 然后是PowerManagerService的处理流程。它根据当前状态决定唤醒或休眠设备。唤醒时,会调用DisplayPowerController更新显示状态,通过DisplayManagerService通知SurfaceFlinger进行图层合成。同时,PowerManagerService通过JNI调用HAL层,最终操作背光驱动调整亮度。 SurfaceFlinger负责合成所有图层并提交给FrameBuffer。HWC的作用需要强调,特别是控制背光的部分。硬件处理阶段,驱动接收PWM信号,调节LED或LCD的亮度,完成整个流程。 需要注意各组件间的交互方式,如Binder通信、HAL接口调用等。引用[4]提到的进程间通信机制在这里很关键,尤其是PowerManagerService与其他服务的交互。另外,背光控制涉及硬件抽象层,需要说明HAL如何桥接Framework和驱动。 用户可能关注各组件的作用和协作顺序,因此每个步骤应明确组件职责。例如,WindowManager确定焦点窗口,但电源键事件被拦截的特殊处理。还要解释WakeLock机制,防止系统休眠,引用[2]中提到了它的重要性。 最后,检查流程是否完整:物理按键→中断→驱动→Input子系统→Framework层各服务→HAL→驱动→硬件。确保各环节衔接自然,特别是跨层调用。需要避免过于技术化的术语,用用户能理解的语言描述流程。 </think>以下是Android系统从物理按下电源键到背光处理的完整流程分析,结合各层级组件的职责与交互: --- ### **1. 物理按键触发(硬件层)** - **行为**:用户按下电源键,产生**硬件中断**。 - **作用**:硬件电路将电信号转换为中断信号传递给SoC芯片。 --- ### **2. Linux内核层处理** - **驱动响应**: - 中断触发**GPIO键盘驱动**,生成`KEY_POWER`事件码。 - 通过**Input子系统**将事件写入`/dev/input/eventX`设备节点[^2]。 - **关键行为**: ```c // 内核驱动伪代码 irq_handler() { report_key(EV_KEY, KEY_POWER, 1); // 按下事件 report_key(EV_KEY, KEY_POWER, 0); // 释放事件 } ``` --- ### **3. Framework层处理流程 #### **(1) InputReader线程** - **职责**:监听`/dev/input`节点,读取原始输入事件。 - **行为**: - 从设备节点读取`KEY_POWER`事件。 - 解析并封装为`KeyEvent`对象,传递给`InputDispatcher`[^2]。 #### **(2) InputDispatcher线程** - **职责**:事件路由分发。 - **行为**: - 识别到`KEY_POWER`为系统按键。 - **跳过应用层分发**,直接发送给`WindowManagerService`(WMS)的系统处理通道。 #### **(3) WindowManagerService** - **职责**:管理窗口策略。 - **行为**: - 调用`PhoneWindowManager.interceptKeyBeforeQueueing()`。 - 判断当前为**唤醒场景**(屏幕原处于休眠状态)[^2]。 #### **(4) PowerManagerService** - **核心操作**: - 执行`wakeUp()`流程: ```java // PowerManagerService伪代码 public void wakeUp(long eventTime) { setWakefulness(WAKEFULNESS_AWAKE); // 更新系统唤醒状态 updatePowerState(); // 触发电源状态更新 } ``` - 通过`DisplayPowerController`请求**屏幕开启**[^2]。 #### **(5) DisplayPowerController** - **职责**:控制显示设备状态。 - **行为**: - 计算目标背光亮度(例如:最大亮度的50%)。 - 通过`DisplayManagerService`通知`SurfaceFlinger`准备显示合成。 #### **(6) SurfaceFlinger** - **职责**:合成所有图层并提交给显示硬件。 - **行为**: - 启用所有显示层(Layer)的合成。 - 通过**HWC (Hardware Composer)** 驱动通知显示硬件开启。 --- ### **4. 背光控制流程** #### **(1) HAL层交互** - **调用链**: ```mermaid graph LR PowerManagerService-->|JNI| LightsService LightsService-->|HIDL/ AIDL| Light HAL Light HAL-->Kernel Driver ``` - **行为**: - `LightsService`调用HAL接口`setLight(LIGHT_ID_BACKLIGHT, brightness)`。 #### **(2) 内核背光驱动** - **行为**: - 接收HAL层传递的亮度值(如`/sys/class/leds/lcd-backlight/brightness`)。 - 转换为**PWM信号**调节背光LED电压。 #### **(3) 硬件执行** - **行为**:LED驱动电路根据PWM信号调整电流,控制屏幕背光亮度。 --- ### **5. 流程关键点总结** | **组件** | **核心作用** | |------------------------|------------------------------------------| | **InputReader** | 原始输入事件采集 | | **WindowManager** | 拦截电源键并决策唤醒 | | **PowerManagerService**| 全局电源状态管理,触发唤醒 | | **DisplayManager** | 协调显示设备状态变更 | | **SurfaceFlinger** | 启动图形合成,提交帧缓冲 | | **Light HAL** | 标准化背光控制接口 | | **背光驱动** | 将数字亮度值转换为硬件控制信号 | --- ### **流程时序图** ```mermaid sequenceDiagram participant Hardware participant Kernel participant InputReader participant WMS participant PowerManager participant DisplayController participant SurfaceFlinger participant Light HAL participant Backlight Driver Hardware->>Kernel: 电源键中断 Kernel->>InputReader: 写入event节点 InputReader->>WMS: 传递KeyEvent WMS->>PowerManager: 唤醒请求 PowerManager->>DisplayController: 更新显示状态 DisplayController->>SurfaceFlinger: 启用合成 SurfaceFlinger->>Light HAL: 背光控制指令 Light HAL->>Backlight Driver: 设置亮度值 Backlight Driver->>Hardware: PWM调光信号 ``` ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值