@ljtletters 特定唤醒词，实际上就是 "Hey Siri"，这个可以看一下苹果给出的技术细节：
http://www.zhiding.cn/techwalker/documents/J9UpWRDfVYHE5T0OHi3xkN_bG8foCpHEECuvwQScpjg

苹果是用的 AOP (一种低功耗协处理器) 来接收麦克风信号，苹果把 "Hey Siri" 这个特定的词放入一个精简缩小精度低的检测器，运行于这个 AOP 上面，避免了 CPU 被唤醒。这个 AOP 识别唤醒词后，才会启动 CPU，改用更高精度的方式来处理。

@ljtletters 如果 App 处于后台没有关闭，此时还在一直监听，那就又回到了耗电的问题上了。

Apple Watch 和 AirPods 实际上是很好的例子，它们对耗电量很敏感，即使协处理器的监听也代价太大，所以会请求用户使用一个 Intent 来唤醒，比如抬起手表、或者轻击耳机，这时开始录音才能监听到有效信息。旧 iPhone 和很多 Android 没有协处理器，也是通过按键或者抬起手机这种行为作为一个 Intent。

没有用户 Intent 的情况下，监听在绝大部分时间都是无效、徒劳的。

@ljtletters 不提业务，这个仅从技术上是可行的，即 "App 处于前台时录音"，时间足够短，即使耗电多也不会太明显。
但是无法解释新闻里都是 "未开启 App" 的情况。

@greed1is9good @ljtletters 请解释一下为什么苹果谷歌的语音唤醒功能比如 Siri 那些，需要低功耗协处理器支持才能实现，没有协处理器的机型，只能充电时才能唤醒？

@ooooo 不考虑耗电的情况下，技术都是可行的，问题就是如何降低耗电。
你在 App 内调用录音功能，即使不编码、不探测，只过一次内存，耗电量都是不可接受的。
探测分贝会消耗计算量、编码会消耗更多计算量、转文本或提取特征会继续消耗更多计算量。

你认为自己技术不行，那苹果谷歌技术总能得到你的认可吧？他们自己的唤醒功能，都是通过自己使用协处理器实现的，iPhone 6s 之前的手机，即使都升级到了最新的系统，没有协处理器仍然只能充电时唤醒。如果有什么人能够实现不用协处理器，还能足够低功耗实现唤醒功能，怕不是早被苹果谷歌用上了。。

按这种性格来说，不论楼主离不离职，只要楼主还没成为主管，都会再次遇到这种问题。。

想了想，原因大概就像 @marsgt 说的那样。
人都是追求因果关系的，"事出有因"、"存在即合理(reasonable)" 都能表达出这种倾向。

这些公司推荐系统做得很好，会引起某些用户的警觉。他们发现推荐切实有效，所以会追求"原因"。但是受限于他们自身的认知，他们无法理解 "推荐系统" 运作的原理，所以他们就会从其他方面去猜测一个能够被自身认知所接受的"原因"。这个过程，就是 "迷信"。

破除这个迷信，需要以他们认知能够理解的方式阐明真正的原因：
1. 现在的推荐系统很强大，好友关系、GPS、IP、你提到的内容被你好友搜索、你经过了棋牌室或者咖啡馆的 Wi-Fi 等等，这些被忽视的东西都可以作为推荐系统的特征。

2. 推荐系统能够一定程度去进行猜测。比如投色子，总有一定概率能够得到我想要的数字。一旦猜测成功，跟你现实生活切实有关系，就容易引起警觉，因为这确实没有一个明确的 "原因"，这就是概率。

3. 实时录音分析在技术方面不可行。因为电量消耗以目前技术水平根本不可接受。如果你是做移动开发的，试试自己实现录音功能，即使不编码不写文件不做分析，电量消耗你也会受不了的。手机中的语音唤醒是由硬件的低功耗芯片 /协处理器实现的。例如苹果的 Hey Siri，支持的设备可见这里： https://support.apple.com/zh-hk/HT209014，iPhone 是从 6s 才开始支持的，是因为 6s 引入的 M9 协处理器，才能以足够低的功耗实现实时监听； AppleWatch 则是需要抬起或者点击屏幕才能唤醒监听。再例如 OK Moto，摩托罗拉用的是自己研发的有 NLP 功能的协处理器，其他 Android 用的是 Sensor Hub。只有那些音箱机顶盒之类的设备，没有电量限制的，才可以不用协处理器实现实时监听。

你们要是做过录音就知道功耗有多大了。。
完整语音上传那消耗资源更大，本地识别或者提取特征码计算量同样也不小。。

OK Google 和 Hi Siri 那种，都是基于设备专门的低功耗芯片来做的，即使如此也会增加不少耗电。
App 只能依赖通用计算功能，真要做长时间语音监听，掉电问题早就会让人石锤揪出来了，哪还轮得到现在这种毫无根据的猜测。。