this.$router.push如何刷新页面_如何提高用户体验:让数据跳动起来

c0079c562243e4c5eb16cdbc8dfce7f2.gif e433e4378aaa9ec7c5a7201b1dbc39da.png

Definesys Pluto:一款以提高人效为目标,面向项目全过程的线上项目管理、人效管理工具。通过将项目运营、项目管理、项目执行过程的数字化,针对数据进行定量而非定性的分析,将项目问题、风险显性化,逐步实现项目的降本增效、持续改善。

d9265d8db413e4e86f0b2e8baf89b1d1.gif d9265d8db413e4e86f0b2e8baf89b1d1.gif

前言

让数据跳动起来,让协作更及时高效。

日清单和任务看板这两个页面承载着Pluto系统上99.8%的任务,这两个页面的任务数据的准确性会很大程度地影响用户的工作效率,本文主要介绍Pluto如何实现页面数据的动态变化。

d9265d8db413e4e86f0b2e8baf89b1d1.gif

如何让数据准确、实时

01

手动刷新

通常情况下,可以通过手动点击浏览器刷新按钮或者点击系统内的功能按钮进行刷新以获得最新的数据。这种手动刷新的方案适用于用户数据交互实时性要求不高的功能,大部分内容展示型网站的主要功能页面(不包括消息)也都是这样做的,比如知乎、微博、简书等,Pluto中的文章广场就是这样做的。

但是这种方案对于Pluto的日清单、项目看板来说体验是最差的,用户基本上得不到任何来自系统的主动反馈,数据是否准确、实时完全取决于用户本身的操作习惯和运气...

02

定时刷新

定时刷新是实现数据伪实时最简单的方案,说白了就是以特定的的时间间隔,由浏览器对服务器发出HTTP请求,然后由服务器返回最新的数据给客户端的浏览器,很多网站的消息中心未读消息数就是这么更新的。

但是浏览器需要不断的向服务器发出请求,轮询的时间间隔设置短了可能会造成资源的不必要浪费,时间间隔设置长了用户的等待也就久了。

03

操作触发刷新

操作触发刷新就是用户主动进行功能操作时,通过请求成功的反馈主动的去更新数据,更新数据的方式可以是前端直接修改数据,也可以是调接口重新获取对应数据。这种方式常用于管理数据型页面,比如更新个人资料、各类型后台管理。

但是单纯采用这种方案是没法解决多用户协同处理数据的需求的。

04

websocket推送刷新

websocket推送刷新就是服务端基于TCP的全双工通信协议主动向客户端推送数据。简单来说就是前端在对应页面激活后,主动与服务端建立连接,服务端通过各种功能埋点,在数据产生变化的时候主动将变化的数据推送至对应用户的客户端。

对于这种方案也有两种更新数据的方式,一种方式是服务端直接将新数据作为内容推送至客户端,客户端直接拿消息的内容进行对应数据的更新;另一种方式是服务端只推送变动的提醒,不提供具体数据,由客户端主动进行新的请求。

理论上好像体验最优,但是这个方案非常依赖网络的高可用性和服务器的资源,所以实施起来的效果并不乐观。可能出现以下现象:

· 网慢就推得慢有延迟

· 切换网络或曾经断网该页面就再也推不动了,除非重新刷新重连

· 同一时段并发数多了,服务器带宽占满了也推不到

· 用户数据量大了连接数多了,内存爆炸了服务器就挂了要重启

·用户数据量大了连接数多了就根本支持不了,单台服务器也就65535个端口

d9265d8db413e4e86f0b2e8baf89b1d1.gif

Pluto的动态页面方案

血泪史

其实一开始Pluto啥方案都没有,研发阶段工作量大时间紧,一堆功能都没开发完,这时候的问题根本不是什么用户体验,而是这个系统有没有功能能用。但是从项目看板和日清单做好以后,我们项目在DEV环境就开始使用Pluto进行项目任务的计划和执行了,所以我们自己就是第一批用户。每天日常工作,都要面临以下场景:

场景1:

“馨怡姐,我任务提交了,前端dev部署了,可以测试了。”

 “好的,我刷新一下看看哪些任务可以测试了。”

过一会......

“馨怡姐,我任务提交了,后端dev部署了,可以测试了。”

 “好的,我再刷新一下。”

场景2:

“馨怡姐,我今天日清单怎么没有任务,是不是还没排。”

“刷新一下。”

场景3:

“有bug,任务被我打回去了。”

“哪个任务啊。”

“刷新一下。”

我内心OS:说好的提高工作效率呢?一点都不智能,干啥都要我手动刷新,任务的执行过程根本无法及时同步到所有相关用户那去。好在通过小伙伴们拼命加班赶进度,我们争取到了上线前的一点buff,这时候我就开始在想怎么让所有相关用户获取的数据尽可能的保持准确、实时,怎么让数据的变化更加自然。

我们第一版方案采用的是纯websocket推送刷新,任务的创建、编辑、认领、完成、验收等等一系列操作全部埋点,统一由服务端主动推数据给客户端,客户端自行重新请求数据。理论上这个方案是行得通的,但是理想很丰满,现实却很骨感,上线后收到无数吐槽,每天都是大型道歉现场:

场景1:

“为什么我点完成任务的勾,任务没反应啊?我都点了好几次了”

“对不起,可能是网速比较慢,请稍等一下。”

场景2:

“为什么我添加个人任务提示成功了,但是日清单没有啊?”

“对不起,可能是websocket断了,数据没推过来,请刷新一下页面。”

场景3:

“为什么我通过这个任务?任务不换甬道啊,我记得以前可以自动刷新啊?”

“对不起,可能是websocket断了,数据没推过来,请刷新一下页面。”

场景4:

“为什么Pluto访问不了啊?”

 “对不起,内存溢出了服务器在重启。”

还是要手动刷新!!!我深刻认识到websocket对用户的使用条件要求太高了。

22b33727f93facd07c6d8453cb2fa3f3.png

轮询是不可能轮询的,这辈子不可能轮询的,高带宽又配不起,就是补充一下操作触发更新,才能维持的了正常使用这样子。(手动狗头)

最终方案

01

自身操作采用操作触发刷新

梳理规划好所有用户自触发的操作,由前端埋点在这些操作的请求返回成功后,主动替用户重新请求新的数据。

比如:创建个人任务场景,在创建个人任务接口返回成功的信息后,再调一次日清单查询的接口,但是去除了loading,辅助动画入场的效果,给用户的感受就是一条新任务动态进来了。

1888fba9b33edf4c8353da8aee5779a3.gif

02

他人操作采用websocket推送刷新

保留原先websocket推送刷新,任务的创建、编辑、认领、完成、验收等等一系列操作全部埋点,统一由服务端主动推数据给客户端,客户端自行重新请求数据。 

比如:其他成员提交任务,在收到服务端通过websocket推来的消息后,再调一次任务看板查询接口,同样也是去除了loading,辅助动画入场的效果,给用户的感受就是其他成员实时提交了新任务。

46ccdcb86b199cf2152b8c38672d1c51.gif

肯定有人要问为什么不前端直接改数据,这样可以节约再次请求的时间啊?

 答:其实我们的确是做到了服务端推送更新后的单条数据,但是由于单次操作可能引起的任务状态变更、任务内容变更、统计数据改变等情况实在是太多了,如果要正确地处理、比较这些改变然后去做对应的动画,等于在前端也写了一套完整的任务逻辑处理代码。且不说这套处理是否准确,是否能做到与服务端的处理保持一致,需要思考的其实是:让前端去做这样复杂的数据处理是否真的合理?

03

单用户多个sessionid

什么是sessionid? 简单来说,它就是用来标识对应的客户端的,否则服务端无法识别消息应该推送给哪个对应的客户端。由于没有单独的redis服务器,我们暂时只能把sessionid存在内存里。

为了不被白白扣上程序员的“天敌”这个帽子,所以我提了这个需求。(开玩笑的 提这个需求的背景是这样的:由于我们也是第一次用websocket,所以一开始实现的只是一个用户对应一个活跃的sessionid,但是后来我发现同一个浏览器开多个标签页就等于多个客户端会有多个sessionid,就会出现以下情况:

1.用户A打开了标签页1与服务器建立连接,分配到sessionid1

2.用户A在打开一个标签页2与服务器建立连接,分配到sessionid2,原sessionid1就失效了

3.用户A的标签页1永远收不到服务端的推送了

同一个网站开多个页面的场景其实是经常出现的,假设我开了一个日清单页面为了执行自己的任务,再开一个任务看板页面为了查看项目的任务执行情况,如果没有实现单用户多个sessionid,那么我的日清单就永远收不到推送了,任务被打回我不知道,有任务指派给我我也不知道,这样明显不合理。

所以无论你开多少个标签页,有网的情况下数据都能推送得到,就能尽可能避免同一用户面对的数据不一致的情况。(大家不要暴力使用,要节约服务器资源哦)

04

分模块socket

Pluto中的websocket还分了日清单、任务看板、消息中心三个模块,每个模块只接收对应的消息,也就是不必要的消息不会被推给不必要的客户端。 

比如:用户A、用户B同属一个项目,任务看板新增一个用户A的任务 如果没有分模块,由于不知道用户在使用哪个功能页面,所以用户B不论在日清单页面还是任务看板页面都会收到推送去请求新数据。但是我们可以发现,如果用户B在使用日清单,此时用户A的任务理论上不会对用户B的日清单数据产生任何影响,这时候重新请求日清单的数据无疑就是多余的操作。

05

心跳检测

由于客户端可能由于网络波动等原因断开websocket的连接,但是服务端并不知情,这些不可用的sessionid就会一直占用着内存,直到再次把内存搞崩。所以我们做了标准的心跳检测,如果客户端没有响应,就清除对应的sessionid。

06

断开重连

由于客户端可能由于网络波动等原因断开websocket的连接,但是用户并不知情,这时前端会检测当前页面需要建立的websocket连接是否打开,如果没有便会进入定时器进行5分钟一次的重连尝试。如果用户电脑锁屏休眠断网了,再次开启使用一段时间后便会自动重新连接,由于补充了操作触发刷新机制,这段时间内用户自身的操作带来的数据变化也能及时更新。

07

定时清除

前面说到sessionid是存在内存里的,配合token每天0点失效的机制,每天0点也会统一清空sessionid,避免有一些漏网之鱼占用内存。

d9265d8db413e4e86f0b2e8baf89b1d1.gif

写在最后

为了让数据能实时地在用户之间传输交互,为了让团队协作更高效,为了让工作更有趣,以上方案我们都思考、探索过,目前我们认为操作触发刷新+websocket推送刷新的方案,能满足大部分场景下数据实时交互的需求,如果各位大佬有更好的技术方案建议,欢迎在评论中讨论,我们很乐于倾听大家的想法和建议。

本文来自《Definesys Pluto绝密档案》专栏文章

作者:许馨怡

8555804af7782b3a48adb9afd933c22a.png

许馨怡 得帆中台首席产品经理

曾负责设计CRM、WMS、定制业务系统、移动物联APP/小程序、互联网产品等。

cb9872f4991d8d5ddc0edae307f90472.png

关于得帆

06ae02e3977f6cac0d26ef4411367718.png

上海得帆信息技术有限公司(简称:得帆信息),公司注册在上海张江高科技园区,经过10年的经营发展,得帆信息已经成为中国在企业级中间件(ESB,Portal,BPM,微服务)和中间件云产品领域人员规模最大、服务范围最广、客户群体最多的IT咨询服务公司之一。

经过10年的砥砺前行,拥有超过300+的大中型客户,实施超过1000+的中间件项目,每年收入50%以上来源于老客户,成为当之无愧的中间件技术服务领导者,用口碑和技术实力践行了得帆的使命“用信息技术帮助客户幸福和成功”。

得帆信息的服务领域包括企业级中台系统咨询和实施、ESB信息系统集成、BPM业务流程系统实施、企业集团全球官网实施、企业内网门户及身份管理实施、大数据规划和实施等服务,为推动客户在数字化,互联网+和工业4.0转型提供专业的信息化支撑和保障。

0462f0bc5a173e6f81838fea44f4a1f8.png
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值