最遗憾的一点就是：
开发为避免所有 bug 堆积在一处效率低，也为了避免反复被打断工作，努力提供便于判断问题的日志之类。
希望在集中到某个判断点之前，有一个简单的初筛分流过程，类似招聘中的 HR ~
但是遇到只测”是否正常“，不想管“哪里异常、如何复现、根据现有表现和提示能不能初步判断归属之类问题”的测试，就会觉得心累了。如果测试在问题堆积的时候，不管你的节奏，反复打断让你立刻查原因，催你怎么还没改好，那可就不止是心累了...

始终觉得把 “初步判断” 和 “详细核查” 分摊到不同人身上，会比较高效吧？

@vocaloidchina #9 http

福建电信，之前 BWG dc8 不混测速只有 1Mbps，混完满带宽。
去年年底到现在，dc8 取消了 cn2，换成 dc3，混完也只有 1~2Mbps 。
另一个 Cloudcone 的混完大约 5Mbps 。

我们这预约已经取消，放开随便买了。

我的做法是：关了那个用音量键控制铃声和通知的开关。
以此实现：
- 音量键始终只控制媒体声音，需要时不区分场景直接按音量键；
- 用静音键控制通知声音，尝试过用捷径动作，发现调整的还是上一条的媒体音量；
- 通话中的音量设置，暂时只能在通话中调整；
- 闹钟音量始终不变；

脑洞一下：

定位太耗电了吧？想确定周围人数，不是非要确定周围人在哪。
用周围蓝牙的个数怎么样？

考虑原因如下：
- 蓝牙的检测距离；
- 蓝牙的普及和耗电；
- 蓝牙可由用户方便的开关；

流程：周围人根据个人感受开启蓝牙，抖音检查到蓝牙个数超过阀值后执行动作。
如果周围有 n 个人带着蓝牙耳机，导致触发阀值，那刚好可以说明：别人都带耳机一般也是不合适外放的场合。

感谢楼上回复的让我没有白折腾~
顺便谴责只用不说的行为。