ArcGIS API for Flex 客户端绘图性能测试

测试环境

Windows XP SP3，3G内存，Firefox 3.0.6，Flash插件 10.0

测试方法

通过改变客户端绘制的Graphic对象个数、Graphic种类、属性等因素，记录程序执行时间的变化。在客户端绘制的时候，Graphic对象的生命周期一般经历了创建-渲染-移除这样一个过程，因此本测试中主要测量的分别是生成所有Graphic对象所花时间、将所有Graphic渲染所花时间、清楚所有Graphic所花时间。另外需要注意的是，Flex对时间的测量有大概几十毫秒的误差，因此小时间的测量结果的相对误差比较大。测试数据依赖硬件和系统环境，因此仅供参考。

测试过程

首先确定Graphic对象数量的变化取值，我对当前地图的x、y方向分别取相同等分，将地图分别使用10、20、30、40、50、60、70、100等分分割后进行测试。

测试分成3个部分，第一部分是点要素：

点要素全部采用圆形符号表示，采用3个半径：3，6，12。

从这里可以看到，Graphic的大小对Flash的操作Graphic速度基本没有影响，在下面的测试中，Graphic的尺寸将不被考虑。另外，操作对象的多少与花费的时间基本成正比，对于点要素来说，每生成1000个点大约花费0.3秒，每渲染1000个点大约花费0.07秒，每擦除1000个点大约花费0.07秒。

下面测试线要素，每个线要素包含10个点，为了与点要素做一定比较，因此选择线要素的数目分别为10、40、90、160、250、360、490、1000个，这样总共的节点数与上面测试的点要素总数相同。同样，对多边形要素的测试也与此类似。

我们发现，操作线与多边形要素，在顶点数相同的情况下，耗时比点要素要少的多。基本上，操作（包括生成、渲染、擦除）包含10000个顶点的1000条线或多边形，花费时间与操作1000个点差不多。换句话说，在Flex中，操作时间基本上与Graphic要素数量有线性关系，与其它因素关系不大。

但是，在这个测试中可以发现，虽然程序测算的线和多边形的操作时间比点要少的多，但是在操作体验上相差很远。具体体现鼠标在图形上移动呈现严重滞后现象，移动地图非常困难，等等。由于测试程序所取线和多边形的顶点都是随机点，因此所有的Graphic要素基本上都叠加在了一起，如下图。在绘制交错的20个10顶点的线的时候，鼠标移动开始出现滞后现象；在绘制重叠的15个10顶点的多边形的时候，鼠标移动开始出现滞后现象。

交错的20个10顶点的线Graphic

重叠的15个10顶点的多边形Graphic

为了考察到底是Graphic的相互重叠导致了操作性能低下，还是其它原因，我们对要素点的取值进行限制，使所有的线、多边形基本没有重合，再次进行了测试。测试发现，用户操作体验有了极大提升，基本上在5000个要素以下用户操作都没有明显的延迟。

不交叉的2500个4顶点的线Graphic

不重叠的2500个4顶点的多边形Graphic

总结

1. ArcGIS API for Flex的客户端绘图耗费时间基本与绘制Graphic的个数呈线性关系，大概每生成1000个Graphic大约花费0.3秒，每渲染1000个Graphic大约花费0.07秒，每擦除1000个Graphic大约花费0.07秒。

2. 客户端绘制的时间主要花费在Graphic的生成（包括新建Graphic实例并添加到图层上）上，渲染和擦除耗时相当，且均不占主要部分。

3. 客户端绘制的时间与绘制要素的类型、样式基本无关。

4. Graphic的相互重叠会导致用户操作体验的急剧下降，应当尽量避免。

5. 客户端绘制，在5000个不重叠的Graphic之内，用户进行地图操作基本没有延迟。