造成原因
前端一次性加载大量点位并计算聚合点位导致渲染时间过久
解决方案
本质上就是由后台计算渲染聚合点位然后返回给前端渲染,减少了前端渲染的压力。后端不管是采用什么聚合算法,最终目的都是返回给前端去渲染,而前端通过传递视野范围和层级来获取聚合后的点位。
同时使用openlayer加载点位又有2种加载方式:
- ol/layer/Vector
- ol/layer/VectorTile
ol/layer/VectorTile
这种是加载矢量图层的方案,以XYZ的网格加载方式请求后台,后台会返回的pbf文件去渲染生成点位。这种方式的优点在于,生成的pbf文件可以缓存在服务端,优化性能。当然有个缺点,如果生成的瓦片的缓冲区没有设置好的话,可能会导致点位在边缘被切割。之所以没有选他的原因很简单,后台没有好的方案解决缓冲区(postgis动态生成MVT)。同时还有个小问题,缩放过程中获取到的Zoom有可能是小数,即使设置了constrainResolution
也无效。
ol/layer/Vector
这种就是最普通的加载点位的方式,它是通过strategy tile
的方式来模拟以网格范围加载点位,这种方法的优点就是无需考虑网格切割问题,但是缺点也很明显,这种加载方式是跟层级无关的,对于已经加载过的经纬度范围,缩放是不会重新发起请求的,所以需要监听地图缩放事件,当层级发生变化时,重新刷新source
,而且没有上面VectorTile加载方式的带来的cache
优点,对于已经出现过的网格,无需重复请求(前面缩放过程中你手动清空了source
),如果需要cache
,那么需要自己手动实现模拟。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。