标签:例子 先后 设备信息 文件 重要 互操作 标记 物理 检查
layout: post
title: 2016-04-25-信息系统实践手记6-JS调用Flex的性能问题一例
key: 20160425
tags: GIS JS FLEX 技术选型 性能 API 调用
modify_date: 2016-04-25
---
说明:
正文:
摘要:
正文
在笔者实践中,遇到有些情况下(比如开发地图应用),客户端的JS代码往往要调用地图引擎的API。
地图引擎的API,有些是JS接口,那最方便,有些是FLEX编程接口的API(运行在Flash里),JS调用Flex性能有如下经验。
比如客户端是基于地图的应用,用JS代码调用FLEX的API接口,需要通过FLEX的语句在地图上呈现(放置)2万个对象(Object)。
另外,考虑到JS/Flex相互调用结构比较复杂,如果传递高级结构,两侧系统容易在解析上不一致而会引起额外的开销;
(备注:其实还尝试过方法A的变种,就是在JS这里启动循环2万次,每次将一条设备信息传递给Flex并在GIS地图上显示Object,虽然每次数据量极小,但是来回调用JS/Flex2万次,效率更低下,所以也舍弃了,这里就不再讨论了)
总体上步骤1到5消耗在1秒左右,达到要求;
(备注:其实在尝试几种其他GIS引擎的时候,我们采用JS/API接口,就没有遇到如上的问题,这其实对技术选型是很重要的。)
总结:
很多时候,开发一个系统,实现了A和B的互相调用和操作,只是达成而已。更多情况下实际应用场景必然有数据压力和性能要求,而一旦上了性能,“可用”就不够了,还要考虑“可行”;
从众多的方法中找到切实可行的,才是最终目的。这其实要求对各种方法的理解和比对有深入的研究。但时间有限,经验有限,人力有限,所以只能做代价有限的尝试,并不断优化,这可能也是迭代开发或敏捷开发比较提倡的吧。
性能优化我在之前的篇幅已经粗略的谈到,只要有性能瓶颈,只要未达到物理(理论)可计算的性能边界,就能找到合适的方法来优化。
另外,技术选型也很重要,对于目前我们接触的几个GIS引擎,支持JSAPI的都未出现类似问题,而非JS的API接口就需要做额外的研究,尝试和优化。这对技术选型也是一个值得思考的例子。
2016-04-25-信息系统实践手记6-JS调用Flex的性能问题一例
标签:例子 先后 设备信息 文件 重要 互操作 标记 物理 检查
原文地址:https://www.cnblogs.com/taichu/p/8868346.html