打盹模式如何影响后台/前台服务,有/无部分/完整唤醒锁？

Question

这是一个简单的问题,看到G +(这里)有关于此的大量帖子,以及官方文档(这里)缺乏信息:

当设备进入"打盹"模式时,应用程序的服务会发生什么变化？

它对后台/前台服务(绑定/未绑定,已启动/未启动)有什么作用,有/无部分/完整唤醒锁？

例如,为了创建在设备屏幕关闭时播放音频流的服务,您会做什么？如果音频流不是来自本地文件,而是来自网络,该怎么办？

看到Google开发者声称:

已经运行前台服务的应用程序(带有相关通知)不受打盹的限制.

- 之后进行了大量的讨论,声称这并不完全正确,我认为知道特殊的后台操作应用程序应该做什么是相当令人困惑的.

Answer 1

具有当前运行前台服务的进程应该不受Doze的影响.绑定/未绑定,已启动/未启动以及唤醒锁不会影响此白名单过程.

但是,Android M设备存在一个问题,即当前台服务与顶级活动处于同一进程且未正确打瞌睡时,前台服务未正确列入白名单.

该修复程序可在AOSP上获得,并将包含在Android N的构建中.由OEM将这个补丁集成到他们生成的任何Android M构建中.

不是特定前台服务的服务(即,他们没有调用[startForeground](https://developer.android.com/reference/android/app/Service.html#startForeground(int,android.app.Notification)) )获得打瞌睡时适用的所有限制 - 它们不列入白名单.根据[2016年I/O媒体播放演讲中的最佳做法],音乐播放应用程序**应始终**成为前台服务的音频(https://www.youtube.com/watch?v=iIKxyDRjecU )强烈建议在一个单独的过程中(因为这是一个好主意和错误) (3认同)
无论他们使用什么targetSdkVersion,Doze都会影响所有应用 (2认同)
@ user1026605 - 不,这是设置服务使用过程的唯一方法. (2认同)
使用示例应用程序进行测试，我有一个后台粘性服务连续运行（服务有一个无限线程），它可以工作并休眠 1 分钟，然后再次醒来以完成它的工作，但后台服务仍然被杀死并且正在运行的线程被挂起. 此外，试图在单独的进程中运行该服务但徒劳无功。如果任何人都可以确认这种行为，因为这种行为没有记录在任何地方？ (2认同)
前台服务是否需要（部分）唤醒锁？我想不通。 (2认同)