今天去面试安卓驱动工程师的岗位，首先他问了我安卓hwui，当时有点懵，以下是常见的framework总结

+---------------------------------------------------------------------------+ | Java Framework | | | | +--------------------+ +--------------------+ +--------------------+ | | | UI 体系 | | 四大组件 | | 系统服务 | | | | View / ViewGroup | | Activity | | AMS (Activity Mgr) | | | | Canvas / Paint | | Service | | WMS (Window Mgr) | | | | Layout | | BroadcastReceiver | | PMS (Package Mgr) | | | | Resource | | ContentProvider | | NotificationMgr | | | +---------+----------+ +---------+----------+ +---------+----------+ | | | | | | +------------|-----------------------|-----------------------|--------------+ | HardwareRenderer | Binder IPC (JNI ↓) | v v v +---------------------------------------------------------------------------+ | Native Framework & C/C++ Libraries / Daemons | | | | +--------------------+ +--------------------+ +--------------------+ | | | 图形 (Graphics) | | IPC / 系统基础 | | 多媒体 (Media) | | | | HWUI | | libbinder | | AudioFlinger | | | | SurfaceFlinger | | servicemanager | | MediaPlayerService | | | | Skia | | init | | MediaCodec | | | | EGL / GLES / Vulkan| | ueventd / logd | | CameraService | | | +--------------------+ +--------------------+ +--------------------+ | | | | +--------------------+ +--------------------+ +--------------------+ | | | 存储 (Storage) | | 网络 (Network) | | 安全 (Security) | | | | vold | | netd | | keystore | | | | installd | | mdnsd | | gatekeeperd | | | | sdcard | | wificond | | fingerprintd | | | +--------------------+ +--------------------+ +--------------------+ | | | | +--------------------+ +--------------------+ | | | 输入 (Input) | | 其他 (Others) | | | | inputflinger | | healthd | | | | EventHub | | lmkd | | | | InputReader | | statsd | | | +--------------------+ +--------------------+ | +---------------------------------------------------------------------------+ | HAL ↓ | +---------------------------------------------------------------------------+

事后复盘，我试着想办法理解framework的复杂

对照图 → 实际目录映射

================================================================================ Android Framework 核心模块源码路径解析 ================================================================================ [1] UI 体系 (UI System) -------------------------------------------------------------------------------- ▪ 架构说明：Android 的 UI 源码是按“功能”进行分包的，而不是把所有 UI 放到一个模块目录下。 ▪ 源码路径： ├─ frameworks/base/core/java/android/view/ │ └─ 核心类：View, ViewGroup, ViewRootImpl (负责视图层级与事件分发) │ ├─ frameworks/base/core/java/android/graphics/ │ └─ 核心类：Canvas, Paint, Bitmap (负责底层 2D 图形绘制与渲染) │ └─ frameworks/base/core/java/android/widget/ └─ 核心类：Button, TextView, LinearLayout 等 (开发者常用的具体 UI 控件) [2] 四大组件 (App Components) -------------------------------------------------------------------------------- ▪ 架构说明：应用层的四大核心组件定义，统一归置在 app 目录下。 ▪ 源码路径： └─ frameworks/base/core/java/android/app/ ├─ Activity (界面容器) ├─ Service (后台服务) ├─ BroadcastReceiver (广播接收器) └─ ContentProvider (内容提供者) [3] 系统服务 (System Services) -------------------------------------------------------------------------------- ▪ 架构说明：系统核心服务的具体实现代码独立于 core 库，统一在 services 目录下管理。 ▪ 源码路径： ├─ frameworks/base/services/core/java/com/android/server/am/ │ └─ 模块：AMS (ActivityManagerService) - 负责四大组件的启动、切换与进程管理 │ ├─ frameworks/base/services/core/java/com/android/server/wm/ │ └─ 模块：WMS (WindowManagerService) - 负责窗口管理与 Z 轴排序 (内部包含 219 个类) │ ├─ frameworks/base/services/core/java/com/android/server/pm/ │ └─ 模块：PMS (PackageManagerService) - 负责 APK 的解析、安装与权限管理 │ └─ frameworks/base/services/core/java/com/android/server/notification/ └─ 模块：NMS (NotificationManagerService) - 负责全局通知的分发与管理

为什么会觉得乱——每块代码被 binder 劈成三段

以 WMS（窗口管理） 为例，一个服务在代码里有 3 份：

① 公开 API（App 能调的） core/java/android/view/WindowManager.java ← 接口定义 ② AIDL 接口（binder 契约） core/java/android/view/IWindowManager.aidl ← 跨进程用 ③ 真正的实现（跑在 system_server）services/core/java/com/android/server/wm/ WindowManagerService.java ← 你想看逻辑就找它

App 进程调用 WindowManager 时，其实是通过 binder 飞到 system_server 里执行
WindowManagerService。所以你找"实现"永远要去 services/ 目录，找"接口/类"去 core/java/android/。

另外两个容易迷路的点

1. 隐藏 API：core/java/com/android/internal/（如 PhoneWindow）——对外不可见但框架内部用的类，也在 core 下，包名是
com.android.internal 而不是 android。
2. 系统服务不止一个目录：老版本还有 services/java/，新版统一在 services/core/java/com/android/server/（按服务名分
am/wm/pm/notification/input 等子目录）。

一句话规律

core/java/android/ = 看"是什么"（类、接口），services/.../server/ = 看"怎么干活"（实现），com.android.internal = 藏着干活的辅助类。

此外还问了我vop和drm之间了解的深度有多少？

第一层：能精准映射软硬模型（入门级）

DRM 为了兼容天下所有的显示硬件，抽象出了一套标准的软件模型（KMS），你要能把它和 VOP 的物理构造一一对应起来：

• Plane（图层）-> 对应 VOP 里的硬件 Overlay 模块（比如视频层、UI层）。

• CRTC（控制器）-> 对应 VOP 里的时序发生器（控制分辨率、刷新率）。

• Encoder / Connector（输出）-> 对应底层的PHY 物理接口（HDMI、MIPI DSI 等芯片引脚）。

第二层：讲透数据流转与零拷贝（进阶级）

不要只说“DRM 控制 VOP”，要说清楚数据是怎么流动的。 你要点出dma-buf的核心地位。GPU 把 3D 画面渲染完放在内存里，DRM 不需要让 CPU 把这块内存复制给 VOP。DRM 只需要把这块内存的物理地址（句柄）丢给 VOP 的寄存器，VOP 就会通过硬件总线（AXI）直接去内存里“吸”数据。这就是零拷贝（Zero-copy），极大地节省了系统带宽。

第三层：掌握时序与同步机制（硬核级）

这是最体现底层功底的环节。你要解释清楚它们是如何协同“卡点”的： 当 GPU 还在画图时，VOP 已经在扫上一帧的画面了。GPU 画完后，会发一个fence信号给 DRM，告诉它“我这块 Buffer 画完了”。但 DRM 不会立刻让 VOP 去拿数据，而是会一直等到屏幕发出下一个Vsync（垂直同步）信号。 此时，DRM 触发page flip（翻页），把新 Buffer 的地址写入 VOP 寄存器，VOP 在下一个扫描周期完美地把新画面送上屏幕，从而避免了画面撕裂（Tearing）。

这种从高层抽象到物理寄存器，再穿插异步同步机制的解释逻辑，足以证明你对显示链路有着非常通透的理解。

在你后续梳理这套显示控制逻辑时，你打算重点从哪个角度（比如驱动代码层面的初始化，还是 Buffer 的流转链路）切入去深入探讨呢？

+---------------------------------------------------------------------------+ | Native Framework (User Space) | | | | +--------------------------------------------------------------------+ | | | 图形 (Graphics) | | | | +--------------------+ | | | | | SurfaceFlinger | <-- 收集所有 App 画面进行合成管理 | | | | | OpenGL / Vulkan | <-- 3D 渲染 API | | | | +---------+----------+ | | | +------------|-------------------------------------------------------+ | | | (通过 HWC API 交接) | +---------------|-----------------------------------------------------------+ v +---------------------------------------------------------------------------+ | HAL (Hardware Abstraction Layer) | | | | +--------------------+ +--------------------+ | | | HWC (HWComposer) | | Gralloc (内存分配) | | | | 决定图层合成策略: | | 分配图形缓冲区 | | | | 谁用 GPU(Client) | | (dma-buf) | | | | 谁用 VOP(Device) | +--------------------+ | | +---------+----------+ | | | (通过 libdrm 库调用 ioctl) | +------------|--------------------------------------------------------------+ v +---------------------------------------------------------------------------+ | Linux Kernel (Kernel Space) | | | | +--------------------------------------------------------------------+ | | | DRM (Direct Rendering Manager) | | | | | | | | +--------------------+ +------------------------------------+ | | | | | GEM (内存管理) | | KMS (模式设置与显示控制) | | | | | | 显存分配, dma-buf | | CRTC (对应硬件 VOP) | Plane (图层) | | | | | +--------------------+ | Encoder(信号编码) | Connector | | | | | | | | | +--------------------+ +------------------------------------+ | | | | | GPU Driver (Mali) | | Display Driver (如 rockchip_drm) | | | | | | 负责"画什么" | | 负责"什么时候送、送到哪" (Vsync) | | | | +--+---------+----------+----+------------------+-----------------+--+ | | | fence 同步机制 (GPU 画完通知 DRM)| | +---------------|----------------------------------|--------------------+ v v +---------------------------------------------------------------------------+ | SoC Hardware | | | | +--------------------+ +------------------------------------+ | | | GPU | | VOP (Video Output Processor) | | | | 渲染 3D / 合成图层 | | 硬件图层叠加 (Overlay) | | | | (结果输出到内存) | | 产生时序信号 (Vsync, page flip) | | | +--------------------+ +------------------+-----------------+ | | | | | +------------------v-----------------+ | | | PHY (物理接口层: MIPI/eDP) | | | +------------------+-----------------+ | | | | | +------------------v-----------------+ | | | LCD Panel | | +-------------------------------+------------------------------------+------+