「装了你们的包，手机放一晚上掉了快一半的电。」「切到别的应用十分钟，回来又要重新登录。」这两句话在内测群里经常一起出现，但它们其实是两条不同的排查线：一条是应用在后台到底还在做什么，一条是系统为什么把它回收掉了。混在一起改，常常改了半天没有效果。下面按顺序拆开讲。
先分清是耗电还是被杀
- 耗电：进程还在跑，网络请求、定位、定时器、日志上报都在持续唤醒设备
- 被杀：进程被系统回收，回到前台只能重新初始化，表现为「又要登录」「页面重置」
- 还有一种情况是两者叠加：为了不被杀掉而强行保活，反过来把电量耗光
判断方法很简单。让测试用户在系统设置的电池用量里找到这个应用，分别看前台时间和后台时间。后台时间明显偏高，才值得往下查；后台时间很短却依然掉电，要先怀疑电池本身或别的应用。
内测包自带的耗电项先排掉
内测包和正式包最大的差别，是它往往带着一堆调试开关。按这个顺序自查：
- 关闭详细日志与网络请求全量打印，只在复现问题时临时打开
- 检查日志与事件上报的策略，是否每一条都实时发出
- 检查轮询间隔，短间隔轮询在后台会反复唤醒设备
- 检查定位权限，内测阶段多数场景只需要「使用期间」
- 检查是否有调试悬浮窗、性能监控面板常驻
这几项改完，相当一部分「莫名耗电」的反馈就直接消失了，不用动业务代码。
后台为什么保不住
两端的规则不同，不能用同一套方案走到底。
| 平台 | 系统限制 | 更实际的做法 |
|---|---|---|
| 安卓 | 长时间不动会进入 Doze 低功耗状态，后台网络与唤醒被限制 |
把非即时任务改成可延后执行，交给系统在合适时机调度 |
| iOS | 切到后台后的可用时间很短，不允许长期驻留 | 在 BGTaskScheduler 里提交可延后任务，进入后台的窗口优先做上报与同步 |
- 不要为了保活无限制地开前台服务，常驻通知用户看得见，内测群里很容易被当成「耍流氓」
- 消息类需求应该走推送通道，而不是指望进程一直活着
- 真需要长期后台能力时，先确认业务是否真的需要，多数「保活」需求其实可以在回到前台时补齐
怎么跟测试用户交代
- 说明这个版本有哪些后台行为，例如会定时同步、会收集日志
- 说明预期耗电水平，避免用户拿内测包和正式版直接对比
- 请用户在反馈时附一张电池用量截图，比口述「掉电很快」准确得多
- 收到反馈先问三件事：哪个版本、什么机型、后台时间多长
常见问题
| 问题 | 说明 |
|---|---|
| 后台被清理算 bug 吗 | 分平台看，系统回收是正常行为，关键看回收后能否恢复状态 |
| 加了白名单就不会被杀吗 | 不保证，厂商策略与系统版本都会影响，只能降低概率 |
| 内测阶段要不要关掉崩溃上报 | 不建议全关，可以降低频率，否则出了问题没有线索 |
| 耗电问题一定要改代码吗 | 不一定，先排调试开关，很多是内测配置带进来的 |
小结
耗电与被杀是两件事，先量化再动手：看后台时间确认现象，清掉多余的调试开关，再按平台规则调整后台任务。确实需要长期驻留的场景，也应该用推送这类机制替代，而不是把进程硬留在后台。版本号记得一并记录，例如 1.4.3，否则反馈无法对应到具体的包。
建议 在提测单里单列一项「后台行为」，写清本版本有哪些后台任务、预期耗电水平、需要用户配合关闭哪些设置。发布时在虾分发（https://xiafenfa.com）按版本分别上传并标注版本号，测试反馈就能直接落到对应的安装包上，排查时省掉一轮来回确认。