由于 GMS 的闭源特性 ， 成熟的商业 App 肯定不会只使用 Google 的 Sleep API ， 更多是以此来辅助自己的算法 ， 用户体验到的会是优化后的融合效果 。 例如我们前面提到的 Sleep as Android ， 设置选项中就有是否使用 Google 睡眠 API 的选项（默认打开） ， 说明当你关闭的时候 ， 它有自己的备选方案来兜底 。
如何减少睡眠监测的电量消耗
相比三方应用开发者 ， 手机厂商的巨大优势就是硬件 ， 这里说的硬件不仅仅是区别于手机的穿戴设备那么简单 ， 而是指手机、手表等设备内部的芯片、传感器 。
上层软件开发者在睡眠监测这个功能上有两个主要劣势：

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

针对上述 2 个缺点 ， 对应聊一聊厂商的系统应用是如何解决的 。
使用融合传感器
任何某个单一传感器都是无法满足监测识别任务的 ， 厂商可以开发专属的传感器 ， 来采集其他基本传感器的数据 ， 融合成新的传感器事件（event） 。 这个专属传感器可以是真实元件 ， 成本较高；也可是模拟的 ， 一般在系统的硬件抽象层（HAL）做模拟 。
最后对于上层的系统应用（System Apps）来说 ， 就是多了一个可以监听的 Sensor 类型而已 。
融合传感器可以避免上层应用同时监听多个传感器 ， 大大降低功耗 。 很多人可能会有疑问：融合的数据不也是在底层同时采集了多个其他传感器吗？
确实是 ， 但是它减少了从底层到上层一系列的框架调用 ， 底层硬件的耗电其实远小于软件层面的CPU消耗电量 。

文章图片

Android系统架构算法下沉
有了融合传感器之后 ， 我们可以进一步把一些较为固定的业务逻辑和算法模型下沉到系统底层 ， 让专用的处理单元（比如 DSP、TPU 等）去做计算工作 ， 最后直接把识别的结果传递给上层应用即可 ， 传递数据之前的整个过程中都不需要唤醒上层的应用进程 ， 应用层只需要在接收结果后稍作修饰 ， 再做纯业务展示即可 。

• AOSP - CHRE

这一系列做法可以极大地降低设备功耗 。 这就是为什么某些厂商可以自信地宣称系统内置运动健康类App的各种活动识别全天耗电在 1% 以内 。
小结
睡眠监测越来越得到各家健康 App 的重视 ， 虽然三方和厂商在基础能力上有先天差距 ， 但随着技术的成熟 ， 厂商为了建立自己的生态 ， 也愿意开放能力出来给大家使用 。 降低行业总体成本的同时 ， 未来角逐的更多还是产品体验 。
题图来自
> 下载 、关注， 解锁全新阅读体验??
> 实用、好用的， 少数派为你呈现??
? 本文著作权归作者所有 ， 并授权少数派独家使用 ， 未经少数派许可 ， 不得转载使用 。