解决方案|科普 | 从解决方案到底层实现：你的手机是这样进行睡眠监测的( 六 )_手机|功能|监测|相关|底层|睡眠

【解决方案|科普 | 从解决方案到底层实现：你的手机是这样进行睡眠监测的】而 SleepClassifyEvent ，便是睡眠识别分类事件，包含了睡眠识别的置信度和传感器数据等信息，且此事件回调周期是固定间隔10分钟：
关键方法说明0到100 ，值越大置信度越高，说明用户当前越可能处于睡眠状态顺便返回环境亮度值顺便返回设备位移值，即加速度传感器的包装数据事件发生时的时间戳，是一个时刻，非连时间段
有了这些方法，睡眠类 App 开发的门槛大幅降低，大概是一件好事吧。当然，这就相当于完全信任 Google 的模型，且依赖 GMS 框架，国内恐怕不好普及。
不过之前在做竞品调研的时候， Pixel 机型的效果确实比其他手机好。同样的一份测试代码，在调用相关 API 时得到的事件数据更多、更连贯，这样更利于后续的处理和展示，而非寥寥几个事件，或者甚至没有；国产某些旗舰机（自带 GMS 框架）虽然也有效果，但比起亲儿子手机，还是要差一些。个人认为导致这个差距的主要原因，还是跟系统后台限制和底层框架的修改有关。
由于 GMS 的闭源特性，成熟的商业 App 肯定不会只使用 Google 的 Sleep API ，更多是以此来辅助自己的算法，用户体验到的会是优化后的融合效果。例如我们前面提到的 Sleep as Android ，设置选项中就有是否使用 Google 睡眠 API 的选项（默认打开），说明当你关闭的时候，它有自己的备选方案来兜底。
如何减少睡眠监测的电量消耗
相比三方应用开发者，手机厂商的巨大优势就是硬件，这里说的硬件不仅仅是区别于手机的穿戴设备那么简单，而是指手机、手表等设备内部的芯片、传感器。
上层软件开发者在睡眠监测这个功能上有两个主要劣势：

只能调用封装好的传感器数据API或者集成好模型的二次API ，无法得知底层实现，做不了数据源的定制化开发，最终必须在数据处理上玩出花才行。
不管监听哪种传感器，以及声音采集，都是非常耗电的行为，即便睡眠场景不用太担心电量，但对各类健康App来说，不只有睡眠功能，其他诸如运动、测量等功耗自然是越低越好，所以功耗问题三方应用没有办法太好地解决，软件优化是有瓶颈的。

针对上述 2 个缺点，对应聊一聊厂商的系统应用是如何解决的。
使用融合传感器
任何某个单一传感器都是无法满足监测识别任务的，厂商可以开发专属的传感器，来采集其他基本传感器的数据，融合成新的传感器事件（event）。这个专属传感器可以是真实元件，成本较高；也可是模拟的，一般在系统的硬件抽象层（HAL）做模拟。