这三类“超时”机制:逻辑类、业务类、性能类……

0 评论 5402 浏览 18 收藏 10 分钟

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

“希望迟迟不来,急死了等待的人”——《等待戈多》。

《等待戈多》是荒诞戏剧的代表作:以两个流浪汉苦等“戈多”,而“戈多”不来的情节,喻示人生是一场无尽无望的等待。

同样在产品体系中,也存在对系统应答的等待预期。因此需要定义超时,并提供相应的超时机制,避免“急死了等待的人”。

“超时”处理机制很常见。

本文笔者将其简单归结为三类:逻辑类的、业务类的,和性能类的超时机制。

一、逻辑类超时处理机制

这类超时机制,是为了完成功能闭环而设立的。举例如下。

1. 超时无应答机制

超时无应答机制比较常见,比如微信请求语音聊天,请求发出15s,对方不应答,则自动取消。

首先,请求发出去,一定要有结束的节点,避免无休止地占用资源。

其次,设置固定的等待时长,超时无应答,则结束。当然,也可以辅助手动取消按钮。

2. 若干时间内不打扰

有的场景,希望用户多次收到提醒,但是又不能过于频繁,因此可以设置成若干时长内不再打扰的模式。

类似下图免打扰的提示:XX分钟内不提醒,为用户提供更宽泛的选择通道。

这三类“超时”机制:逻辑类、业务类、性能类……

当然超过选定的时间久继续“打扰”了。

3. 超过一定时间,则采取措施

例如,出于存储的空间考虑,小米手机存储的照片超过一定时间没打开过,则自动上传到云端。那么这也是保障手机性能的一个策略。

它比“超时无应答”更激进一点,“自作主张”地将事件向前推进一步。

4. 超过一定时间,才释放新消息

比如发起好友请求,等待对方接受。发起方可以多次发送请求。

但是作为接受方,若始终看不到,或不处理,是否重复推送新消息,一条条通知摞起来呢?

通常的方案是引入超时释放消息的机制。即定义一个规则:

一定时间内,发起方可以连续发送待处理的消息,但只给接收方释放第一条。这样接收方就只显示一条待处理通知。

若超过一段时间(通常一周)仍没得到处理,则发起方再次发送的时候,重新释放一条新消息给对方,并将旧消息做更新(仍显示一条)。

5. 超过一定时间,则内容消失

某些互动游戏,需要双方对称发出的,如划拳类(石头剪刀布)、比大小类(掷骰子)。

一方发出之后,要等待对方。二人又可以不断地发新的,那么上次发出的要等待多久呢?

微信的处理办法是将发出的当作历史消息。这是一种省事的方案。

但是如果界面不是聊天信息流,而是有限的空间,比如这样:

这三类“超时”机制:逻辑类、业务类、性能类……

那么就需要考虑新的消息顶替旧消息,以及同一方发出的消息最长停留时间。

比如可以约定,同一方发出的,停留最长时间5s,超时则自动消失,无需等待对方的。若有新的则直接替换旧的。

二、业务类超时处理机制

业务方面的超时机制,多由业务习惯而定,相较宽松灵活。

1. “门槛”类的超时机制

一些社交软件,限时免费聊天,超时则需要付费,或其他办法获取延时。

比如语音聊天(未公开身份时)超过60s则自动结束。

这种就是从运营的需求考虑,人为设置一个“免费品尝”的条件,从而引入了超时的概念。

2. 交易类的超时处理

比如,卖家操作“发货”之时起,买家超过规定时限内确认收货且未申请退款的,则默认买家已收到货,且货物质量符合交易双方的约定,交易成功。

如果在贴近市场的话,还可以规定快递、EMS及不需要物流的商品十天内,平邮商品三十天内。

类似还有,买家自拍下商品之时起一天内未付款的,交易自动关闭;

自买家付款之时起三百六十五天内卖家未点击“发货”的,交易自动关闭,退款给买家;

卖家自本退款申请提交之日起五天内,不响应退款申请的,默认达成退款申请,进入到退货程序等。如电商这类业务性极强的领域,到处都是类似的超时机制。

3. 其他行业的超时规则

业务类超时机制,实际都是对实际业务模型的线上呈现,本质是对行业契约的履约。

三、性能类超时处理机制

性能方面的超时多是客观被动的,最主要是加载超时。包括是网络状态不好,和客户端配置不足导致的。

1. 网络原因的超时

网络原因的超时的原因,主要包括如下:

  1. 手机自身问题,比如停机、没开wifi或者流量、系统卡死等。
  2. 手机所处环境网络不好,向服务器请求超时。比如信号不好、或者信号接受不良。
  3. 服务器自身故。
  4. 服务器接收或回复故障,比如机房网络问题或服务器处理问题。

产品经理要做的就是如何让这个事件融洽地落地。

(1)直接报以空白页或者错误页

这三类“超时”机制:逻辑类、业务类、性能类……

(2)提供当前刷新渠道,保存前面的操作

比如用户是在网购,接近下单了,结果网络中断了一会。这时候直接反馈一个空白页,用户只能退回到上一步,前功尽弃。

因此最好是设计一个本地刷新按钮,点击即在当前刷新,避免了用户重复操作之前的步骤。

基于该思想,可以作如下发挥或拓展:

  1. 设计刷新时的彩蛋,给用户带来一些惊喜。比如弹出来一个俏皮的图案,或一句诙谐的话缓解用户的不满的情绪。
  2. 增加保存本地,或保存草稿的按钮。在表单资料填写界面,多使用类似的设计。
  3. 增加自动重新刷新:可以设置超时加载的机制。超过一定的时间 则取消本次加载。比如王者荣耀的连线尝试7次。

这三类“超时”机制:逻辑类、业务类、性能类……

以上实现的本质就是缓存。比如对于新闻类的、咨询类的,这类APP一般都会有缓存。这就是微信朋友圈,为什么在没有网络的情况下也是可以查看之前加载过的内容。

有的应用之所以很大,就是因为缓存了大量内容,当然也需要定期自动或手动清缓存的。

2. 客户端配置不足导致的超时

比如内存、分辨率等硬件参数导致的。这不是话题重点。

作为产品经理,只需要注意的是,做好边缘机型的适配。

#专栏作家#

唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm),人人都是产品经理专栏作家,2019年年度作者。《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!