等待戈多|这三类“超时”机制：逻辑类、业务类、性能类……

【等待戈多|这三类“超时”机制：逻辑类、业务类、性能类……】编辑导语： “超时”处理机制很常见。也许很多人疑惑超时机制是什么，但其实它与我们的生活密不可分。笔者将其分为三类：逻辑类的、业务类的、和性能类的超时机制，并详细介绍了这三大类。推荐对超时机制感兴趣的用户阅读。

文章插图
“希望迟迟不来，急死了等待的人”——《等待戈多》。
《等待戈多》是荒诞戏剧的代表作：以两个流浪汉苦等“戈多”，而“戈多”不来的情节，喻示人生是一场无尽无望的等待。
同样在产品体系中，也存在对系统应答的等待预期。因此需要定义超时，并提供相应的超时机制，避免“急死了等待的人”。
“超时”处理机制很常见。
本文笔者将其简单归结为三类：逻辑类的、业务类的，和性能类的超时机制。
一、逻辑类超时处理机制这类超时机制，是为了完成功能闭环而设立的。举例如下。
1. 超时无应答机制超时无应答机制比较常见，比如微信请求语音聊天，请求发出15s，对方不应答，则自动取消。
首先，请求发出去，一定要有结束的节点，避免无休止地占用资源。
其次，设置固定的等待时长，超时无应答，则结束。当然，也可以辅助手动取消按钮。
2. 若干时间内不打扰有的场景，希望用户多次收到提醒，但是又不能过于频繁，因此可以设置成若干时长内不再打扰的模式。
类似下图免打扰的提示：XX分钟内不提醒，为用户提供更宽泛的选择通道。

文章插图
当然超过选定的时间久继续“打扰”了。
3. 超过一定时间，则采取措施例如，出于存储的空间考虑，小米手机存储的照片超过一定时间没打开过，则自动上传到云端。那么这也是保障手机性能的一个策略。
它比“超时无应答”更激进一点，“自作主张”地将事件向前推进一步。
4. 超过一定时间，才释放新消息比如发起好友请求，等待对方接受。发起方可以多次发送请求。
但是作为接受方，若始终看不到，或不处理，是否重复推送新消息，一条条通知摞起来呢？
通常的方案是引入超时释放消息的机制。即定义一个规则：
一定时间内，发起方可以连续发送待处理的消息，但只给接收方释放第一条。这样接收方就只显示一条待处理通知。
若超过一段时间（通常一周）仍没得到处理，则发起方再次发送的时候，重新释放一条新消息给对方，并将旧消息做更新（仍显示一条）。
5. 超过一定时间，则内容消失某些互动游戏，需要双方对称发出的，如划拳类（石头剪刀布）、比大小类（掷骰子）。
一方发出之后，要等待对方。二人又可以不断地发新的，那么上次发出的要等待多久呢？
微信的处理办法是将发出的当作历史消息。这是一种省事的方案。
但是如果界面不是聊天信息流，而是有限的空间，比如这样：

文章插图
那么就需要考虑新的消息顶替旧消息，以及同一方发出的消息最长停留时间。
比如可以约定，同一方发出的，停留最长时间5s，超时则自动消失，无需等待对方的。若有新的则直接替换旧的。
二、业务类超时处理机制业务方面的超时机制，多由业务习惯而定，相较宽松灵活。
1. “门槛”类的超时机制一些社交软件，限时免费聊天，超时则需要付费，或其他办法获取延时。