Service

Activity 生命周期是什么？ onCreate：初始化视图、数据恢复 onStart：页面可见 onResume：页面处于前台，可交互 onPause：失去焦点，轻量释放 onStop：完全不可见，重资源释放 onDestroy：销毁前清理，但不保证一定执行 加上一个onrestart 启动模型 跳转时： 旧 Activity 先 onPause，新 Activity 启动后，旧的再 onStop。 切回主界面时： onRestart -> onStart -> onResume。 activity的启动模式 (LaunchMode) 及场景 Standard： 默认模式，每次启动都创建新实例。 SingleTop： 栈顶复用。场景： 通知栏点击进入已打开的页面，避免重复创建。 SingleTask： 栈内复用，会移除其上方的所有 Activity。场景： APP 主页。 SingleInstance： 独占一个任务栈。场景： 闹钟、来电显示。 屏幕旋转后的 Activity 重建 原理： 默认会执行销毁并重建流程。 处理方案： 持久化： 在 onSaveInstanceState 中保存 Bundle 数据，在 onCreate 或 onRestoreInstanceState 中恢复。 ViewModel： 利用 ViewModel 生命周期长于 Activity 的特性存储 UI 数据。可以详细了解Viewmodel 中的过程。 配置拦截： 在 Manifest 设置 android:configChanges=“orientation|screenSize”，拦截后在 onConfigurationChanged 中手动处理。 ...

一、需求背景与核心挑战 功能需求 需实现一个全局悬浮窗（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，从而呈现悬浮状态。 ...