安卓驱动面试后对framework的思考

今天去面试安卓驱动工程师的岗位首先他问了我安卓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 份① 公开 APIApp 能调的 core/java/android/view/WindowManager.java ← 接口定义 ② AIDL 接口binder 契约 core/java/android/view/IWindowManager.aidl ← 跨进程用 ③ 真正的实现跑在 system_serverservices/core/java/com/android/server/wm/ WindowManagerService.java ← 你想看逻辑就找它App 进程调用 WindowManager 时其实是通过 binder 飞到 system_server 里执行WindowManagerService。所以你找实现永远要去 services/ 目录找接口/类去 core/java/android/。另外两个容易迷路的点1. 隐藏 APIcore/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 | | -------------------------------------------------------------------------