如何绘制数千自定义标记与信息窗口且不阻塞UI（不使用Cluster Manager）

嘿，这个问题我之前帮不少开发者踩过坑——数千标记的流畅渲染确实是个棘手的点，尤其是还要兼顾缩放切换和信息窗口的逻辑，不用Cluster Manager的话，咱们可以从几个核心方向入手优化：

1. 视口可见性过滤（虚拟渲染） #

• 别一股脑把所有标记都怼到地图上，只渲染当前地图视口范围内的标记就够了。你可以监听地图的cameraIdle（相机停止移动后）或者做节流后的onCameraMove回调，先算出当前视口的经纬度边界，再遍历标记列表过滤出在范围内的标记才绘制。
• 注意：千万别在onCameraMove里做密集计算，不然反而会越拖越卡——加个节流（比如每100ms触发一次）或者只在相机停稳后更新渲染列表，效果会好很多。

2. 批量绘制与实例复用 #

• 如果是自定义标记，别逐个创建DOM元素或者频繁调用地图的标记添加API。可以把可见标记批量绘制到单个Canvas上，再作为一个地图覆盖物添加，大幅减少DOM节点和API调用次数。
• 要是用地图原生Marker组件，一定要搞个对象池：把不在视口的Marker隐藏起来，需要的时候直接拿出来更新坐标、图标再显示，别每次都销毁重建——DOM的创建销毁开销比你想象的大得多。

3. 信号量与线程调度的精细化调整 #

• 你现在用了信号量和休眠线程，应该是在后台处理标记数据？那要避免一次性把所有数据都推给UI线程。把标记数据拆成小批次，用信号量控制同时处理的批次数量（比如一次处理5批），而且用requestIdleCallback代替setTimeout来触发处理——这样能利用浏览器的空闲时段干活，不会抢占UI线程的资源。
• 举个简单的代码示例：

  class Semaphore {
    constructor(max) {
      this.max = max;
      this.count = 0;
      this.queue = [];
    }
    acquire() {
      return new Promise(resolve => {
        if (this.count < this.max) {
          this.count++;
          resolve();
        } else {
          this.queue.push(resolve);
        }
      });
    }
    release() {
      this.count--;
      if (this.queue.length > 0) {
        const resolve = this.queue.shift();
        this.count++;
        resolve();
      }
    }
  }
  
  const semaphore = new Semaphore(5);
  async function processMarkerBatches(batches) {
    for (const batch of batches) {
      await semaphore.acquire();
      requestIdleCallback(() => {
        batch.forEach(markerData => {
          // 更新或复用Marker实例
        });
        semaphore.release();
      }, { timeout: 500 }); // 超时兜底，避免一直等空闲
    }
  }
  

4. 图标生成的缓存策略 #

• 缩放切换时的图标生成绝对是性能杀手，必须加缓存！按「缩放级别+标记ID」作为key，把生成好的图标（Canvas对象或者Blob URL）存在Map里，下次需要直接拿，不用重新生成。
• 如果图标是模板化的（比如只是颜色不同的同形状图标），提前把所有可能的模板图标生成好存起来，缩放时直接切换，省掉实时生成的开销。

5. 把 heavy 逻辑扔去Web Worker #

• 标记的坐标转换、数据预处理、视口过滤计算这些操作，全丢去Web Worker里做，别阻塞UI线程。Worker处理完过滤后的标记数据，再发给UI线程渲染——这样UI线程只负责最轻量的绘制工作，自然就流畅了。

6. 简化标记的DOM/CSS #

• 如果用自定义DOM做标记，尽量简化结构，少嵌套节点，别用太复杂的CSS。比如用CSS伪元素代替额外的DOM，避免box-shadow、multiple transforms这类高开销样式；要是必须用，加个will-change: transform提前告诉浏览器做优化。

最后提个小建议：先用Chrome DevTools的Performance面板做个性能分析，看看卡顿到底出在哪——是标记创建太多？图标生成太慢？还是线程调度不合理？找到瓶颈再针对性优化，比盲目试效果好太多。

内容的提问来源于stack exchange，提问作者Rahul Baboria