如果你用一堆 SpriteRenderer 一张张往场景里铺 2D 地图项目规模一旦上去DrawCall 和内存数据会率先把你劝退。大多数人第一次意识到 Tilemap 的价值都是在帧率报表突然变得难看的时候。我刚开始做 2D 项目也踩过同样的坑上千个瓦片精灵堆在场景里运行时代码要管它们的排序、位置、碰撞、图层稍微多一点动态地图逻辑卡顿和内存开销就一起上来了。后来彻底把地图底层的实现切到 Tilemap 系统这些麻烦才算是真正从根上解决。这是一套能承载超大场景、适合程序化生成、又能让美术直接在编辑器里涂改的完整地图方案。这篇内容不打算把官方文档复述一遍我想从实际项目里摸过的机制出发把渲染合批、碰撞合并、规则瓦片、运行时性能这几个最容易被忽视的环节拆开讲。适合已经知道 Tilemap 怎么添加场景、但想搞清楚它内部工作原理以及准备在项目里大规模使用的人。1. 从“铺精灵地图铺到卡顿”说起Tilemap 解决了什么1.1 为什么几百个瓦片就能拉开肉眼可见的差距很多新手理解不了Tilemap 和“用普通 Sprite 摆地图”到底差在哪。直观上看两种方式最后屏幕上显示的都是一个个 32×32、64×64 的小图片。但背后的数据结构完全不是一回事。用 SpriteRenderer 铺地图每一个瓦片都是一个独立的 GameObject每个 GameObject 对应一个 Transform 组件、一个 SpriteRenderer 组件、一个排序数据、一个可见性判定。场景里哪怕只有一百个瓦片Unity 也需要给这一百个组件做剔除、排序、批次提交。一旦地图做到 200×200就是四万个对象这一层 Transform 和渲染组件的内存与遍历开销就已经非常可观更别谈一次性访问所有瓦片时的物理、寻路和逻辑遍历。Tilemap 的方式是把“地图”当成一张数据表来处理。Tilemap 组件内部没有为每一格创建一个对象而是保存了一个以格子坐标为核心的瓦片索引表每格存的是对这个 Tile 资产的引用。要知道某个坐标放的是什么就直接查这个表要渲染TilemapRenderer 负责把这些格子按网格合并成若干块 Chunk 再做绘制。这样的设计天然避开了 GameObject 数量爆炸的问题。我在一个模拟项目中测试过同样是一张 128×128 的地图用 SpriteRenderer 铺场景里光 Transform 就有上万个编辑器和运行时的 Load 时间都肉眼可见地变久切到 Tilemap 之后负责地图的物体只有 Grid、Tilemap、TilemapRenderer 三个组件数据全部压进内部结构地图越大这种优势越明显。1.2 数据驱动的设计解放的是逻辑复杂度Tilemap 不只是省了 GameObject更重要的是它改变了你操作地图的方式。以前想在某个坐标放一个草地块需要找到那个坐标对应的 GameObject改它的 Sprite、颜色、排序甚至可能还要再挂一个用来标识地块类型的脚本现在只需要一行SetTile(cellPosition, tileAsset)。以前想检测某个格子是什么地形要去遍历 GameObject 列表或者维护一套字典现在直接GetTile(cellPosition)就拿到了 TileBase 实例。这种数据驱动模式带来的另一个好处是地图的存盘和序列化变得非常简单。整个 Tilemap 的网格数据可以整体保存保存格式就是一个坐标和瓦片引用的映射。也正因为有这个基础程序化地图生成、运行时地图编辑、存档系统才变得干净利落。我这里并不是说 SpriteRenderer 铺地图一无是处——如果你的地图只有十几个装饰物或者全是完全不规则的大型物件那用普通 GameObject 反而更灵活。但凡是格子类地图不管你做的是策略战棋、横版跑酷、俯视角射击还是传统 RPGTilemap 几乎都是更合理的地基。这一点在项目早期就要想清楚否则中途从 Sprite 铺法切换到 Tilemap转换成本会比重新做一张地图还高。下面这个表可以直观地看出两者在几个核心维度上的差别对比项SpriteRenderer 逐格摆放Tilemap 系统单格对象数每格一个 GameObject Transform Renderer每格只是一个索引表项DrawCall 压力多图集、多排序层下很容易膨胀同图集内自动合批Chunk 化提交编辑器编辑只能手工移动、复制、删除对象笔刷直接涂抹、擦除、批量替换运行时改格需要找到并修改 GameObejct 组件SetTile / SetTilesBlock 直接写数据碰撞与物理每格都要手动挂碰撞体TilemapCollider2D Composite 合并存档序列化需要自己记录所有对象状态可以直接序列化格子索引表1.3 Tilemap 的组成角色先分清楚再聊其他Tilemap 系统不是一个单一组件它由几个分工明确的部分组成。最上面是 Grid它决定格子坐标系的规则包括格子大小、排列方式比如矩形格、菱形格、六边形格都属于 Grid 的 Layout 范围。Grid 下挂着 Tilemap 物体Tilemap 组件负责维护瓦片数据本身。TilemapRenderer 负责把数据变成渲染网格TilemapCollider2D 负责把格子数据转成物理碰撞体。还有一大类组件是 Tile 资产本身它定义了这块格子长什么样、有没有碰撞、是不是“地形自适应”RuleTile、AnimatedTile、RandomTile 都属于这类。很多人拿到就急着画没把这几层分清楚后面会遇到一个典型困惑为什么我改了 Sprite 图片瓦片没变化因为那你改的是图集素材瓦片资产里记录的引用和绘制参数没变。又比如为什么瓦片已经画上去了角色却还是直接穿过因为碰撞体要靠 TilemapCollider2D 生成不是画上去就有碰撞的。我先在这里把角色分工说清楚后面每一章再深入一层。理解这套数据流比会用笔刷涂地图重要得多。2. 渲染层的真相Chunk 合批、图集规范和 Pixel Perfect 的缝2.1 TilemapRenderer 是怎么做到低 DrawCall 的既然 Tilemap 不是靠每个瓦片一个渲染器来画图那它到底怎么把图渲染出来答案在 Chunk 机制。Unity 会把 Tilemap 的整个网格区域切分成若干块区块每一块区块内部把其中所有瓦片需要的顶点、UV、颜色等信息合并成同一个 Mesh最后以一个 Mesh 为单位提交渲染。至于这些 Mesh 能不能合到同一个批次还取决于瓦片使用的 Sprite 是否来自同一张图集。这个机制带来的具体效果是如果一张地图的瓦片都来自同一张 Atlas 图集那么不管地图上有三千个还是三万个瓦片只要它们分布在一个可见 Chunk 内渲染提交往往只要很少的批次。我用过一张 256×256 的地图做过测试地图上铺了六万块瓦片左右帧率反而稳得离谱。换成同样数量的独立 SpriteRenderer想要跑到同样流畅度得对图集、排序、剔除做一大堆额外优化。Tilemap 把这些底层工作直接吃掉了项目里只需要保证素材规范即可。这里要重点敲一下黑板Tilemap 的合批效果高度依赖图集规范。如果你导入的每个瓦片都是单独一张贴图没有打成图集那 TilemapRenderer 合批的能力就会被限制因为它只能在同类图集内部做合并。多个纹理之间的 Mesh 无论如何都得分开提交每切换一次纹理就是一个额外的批次。所以做瓦片素材时一定不要偷懒不生成图集。你可以手动建图集也可以交给引擎的 Sprite Atlas 自动处理只要确保地图瓦片和动态 UI 等经常切换贴图的内容分开放别混进同一张图集导致频繁打断合批就行了。2.2 Chunk 刷新机制为什么你改了几个格子整块都重建了Chunk 的合并渲染不是一成不变的。当你用代码或者编辑器改动任何一个格子时Unity 需要更新该格子所在 Chunk 的 Mesh 数据。它不是只改那一个顶点而是会把所在 Chunk 的所有顶点重新生成一遍。这意味着你在一大块区域内频繁修改零散格子性能消耗会远高于你的直觉预期。打个比方这就像你有一张 Excel 表每次改动其中一个单元格Excel 都会把整张工作表重新计算一遍。放在 Tilemap 里如果你在循环里对几十个分散坐标分别调用 SetTile每次都触发所在 Chunk 重建那么性能会随着改动次数线性变差。正确做法是尽量把一次操作涉及的所有格子收拢到同一次刷新里。用 SetTiles 一次性传一组坐标和瓦片引擎会先完成批量写入再统一刷新受影响区域。这样你的改动逻辑次数相同实际触发的网格重建却少了很多。我踩过最典型的坑是在一款实时地形编辑 Demo 里玩家用笔刷每帧改二十多个格子结果低配手机上帧率疯狂掉。后来排查发现是每帧触发了多次 Chunk 重建改成一次性收集笔刷区域再调用批量接口之后帧率直接翻了倍。这种事不实际跑起来很难意识到文档里也不会强调但恰恰是运行时动态地图的命门。2.3 Pixel Perfect 与网格裂缝防患于未然的几个设置2D 游戏使用 Pixel Perfect Camera 后最讨厌的就是瓦片之间出现白色细缝。原因是相机渲染时瓦片的 UV 采样容易落在图集边缘或者因为摄像机正交尺寸计算不是像素整倍数导致采样偏移让相邻瓦片之间露出背景色或图集旁边的内容。很多人遇到裂缝第一反应是去调整 Pixel Perfect 组件的设置但真正的关键在素材这一层。最有效的方案是给瓦片图集预留足够的边缘留白也叫 padding。在 Sprite Atlas 中给瓦片设置 4~8 像素的 padding相邻瓦片边缘就不会因为浮点误差采样到图集其他区域。其次是确保瓦片是“整像素”大小比如 16、32、64 这类能被相机 PPU 整除的尺寸。如果瓦片是 48×48相机 PPU 却是 32每个瓦片占据的像素并非整数裂缝几乎是必然的。另一个容易忽略的是 Sprite 的 Mesh Type尽量保持 Full Rect不要因为想省面积改成 Tight不然边界顶点会偏离实际矩形缝隙出现的概率会更高。把这些老规矩都做到位Tilemap 的渲染层基本就是稳的。渲染层稳定了地图越大越不用担心 DrawCall接下来真正的性能瓶颈就会转到另一层——物理碰撞。3. 碰撞体才是隐形杀手独立 Box 与 Composite 的取舍3.1 一个格子一个 Collider 的地图物理工程师看了会头大TilemapCollider2D 给地图生成碰撞是完全自动的但它默认的行为是给每个有瓦片的格子生成一个独立的 BoxCollider2D。如果你确认过地图属性面板会发现碰撞体数量巨大——一张 100×100 的地图如果铺满瓦片里外里就有一万个小的 BoxCollider。碰撞体数量一多物理引擎每帧光做 Broadphase 碰撞对检测就非常吃力。因为每个 Collider 都要跟附近的 Rigidbody2D、其他 Collider 做配对测试。许多 2D 游戏卡顿不是渲染瓶颈而是碰撞体数量太夸张。我在项目里见过最夸张的情况地图只有两层地面但 TilemapCollider2D 生成了接近八千个碰撞体角色在地图上跳跃时物理开销几乎占了帧时间的四分之一。所以凡是一张地图里瓦片数量到了上百都强烈建议立刻配一个 CompositeCollider2D。它的作用是把同一 Tilemap 上所有瓦片的外轮廓合并成一个或几个多边形碰撞体内部共享边完全去掉。比如一整块矩形地面合并完就真的只有一个矩形碰撞体了而不是几百个小方块。物体在地面上行走时物理引擎要处理的多边形数量急剧下降跑起来的区别是能直接感知的。3.2 合并碰撞体的正确组法Component 结构和刚体谁去挂合并碰撞体的配置流程有一定讲究。我在项目里会把 Grid 物体上挂一个 CompositeCollider2D然后把 TilemapCollider2D 的 Used By Composite 选项勾上再把 CompositeCollider2D 的 Geometry Type 设为 Polygons。这样瓦片碰撞数据就会从 TilemapCollider2D 输出到 CompositeCollider2D 做多边形合并。合并出来的是完整的闭合碰撞多边形而不是一堆竖着的细长边。这里有一个常见误区有人直接把 Rigidbody2D 挂到 Tilemap 或者 Grid 上想让地面变成静态刚体。其实地面这种静止物体不需要 Rigidbody2D没有刚体碰撞体就能作为静态环境参与碰撞。只有当你需要地面随着平台一起运动时才需要给 Composite 所在物体挂一个动态 Rigidbody2D。还有一种情况是你希望整个地图可以被推动、旋转、连接关节这也是给 Composite 所在节点挂 Rigidbody2D 的时机。另外要注意CompositeCollider2D 默认情况下会把碰撞体当成实心区域处理。如果希望瓦片只是一层单向平台角色从底下能穿上来从上面能落到平台上直接靠 Composite 做不出来。我惯用的替代方案是在 CompositeCollider2D 上再挂 PlatformEffector2D并且把碰撞体的 Used By Effector 勾上。这样一个由 Tilemap 生成的巨大碰撞体也能变成单向平台效果和多块独立碰撞体完全一致性能却好非常多。3.3 触发器、移动平台和断层区域合并后怎么处理如果你想用瓦片做陷阱区比如岩浆、尖刺、水面这套碰撞配置依然能用。做法是给对应的 Tile 资产配置 Collider Type 为 Sprite然后单独建一个只用于触发器的 Tilemap。这个 Tilemap 上的 TilemapCollider2D 勾上 Is Trigger再勾 Used By Composite 去合并且共享 CompositeCollider2D。为了让 Composite 能正确参与触发逻辑把 CompositeCollider2D 的 Used By Effector 也打开。这样一个瓦片地图的碰撞体数量可以压缩到几个触发检测依旧有效。还有一种麻烦情况是地图里有断层比如中间挖掉的洞、悬空的浮空岛。Composite 合并规则会把不相连的瓦片区域自动拆成多个多边形所以这并不需要你额外操作。但要注意多边形碰撞体在凹多边形和复杂地形下可能会出现顶点过多的现象如果某个浮岛的轮廓被合并得过于复杂物理计算也可能偏高。这种时候可以考虑把美术形态做简化处理让碰撞轮廓的顶点数量控制在合理范围例如用小体积的 BoxCollider2D 补一部分而非让 Composite 合并出上百个顶点的轮廓。碰撞层稳定后静态地图基本就非常能打了。但真正要跟 Tilemap 深度打交道绕不开的是瓦片资产本身的规则系统——比如 RuleTile 这种看起来是美术工具的玩意儿背后其实是一套匹配逻辑。我建议所有做 2D 项目的开发者在项目初期就认真理解它这东西能帮你省掉大量重复劳动。4. RuleTile 不是画图工具把规则匹配拆开看4.1 邻居位掩码RuleTile 判断“接缝”的底层方式RuleTile 之所以能让地形瓦片自动连接靠的并不是魔法而是一套基于邻居格子状态的匹配规则。你在 RuleTile 编辑界面看到的那些小箭头、小叉叉、问号翻译成代码就是根据当前位置周围八格的瓦片情况组合出一个“邻居状态”然后拿这个状态去匹配用户定义的各种规则。匹配上哪条规则就用哪个 Sprite 来画当前格子。这里很容易被误解的点是RuleTile 看的是“邻居位置上有没有别的瓦片”而不是邻居是不是同一块地形的瓦片。比如你做一块草地方块和一块泥土方块草地的 RuleTile 规则里如果定义了“旁边是泥土就不算草地边缘”那么草地和泥土的接缝处可以有过渡效果这是很多人的预期。但在默认取向上如果你想区分“相邻有草地块”和“相邻为空地”的不同表现就必须把规则里的对应方向设成确定的状态而不是问号。问号代表这个方向不参与判断取任何值都能匹配这样虽然省事但会让不同接缝形态共用同一块 Sprite看起来地形就“没有变化”。弄清楚这一点后你才会知道为什么有些地形瓦片怎么连都连不对。4.2 规则优先级与兜底默认值接缝乱掉的根源RuleTile 里有一个默认 Sprite当一个格子出现了没有任何规则匹配的邻居状态时就会回退到这个默认 Sprite。很多接缝错误都出在这里你定义了新的规则但忘记更新默认值或者规则本身的优先级设置不对导致某几种关键的接缝形态被更靠前的一条模糊规则抢走了匹配。一旦出现这种现状表现就是同一种 Sprite 在多个场景里复用边缘自动连接失效地形看起来千篇一律。排查时我会先回到 RuleTile 资产里检查默认值再逐条理一遍规则确认模糊的问号方向没有把具体的方向规则盖掉。4.3 自定义 RuleTile写一个属于自己的匹配器如果默认的 RuleTile 编辑器已经满足不了你的需求真正的钥匙是写一个继承 RuleTile 的类重写它的匹配逻辑。比如说你想让地形在“上面有角色或者有特殊物件”时换一种显示或者在一个复杂的程序化地图里根据自定义数据决定外观。这种需求没法纯靠编辑器规则做出来需要从代码层定制。它的核心 API 是RuleTile.TilingRule里的邻居定义以及RuleTile.GetTileData这个回调。你在自定义类里可以先按自己的规则计算当前格子要显示的 Sprite然后改写 GetTileData 来强制返回指定 Sprite。甚至可以做到完全不管默认邻居系统直接用运行时生成的随机数据、噪声数据来决定每个格子的外观。举一个我在模拟地形生成项目里的用法我用一个自定义 RuleTile让瓦片根据自身坐标和一张噪声贴图计算颜色和形态映射实现在运行时生成随机地表纹理。做法并不复杂核心就是重写 GetTileData把噪声采样结果传进 Sprite 的选择逻辑。这个能力特别适合程序化地图项目——它能让瓦片看起来是精心手摆的实际上全是跑的算法。4.4 RandomTile 和 AnimatedTile别为了偷懒牺牲一致性Unity 还内置了 RandomTile 和 AnimatedTile。RandomTile 会在放置时从一组 Sprite 里随机挑一个用于地面碎石、草地斑驳这类重复纹理非常合适。AnimatedTile 可以播放逐帧动画适合岩浆、水、闪烁的灯。这俩我用过之后有个心得RandomTile 很方便但如果你后续要做地形寻路比如不同 Sprite 代表不同可通行状态RandomTile 的“随机”会导致同一地形块有不同视觉表达却要共用同一份逻辑属性这时最好还是老老实实手动指定瓦片类型避免出现看起来不连通但逻辑上能通行的区域。规则瓦片讲到这里接下来进入游戏开发者最终绕不开的部分——运行时操作 Tilemap。铜墙铁壁的静态地图固然好但大量项目需要程序化生成、动态改格、玩家建筑系统。这部分性能优化的差别比前面任何环节都更能决定游戏的上限。5. 运行时改地图SetTile 系列函数的性能梯度与正确姿势5.1 三个写入接口的性能差异别等卡了才回头看在运行时修改瓦片数据最常用的接口是SetTile、SetTiles和SetTilesBlock。表面看它们都是把瓦片写到某个位置但实际触发的内部逻辑差异很大。SetTile(cellPosition, tile)适合单个瓦片的零星修改。比如玩家在地图上放置一个装饰物或者被炸弹炸掉一格。它会立刻将数据写入 Tilemap并触发所在 Chunk 的刷新。SetTiles(Vector3Int[] positions, TileBase[] tiles)适合一次性改一批坐标不连续的多个瓦片。比如一串散点地形更新、多个缺口同时填充。Unity 会在所有坐标都写入完成后再统一刷新性能比循环调用 SetTile 好不少。SetTilesBlock(BoundsInt bounds, TileBase[] tiles)适合整块区域的填充或者清空。它会把一块矩形区域内所有格子一次性写入性能在三种接口中最高。但也因为它是整块写入改动不规则的形状时需要你先把对应 bounds 内的旧数据读出来修改后再整块写回去。我建议做任何批量修改时都优先考虑后两种。特别是”清理一大片地图然后重新填一层”这种场景SetTilesBlock 是碾压级的优势。写代码时注意tiles数组长度必须刚好等于bounds.size.x * bounds.size.y顺序是从左下到右上按行遍历。漏一个坐标位会导致整块填充错位这是最容易被忽视的细节。5.2 大量动态修改不能忽略的刷新成本一次改完再刷新关于 Chunk 刷新前面第 2 章说过了。在运行时这更是重灾区。地图编辑器里你手动画几百个格子没有感觉因为编辑流程不追求每帧交互。但游戏运行时如果玩家或者 AI 每帧都在改大量格子又没做好合并帧率掉得比什么都快。一个铁律是运行时的地形修改尽量集中到一个逻辑帧内完成不要跨多个函数调用零散修改。你把一帧内所有改动格子收集成一个集合最后统一调用 SetTiles 或 SetTilesBlock让引擎只做一次网格重建。这比写十次 SetTile 再在末尾手动调用 RefreshAllTiles 要稳妥得多。RefreshAllTiles 本身是极端接口它会强制刷新整个 Tilemap 的所有 Chunk几万格地图调用一次都够喝一壶的。我见过有人在循环里调用它当场表演什么叫“掉帧瀑布”。另外如果你能预测将来一段时间内不会有人改某个区块可以考虑把这个区块的瓦片数据搬到更简单的运行时 Mesh 或者单独渲染层里。Tilemap 是通用方案但极端性能敏感的地块比如超大地形的底层、被迷雾遮挡的区域用更底层的网格方案往往更划算。5.3 坐标系换算World、Cell 与 Bounds 的来回拉扯运行时处理地图坐标系换算绕不开。网格坐标系Vector3Int和你常用的世界坐标Vector3之间全靠 Grid 组件做换算。核心就两个方法Grid.WorldToCell(worldPosition)把世界坐标换算成格子坐标Grid.CellToWorld(cellPosition)把格子坐标换算成世界坐标。注意WorldToCell得到的是格子左下角的整数索引而CellToWorld返回的是这个格子左下角的世界坐标不是中心。如果你要判断角色踩在哪个格子用WorldToCell很合适如果要往某个格子中心放特效得自己做半格偏移。还有一对容易被忽略的 APITilemap.origin和Tilemap.size它们描述了当前地图占用的格子包围盒。遍历所有瓦片的时候正确姿势是拿tilemap.cellBounds遍历而不是自己猜范围。否则程序化地图加了旋转、偏移你的遍历范围就会错位。我自己写导出工具时还用过GetTilesBlock把整块矩形数据一次性读出来做序列化效率和逐个 GetTile 完全不是一个量级。5.4 一个常规程序化地形生成的小例子综合上面这些点给出一个我在模拟地形 Demo 里常用的结构。它做的事情是先生成一块草地地形区域然后在指定范围里随机挖掉若干块作为水塘。整个过程刻意用批量接口避免逐格写入using UnityEngine; using UnityEngine.Tilemaps; public class TerrainGenerator : MonoBehaviour { public Tilemap tilemap; public TileBase grassTile; public TileBase waterTile; void Generate(int sizeX, int sizeY, int waterCount) { tilemap.ClearAllTiles(); Vector3Int origin new Vector3Int(0, 0, 0); BoundsInt area new BoundsInt(origin, new Vector3Int(sizeX, sizeY, 1)); var grassTiles new TileBase[area.size.x * area.size.y]; for (int i 0; i grassTiles.Length; i) grassTiles[i] grassTile; tilemap.SetTilesBlock(area, grassTiles); var random new System.Random(); for (int i 0; i waterCount; i) { int px random.Next(1, sizeX - 2); int py random.Next(1, sizeY - 2); var positions new Vector3Int[9]; var tileRefs new TileBase[9]; int idx 0; for (int x px - 1; x px 1; x) { for (int y py - 1; y py 1; y) { positions[idx] new Vector3Int(x, y, 0); tileRefs[idx] waterTile; idx; } } tilemap.SetTiles(positions, tileRefs); } } }这段代码里先用 SetTilesBlock 铺满草地方块再用 SetTiles 批量写水塘区块。中间没有任何循环内 SetTile所以性能非常好。即使地图规模扩大这种写法的修改成本也远低于每次调用单个瓦片接口。把它扩展开加入噪声、高度或者寻路数据就是很典型的程序化地形生成骨架了。5.5 运行时瓦片读取GetTile 之外要关心的类型转换运行时除了写入读取也一样有讲究。GetTileRuleTile(cellPosition)和GetTile(cellPosition)的差别在于泛型版本会帮你做类型转换。如果格子为空或者瓦片类型不匹配泛型版本会返回 null不需要额外判断。但如果你只是想知道这个格子“有没有瓦片”直接用HasTile(cellPosition)或者判空就够了没必要 GetTile 再判。查地形类型的时候同样如此直接用 GetTile 拿 TileBase再比对你的类型引用比每次做完整类型转换更快、更直观。另外一个常被我团队问到的问题地图瓦片到底要不要在运行时做“数据层和表现层分离”。我的建议是分。Tilemap 本身适合做表现和数据但如果你有复杂的模拟逻辑例如每个格子的 HP、属性、刷新时间就不要把这些状态全塞进 Tilemap。Tilemap 存 TileBase 引用只是外观真正的模拟状态放在你自建的二维数组或字典里两者通过格子坐标对齐。这样地图数据量再多逻辑层也不会被 Tilemap 的性能拖累。我也因为这个选择逃过好几次逻辑和表现互相污染的大坑。6. 修改瓦片却不生效一张排查链路把问题定位到根写完运行时操作聊一个非常实际的现场排查过程。这个问题几乎每个用 Tilemap 的人都会撞上一次“我在代码里 SetTile 了运行时瓦片就是不显示或者显示错了。”遇到这类问题我从来不会直接怀疑 Tilemap 损坏。第一件事是确认坐标到底对不对。把 SetTile 传入的Vector3Int打印出来同时打印Grid.WorldToCell(camera.ScreenToWorldPoint(Input.mousePosition))比对两者是不是同一个格子。多数情况下就是坐标偏移了半格或者因为 Grid 有旋转、缩放导致换算结果和自己预期不一致。这个环节用场景视图里的“显示网格”辅助确认可以省下大把瞎猜时间。坐标没问题第二步检查瓦片资产本身。把你 SetTile 时传入的 TileBase 拖到场景里看它有没有内容。RuleTile 和自定义 TileBase 尤其容易出现“资产看着存在、但 Sprite 列表没填或 Sprite 被隐藏”的情况。如果 Sprite 是空的Tilemap 渲染自然什么都没有。第三步看渲染器的可见性设置TilemapRenderer 的 Sorting Layer 是不是被放在了最后面、有没有被其他层挡住颜色是不是被调成了全透明Mask 交互是否正常。这几个问题经常会在大型项目里悄悄出现还特别难发现。第四步查碰撞体。瓦片显示正常但角色穿过去检查 TilemapCollider2D 的 Enabled 是否打开、Used By Composite 是否指向了正确的 CompositeCollider2D。如果是动态生成的瓦片新瓦片不会自动刷新碰撞体你需要主动调用tilemapCollider.ProcessTileChange或者在生成完后手动遍历变化的格子刷新。如果以上都没问题最后一步才是怀疑 Tilemap 数据本身。我在某个项目里遇到过编辑器里改好的瓦片打包后不显示的情况最后定位到是那个瓦片资产放在了一个打包时被排除的目录里导致运行时根本找不到资源。这类资源管理问题用排查顺序很难一下子想到但如果从显示层、坐标层、资源层、碰撞层逐级排查往往几分钟就能锁定到根因。我把最近一段时间团队里最常踩的坑整理成了一张表方便对照现象常见原因排查方向运行时 SetTile 无效果坐标换算错误 / 瓦片资产 Sprite 为空打印坐标、检查 Tile 资产瓦片显示但无碰撞TilemapCollider2D 未启用 / 未合并到 Composite检查碰撞组件勾选状态局部瓦片出现白缝图集无 padding / 瓦片尺寸非整像素调整图集留白、检查 PPU动态地图修改掉帧循环 SetTile 触发多次 Chunk 刷新改 SetTiles / SetTilesBlock接缝瓦片显示混乱RuleTile 规则优先级冲突或默认值不对检查规则列表和默认 Sprite打包后瓦片消失资源目录未包含 / Tile 资产被动态加载释放检查 AssetBundle 或 Resources 目录排查的经验看起来零碎但归纳下来其实就是一条主线数据写入对不对、资产内容全不全、渲染通道通不通、碰撞逻辑有没有跟上。沿着这条链路走大部分问题都能在十分钟内水落石出。最后再分享两个实用小技巧一是调试时经常在 Scene 视图开启 Tilemap 的 “Show Grid” 和 “Tilemap Collider” 叠加显示能让你一眼看出碰撞轮廓和格子边界二是所有批量改动瓦片的代码都留一个产出前后 cellBounds 的日志一旦哪个版本出现地形异常可以直接比对是哪一批写入出了问题。这些习惯帮我在项目里避免了很多返工也希望接下来做 2D 项目的你能用上。 
长河君 · 2026/10/21 13:58:40 · 阅读 1.2k Unity Tilemap 性能优化：从渲染合批到运行时改图全解析
如果你用一堆 SpriteRenderer 一张张往场景里铺 2D 地图项目规模一旦上去DrawCall 和内存数据会率先把你劝退。大多数人第一次意识到 Tilemap 的价值都是在帧率报表突然变得难看的时候。我刚开始做 2D 项目也踩过同样的坑上千个瓦片精灵堆在场景里运行时代码要管它们的排序、位置、碰撞、图层稍微多一点动态地图逻辑卡顿和内存开销就一起上来了。后来彻底把地图底层的实现切到 Tilemap 系统这些麻烦才算是真正从根上解决。这是一套能承载超大场景、适合程序化生成、又能让美术直接在编辑器里涂改的完整地图方案。这篇内容不打算把官方文档复述一遍我想从实际项目里摸过的机制出发把渲染合批、碰撞合并、规则瓦片、运行时性能这几个最容易被忽视的环节拆开讲。适合已经知道 Tilemap 怎么添加场景、但想搞清楚它内部工作原理以及准备在项目里大规模使用的人。1. 从“铺精灵地图铺到卡顿”说起Tilemap 解决了什么1.1 为什么几百个瓦片就能拉开肉眼可见的差距很多新手理解不了Tilemap 和“用普通 Sprite 摆地图”到底差在哪。直观上看两种方式最后屏幕上显示的都是一个个 32×32、64×64 的小图片。但背后的数据结构完全不是一回事。用 SpriteRenderer 铺地图每一个瓦片都是一个独立的 GameObject每个 GameObject 对应一个 Transform 组件、一个 SpriteRenderer 组件、一个排序数据、一个可见性判定。场景里哪怕只有一百个瓦片Unity 也需要给这一百个组件做剔除、排序、批次提交。一旦地图做到 200×200就是四万个对象这一层 Transform 和渲染组件的内存与遍历开销就已经非常可观更别谈一次性访问所有瓦片时的物理、寻路和逻辑遍历。Tilemap 的方式是把“地图”当成一张数据表来处理。Tilemap 组件内部没有为每一格创建一个对象而是保存了一个以格子坐标为核心的瓦片索引表每格存的是对这个 Tile 资产的引用。要知道某个坐标放的是什么就直接查这个表要渲染TilemapRenderer 负责把这些格子按网格合并成若干块 Chunk 再做绘制。这样的设计天然避开了 GameObject 数量爆炸的问题。我在一个模拟项目中测试过同样是一张 128×128 的地图用 SpriteRenderer 铺场景里光 Transform 就有上万个编辑器和运行时的 Load 时间都肉眼可见地变久切到 Tilemap 之后负责地图的物体只有 Grid、Tilemap、TilemapRenderer 三个组件数据全部压进内部结构地图越大这种优势越明显。1.2 数据驱动的设计解放的是逻辑复杂度Tilemap 不只是省了 GameObject更重要的是它改变了你操作地图的方式。以前想在某个坐标放一个草地块需要找到那个坐标对应的 GameObject改它的 Sprite、颜色、排序甚至可能还要再挂一个用来标识地块类型的脚本现在只需要一行SetTile(cellPosition, tileAsset)。以前想检测某个格子是什么地形要去遍历 GameObject 列表或者维护一套字典现在直接GetTile(cellPosition)就拿到了 TileBase 实例。这种数据驱动模式带来的另一个好处是地图的存盘和序列化变得非常简单。整个 Tilemap 的网格数据可以整体保存保存格式就是一个坐标和瓦片引用的映射。也正因为有这个基础程序化地图生成、运行时地图编辑、存档系统才变得干净利落。我这里并不是说 SpriteRenderer 铺地图一无是处——如果你的地图只有十几个装饰物或者全是完全不规则的大型物件那用普通 GameObject 反而更灵活。但凡是格子类地图不管你做的是策略战棋、横版跑酷、俯视角射击还是传统 RPGTilemap 几乎都是更合理的地基。这一点在项目早期就要想清楚否则中途从 Sprite 铺法切换到 Tilemap转换成本会比重新做一张地图还高。下面这个表可以直观地看出两者在几个核心维度上的差别对比项SpriteRenderer 逐格摆放Tilemap 系统单格对象数每格一个 GameObject Transform Renderer每格只是一个索引表项DrawCall 压力多图集、多排序层下很容易膨胀同图集内自动合批Chunk 化提交编辑器编辑只能手工移动、复制、删除对象笔刷直接涂抹、擦除、批量替换运行时改格需要找到并修改 GameObejct 组件SetTile / SetTilesBlock 直接写数据碰撞与物理每格都要手动挂碰撞体TilemapCollider2D Composite 合并存档序列化需要自己记录所有对象状态可以直接序列化格子索引表1.3 Tilemap 的组成角色先分清楚再聊其他Tilemap 系统不是一个单一组件它由几个分工明确的部分组成。最上面是 Grid它决定格子坐标系的规则包括格子大小、排列方式比如矩形格、菱形格、六边形格都属于 Grid 的 Layout 范围。Grid 下挂着 Tilemap 物体Tilemap 组件负责维护瓦片数据本身。TilemapRenderer 负责把数据变成渲染网格TilemapCollider2D 负责把格子数据转成物理碰撞体。还有一大类组件是 Tile 资产本身它定义了这块格子长什么样、有没有碰撞、是不是“地形自适应”RuleTile、AnimatedTile、RandomTile 都属于这类。很多人拿到就急着画没把这几层分清楚后面会遇到一个典型困惑为什么我改了 Sprite 图片瓦片没变化因为那你改的是图集素材瓦片资产里记录的引用和绘制参数没变。又比如为什么瓦片已经画上去了角色却还是直接穿过因为碰撞体要靠 TilemapCollider2D 生成不是画上去就有碰撞的。我先在这里把角色分工说清楚后面每一章再深入一层。理解这套数据流比会用笔刷涂地图重要得多。2. 渲染层的真相Chunk 合批、图集规范和 Pixel Perfect 的缝2.1 TilemapRenderer 是怎么做到低 DrawCall 的既然 Tilemap 不是靠每个瓦片一个渲染器来画图那它到底怎么把图渲染出来答案在 Chunk 机制。Unity 会把 Tilemap 的整个网格区域切分成若干块区块每一块区块内部把其中所有瓦片需要的顶点、UV、颜色等信息合并成同一个 Mesh最后以一个 Mesh 为单位提交渲染。至于这些 Mesh 能不能合到同一个批次还取决于瓦片使用的 Sprite 是否来自同一张图集。这个机制带来的具体效果是如果一张地图的瓦片都来自同一张 Atlas 图集那么不管地图上有三千个还是三万个瓦片只要它们分布在一个可见 Chunk 内渲染提交往往只要很少的批次。我用过一张 256×256 的地图做过测试地图上铺了六万块瓦片左右帧率反而稳得离谱。换成同样数量的独立 SpriteRenderer想要跑到同样流畅度得对图集、排序、剔除做一大堆额外优化。Tilemap 把这些底层工作直接吃掉了项目里只需要保证素材规范即可。这里要重点敲一下黑板Tilemap 的合批效果高度依赖图集规范。如果你导入的每个瓦片都是单独一张贴图没有打成图集那 TilemapRenderer 合批的能力就会被限制因为它只能在同类图集内部做合并。多个纹理之间的 Mesh 无论如何都得分开提交每切换一次纹理就是一个额外的批次。所以做瓦片素材时一定不要偷懒不生成图集。你可以手动建图集也可以交给引擎的 Sprite Atlas 自动处理只要确保地图瓦片和动态 UI 等经常切换贴图的内容分开放别混进同一张图集导致频繁打断合批就行了。2.2 Chunk 刷新机制为什么你改了几个格子整块都重建了Chunk 的合并渲染不是一成不变的。当你用代码或者编辑器改动任何一个格子时Unity 需要更新该格子所在 Chunk 的 Mesh 数据。它不是只改那一个顶点而是会把所在 Chunk 的所有顶点重新生成一遍。这意味着你在一大块区域内频繁修改零散格子性能消耗会远高于你的直觉预期。打个比方这就像你有一张 Excel 表每次改动其中一个单元格Excel 都会把整张工作表重新计算一遍。放在 Tilemap 里如果你在循环里对几十个分散坐标分别调用 SetTile每次都触发所在 Chunk 重建那么性能会随着改动次数线性变差。正确做法是尽量把一次操作涉及的所有格子收拢到同一次刷新里。用 SetTiles 一次性传一组坐标和瓦片引擎会先完成批量写入再统一刷新受影响区域。这样你的改动逻辑次数相同实际触发的网格重建却少了很多。我踩过最典型的坑是在一款实时地形编辑 Demo 里玩家用笔刷每帧改二十多个格子结果低配手机上帧率疯狂掉。后来排查发现是每帧触发了多次 Chunk 重建改成一次性收集笔刷区域再调用批量接口之后帧率直接翻了倍。这种事不实际跑起来很难意识到文档里也不会强调但恰恰是运行时动态地图的命门。2.3 Pixel Perfect 与网格裂缝防患于未然的几个设置2D 游戏使用 Pixel Perfect Camera 后最讨厌的就是瓦片之间出现白色细缝。原因是相机渲染时瓦片的 UV 采样容易落在图集边缘或者因为摄像机正交尺寸计算不是像素整倍数导致采样偏移让相邻瓦片之间露出背景色或图集旁边的内容。很多人遇到裂缝第一反应是去调整 Pixel Perfect 组件的设置但真正的关键在素材这一层。最有效的方案是给瓦片图集预留足够的边缘留白也叫 padding。在 Sprite Atlas 中给瓦片设置 4~8 像素的 padding相邻瓦片边缘就不会因为浮点误差采样到图集其他区域。其次是确保瓦片是“整像素”大小比如 16、32、64 这类能被相机 PPU 整除的尺寸。如果瓦片是 48×48相机 PPU 却是 32每个瓦片占据的像素并非整数裂缝几乎是必然的。另一个容易忽略的是 Sprite 的 Mesh Type尽量保持 Full Rect不要因为想省面积改成 Tight不然边界顶点会偏离实际矩形缝隙出现的概率会更高。把这些老规矩都做到位Tilemap 的渲染层基本就是稳的。渲染层稳定了地图越大越不用担心 DrawCall接下来真正的性能瓶颈就会转到另一层——物理碰撞。3. 碰撞体才是隐形杀手独立 Box 与 Composite 的取舍3.1 一个格子一个 Collider 的地图物理工程师看了会头大TilemapCollider2D 给地图生成碰撞是完全自动的但它默认的行为是给每个有瓦片的格子生成一个独立的 BoxCollider2D。如果你确认过地图属性面板会发现碰撞体数量巨大——一张 100×100 的地图如果铺满瓦片里外里就有一万个小的 BoxCollider。碰撞体数量一多物理引擎每帧光做 Broadphase 碰撞对检测就非常吃力。因为每个 Collider 都要跟附近的 Rigidbody2D、其他 Collider 做配对测试。许多 2D 游戏卡顿不是渲染瓶颈而是碰撞体数量太夸张。我在项目里见过最夸张的情况地图只有两层地面但 TilemapCollider2D 生成了接近八千个碰撞体角色在地图上跳跃时物理开销几乎占了帧时间的四分之一。所以凡是一张地图里瓦片数量到了上百都强烈建议立刻配一个 CompositeCollider2D。它的作用是把同一 Tilemap 上所有瓦片的外轮廓合并成一个或几个多边形碰撞体内部共享边完全去掉。比如一整块矩形地面合并完就真的只有一个矩形碰撞体了而不是几百个小方块。物体在地面上行走时物理引擎要处理的多边形数量急剧下降跑起来的区别是能直接感知的。3.2 合并碰撞体的正确组法Component 结构和刚体谁去挂合并碰撞体的配置流程有一定讲究。我在项目里会把 Grid 物体上挂一个 CompositeCollider2D然后把 TilemapCollider2D 的 Used By Composite 选项勾上再把 CompositeCollider2D 的 Geometry Type 设为 Polygons。这样瓦片碰撞数据就会从 TilemapCollider2D 输出到 CompositeCollider2D 做多边形合并。合并出来的是完整的闭合碰撞多边形而不是一堆竖着的细长边。这里有一个常见误区有人直接把 Rigidbody2D 挂到 Tilemap 或者 Grid 上想让地面变成静态刚体。其实地面这种静止物体不需要 Rigidbody2D没有刚体碰撞体就能作为静态环境参与碰撞。只有当你需要地面随着平台一起运动时才需要给 Composite 所在物体挂一个动态 Rigidbody2D。还有一种情况是你希望整个地图可以被推动、旋转、连接关节这也是给 Composite 所在节点挂 Rigidbody2D 的时机。另外要注意CompositeCollider2D 默认情况下会把碰撞体当成实心区域处理。如果希望瓦片只是一层单向平台角色从底下能穿上来从上面能落到平台上直接靠 Composite 做不出来。我惯用的替代方案是在 CompositeCollider2D 上再挂 PlatformEffector2D并且把碰撞体的 Used By Effector 勾上。这样一个由 Tilemap 生成的巨大碰撞体也能变成单向平台效果和多块独立碰撞体完全一致性能却好非常多。3.3 触发器、移动平台和断层区域合并后怎么处理如果你想用瓦片做陷阱区比如岩浆、尖刺、水面这套碰撞配置依然能用。做法是给对应的 Tile 资产配置 Collider Type 为 Sprite然后单独建一个只用于触发器的 Tilemap。这个 Tilemap 上的 TilemapCollider2D 勾上 Is Trigger再勾 Used By Composite 去合并且共享 CompositeCollider2D。为了让 Composite 能正确参与触发逻辑把 CompositeCollider2D 的 Used By Effector 也打开。这样一个瓦片地图的碰撞体数量可以压缩到几个触发检测依旧有效。还有一种麻烦情况是地图里有断层比如中间挖掉的洞、悬空的浮空岛。Composite 合并规则会把不相连的瓦片区域自动拆成多个多边形所以这并不需要你额外操作。但要注意多边形碰撞体在凹多边形和复杂地形下可能会出现顶点过多的现象如果某个浮岛的轮廓被合并得过于复杂物理计算也可能偏高。这种时候可以考虑把美术形态做简化处理让碰撞轮廓的顶点数量控制在合理范围例如用小体积的 BoxCollider2D 补一部分而非让 Composite 合并出上百个顶点的轮廓。碰撞层稳定后静态地图基本就非常能打了。但真正要跟 Tilemap 深度打交道绕不开的是瓦片资产本身的规则系统——比如 RuleTile 这种看起来是美术工具的玩意儿背后其实是一套匹配逻辑。我建议所有做 2D 项目的开发者在项目初期就认真理解它这东西能帮你省掉大量重复劳动。4. RuleTile 不是画图工具把规则匹配拆开看4.1 邻居位掩码RuleTile 判断“接缝”的底层方式RuleTile 之所以能让地形瓦片自动连接靠的并不是魔法而是一套基于邻居格子状态的匹配规则。你在 RuleTile 编辑界面看到的那些小箭头、小叉叉、问号翻译成代码就是根据当前位置周围八格的瓦片情况组合出一个“邻居状态”然后拿这个状态去匹配用户定义的各种规则。匹配上哪条规则就用哪个 Sprite 来画当前格子。这里很容易被误解的点是RuleTile 看的是“邻居位置上有没有别的瓦片”而不是邻居是不是同一块地形的瓦片。比如你做一块草地方块和一块泥土方块草地的 RuleTile 规则里如果定义了“旁边是泥土就不算草地边缘”那么草地和泥土的接缝处可以有过渡效果这是很多人的预期。但在默认取向上如果你想区分“相邻有草地块”和“相邻为空地”的不同表现就必须把规则里的对应方向设成确定的状态而不是问号。问号代表这个方向不参与判断取任何值都能匹配这样虽然省事但会让不同接缝形态共用同一块 Sprite看起来地形就“没有变化”。弄清楚这一点后你才会知道为什么有些地形瓦片怎么连都连不对。4.2 规则优先级与兜底默认值接缝乱掉的根源RuleTile 里有一个默认 Sprite当一个格子出现了没有任何规则匹配的邻居状态时就会回退到这个默认 Sprite。很多接缝错误都出在这里你定义了新的规则但忘记更新默认值或者规则本身的优先级设置不对导致某几种关键的接缝形态被更靠前的一条模糊规则抢走了匹配。一旦出现这种现状表现就是同一种 Sprite 在多个场景里复用边缘自动连接失效地形看起来千篇一律。排查时我会先回到 RuleTile 资产里检查默认值再逐条理一遍规则确认模糊的问号方向没有把具体的方向规则盖掉。4.3 自定义 RuleTile写一个属于自己的匹配器如果默认的 RuleTile 编辑器已经满足不了你的需求真正的钥匙是写一个继承 RuleTile 的类重写它的匹配逻辑。比如说你想让地形在“上面有角色或者有特殊物件”时换一种显示或者在一个复杂的程序化地图里根据自定义数据决定外观。这种需求没法纯靠编辑器规则做出来需要从代码层定制。它的核心 API 是RuleTile.TilingRule里的邻居定义以及RuleTile.GetTileData这个回调。你在自定义类里可以先按自己的规则计算当前格子要显示的 Sprite然后改写 GetTileData 来强制返回指定 Sprite。甚至可以做到完全不管默认邻居系统直接用运行时生成的随机数据、噪声数据来决定每个格子的外观。举一个我在模拟地形生成项目里的用法我用一个自定义 RuleTile让瓦片根据自身坐标和一张噪声贴图计算颜色和形态映射实现在运行时生成随机地表纹理。做法并不复杂核心就是重写 GetTileData把噪声采样结果传进 Sprite 的选择逻辑。这个能力特别适合程序化地图项目——它能让瓦片看起来是精心手摆的实际上全是跑的算法。4.4 RandomTile 和 AnimatedTile别为了偷懒牺牲一致性Unity 还内置了 RandomTile 和 AnimatedTile。RandomTile 会在放置时从一组 Sprite 里随机挑一个用于地面碎石、草地斑驳这类重复纹理非常合适。AnimatedTile 可以播放逐帧动画适合岩浆、水、闪烁的灯。这俩我用过之后有个心得RandomTile 很方便但如果你后续要做地形寻路比如不同 Sprite 代表不同可通行状态RandomTile 的“随机”会导致同一地形块有不同视觉表达却要共用同一份逻辑属性这时最好还是老老实实手动指定瓦片类型避免出现看起来不连通但逻辑上能通行的区域。规则瓦片讲到这里接下来进入游戏开发者最终绕不开的部分——运行时操作 Tilemap。铜墙铁壁的静态地图固然好但大量项目需要程序化生成、动态改格、玩家建筑系统。这部分性能优化的差别比前面任何环节都更能决定游戏的上限。5. 运行时改地图SetTile 系列函数的性能梯度与正确姿势5.1 三个写入接口的性能差异别等卡了才回头看在运行时修改瓦片数据最常用的接口是SetTile、SetTiles和SetTilesBlock。表面看它们都是把瓦片写到某个位置但实际触发的内部逻辑差异很大。SetTile(cellPosition, tile)适合单个瓦片的零星修改。比如玩家在地图上放置一个装饰物或者被炸弹炸掉一格。它会立刻将数据写入 Tilemap并触发所在 Chunk 的刷新。SetTiles(Vector3Int[] positions, TileBase[] tiles)适合一次性改一批坐标不连续的多个瓦片。比如一串散点地形更新、多个缺口同时填充。Unity 会在所有坐标都写入完成后再统一刷新性能比循环调用 SetTile 好不少。SetTilesBlock(BoundsInt bounds, TileBase[] tiles)适合整块区域的填充或者清空。它会把一块矩形区域内所有格子一次性写入性能在三种接口中最高。但也因为它是整块写入改动不规则的形状时需要你先把对应 bounds 内的旧数据读出来修改后再整块写回去。我建议做任何批量修改时都优先考虑后两种。特别是”清理一大片地图然后重新填一层”这种场景SetTilesBlock 是碾压级的优势。写代码时注意tiles数组长度必须刚好等于bounds.size.x * bounds.size.y顺序是从左下到右上按行遍历。漏一个坐标位会导致整块填充错位这是最容易被忽视的细节。5.2 大量动态修改不能忽略的刷新成本一次改完再刷新关于 Chunk 刷新前面第 2 章说过了。在运行时这更是重灾区。地图编辑器里你手动画几百个格子没有感觉因为编辑流程不追求每帧交互。但游戏运行时如果玩家或者 AI 每帧都在改大量格子又没做好合并帧率掉得比什么都快。一个铁律是运行时的地形修改尽量集中到一个逻辑帧内完成不要跨多个函数调用零散修改。你把一帧内所有改动格子收集成一个集合最后统一调用 SetTiles 或 SetTilesBlock让引擎只做一次网格重建。这比写十次 SetTile 再在末尾手动调用 RefreshAllTiles 要稳妥得多。RefreshAllTiles 本身是极端接口它会强制刷新整个 Tilemap 的所有 Chunk几万格地图调用一次都够喝一壶的。我见过有人在循环里调用它当场表演什么叫“掉帧瀑布”。另外如果你能预测将来一段时间内不会有人改某个区块可以考虑把这个区块的瓦片数据搬到更简单的运行时 Mesh 或者单独渲染层里。Tilemap 是通用方案但极端性能敏感的地块比如超大地形的底层、被迷雾遮挡的区域用更底层的网格方案往往更划算。5.3 坐标系换算World、Cell 与 Bounds 的来回拉扯运行时处理地图坐标系换算绕不开。网格坐标系Vector3Int和你常用的世界坐标Vector3之间全靠 Grid 组件做换算。核心就两个方法Grid.WorldToCell(worldPosition)把世界坐标换算成格子坐标Grid.CellToWorld(cellPosition)把格子坐标换算成世界坐标。注意WorldToCell得到的是格子左下角的整数索引而CellToWorld返回的是这个格子左下角的世界坐标不是中心。如果你要判断角色踩在哪个格子用WorldToCell很合适如果要往某个格子中心放特效得自己做半格偏移。还有一对容易被忽略的 APITilemap.origin和Tilemap.size它们描述了当前地图占用的格子包围盒。遍历所有瓦片的时候正确姿势是拿tilemap.cellBounds遍历而不是自己猜范围。否则程序化地图加了旋转、偏移你的遍历范围就会错位。我自己写导出工具时还用过GetTilesBlock把整块矩形数据一次性读出来做序列化效率和逐个 GetTile 完全不是一个量级。5.4 一个常规程序化地形生成的小例子综合上面这些点给出一个我在模拟地形 Demo 里常用的结构。它做的事情是先生成一块草地地形区域然后在指定范围里随机挖掉若干块作为水塘。整个过程刻意用批量接口避免逐格写入using UnityEngine; using UnityEngine.Tilemaps; public class TerrainGenerator : MonoBehaviour { public Tilemap tilemap; public TileBase grassTile; public TileBase waterTile; void Generate(int sizeX, int sizeY, int waterCount) { tilemap.ClearAllTiles(); Vector3Int origin new Vector3Int(0, 0, 0); BoundsInt area new BoundsInt(origin, new Vector3Int(sizeX, sizeY, 1)); var grassTiles new TileBase[area.size.x * area.size.y]; for (int i 0; i grassTiles.Length; i) grassTiles[i] grassTile; tilemap.SetTilesBlock(area, grassTiles); var random new System.Random(); for (int i 0; i waterCount; i) { int px random.Next(1, sizeX - 2); int py random.Next(1, sizeY - 2); var positions new Vector3Int[9]; var tileRefs new TileBase[9]; int idx 0; for (int x px - 1; x px 1; x) { for (int y py - 1; y py 1; y) { positions[idx] new Vector3Int(x, y, 0); tileRefs[idx] waterTile; idx; } } tilemap.SetTiles(positions, tileRefs); } } }这段代码里先用 SetTilesBlock 铺满草地方块再用 SetTiles 批量写水塘区块。中间没有任何循环内 SetTile所以性能非常好。即使地图规模扩大这种写法的修改成本也远低于每次调用单个瓦片接口。把它扩展开加入噪声、高度或者寻路数据就是很典型的程序化地形生成骨架了。5.5 运行时瓦片读取GetTile 之外要关心的类型转换运行时除了写入读取也一样有讲究。GetTileRuleTile(cellPosition)和GetTile(cellPosition)的差别在于泛型版本会帮你做类型转换。如果格子为空或者瓦片类型不匹配泛型版本会返回 null不需要额外判断。但如果你只是想知道这个格子“有没有瓦片”直接用HasTile(cellPosition)或者判空就够了没必要 GetTile 再判。查地形类型的时候同样如此直接用 GetTile 拿 TileBase再比对你的类型引用比每次做完整类型转换更快、更直观。另外一个常被我团队问到的问题地图瓦片到底要不要在运行时做“数据层和表现层分离”。我的建议是分。Tilemap 本身适合做表现和数据但如果你有复杂的模拟逻辑例如每个格子的 HP、属性、刷新时间就不要把这些状态全塞进 Tilemap。Tilemap 存 TileBase 引用只是外观真正的模拟状态放在你自建的二维数组或字典里两者通过格子坐标对齐。这样地图数据量再多逻辑层也不会被 Tilemap 的性能拖累。我也因为这个选择逃过好几次逻辑和表现互相污染的大坑。6. 修改瓦片却不生效一张排查链路把问题定位到根写完运行时操作聊一个非常实际的现场排查过程。这个问题几乎每个用 Tilemap 的人都会撞上一次“我在代码里 SetTile 了运行时瓦片就是不显示或者显示错了。”遇到这类问题我从来不会直接怀疑 Tilemap 损坏。第一件事是确认坐标到底对不对。把 SetTile 传入的Vector3Int打印出来同时打印Grid.WorldToCell(camera.ScreenToWorldPoint(Input.mousePosition))比对两者是不是同一个格子。多数情况下就是坐标偏移了半格或者因为 Grid 有旋转、缩放导致换算结果和自己预期不一致。这个环节用场景视图里的“显示网格”辅助确认可以省下大把瞎猜时间。坐标没问题第二步检查瓦片资产本身。把你 SetTile 时传入的 TileBase 拖到场景里看它有没有内容。RuleTile 和自定义 TileBase 尤其容易出现“资产看着存在、但 Sprite 列表没填或 Sprite 被隐藏”的情况。如果 Sprite 是空的Tilemap 渲染自然什么都没有。第三步看渲染器的可见性设置TilemapRenderer 的 Sorting Layer 是不是被放在了最后面、有没有被其他层挡住颜色是不是被调成了全透明Mask 交互是否正常。这几个问题经常会在大型项目里悄悄出现还特别难发现。第四步查碰撞体。瓦片显示正常但角色穿过去检查 TilemapCollider2D 的 Enabled 是否打开、Used By Composite 是否指向了正确的 CompositeCollider2D。如果是动态生成的瓦片新瓦片不会自动刷新碰撞体你需要主动调用tilemapCollider.ProcessTileChange或者在生成完后手动遍历变化的格子刷新。如果以上都没问题最后一步才是怀疑 Tilemap 数据本身。我在某个项目里遇到过编辑器里改好的瓦片打包后不显示的情况最后定位到是那个瓦片资产放在了一个打包时被排除的目录里导致运行时根本找不到资源。这类资源管理问题用排查顺序很难一下子想到但如果从显示层、坐标层、资源层、碰撞层逐级排查往往几分钟就能锁定到根因。我把最近一段时间团队里最常踩的坑整理成了一张表方便对照现象常见原因排查方向运行时 SetTile 无效果坐标换算错误 / 瓦片资产 Sprite 为空打印坐标、检查 Tile 资产瓦片显示但无碰撞TilemapCollider2D 未启用 / 未合并到 Composite检查碰撞组件勾选状态局部瓦片出现白缝图集无 padding / 瓦片尺寸非整像素调整图集留白、检查 PPU动态地图修改掉帧循环 SetTile 触发多次 Chunk 刷新改 SetTiles / SetTilesBlock接缝瓦片显示混乱RuleTile 规则优先级冲突或默认值不对检查规则列表和默认 Sprite打包后瓦片消失资源目录未包含 / Tile 资产被动态加载释放检查 AssetBundle 或 Resources 目录排查的经验看起来零碎但归纳下来其实就是一条主线数据写入对不对、资产内容全不全、渲染通道通不通、碰撞逻辑有没有跟上。沿着这条链路走大部分问题都能在十分钟内水落石出。最后再分享两个实用小技巧一是调试时经常在 Scene 视图开启 Tilemap 的 “Show Grid” 和 “Tilemap Collider” 叠加显示能让你一眼看出碰撞轮廓和格子边界二是所有批量改动瓦片的代码都留一个产出前后 cellBounds 的日志一旦哪个版本出现地形异常可以直接比对是哪一批写入出了问题。这些习惯帮我在项目里避免了很多返工也希望接下来做 2D 项目的你能用上。