OpenLayers性能瓶颈与优化（闭包引用与GML解析低效率）
1. 结构中大量闭包的引用关系造成的性能瓶颈
OpenLayers其实是受到了js本身的限制，js是解释型的语言，执行效率不高，而且寄生在客户端让浏览器执行的。而OpenLayers中大量用到了闭包，最开始OpenLayers的内存泄露问题也是满严重的，后来差不多每个类中都写了destroy方法，用于释放资源，解除对象与DOM的绑定,相当于析构函数那种，这在很大程度上优化了OpenLayers的性能，但是js本身的限制是不能突破的。
OpenLayers的Map类包含了许多东西，其中Map对象和其他相关对象之间的引用关系才是OpenLayers性能的瓶颈。从DOM结构上来看，对于一个map他包含了其根节点内的所有DOM元素的引用，以及差不多所有这些DOM元素涉及到的自定义对象的引用，而且这些对象也引用了map，每个对象的执行环境就形成了一个闭包，那么OpenLayers实际上是通过引用将所有的这些闭包联系到了一起从而形成了一个超大的闭包，我认为是这个闭包在消耗着系统的资源，而OpenLayers的垃圾回收机制是否解除如此复杂的引用关系并将不需要的小闭包从这个大的闭包中拿走，在实践中显示并不可靠。
对于结构不清晰和不理解闭包产生的同学，请参考这篇：http://blog.csdn.net/a511596982/article/details/8046514
2. GML解析的低效率
OpenLayers在解析GML数据时候，将所有的面、线包含的点全部都对象化为Openlayers.Geometry.Point，并首先将所有的对象读取到内存，得到一个Feature的集合，然后将这个集合提交给渲染器进行渲染。本来这个思想就行不通，加入我们通过WFS收到的文件有10M或者更大，要是把这些全部解析出来然后放到内存，处理缓慢。如果一个100M的文本文件要解析出来一样，要是等全部解析完了再处理数据是行不通的，而且如果数据量大，比如8G的数据，也不能全部读到内存。
而其实将所有的点都对象化才是它效率低下的根本原因，根据XX文章作者测试（记不清楚了），将16145个Openlayers.Geometry.Point在现有机器配置下实例化耗时6S（除了一个QQ外，机器不运行任何其他程序），这个解析效率显然是不能满足GIS应用的。
需要优化的：应该在gml数据解析得到相应Geometry对象的时候就直接将其用VML或SVG画出来，而且构建Polygon对象的时候不要涉及Point对象，及不要像这样构建
ring1 = new OpenLayers.Geometry.LinearRing(p.points);
rings.push(ring1);
var poly = new OpenLayers.Geometry.Polygon(rings);最好是直接传入一系列坐标对直接构建Polygon。
附：VML和SVG是以DOM元素的形式存在与客户端用于适量数据的显示，因而二者都不能显示大数据量，它们只能作为一种辅助的形式显示少量的矢量数据。要想获得以接受的效率，矢量对象的个数最多在1000个左右。VML和SVG的绘图效率比较低下，假如矢量对象比较多或者面对象的面积普遍较大，那么重绘也是比较慢的。
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处、作者信息和本声明。否则将追究法律责任。
http://blog.csdn.net/a511596982/article/details/8046514
转载自：https://blog.csdn.net/vernonzheng/article/details/8046615
