根据样式layer按需解析MVT文件，延迟繁重的投影计算(OMBB)

[HGX-DJK]

主要的修改：
1、按需解析，跳过无用数据，矢量瓦片（MVT）内部通常包含多个 layer（如水系、道路、建筑、POI等）。在渲染时，当前地图样式可能只需要其中的一部分图层，增加这个判断后，Worker 会根据主线程传入的所需图层集合（_activeLayers），直接跳过不需要渲染的源图层。这就避免了去遍历、实例化那些注定不会被渲染的图层下的成百上千个要素，从而极大节省了 CPU 解析时间、减少了内存对象的大量创建，同时也降低了垃圾回收（GC）的压力
2、延迟繁重的投影计算，在优化前，不管要素用不用得上，解析瓦片时会把所有要素的 OMBB 全算一遍。优化后，采用了懒计算（Lazy Projection），只有当渲染引擎或上层主逻辑真正“点名”要读取某个要素的 OMBB 数据时，才会触发投影计算。

[HGX-DJK]

vt错误排查了一下，好像是_getStyleByCounter异步卡点超时导致的

[deyihu]

@fuzhenn

应该不需要这么复杂的，worker里所有的filter都会走这里 (哪些features会参与渲染)

maptalks.js/packages/vt/src/worker/layer/BaseLayerWorker.js

Line 571 in 9f5afcf

const dataConfig = pluginConfig.renderPlugin.dataConfig;

maptalks.js/packages/vt/src/worker/layer/BaseLayerWorker.js

Line 359 in 9f5afcf

for (let i = 0; i < pluginConfigs.length; i++) {

在这里遍历下判断下OMBB即可，同样的geometry的处理也是一样的，当然我不确定是否正阳完全正确？

要注意的是主线程里是否会用到这些东西,geometry,properties.OMBB,因为目前的改动说白了就是按需计算，这些features会复制到主线程的，如果主线程用到了这些东西，那么就会出现bug,

例如主线程里有identify,getFeatures等这些功能的

[fuzhenn]

看上去应该是能正常工作的，测试用例里有ombb和geometry相关的验证用例。

[fuzhenn]

vt错误排查了一下，好像是_getStyleByCounter异步卡点超时导致的

目前master分支上该用例能正常运行，还是需要排查一下用例失败的原因

[fuzhenn]

有些图层特别多的场景，compiledLayerFilter会比较庞大，造成每次请求tile时layerFilter参数会很大，maptalks中的worker消息是每一帧集中发送的，这里可能会影响worker消息的传递性能。
因此compiledLayerFilter 应该改到worker中构造，可以同样通过请求参数中的styleCounter来判断是否命中缓存

[HGX-DJK]

好的