【术语】乐观更新
什么是「乐观更新」
通常,客户端在发起 CRUD 请求之后,都需要等待服务端返回,然后再去更新视图。这逻辑非常合理,一点毛病没有。唯一的缺点,就是在等待服务端响应的时间里,客户端只能空等,直观感受就是:用户从交互结束,到看到结果,中间免不了会有一个可感知的延迟。稍微对用户体验有所追求的,都会在这个时候显示一个 Loading,让用户知道系统还在运行。
如果你体验过 Google 家的产品,你一定会惊叹于其交互的响应速度,那种按下按钮之后立刻得到结果的快感,就好像一切都发生在本地,根本不用等待接口响应一样。Google 之所以能做到这种程度,并不是因为它是 Google —— 一个掌握着浏览器、网络协议、V8 引擎等核心技术的互联网巨头。人家的方案非常简单:真就是不等待接口返回,请求发出去的同时,直接就把交互的结果体现到视图上。
这就是「乐观更新」:客户端假设请求必然成功,因此不等待接口的返回,先行对视图进行更新。
这么乐观,适用所有场景吗?
乐观虽好,但我们也不能盲目乐观。并不是所有操作都可以通过「乐观更新」的方式来实现,需要有一些前提条件:
操作成功率非常高,大概率是不会失败的。
接口正常响应的耗时很短,不涉及大规模的计算或 IO。
操作可逆,失败了可以撤销。
像发送一条消息、删除一个文件,这些都是可以考虑「乐观更新」的,能够大幅提升用户体验。
你能接受每发一条微信消息都要等个半秒钟它才会出现在屏幕上吗?Windows 10 中删除到回收站的默认行为已经不会弹确认框了你发现了吗?
反过来,像文件传输、鉴权相关的操作,就不适合「乐观更新」了。
你能想象迅雷还没开始下载就直接显示下载完毕了吗?或者用支付宝付款的时候,先显示支付成功,然后才告诉你余额不足被撤单吗?