信息系统实践手记6-JS调用Flex的性能问题一例

说明：

正文：

  • 信息系统实践手记系列是系笔者在平时研发中先后遇到的大小的问题，其中比较典型的内容加以收集和分享。
  • 信息系统实践手记目录：博客园(或查看源码的README.MD文件)

摘要：

  • 此文描述了JS和FLEX（Flash）交互的一些经验总结。

正文

在笔者实践中，遇到有些情况下（比如开发地图应用），客户端的JS代码往往要调用地图引擎的API。
地图引擎的API，有些是JS接口，那最方便，有些是FLEX编程接口的API（运行在Flash里），JS调用Flex性能有如下经验。
比如客户端是基于地图的应用，用JS代码调用FLEX的API接口，需要通过FLEX的语句在地图上呈现（放置）2万个对象（Object）。

  • 方法A(较低效)：

    • 在JS中，通过业务层得到N万个设备的信息数据，诸如数组DEV[N0000]；
    • 在JS中，将信息数据打包为hashmap(key -> value)；
    • 在JS中，将hashmap数据结构从JS传入Flex： JS --> Flex;
    • 在Flex中，获得传入的hashmap结构，并循环显示在GIS地图上；
    • 在Flex中，通过hashmap结构提供用key查value的服务：val = devicehashmap.get（key）；

  • 性能评估&分析：

    • 在步骤2，3，4中消耗了20秒左右，数据量是2万个device；主要是步骤3较慢；
    • 初步估计，JS中组成hashmap结构需要花费一定时间，但不多；可惜这种高级结构对JS/Flex两侧是个负担，传入的时候需要做必要的检查和转换，所以比较慢；
    • 另外，考虑到JS/Flex相互调用结构比较复杂，如果传递高级结构，两侧系统容易在解析上不一致而会引起额外的开销；
      （备注：其实还尝试过方法A的变种，就是在JS这里启动循环2万次，每次将一条设备信息传递给Flex并在GIS地图上显示Object，虽然每次数据量极小，但是来回调用JS/Flex2万次，效率更低下，所以也舍弃了，这里就不再讨论了）

  • 方法B（较好）：

    • 在JS中，通过业务层得到N万个设备的信息数据，诸如数组DEV[N0000]；
    • 在JS中，将信息数据打包为长字符串String（带约定结构/类似JSON）；
    • 在JS中，将String从JS传入Flex： JS --> Flex;
    • 在Flex中，获得传入String，并解析还原为hashmap，并循环显示在GIS地图上；
    • 在Flex中，通过hashmap结构提供用key查value的服务：val = devicehashmap.get（key）；

  • 性能评估&分析：

    • 在步骤3中消耗了1秒左右（其实是500ms左右），数据量是2万个device；
    • 初步估计，经典的数据结构String，在大多数系统中都能很好的互操作，并获得最简单的支持和解析（比如大都是bytes字节数组，最后一个是标记，或者有一个小小的优雅的头结构等等），所以传递String极大的降低了时间开销。而对JS侧，拼接String比组装hashmap更快些；在Flex侧，自己解析String组装自己的haspmap（不是理解JS的hashmap结构）也很快。
    • 总体上步骤1到5消耗在1秒左右，达到要求；
      （备注：其实在尝试几种其他GIS引擎的时候，我们采用JS/API接口，就没有遇到如上的问题，这其实对技术选型是很重要的。）

总结：

很多时候，开发一个系统，实现了A和B的互相调用和操作，只是达成而已。更多情况下实际应用场景必然有数据压力和性能要求，而一旦上了性能，“可用”就不够了，还要考虑“可行”；
从众多的方法中找到切实可行的，才是最终目的。这其实要求对各种方法的理解和比对有深入的研究。但时间有限，经验有限，人力有限，所以只能做代价有限的尝试，并不断优化，这可能也是迭代开发或敏捷开发比较提倡的吧。
性能优化我在之前的篇幅已经粗略的谈到，只要有性能瓶颈，只要未达到物理（理论）可计算的性能边界，就能找到合适的方法来优化。
另外，技术选型也很重要，对于目前我们接触的几个GIS引擎，支持JSAPI的都未出现类似问题，而非JS的API接口就需要做额外的研究，尝试和优化。这对技术选型也是一个值得思考的例子。

END