证实:音讯种类施行手记种类是系作者在平日研究开发中程序遭受的大大小小的主题素材,或然朴实和一线,但一再却是经常碰着的标题。小编对中间比较规范的加以搜罗,描述,归咎和享受。

摘要:此文描述了小编接触过的一些信息种类或平台之间的连结构型和情况,以蠡测海的下结论分享之。

正文

文山会海小说目录:新闻连串实施手记 (http://www.cnblogs.com/taichu/p/5305603.html

作者:太初

转发表明:请指明原著者,连接,及出处。

 

正文

 

在作者施行中,越到稍微情形下(举例开采GIS地图应用),客商端的JS代码往往要调用GIS地图引擎的API。

稍许API提供JS接口(版本),那是最方便的,有个别提供诸如FLEX编程接口的API,让你在JS中调用,也是能够,但遭受如下情形,分享之。

 

大家的客户端是依据GIS地图的应用,用JS代码调用FLEX的API接口,需求通过FLEX的语句在GIS地图上海展览中心现(放置)2万个指标(Object)。

方法A(老方法):

  1. 在JS中,通过作业层获得2万个道具的音讯数量,诸如数组DEV[20000];
  2. 在JS中,将音讯数据打包为hashmap(key -> value);
  3. 在JS中,将hashmap数据结构从JS传入Flex: JS –> Flex;
  4. 在Flex中,获得传播的hashmap结构,并循环显示在GIS地图上;
  5. 在Flex中,通过hashmap结构提供用key查value的服务:val =
    devicehashmap.get(key);

天性评估&解析:

  1. 在步骤2,3,4中消耗了20秒左右,数据量是2万个device;首若是手续3极慢;
  2. 开首估量,JS中结合hashmap结构亟待开销自然时间,但不多;缺憾这种高端结构对JS/Flex两边是个肩负,传入的时候须要做供给的检讨和更动,所以相当慢;
  3. 其余,考虑到JS/Flex相互调用结构比较复杂,假若传递高等结构,两边系统轻松在解析上分裂样而会挑起额外的支出;

(备注:其实还品尝过方法A的变种,正是在JS这里运维循环2万次,每一回将一条设备音信传递给Flex并在GIS地图上展现Object,即使每一趟数据量非常小,不过来回调用JS/Flex2万次,效用更低下,所以也吐弃了,这里就不再商讨了)

方法B(新方法):

  1. 在JS中,通过专门的学业层获得2万个道具的信息数量,诸如数组DEV[20000];
  2. 在JS中,将新闻数据打包为长字符串String(带约定结构/类似JSON);
  3. 在JS中,将String从JS传入Flex: JS –> Flex;
  4. 在Flex中,获得传播String,并分析还原为hashmap,并循环展现在GIS地图上;
  5. 在Flex中,通过hashmap结构提供用key查value的服务:val =
    devicehashmap.get(key);

属性评估&分析:

  1. 在步骤3中消耗了1秒左右(其实是500ms左右),数据量是2万个device;
  2. 开始评估价值,杰出的数据结构String,在大部体系中都能很好的互操作,并赢得最简易的协理和分析(举例大都以bytes字节数组,最终三个是标识,大概有多少个非常小的幽雅的头结构等等),所以传递String非常大的狂跌了时间支付。而对JS侧,拼接String比组装hashmap更加快些;在Flex侧,自个儿深入分析String组装自个儿的haspmap(不是理解JS的hashmap结构)也不慢。
  3. 完整上手续1到5消耗在1秒左右,达到必要;

(备注:其实在品尝两种别的GIS引擎的时候,大家运用JS/API接口,就平昔不碰到如上的问题,那其实对技能选型是相当的重大的。)

 

总结:

  1. 重重时候,大家开辟一个连串,实现了A和B的并行调用和操作,只是达到而已。更加的多情状下实际利用场景必然有数据压力和性格需求,而假若上了品质,“可用”就相当不足了,还要思考“可行”;
  2. 从好些个的秘技中找到具体的,才是终极目标。那实际需求对种种方法的了然和比对有深切的钻研。但日子少于,经验有限,人力有限,所以不得不做代价有限的尝尝,并每每优化,那可能也是迭代开支或高速开荒相比较提倡的呢。
  3. 本性优化自己在前边的字数已经粗略的谈起,只要有质量瓶颈,只要未达到规定的规范物理(理论)可总结的本性边界,就能够找到适当的不二诀要来优化。
  4. 除此以外,技术选型也很入眼,对于当前我们接触的多少个GIS引擎,协理JSAPI的都未出现类似主题材料,而非JS的API接口就要求做额外的商讨,尝试和优化。这对才干选型也是一个值得思量的例证。