一些设计原则和权衡

一些设计原则和权衡

选项越少越好

• 太多的选项会增加用户的认知负荷和决策时间
• 如果很多选项不可避免，应该分类和分页
• 低频的选项应该隐藏或者直接删除

如果1%的用户真的有那种高级需求，就去改代码好了

真正的小而美（不要学微信）

B站官方的评论栏有 高能榜排行+荣耀等级+粉丝勋章+头衔，我认为这实在太丑了，完全是为了刺激氪金而添加的。真正重要的信息只有用户名、消息内容，最多再加上舰队等级。其他的东西只是扰人耳目，我希望用户不会因为这些东西而被区别对待

流畅 VS 低延迟

因为网络抖动、B站服务器消息缓冲、用户发送弹幕时间不确定等原因，收到消息的速率是会频繁变化的。可能好几秒没有消息，然后又突然收到很多消息。如果要保证流畅（显示消息的速率波动小），就要引入jitter buffer，即收到的消息暂时不显示，而是存放到缓冲区里慢慢显示。这样，即使有一段时间没有消息，只要缓冲区里的消息还没发完，就一直有消息可以显示。只要在缓冲区里的消息发完之前，有新的服务器消息到达，那么用户看到的就是连续地有消息显示

但是jitter buffer会导致更大的延迟，这里的原则是流畅绝对优先于低延迟。因为对于显示弹幕这个场景，延迟是不太重要的——就算有5秒的延迟又有什么关系，只要大家看到的都是一样的内容就行了。另一方面，假如一有消息就立即显示，用户看到的是每隔两三秒出来一波消息，然后停顿一段时间，这样会极大破坏阅读体验。冷知识：即使是实时性要求很高的PVP游戏，也会有一到两帧的jitter buffer

当然延迟也要在一个合理的范围，目前blivechat除了网络延迟以外，额外引入的延迟也就每个消息最多1秒左右（其实就是抄YouTube的）

性能

性能是最后才考虑优化的方面，目前blivechat远远没到性能瓶颈。万一某天真的要优化性能，在改代码之前还有很多简单的方法可以用：

• 减少最大弹幕数
• 减少OBS浏览器的帧率
• OBS浏览器不可见时关闭源

不承诺不丢弹幕

不丢弹幕这件事在客户端是不可能做到的，因为即使代码做到完全可靠，网络本身也是不可靠的，万一闪断了那一定会有一小段时间的消息丢失，除非B站服务器协议设计了补发机制。客户端能做的只是尽早发现死连接，然后断线重连。为此我减小了心跳周期和超时判定的时间

如果用户需要100%不丢失付费消息，应该去看B站后台，因为只有B站有这个记录