现象识别：后台任务异常常见表现、关键特征、影响范围判断
后台任务异常是 Android 系统中出现频率最高、排查链路最长的疑难杂症之一。排查的第一步不是点开 logcat，而是通过用户反馈、系统监控、自动化埋点识异常现象、提取关键特征、划分影响范围。只有把现象描述从“卡顿、耗电、杀后台”等模糊词汇收敛到可量化的特征指标，后续数据采集才有方向。
▶ 排查原则：现象识别阶段不碰代码，不抓日志，只做三件事 —— 收集表现、提取特征、判断范围。这三件是整棵故障树的根节点。
1.1 常见异常表现
后台任务异常在用户侧通常体现为以下 6 类表现。每一类背后都有对应的系统行为特征，需要排查人员快速对号入座。
| 序号 | 用户侧表现 | 典型场景 | 初步怀疑方向 |
|---|---|---|---|
| ① | 应用后台运行一段时间后自动关闭，再次打开时重新加载 | 切出应用几分钟后回来，应用重启，进度丢失 | LMK（低内存杀进程）、OOM adj 过高、缓存限制 |
| ② | 定时任务（如闹钟、推送）延迟或完全未执行 | 闹钟不响、推送消息推迟到达、定时同步失败 | AlarmManager受限、Doze/App Standby、省电策略 |
| ③ | 后台耗电异常，发热明显 | 一晚上耗电 30%+，手机发烫，系统 battery stats 显示某应用后台唤醒频繁 | WakeLock 未释放、Alarm 频繁、网络轮询、WorkManager 周期太短 |
| ④ | 后台网络请求失败或超时 | 图片上传失败、后台同步无响应、推送通道掉线 | JobScheduler 限制、网络策略（data saver）、应用被挂起 |
| ⑤ | 前台进程间切换卡顿，系统资源紧张 | 多任务切换时明显掉帧，后台应用过多导致系统频繁swap | 内存泄漏、后台服务过多、zram 压力大 |
| ⑥ | 后台任务日志中频繁出现“Process killed”、“SIGKILL”、“anr”字眼 | 开发者反馈日志中出现大量异常终止记录 | 系统杀进程、ANR超时、崩溃 |
⚠ 误区提醒：不要看到“杀后台”就只查 LMK。影响后台任务的因素包括 Android 版本差异、OEM 定制策略、应用 Target API 级别、省电模式开启状态。现象识别阶段应保持怀疑范围足够宽。
1.2 关键特征提炼
同一类表现可能有不同的根因，需要通过关键特征进行初步分流。以下是最常用的 8 个可量化特征，帮助排查者快速缩小范围。
- 存活时间：从应用进入后台到被杀死的时间（秒）。< 30s 强杀倾向，> 5min 正常或轻度受限。
- 唤醒频率：alarm + wakelock 每小时次数。> 20 次/小时属于高频唤醒，通常伴随耗电。
- CPU 占用率（后台）：进程处于后台时 CPU 平均利用率。> 5% 持续 10s 以上视为异常。
- 内存占用（RSS/PSS）：进程在后台时的 RSS 和 PSS。RSS > 200MB 或 PSS > 150MB 容易成为 LMK 目标。
- OOM adj 值：系统为该进程分配的 adj 值（范围 -1000~1000）。adj > 500 被杀的优先级高。
- WakeLock 持有时间：超时未释放的 WakeLock。超过 30s 计入 kernel wakelock 统计，影响睡眠。
- ANR 发生次数：后台 ANR 次数。首次发生后 24h 内重复出现则定位价值高。
- 系统版本与厂商：不同 OEM 对后台限制差异极大（如小米、华为、三星），必须记录。
1.3 影响范围判断
影响范围决定了排查的着力点：是单一应用问题、系统级问题还是硬件问题。推荐使用三分法快速诊断。
| 范围类型 | 典型现象 | 初步动作 |
|---|---|---|
| 单应用 | 仅目标应用异常，其他应用后台正常 | 检查应用 Target API、权限、部分厂商后台白名单 |
| 系统级 | 多个应用同时出现后台被杀/延迟，甚至系统服务（如电话、短信）也受影响 | 检查系统内存压力、Doze 状态、系统更新、安全补丁 |
| 硬件相关 | 仅特定机型/特定电池容量、充电状态下发生 | 检查电池健康度、温度限制、低电量策略 |
💡 判断技巧：在 Settings → Developer options → Running services 中查看正在运行的服务列表。如果多个三方应用的服务都在 Restarting 状态，优先怀疑系统级内存不足；如果只有你的应用被杀，优先怀疑应用自身限制。
1.4 故障树：后台任务异常现象识别
使用故障树将“后台任务异常”这一顶层事件逐级分解为可观测的现象叶子节点。每一个叶子节点都对应一个关键特征，方便后续数据采集时直接对照。
1.5 排查表：现象 → 特征 → 初步方向
将表现、关键特征、可能原因汇集成一张判断表格，便于在数据采集前快速对号。
| 表现速查码 | 用户侧描述 | 关键特征 | 可能原因（优先级排序） |
|---|---|---|---|
| A1 | 后台运行几分钟后应用重启 | 存活时间 < 60s；adj > 600；系统可用内存 < 10% | LMK > 缓存策略 > vendor 省电 |
| A2 | 闹钟不响，推送延迟1h以上 | Alarm 被跳过 count > 3；设备处于 Doze | App Standby > Doze > 省电白名单 |
| B1 | 待机一晚上耗电 30% | WakeLock 总时长 > 60min；CPU 后台平均利用率 > 5% | WakeLock 泄漏 > Alarm 高频 > JobScheduler 周期过短 |
| B2 | 后台同步失败，显示网络错误 | NetworkCallback onAvailable 未触发；设备处于 data saver | Data Saver > Battery Optimization > 后台 network 权限 |
| C1 | 切换任务时系统卡顿，有时 ANR | PSS > 200MB；后台服务数量 > 5；zram 使用率 > 80% | 内存泄漏 > 服务未释放 > 系统 swap 压力 |
💡 现场快速判断：在终端执行
adb shell dumpsys activity processes | grep "appAdj" 可以查看所有进程的 adj 值。如果目标进程 adj >= 900，则几乎必然在下一轮 LMK 中被杀死。
1.6 判断规则（三条硬规则）
- 规则一（存活规则）：从用户切出到应用进程死亡的时间间隔。若间隔 < 30s，优先排查 LMK、OOM adj；若间隔 > 5min，排查 Doze/Standby 限制。
- 规则二（唤醒规则）：累计每小时唤醒次数（alarm + wakelock）超过 20 次，且用户报告耗电/发热，则 90% 是应用自身唤醒频率过高，先查 WorkManager/AlarmManager 参数。
- 规则三（范围规则）：若多款应用同时出现后台问题，优先排查系统级因素：低内存状态（/proc/meminfo）、系统更新、安全补丁、厂商省电模式。若只有单款应用异常，检查应用 Target API 和后台服务约束。
完成现象识别后，排查人员应得到一张清晰的“现象-特征-范围”对照表。接下来的数据采集阶段将围绕这张表选择对应的 adb shell dumpsys 命令和日志开关。