我理解这个玩意的原理如下：当声音很大的时候耳朵和拾音器的敏感度都下降了。这玩意发出很大声的超声波，导致拾音器的敏感度下降，从而使拾音器在可听频率的声音相对减小从而被淹没。如果我理解不对，请指出。

那么，如果拾音器在模电转换之前就通过一个低通滤波器把超声波滤掉，这样的拾音器是否能对抗该设备？

有啊。比如讯飞的语音合成就可以通过很少的语料训练生成某个人口音的机器音。

2019 年广州平均工资 7860.6

是我的问题么，我都没看见是什么公司。

@whileFalse #11 还有就是 @HonorLee #8 说的有一点很重要，消息队列和消息流不是一类东西，虽然他们很相像并且某种情况下可以互相替代。AWS 中分别对应着 SQS 和 Kinesis 两个服务，不知道阿里云之类有没有对应。

@xidianzyf #3 如果是 AWS 的话，就非常简单，几乎不用写代码。
1. IoT Core 用于和所有设备保持连接，并收集消息。IoT Core 没有连接数上限。
2. 将消息流输出到 Kinesis Data Firehose 中，可以讲将原始数据存储到文件存储 S3 中。Firehose 具有完全弹性，因而可以承载足够多的设备消息。
3. 使用 Kinesis Data Analytics SQL，使用 SQL 语句从 Firehose 流数据中实时查询。可以配置使用滑动窗口查询，比如收集每分钟的数据查询一次，每分钟出一系列的查询结果。
4. 使用 AWS QuickSight 展示 Kinesis Data Analytics SQL 的查询结果。

我不熟悉国内的云，但如果有对应的组件，也可以极大地减少开发成本。比如说压力最大的 hold 连接、转发到队列这里可以用基本具备完全弹性能力的函数计算，或者你愿意用负载均衡器和弹性伸缩组也行；把消息丢到托管消息队列里面；然后你的服务基本就不会崩溃了，后面你怎么读消息怎么可视化就无所谓了。

大量是多大量？数万吗？
这个需求能上云的话随随便便就搭一个出来。不能上云就按楼上的办。

那不是有五个触点么。

图裂。

pac 脚本没问题吧。可以试试直接用 curl 取一下 pac 脚本，看看用时

老哥在 p2p 干来着？

@newbieRenew #3 纠正一下，辞退叫赔偿，不续签叫补偿。🐶

这相当于公司给你提供一个额外的选项，不选没有任何损失。

凡是概率低于 50%的，建议你们把题目中的参数改成“....目击者在当时能够正确辨认出这两种颜色的概率是 [100%] ”，带入你们的公式，看结果合逻辑不？

@crs0910 #18 @JimmyG #17 @wjfz #14 @Tardis233 #11 @iVeego #7

可以看看 Speedify

干啥能上两万连接？

@scf10cent #12
你提到自用的后端对性能不敏感，是 Flask ；前端是独立的函数。那你前端还是几乎不依赖框架裸写咯？在生产场景下，普通的后端程序员不依赖框架的工作效率是很低的。至于对性能不敏感的管理端，部署在 lambda 中也没有太大意义。

厂商是在优化冷启动问题，但更多的是用户代码之外的冷启动速度优化。Flask 作为用户代码，几乎没法优化冷启动效率。

我家的就有