JustZht's EchoChamber

说两个好玩的事情。
第一个事情还蛮侦探的。最近在美国住在 Bell Canyon 附近，然后住处的路由器是 Google WI-FI。有天在外面玩我妈打电话给我说是不是我刷了我爸卡四笔共 2000 块钱，我说没啊最近都只用自己的卡，再一看我爸卡的消费记录是国内时间半夜，一个小时内连续四笔，每笔金额都差不多。自己以为是被盗刷了于是让我爸先去锁卡。然后我爸和银行客服沟通后说是优步扣的，我去看优步和 Paypal 都没有记录，又搜了下网络说有很多盗卡给别人提供低价打车服务的，因此觉得是不是遇到了啥盗刷套现或者幽灵车之类的事情，因此和 Uber 客服联系了下。
Uber 客服还没给我回信，我的一位也在 Bell Canyon 的同事和我说她今天查看了下她的银行卡发现也被刷了，而且模式很像：一小时内连刷四笔，四笔金额都差不多，而且时间就在我被盗刷后二十分钟内。我们就更摸不着头脑了，开始研究是不是有什么中间人或者奇怪的手段，不然不可能手法如此相像，气氛也有点奇怪了起来，感觉网络被做了什么手脚。
我的那位同事打了通电话给银行客服，客服说是 Lyft 的扣费，但是银行这边状态是拒绝交易了。然后我们回想起来貌似国内半夜的那个时候正是 LA 这边早上八九点，那天要一起去 LA 市内取车，因此我们都在不停地打车，但是都没有打到，最后是另外一位同事帮忙打到的。而信用卡盗刷消费每笔的金额差不多就是 Bell Canyon 到市内目的地的价格。
所以这个事情变成了：扣费应该是我们自己主观打车操作造成的，但是 Uber 和 Lyft 在那天早上不约而同都出现了没打到车但是扣费也没订单记录的问题。我们研究了下，感觉是不是 Google WI-FI 路由器的 Mesh Network 切换路由器导致状态没同步或者内建的防火墙拦截了什么不该拦截的请求。
不管怎么说至少不是奇怪的剧情走向了，而是变成了一个技术 bug 相关的问题，现在就希望 Uber 客服能早点退钱给我。🤔
第二个是：8012 年了，Unity 的 AudioSource 竟然还没有播放完成的 API。
这么一个简单必须的 API，竟然到现在还没有提供，因此搜遍论坛上得到大家普遍的最佳实践是：先获取 AudioClip 的长度，然后设置一个携程去做倒计时，在携程最后调用自己的回调。
因此为了一个简单的事件，就必须在引入 AudioSource 的类中再引入一个长度的倒计时，而且要在每次 AudioClip Re-Assign 的时候清零重新计算。这就是典型的我所痛恨的 Unity Pattern：为了一个简单的事情，在一个类里面引入不必要的 Flag 作为状态标识符，然后事情一多，多个 Flag 就开始打起来了，类变得非常混乱。
这个事情不是不能避免，但是对于很多新手来说，这种 API 设计就是在逼着大家去写 Shit Code，把所有东西都逼着写到 Update 里面重复检测，活生生写成面向过程的东西，而且系统提供的 API 缺乏很多必须的信息，导致如果不从头抛弃内建的音频系统（FMOD 和 Audio Mixer）的话，最后看起来比较简洁的代码背后的实现也是比较耗费资源的（比如做一个属性变动的观察，实际上只是把 Flag 标识符的代码写在一个全局的专门用来观察的地方罢了）。