【规划】客户端更新界说数据(Definition)的几个计划51CTO博客 - 凯发娱乐

【规划】客户端更新界说数据(Definition)的几个计划51CTO博客

2019年03月31日13时33分18秒 | 作者: 运盛 | 标签: 计划,更新,数据 | 浏览: 799

一、问题/需求

场景:

  • 客户端展现来自服务端的数据;
  • 数据项(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的恳求,兼并到同一个恳求中,节省一次网络交互。这能够防止终端呼应时刻过长,关于移动互联网特别有价值。

四、结语

你会挑选哪个?或许有更好的计划,也请主张。

版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表凯发娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章