未持有wake lock的Android Service是否没有实际使用价值？

不持有Wake Lock的Service的存在意义 #

• 用于响应跨进程调用场景：作为暴露给其他应用的功能载体，仅在收到其他应用的IPC请求时才会被唤起执行对应逻辑，执行完成后即可销毁，全程不需要后台持续运行，自然不需要持有Wake Lock。
• 用于短时间后台任务：比如小文件上传、少量数据同步这类几秒即可完成的操作，在系统给后台应用的默认存活窗口内就能执行完成，不需要额外申请Wake Lock增加功耗。
• 用于绑定式场景：比如和前台组件绑定的音乐播放Service、投屏Service，仅在绑定的前台组件存活时需要运行，用户关闭前台组件后Service被系统杀死完全符合预期，无需长期持有Wake Lock占用资源。
• 作为系统调度任务的执行载体：Android 8.0之后官方推荐使用WorkManager调度延后、周期性任务，系统会在任务执行期间自动持有Wake Lock保证任务正常完成，应用侧的Service仅作为任务执行容器，不需要自行管理Wake Lock。

官方文档未在Service介绍中提及Wake Lock的原因 #

• Service的核心定位是通用型后台组件，Wake Lock属于PowerManager范畴的特殊能力，仅适用于需要阻止系统休眠的极特殊场景，不属于Service的必备配套能力，因此官方将Wake Lock相关说明放在了功耗优化、Doze模式适配的独立文档中，没有和基础Service文档绑定。
• 不同Android版本对后台Service、Wake Lock的限制差异极大：从Android 6.0引入Doze模式大幅收窄后台应用权限，到12+对前台Service类型做强制分类限制，Wake Lock的适用场景一直在被收紧，官方不希望开发者默认将Service和Wake Lock绑定，引导开发者优先使用系统提供的低功耗后台任务方案。
• Wake Lock滥用会导致设备待机功耗飙升，是Google Play审核的常见拒审项，官方不会在基础组件文档中主动引导开发者使用这类高功耗能力，仅在导航、健身追踪等确实需要长时间后台运行的场景的专项开发指南中才会提及相关适配要求。

内容的提问来源于stack exchange，提问作者Willem Bijker