博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【设计】客户端更新定义数据(Definition)的几个方案
阅读量:6245 次
发布时间:2019-06-22

本文共 836 字,大约阅读时间需要 2 分钟。

一、问题/需求

场景:

  • 客户端展示来自服务端的数据;
  • 数据项(Item)有很多,并且可能增、减;
  • 每个数据项的定义(Definition)也可能变化
  • 数据(Data)的展示将依据它的定义

分析:

  • 尽管定义可能发生变化,但频度是比较低的,并不需要每次均从服务器端获取。而具体的数据则是变化的,需要每次获取。
  • 当客户端为移动终端(如手机)时,响应时间是个重要指标
  • 减少Definition的获取,将有效提升客户端的响应时间

 

二、方案

有3个方案:

1) 即时(JIT, Just In Time)  更新
每次申请Data时,同时(JIT)传过去Define的LastUpdateTime.
服务端判断有新的,则与数据一起返回。

2) 按需(OnDemand)更新:

每次需要此数据时,判断IsNull。若为空,则申请更新

3) 初始化(Initiation)更新:第一次运行时全部更新

- 建立标志Flag_Initiated = False.
- 若FALSE, 则做个初始化动作,全部更新;完成后设为True

注:2,3均需同时运行【独立更新Definition】功能 -- 后台线程在空闲时取。

 

 

三、方案比较

----------------------

  • 文案2 与 方案3 比,其实是一种延迟策略,只取所需。很多场景下,Definition集合很大,用户不会每条路径都走到。方案3(初始化)不仅有大量浪费,而且初次占用时间可能过长,导致用户体验较差。
  • 方案2与3 存在一定的Definition过时风险
  • 方案1的缺点是:2个逻辑混在一起,复杂度提高一点点;同时,大部分情况下是无用功(返回空)。
  • 方案1的优点是:正确性可以很好地保障。

 

另,方案1与2,均可以作合并申请的优化:将Definition的申请与Data的申请,合并到同一个请求中,节约一次网络交互。这可以避免终端响应时间过长,对于移动互联网特别有价值。

四、结语

你会选择哪个?或者有更好的方案,也请建议。

转载地址:http://jkoia.baihongyu.com/

你可能感兴趣的文章
web基础html元素制作web
查看>>
Codeforces 96C - Hockey
查看>>
生成树协议
查看>>
Web应用三种部署方式的优缺点
查看>>
python爬虫——绕开杂乱无章的代码和堵住请求的302异常(2)
查看>>
static易错点
查看>>
js获取当前日期(年月日格式)
查看>>
LeetCode【217. Contains Duplicate】
查看>>
EBook
查看>>
单词加密
查看>>
【转】关于使用GUID和Identity做主键的一些思考
查看>>
oracle入坑日记<六>自增列创建和清除(含序列和触发器的基础用法)
查看>>
JS框架设计之主流框架的引入机制DomeReady一种子模块
查看>>
js失效的原因及解决方式
查看>>
heap堆内存不足
查看>>
scp命令
查看>>
02-Java中的对象和类
查看>>
if 判断语句
查看>>
tornado+websocket+mongodb实现在线视屏文字聊天
查看>>
如何使用VSTS做压力测试
查看>>