最近在做关于带屏项目，前期的一些准备工作涉及到了屏保模式。上半年的时候参与类似的智屏音箱时也做个这样的功能。由于缺乏经验，对接的系统底层技术人员也没有开发过类似的功能，当时在调试过程中发现系统一个规律：先发送广播过一定时间再灭屏。所以就针对这个逻辑，延长了系统息屏一定时间，然后修改 ContentProvider 数据，应用层通过监听该数据值的变化，作出判断，在接收到息屏广播时，判断是否显示屏保页面，继续调整待机时长，从而达到屏保效果。这样做一定程度是完成了功能，但不严谨，存在不可控制问题，也会出现 Bug 。
这次处理屏保功能时，与另外一方的系统底层技术人员讨论了具体的实现逻辑。最后初步制定为：
1.Power 键维持系统原来的逻辑。
2.待机时间到，发送一个自定义的屏保广播。
3.应用层接收屏保广播，判断是否需要进入屏保模式。
4.不需要时，发送自定义的灭屏广播，系统层接收到该广播之后进入息屏状态。
5.系统层一样走原来的逻辑，发送息屏广播，防止第三方应用出现异常问题。
这样相当于应用层可以反向控制系统进行休眠。也可以更好兼容第三方资源 App 。这只是本人参与项目中实际开发时的一些逻辑，仅供参考。
