后台任务消耗的系统资源需要对用户透明，避免被误判为异常耗电耗流量
别名: 后台耗电 · 流量透明 · battery blame · 不是泄漏
概念解释
备份在传、视频在转、模型在下，电量和流量会明显下降。人若看不见是哪一件工作在用，就会把下降归到「这个 app 有问题」或「系统泄漏」。资源消耗对用户透明指：正在用的电、网、热，能对上具体任务，数量级可感知，而不是只有系统设置里一串匿名的耗电排行。
透明不是精确到毫瓦的仪表盘。它是归因通道：这件任务、大概多少、还要多久这一档才会停。
机制
资源下降是全身感觉：发热、掉电曲线变陡、运营商流量警告。感觉没有标签。后台任务又故意不占屏幕，标签更少。归因于是落到最近用过的、或系统点名的那个进程。进程名往往是产品名，不是「正在备份那 2 GB」。人会去杀进程、关后台刷新、给差评——这些动作伤害的是被误判的耐久任务，不是真正的泄漏。
透明把感觉重新贴上任务对象：列表项旁的「正在使用蜂窝网络 / 预计还要 400 MB / 耗电偏高是因为转码」。贴上之后，人的策略变成取消或改到 Wi-Fi，而不是把整个产品当成故障。数量级比精确值重要：400 MB 和 4 MB 的决策不同，387 与 412 没有决策差。误报（任务已停仍显示在耗电）会把透明变成新的谎，所以透明要跟任务寿命走，停了就摘标。
边界
前台正在看的短任务，资源使用是预期内的，不必另开仪表，免得噪声。系统级的耗电统计有延迟，产品内的透明应以当前任务的已知体积和状态为准，不要和系统排行逐瓦对账。企业管控下流量费用不由用户承担，透明仍有意义（热、电、共享热点），但文案不要恐吓「你要付很多钱」。无障碍上，发热和掉电对有些人不可感知，透明更要走文字，不能只靠设备变烫来「自然提醒」。极小的心跳、分析打点不应进入这个通道，否则真的任务被噪声淹没；设一个会改变决策的阈值（体积、预计分钟、是否走蜂窝）。
怎么落地
- 在任务项上标正在用的资源种类（蜂窝 / Wi-Fi / CPU）和数量级（约多少 MB、约多长时间这一档）。
- 走蜂窝且体积会让人在乎时，提交前或开始后立刻给一次可改到 Wi-Fi 或取消的机会。
- 任务结束或暂停，资源标摘掉；不要在空闲时继续显示「耗电」。
- 验证：在蜂窝网络下开始一次数百 MB 的备份，不打开系统设置。产品内应能看见这件任务在用蜂窝、体积量级对得上。把任务取消，掉电归因应不再指向它。对照：同一备份在界面上毫无资源信息，只在系统耗电排行里出现产品名——这就是会把备份误判成泄漏的形态。