Android 悬浮窗前后台自动显隐方案设计
一、需求背景与核心挑战 功能需求 需实现一个全局悬浮窗（Floating View），具体行为规范如下： 应用位于前台时，隐藏悬浮窗，避免遮挡用户正常操作。 应用退至后台时，显示悬浮窗，使其保持悬浮于系统或其他应用界面之上。 核心挑战 悬浮窗通常由独立的 Service 组件维护，以确保其生命周期独立于 Activity。因此，该需求的技术难点在于：在后台运行的 Service 如何实时、准确地感知当前应用的前后台状态切换？ 二、悬浮窗实现的核心原理剖析 在阐述具体代码方案前，需明确通过"前台 Service + WindowManager"实现悬浮窗效果的底层原理。此机制主要涉及 Android 的显示架构与进程保活策略： 2.1 Android 的窗口层级体系 (Z-order) Android 的显示系统并非局限于各个应用单独绘制自身区域。屏幕上的所有渲染内容均由 WindowManagerService (WMS) 统一管理。WMS 维护着一个全局的窗口 Z-order 栈，不同类型的窗口对应不同的显示层级： 系统窗口层（System Window）：最高层级，包含状态栏、导航栏、Toast、悬浮窗等。 子窗口层（Sub Window）：中间层级，包含 Dialog、PopupWindow 等（需依附于宿主窗口）。 应用窗口层（Application Window）：最底层级，对应普通 Activity 的窗口。 由于系统窗口层的 Z-order 高于应用窗口层，将窗口类型配置为系统级，即可实现覆盖于所有应用之上的"悬浮"效果。 2.2 WindowManager.addView() 的底层机制 调用 WindowManager.addView(view, params) 时，系统底层的实际调用链路如下： 应用层代码 → WindowManager (客户端代理) → Binder IPC → WindowManagerService (系统服务端) → SurfaceFlinger (合成渲染) 传入的 LayoutParams.type 参数决定了目标 View 所属的显示层级。当参数配置为： params.type = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY WMS 会将该窗口分配至系统窗口层。该窗口独立于任何 Activity 的生命周期，直接由系统 WMS 管理，其 Z-order 默认高于所有普通 Activity，从而呈现悬浮状态。 ...