Android 地图卡成 PPT 之后：双渲染管线与空间网格渐进加载怎么救

轻量与海量之间能不能自由伸缩，靠的不是堆性能，是把复杂度按层切开。

地图一拖动就掉帧、一打开就白屏，这种事谁都遇过。问题往往不是"代码写得慢"，而是我们习惯把两个量级完全不同的麻烦当成同一件事去解决：一边是"图层怎么画出来"的渲染问题，一边是"十万个要素怎么喂给 GPU"的数据问题。把这两件事揉在一起硬扛，结果就是要么卡成 PPT，要么为了不卡把架构写成了谁都不敢碰的怪物。

这篇文章合并讲两件本来分开发的东西：一套地图引擎怎么在同一份接口底下挂两条渲染管线（Canvas 轻量、OpenGL 重量），以及它怎么用空间网格把海量数据切成薄片、按视口渐进加载。把它们放在一起看，你会得到一个判断------地图引擎真正的伸缩能力，不是靠堆硬件性能，是靠把复杂度按层切开：渲染层用一份稳定的接口契约把底层差异关起来，数据层用空间网格把"一次吃掉全部"变成"按视口一点点吃"。

一、同样的"卡"，其实是两个不同量级的问题

先别急着谈方案，得把"卡"拆开看，因为卡的原因完全不同。

第一类卡，是渲染模型不匹配。数据量小的时候，用系统 Canvas 顺手画几笔就够：几个标注、几条临时线，命令式地"画一笔是一笔"，简单直接。可一旦图层里有几十万个面要填色描边，还得随手指平移缩放实时更新，CPU 就彻底算不过来了------这时候必须交给 GPU，用 OpenGL 的三角形、顶点缓冲、着色器去渲染。两种写法的编程模型几乎不兼容：

text 复制代码

// 轻量：命令式，画一笔是一笔
canvas.drawLine(x1, y1, x2, y2, paint)
canvas.drawCircle(cx, cy, r, paint)

// 重量：声明式，把几何转成顶点喂给 GPU
glEnableVertexAttribArray(loc)
glVertexAttribPointer(loc, 3, GL_FLOAT, false, stride, offset)
glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_INT, 0)

如果上层业务代码一会儿对接 Canvas、一会儿对接 OpenGL，耦合度会高到切来切去就出错。注意这里说的是"先抽象接口、再谈实现"，顺序不能反。如果先写两个具体地图、回头再抽接口，你抽出来的往往是"两个实现恰好都有的交集"，而不是"上层真正需要的能力"------后者才是稳定的，前者随时可能因为某个实现的特殊需求而被改坏。

第二类卡，是数据量压垮了首帧。这是更隐蔽的一种：十万个要素如果一次性全部构建成三角形再上传 GPU，构建要花几百毫秒，上传又要几百毫秒，期间屏幕直接冻结。有人想了个朴素的办法------只加载屏幕能看到的范围。道理没错，但"屏幕范围"是会变的：手指一拖视野变了，之前加载的要不要卸载？新出现区域的要素从哪读、按什么顺序读？加载到一半用户又拖走了怎么办？这一连串问题，比"一次全加载"复杂得多。

所以这两类卡，本质上是两个维度的事：一个是"怎么画"（渲染层），一个是"先画哪、怎么不一次性画完"（数据层）。下面分别拆。

很多人最初的做法，是把这两个问题各自硬扛：渲染上，轻量需求写一套 Canvas 代码、海量需求另写一套 OpenGL 代码，两套几乎不共享逻辑；数据上，要么全量加载赌用户不拖，要么在业务代码里手写一堆"现在视口在哪、去哪读数据"的临时判断。两套渲染代码各自演进，迟早出现行为不一致；数据层的临时判断散落在业务里，拖一次地图就冒出新的边界 bug。等发现想统一的时候，重构成本已经高到没人敢动。所以这篇文章要讲的，不是两个孤立技巧，而是怎么从一开始就把这两层设计成"能伸缩"的样子。

二、渲染层：用一份接口契约把两条管线关起来

先看渲染层。很多人把"支持两种渲染"做成两个独立组件，让调用方自己选。这其实是把底层差异的错误暴露到了上层------业务代码根本不该关心"这一层是用 CPU 画还是用 GPU 画"。

真正该做的是先把"地图该支持哪些能力"抽象成一份稳定的接口，再让两种渲染方式各自去实现它。这样上层永远只跟接口打交道，底下实现随便换。这份接口里至少要有这些能力：

图层管理：按名字添加、查找、移除图层，遍历所有图层。
图层状态：每层是否可见、可见的比例尺范围、颜色、透明度、线宽等。
渲染器管理：每层绑定一个负责真正绘制的东西。
生命周期与交互：暂停、恢复、销毁，以及把触摸、滚轮、双击、缩放手势等事件派发给每个图层。

接口里特意把"可见的比例尺范围"放进图层状态，而不是让每个渲染器自己判断，是个很关键的设计点。地图在放大缩小时，很多图层只在特定比例尺区间才有意义（比如建筑轮廓在小比例尺下根本看不清，反而拖累性能）。把这个判断收口到图层状态里，渲染层在遍历时统一过滤，渲染器就不需要、也不应该关心"现在该不该画我"------职责又一次被切干净了。

这套设计的核心是三层结构：第一层是地图接口 ，定义上面那堆能力，是所有上层代码唯一依赖的东西；第二层是公共抽象基类 ，把图层列表、图层状态表、渲染器管理这些"两种渲染都共用"的逻辑放进去，一套实现两边复用；第三层是两个具体地图，一个走 Canvas（轻量），一个走 OpenGL（重量），各自重写"怎么画"。

图层和"图层渲染器"被刻意解耦：图层只是数据的容器（它持有数据集、名字），真正负责绘制的是"图层渲染器"。加一个图层时，可以自动匹配默认渲染器，也可以由调用方传入自定义渲染器------这给"同一份数据、不同的画法"留足了扩展空间。举个具体的例子：同一份地形点数据，在"总览模式"下你可能只想用 Canvas 画几个简单圆点做轻量预览，在"精细模式"下又想交给 OpenGL 画带描边和符号的高精度点。因为图层和渲染器解耦，你不用为两种画法复制两份数据，只要给同一个图层换一个渲染器即可。这种弹性在地图应用里几乎天天用得上------同一份数据，调试时走轻量管线看逻辑，上线时走重量管线看效果。

kotlin 复制代码

// 公共抽象基类：两种渲染共用的一套逻辑
abstract class BaseMap(protected val mapView: MapView) : MapApi {

    // 线程安全的图层表
    private val layerList = mutableListOf<Layer>()
    private val lock = Any()

    override fun addLayer(layer: Layer, renderer: LayerRenderer?): Int {
        synchronized(lock) {
            if (exist(layer.name)) return 0
            layerList.add(layer)
        }
        // 绑定渲染器：要么用调用方给的，要么按图层类型自动配一个
        registerRenderer(layer, renderer)
        return 1
    }

    // 把事件轮流派发给每个图层的渲染器，谁处理了谁返回 true
    override fun onTouchEvent(event: MotionEvent, view: MapView): Boolean {
        for (renderer in renderers()) {
            if (renderer.onTouchEvent(event, view)) return true
        }
        return false
    }

    // 抽象：子类决定"这一帧怎么画"
    protected abstract fun drawLayer(renderer: LayerRenderer, ctx: RenderContext)
}

整体分层关系可以这样看：

flowchart TD A["上层业务代码"] --> B["MapApi 接口契约"] B --> C["BaseMap 公共基类"] C --> D["Canvas 渲染实现"] C --> E["OpenGL 渲染实现"] D --> F["轻量叠加层"] E --> G["海量矢量主图"]

两个具体实现各自的差异，只在"怎么画"这一个点上。下面对比一下两种管线到底差在哪：

维度	Canvas 轻量管线	OpenGL 重量管线
适用数据量	几万要素、辅助叠加层	几十万面、主图
编程模型	命令式，画一笔是一笔	声明式，喂顶点给 GPU
擅长场景	标注、临时图形	随视口实时平移缩放
在架构里的角色	辅助层	主图

Canvas 版 ：遍历所有可见图层，按比例尺范围过滤，然后用 saveLayerAlpha / save 包裹起来逐层绘制，处理图层的透明度。
OpenGL 版：同样遍历可见图层，但把每个矢量图层的上下文（视口范围、MVP 矩阵、颜色、线宽、点符号）打包进一个"渲染请求"，交给 GPU 渲染管线异步处理。

kotlin 复制代码

// Canvas 版：遍历可见图层，按比例尺过滤，逐层包裹绘制透明度（示意）
override fun drawLayer(renderer: LayerRenderer, ctx: RenderContext) {
    for (layer in visibleLayersInScale(ctx.scale)) {
        canvas.saveLayerAlpha(0f, 0f, w, h, (layer.alpha * 255).toInt())
        renderer.draw(canvas, layer.dataset)   // 这一层具体怎么画交给渲染器
        canvas.restore()
    }
}

kotlin 复制代码

// OpenGL 版：把每层上下文打包成渲染请求，异步交给 GPU 管线（示意）
override fun drawLayer(renderer: LayerRenderer, ctx: RenderContext) {
    for (layer in visibleLayersInScale(ctx.scale)) {
        val req = RenderRequest(
            viewport = ctx.viewport, mvp = ctx.mvpMatrix,
            color = layer.color, lineWidth = layer.lineWidth,
            pointSymbol = layer.pointSymbol
        )
        gpuPipeline.enqueue(req)   // 异步上传，不阻塞当前帧
    }
}

关键洞察是：两种实现共享了全部"图层怎么管理、事件怎么派发、生命周期怎么走"的代码，只各自实现"这一帧画什么"。上层写一次，两种能力都有了。

三、数据层：空间网格把海量切成可吃的薄片

渲染层解决了"怎么画"，但十万个要素如果一股脑全部构建上传，第一帧照样卡死。数据层要解决的是"先加载哪、怎么不一次性加载完"。

根因一句话：把十万要素一次画完会卡，是因为把全部成本压在了第一帧 。而把成本摊开到很多帧里，每一帧只干一点点活，用户就几乎感觉不到卡。但"摊开"有个前提：必须知道先干哪部分、后干哪部分。这就需要一个能把空间划分开的结构，让我们能回答"视口里有哪些格子、这些格子该按什么顺序加载"。

这就是空间网格的用处：把整个数据范围切成一个固定行列的矩形网格，每个格子是独立的加载单元。视口在哪，就优先加载和它相交的格子。

这里有个粒度权衡：格子切得太粗，一个格子就包含上万要素，渐进加载的意义就被稀释了；切得太细，格子的元数据（行列索引、空格集合、已加载集合）本身会膨胀，查询和状态维护的开销又上来了。"每格最多放多少要素"这个参数不是拍脑袋定的，它直接决定了首帧要构建多少个 Mesh、每个 Mesh 多大，需要按设备 GPU 能力和典型数据分布去调。文中 computeOptimalGrid 的 maxPerCell 就是这个旋钮。

切网格前，先用数据集的总范围算出该切成多少格。一个朴素的做法是：给定"每格最多放多少要素"，用总要素数除以它得到目标格数，再按范围的长宽比调整行列数，让格子尽量接近正方形。

kotlin 复制代码

// 根据总要素数 + 每格上限，算出网格行列
fun computeOptimalGrid(totalFeatures: Int, maxPerCell: Int): Grid {
    if (totalFeatures <= 0) return Grid(cols = 1, rows = 1)
    val count = ceil(totalFeatures.toDouble() / maxPerCell).toInt().coerceAtLeast(1)
    val aspect = totalBounds.width / max(totalBounds.height, 1e-10)
    val cols = round(sqrt(count * aspect)).toInt().coerceAtLeast(1)
    val rows = max(1, count / cols)
    return Grid(cols, rows)
}

这样每个格子的空间范围就能通过行列号反算出来，而且天然支持负坐标------用 floor 而不是 (int) 截断，避免负数边界出错。

视口平移或缩放后，查询与视口相交的格子，并按"格子中心到视口中心的距离"升序排列。这样最靠近屏幕中央的数据最先出现，符合用户的视觉预期------眼睛盯着的地方最先加载好。

kotlin 复制代码

fun queryCells(viewport: Bounds): List<Int> {
    // 先算出视口覆盖的行列范围
    val cells = mutableListOf<Int>()
    for (r in minRow..maxRow) {
        for (c in minCol..maxCol) {
            val id = r * cols + c
            if (!emptyCells.contains(id) && !loadedCells.contains(id)) {
                cells.add(id)
            }
        }
    }
    // 按距视口中心距离升序
    return cells.sortedBy { cellCenterDistSq(it, cx, cy) }
}

真正花时间的是把每个格子里的要素转成 GPU 可用的三角形网格（Mesh）。这一步用固定线程池并行做：每个 worker 负责一个格子，建完的 Mesh 塞进一个有界队列；GL 渲染线程每帧从队列里取，取到就上传 GPU 并立即刷新一帧。

kotlin 复制代码

// worker 线程：为一个格子构建 Mesh，入队
executor.submit {
    for (fid in cellFids(cid)) {
        if (aborted) break
        val feature = readFeature(fid)
        val mesh = visualizer.buildMesh(feature, context)
        queue.offer(CellMesh(cid, mesh), 100, TimeUnit.MILLISECONDS)
        markLoaded(fid)
    }
    completeQueue.offer(cid) // 通知 GL 线程：这格处理完了
}

GL 线程每帧做的事很轻：把队列里的 Mesh 全部取走上传，再检查有没有格子完成，完成就刷新一帧。这样构建和渲染被两个线程解耦，构建再慢也不阻塞绘制。

队列之所以要设成有界的，是为了给整条流水线加一道背压：当 worker 建 Mesh 的速度超过 GL 线程上传的速度时，队列满了 offer 会超时返回，worker 自然慢下来，不会无限占用内存把手机拖垮。这种"生产者快、消费者慢"的节奏在地图里很常见------构建几何是纯 CPU 活，上传 GPU 受带宽限制，二者解耦后各自按自己的节奏走，整机的卡顿感就被抹平了。

加载过程用一个简单状态机管理，避免各种边界条件打架：

stateDiagram-v2 [*] --> IDLE IDLE --> LOADING : 首次需要更新 LOADING --> FALLBACK : 格子处理完仍有遗漏 FALLBACK --> LOADING : 视口变化出现新格子 LOADING --> [*] : 全部加载完成 FALLBACK --> [*] : 兜底完成修正总数

IDLE：还没开始。首次需要更新时进入 LOADING，初始化网格索引。
LOADING：每帧按视口优先级调度格子，worker 并行构建。所有格子处理完、但仍有要素没加载到时，进入 FALLBACK。
FALLBACK：格子是粗粒度划分，可能有些要素"卡"在格子缝隙或跨格没被拾到，此时用全量迭代器顺序兜底加载剩余要素，每攒够一批刷新一帧；一旦视口变了出现新格子，立即退回 LOADING 优先加载新格子。

kotlin 复制代码

private fun onUpdate() {
    when (state) {
        IDLE -> { state = LOADING; initSpatialGrid() }
        LOADING, FALLBACK -> {
            drainMeshQueue()          // GL 线程消费 Mesh
            pollCellComplete()        // 处理完成的格子，上传 + 刷新
            if (noWorkInFlight()) {
                if (state == FALLBACK) scheduleFallbackBatch()
                else scheduleNextCell() // 提交新格子给线程池
            }
            checkAllDone()
        }
    }
}

反直觉的坑 ：兜底加载时，如果数据集里有些要素没有有效几何，实际加载数会小于预估总数。如果不对总数做修正，状态机会认为"永远没加载完"而死循环。所以兜底结束后要把 totalFeatures 修正为实际加载数。

整个调度链路串起来是这样：

flowchart LR A["视口变化"] --> B["网格相交查询"] B --> C["按中心距离排序"] C --> D["worker 并行建 Mesh"] D --> E["有界队列"] E --> F["GL 线程消费上传"] F --> G["刷新一帧"]

下面这张表把数据层最容易踩的坑列出来，方便对照排查：

症状	根因	解法
首次加载屏幕冻结几百毫秒	全部要素一次性建 Mesh 并上传 GPU，成本压在第一帧	固定网格切片加双线程，把构建摊到多帧
拖走后旧数据堆积、新区域没数据	视口会变，需要按相交格子动态增删	视口查询取相交格子，按中心距排序按需加载
加载进度卡在 99% 死循环	部分要素无有效几何，实际数小于预估总数	FALLBACK 结束后把 totalFeatures 修正为实际加载数

四、统一视角：轻量与海量之间，靠的是"切开复杂度"

现在把渲染层和数据层合起来看，会发现它们是同一个判断的两面。

渲染层面对的是"轻量 Canvas"和"重量 OpenGL"两种诉求长期并存，解法是用一份接口契约把底层差异关起来，让上层永远只面对接口；数据层面对的是"十万个要素一次性画完会卡死"，解法是用空间网格把数据分层切片、按视口按需加载，避免一次性吃掉全部数据。两者共同回答的是同一个问题：地图引擎怎么在「轻量」和「海量」之间自由伸缩。

它们的底层心法是一样的------把复杂度按层切开，而不是靠堆性能硬扛：

渲染层切的是"接口与实现"：共性（图层管理、事件派发、生命周期）收进公共基类，只让"怎么画"成为差异点。
数据层切的是"空间与时间"：空间维度用网格切块回答"先加载哪"，时间维度用状态机加双线程把构建摊到多帧回答"怎么不卡"。

顺带说一句这套"接口加双实现"的取舍：它本质是策略模式的运用，适合"两种渲染确实都需要、且会长期并存"的场景，而不是过渡期的临时方案。如果只是暂时试点，强行上双实现反而是过度设计------现代地图 SDK 大多直接选 GPU 管线作为唯一渲染路径，再在上层提供 Canvas 叠加层补足轻量需求，这其实也是"接口加灵活渲染器"思路的变体，只是把"轻量"收敛成了"辅助层"。凡底层有"多种实现可能、但对外行为一致"的模块，都值得先定义一份稳定接口再谈实现。

落到你自己的工程上，判断标准是具体的：如果一个模块对外行为稳定、但内部有两种以上实现可能（渲染如此，编解码、存储、网络传输也一样），那就先把契约写清楚；如果其中一种实现只是过渡期临时顶上、迟早被替换，那就别急着抽象，等它稳定了再抽。过度抽象和欠抽象一样有害，分寸就在"对外行为是否真的稳定"这一条上。

在手机上这套设计还有一层现实意义：内存和发热都经不起"一次性全加载"。GPU 显存、构建 Mesh 时的临时内存、以及持续高负载带来的发热降频，都会让"硬扛"方案在真机上比在桌面模拟器里更快露馅。把复杂度按层切开之后，每一帧只处理视口内最必要的一小块，既省内存又压住了发热，这也正是移动端地图和桌面地图在架构上必须分道扬镳的原因。

小结

把"卡"拆成两类：渲染模型不匹配、数据量压垮首帧，二者解法完全不同。
渲染层用一份接口契约把关：公共基类装共性，只让"怎么画"成为 Canvas 与 OpenGL 的差异点。
图层是数据容器、渲染器才是绘制者，二者解耦换来"同数据、多画法"的弹性。
数据层用固定空间网格切块加优先级排序，让屏幕中心的数据最先出现。
worker 并行建 Mesh、GL 线程消费上传，双线程解耦构建与绘制，成本摊到多帧才不卡。
缩放能力不是靠堆性能，是靠把复杂度按层切开：接口与实现切一刀，空间与时间再切一刀。

系列导航：GIS 系列第 1 篇（共 10 篇）。下一篇《地图渲染的三处翻车：字体、坐标、顶点批上传》。