k-NN（k nearest neighbors）

我在一个场景中，有100k个小怪，我需要得到1k个与我最近的单位，如何快速查找？

四叉树

四叉树适用于二维场景，将空间递归划分成四个象限，按区域把单位放进去。

树基本结构

• 根节点：覆盖整个场景范围
• 每个节点最多存放一定数量的对象（例如 8~16 个）
• 超过阈值时分裂成 4 个子节点
• 对象根据坐标放入对应的子节点

查找最近 1k 个单位的步骤

1. 从根节点开始，把查询点所在的区域优先搜索
2. 对当前节点里的对象计算距离，维护一个最大堆或固定大小的候选列表
3. 对子节点递归搜索，但只进入那些有可能包含更近对象的区域
4. 对每个子节点，先检查该节点包围盒到查询点的最小距离
   • 如果该最小距离已经比当前第 1k 近的距离大，就可以剪枝跳过该子节点
5. 继续搜索直到所有可能更近的区域都处理完

网格 / 空间哈希（Spatial Hash Grid）

• 把场景分成固定大小的格子，每个格子维护一个对象列表。查询时只检查当前格子和相邻格子，速度快，非常适合均匀分布。
• 把格子坐标哈希成桶，适合大范围、动态移动对象。插入、删除、查询都是常数级别，维护简单。也可以看成“网格划分+哈希映射”。
• 查询时只访问与自身相邻的若干格子
• 适合均匀分布、实时更新频繁的场景

k-d 树

• 构建过程的时间复杂度是 O(N log N)。对于100k个小怪，这是一次性的、完全可以接受的开销。
  • 构建完后，这棵树在这一帧内是静态的。
  • 适合静态点集或少量动态更新
• 递归按 x/y 轴交替划分空间

查找最近 1k 个单位的步骤

最近邻查询类似二叉树剪枝

• 从根节点开始，比较你的位置和当前节点在分割轴上的坐标。
• 如果你在节点的左边，就优先进入左子树；如果在右边，就优先进入右子树。像普通二叉树查找一样，一路向下，直到到达一个叶子节点。
• 当你从递归中返回，开始回溯到父节点时，执行最关键的“剪枝”判断。
• 核心问题: “另一半子树所代表的空间区域，有没有可能存在比我当前找到的第1000个邻居更近的点？”
• 判断方法: 计算你的位置到当前节点“分割面”的垂直距离 d_plane。
  • 如果 d_plane ≥ radius: 这意味着另一半子树的整个空间，都比你当前最远的邻居还要远。因此，你完全不需要进入那个子树进行搜索！ 这就是“剪枝”。
  • 如果 d_plane < radius: 意味着另一半子树的空间与你的“搜索球”有交集，里面可能存在更近的点。因此，你必须进入这个子树，重复上面的递归搜索过程。

BVH (Bounding Volume Hierarchy) / 包围盒层级

• 每个节点是一个包围一组物体的盒子（AABB/OBB等）
• 子节点是把物体集合拆成两组（常见二叉），再分别求包围盒。
• 划分不要求等分空间，通常按数据分布和代价（如 SAH）自适应构建。

查找最近 1k 个单位的步骤

• 初始化: 将所有100k个小怪（或它们的精确位置）看作“物体”，放入一个列表中。
• 递归构建:
  • 终止条件: 如果当前列表中的物体数量小于等于某个阈值（比如8），则创建一个叶子节点。这个叶子节点的AABB是紧紧包裹这几个物体的包围盒，节点内部存储这些物体的引用。然后返回。
  • 选择最长的轴: 计算当前列表中所有物体的AABB，找到这个AABB最长的轴（X, Y, 或 Z）。
  • 排序与划分: 沿着这个最长的轴，根据物体重心的坐标，对列表中的所有物体进行排序。找到中位数，将列表一分为二。
  • 创建子节点:
    • 对第一半的物体，递归调用构建过程，创建一个左子节点。
    • 对第二半的物体，递归调用构建过程，创建一个右子节点。
  • 创建父节点: 创建一个新的中间节点，它的AABB是其左、右两个子节点AABB的并集（即一个能同时包裹住左右两个子包围盒的新包围盒）。这个中间节点的子节点就是刚刚创建的左右子节点。

这个过程从包含所有物体的根节点开始，一直递归下去，直到所有物体都被分配到叶子节点中。构建完成后，你就有了一个完整的BVH树。

• K-近邻查询 (每帧执行的核心算法)
  一个容量为 K (这里是1000) 的最大优先队列 (Max-Priority Queue)，我们称之为“结果集 (resultSet)”。
• 作用: 用来存储到目前为止找到的 K 个最近邻居。
• 特性: 队列的“顶部” i.e. queue.peek() 永远是这 K 个中距离你最远的那个。当你尝试加入一个新邻居时，如果它比最远的那个更近，最远的就会被自动“踢”出去。

一个最小优先队列 (Min-Priority Queue)，我们称之为“待办列表 (todoList)”。

• 作用: 用来存储接下来需要检查的 BVH 节点。
• 特性: 队列的“顶部”永远是距离你最近的那个节点/AABB盒。这保证了我们总是优先探索最有希望找到近邻的区域。

具体算法

假设你的位置是 myPosition，要查找 K=1000 个最近邻。

• 初始化:
  创建一个空的、容量为1000的 resultSet (最大优先队列)。
  创建一个空的 todoList (最小优先队列)。
  将 BVH 的根节点以及你到根节点AABB的最近距离 d_box (初始时这个距离是0，因为你在场景内)作为一个元组 (rootNode, d_box) 加入 todoList。
  将“最大搜索半径 radius” 初始化为无穷大。
  开始循环搜索: 当 todoList 不为空时，持续循环：

a. 取出最优节点: 从 todoList 中取出距离最近的节点 (currentNode, dist_box)。

b. 核心剪枝:
从 resultSet 中获取当前已找到的最远邻居的距离（如果 resultSet 已满），这个距离就是我们当前的最大搜索半径 radius。
如果 dist_box ≥ radius: 这意味着 todoList 中所有剩下的节点（因为它们比 currentNode 更远）以及它们包含的所有物体，都不可能比我们已经找到的第K个邻居更近。搜索可以提前结束！ 跳出循环。

c. 处理节点:
如果 currentNode 是一个叶子节点:
遍历该叶子节点包含的所有实际物体。
对于每个物体，计算你到它的精确距离 d_obj。
尝试更新结果集: 将这个物体和它的距离 d_obj 加入 resultSet。如果 resultSet 已满且 d_obj 更近，优先队列会自动T出最远的那个。
重要: 每当 resultSet 被更新后（特别是当它首次满员时），需要更新 radius 为 resultSet 中新的最大距离。这个 radius 会不断缩小，从而让步骤 b 的剪枝变得越来越强大。

如果 currentNode 是一个中间节点:
获取它的左、右两个子节点。
对于每一个子节点：
计算你到这个子节点AABB的最近距离 d_child_box。
如果 d_child_box < radius: 这意味着这个子节点的区域内可能存在更近的邻居，我们必须探索它。将这个子节点和它的距离 (childNode, d_child_box) 加入 todoList。
如果 d_child_box ≥ radius，则直接忽略这个子节点及其整个分支（又一次剪枝！）。

完成: 当循环结束时，resultSet 中存储的就是最终的1000个最近邻居。

倒排桶 / 桶排序距离

• 先用距离近似值分桶，再只对近距离桶内对象精确排序
• 适合距离范围已知、精度需求不高的场景

粗略筛选 + 精确排序

• 先用简单空间划分得到一小部分候选对象
• 然后在候选集中排序取前 1k
• 例如：先找 5x5 个邻近网格，再精确计算

Batching

静态合批: 将相同材质并且始终不动的的Mesh合并成为一个大Mesh，然后由CPU合并为一个批次发送给GPU处理,从而减少DrawCall带来的消耗。
动态合批: 相同材质并且会动的物体Mesh合并成为一个大Mesh
SRP Batcher: 将多个网格合并成单个批次进行渲染，从而提高性能。与其他合批不同，SRP Batcher将未改变属性的Mesh缓存起来，从而减少消耗
GPU Instancing: 使用一个DrawCall渲染多个相同材质的网格对象（如场景中大量重复的物体如树木和草地等），从而减少CPU和GPU的开销

Static Batching

针对静态物体（勾选 Static）。在构建时，Unity 把所有使用相同材质的静态 mesh 合并成一个大 mesh，存到内存里。运行时一次 Draw Call 画完。

1
2
3

场景里100棵树（同材质，Static）：
  构建时合并 → 1个大mesh
  运行时：SetPass × 1，Draw Call × 1

代价是内存，合并后的大 mesh 常驻内存，物体也不能移动。

Dynamic Batching

与静态合批不同，动态合批是的物体是可以运动的，针对动态小物体。每帧 CPU 实时把符合条件的 mesh 合并，然后一次提交。
条件很苛刻：顶点数 < 300，不能使用lightmap，不能使用多通道的shader，不能是缩放比不同的物体。
Unity 的 Dynamic Batching（动态批处理）是自动触发的。只要启用了该功能且物体满足特定条件（如使用相同材质、顶点数较少），Unity 引擎就会在运行时自动合并 Draw Call，无需手动干预。

1
2

每帧：
  CPU 检查哪些动态物体同材质 → 临时合并 mesh → 一次 Draw Call

代价是 CPU 每帧都要做合并，物体多了反而更慢。

SRP Batcher

Batches draw calls by grouping objects that use the same shader variant, reducing SetPass calls
Shader properties stored in GPU buffers instead of individual material constants

创建大型 GPU 缓冲区: 在每一帧开始时，SRP Batcher 会在 GPU 上开辟一个巨大的、持久化的缓冲区 (在现代图形API中通常是 Constant Buffer 或 UBO)。
打包所有数据: 它会遍历所有使用相同 Shader Variant（着色器变体）的物体，把它们的材质属性（颜色、向量、浮点数等）全部打包塞进这个大缓冲区里。

现在，当 CPU 指示 GPU 绘制时，CPU 对 GPU 说：“准备画一批物体，它们都用 Shader A。它们的材质数据已经全部放在那个大缓冲区里了。” (这对应一个非常快速的、几乎可以忽略不计的 SetPass 准备工作)
然后 CPU 快速地连续下达指令：
“画第一个物体，它的数据在缓冲区偏移量0的位置。” (一个 Draw call)
“画第二个物体，它的数据在缓冲区偏移量64的位置。” (一个 Draw call)
“画第三个物体，它的数据在缓冲区偏移量128的位置。” (一个 Draw call)

SetPass call: 只有在切换 Shader Variant 时才会发生一次。对于所有使用相同 Shader Variant 的物体，无论它们有多少个，都属于同一个“SRP Batch”，共享一次 SetPass 设置。因此 SetPass call 的数量大幅降低。
Draw call: 每个物体最终还是需要 GPU 单独绘制一次。CPU 依然需要为每个物体都发送一个 Draw 指令。因此 Draw call 的数量没有改变。

使用条件：

• 不支持内置渲染管线，支持通用(URP)/高清(HDRP)/自定义(SRP)渲染管线
• 不使用 MaterialPropertyBlocks
• Materials must use SRP-compatible shaders

在标准的渲染流程下，CPU需要收集所有场景物体的参数，场景中的材质越多CPU提交给GPU的数据就越多。
而在SRP中流程下GPU拥有数据管理的 “生命权” ,管理大量不同材质但Shader变动较小的的内容。
让数据在GPU中持久存在,从而减少消耗(SetPass Call)。

SRP Batcher vs. Dynamic Batching

Both can be used together in SRP, but SRP Batcher takes precedence when enabled. For optimal performance in modern Unity projects, prefer SRP Batcher with proper shader setup.

Both Dynamic Batching and SRP Batcher are triggered automatically in Unity when their conditions are met:

• Unity automatically detects and performs Dynamic Batching on compatible objects at runtime
• SRP batcher automatically batches during render loop when objects use compatible shader variants enabled in the render pipeline settings (Window → Rendering → Render Pipeline → Universal Render Pipeline → General → SRP Batcher)

GPU Instancing

针对大量相同 mesh + 相同材质的物体（但允许不同的属性，比如颜色、位置）。CPU 只提交一次 mesh 数据，附带一个”实例属性数组”，GPU 自己循环绘制 N 次。
在 Unity 中，需要在材质属性中勾选 “Enable GPU Instancing”。

1
2
3
4

// shader 里声明每个实例可以有不同颜色
UNITY_INSTANCING_BUFFER_START(Props)
    UNITY_DEFINE_INSTANCED_PROP(float4, _Color)
UNITY_INSTANCING_BUFFER_END(Props)

使用条件：

• 材质需要支持GPU Instancing，例如默认标准材质就有
• Tranform信息需要有所不同（完全重合了渲染出来也没有意义）
• 未使用SRP Batcher，如有会优先使用SRP Batcher。(在URP渲染管线中是默认开启的)
• 粒子对像不能合批

此时的CPU依然只提交1次Drawcall

1
2
3
4

100棵树（同mesh，同材质，不同位置/颜色）：
  CPU：提交1次mesh + 100个transform数组
  GPU：自己 instance 100次
  结果：SetPass × 1，Draw Call × 1

对称加密

对称加密是指加密和解密使用同一个密钥。加密方和解密方必须共享同一个秘密密钥。

• 建立安全通道后，用于实际的数据传输。
• 常见的算法有 AES、DES、3DES、Blowfish、ChaCha20。

优点：

• 速度快，适合加密大量 HTTP 请求和响应内容。
• 算法实现简单。

缺点：

• 密钥分发困难：如何安全地把密钥传给对方。
• 一旦密钥泄露，所有通信都被破解。

非对称加密

非对称加密使用一对密钥：公钥和私钥。公钥公开给所有人，私钥保存在自己手里，主要用于“身份验证”和“密钥交换”。
用公钥加密的数据只能用对应的私钥解密。用私钥签名的数据可以用对应的公钥验证。

• 服务器把自己的公钥包含在证书中公开给客户端
• 客户端用服务器公钥加密一个随机对称密钥
• 服务器用自己的私钥解密，得到同一个对称密钥
• 这一阶段常见的协议是 TLS 中的 RSA、ECC（椭圆曲线加密）、DH、ECDH 等

优点：

• 解决了密钥分发问题，公钥可以公开发布。
• 支持数字签名，保证身份与完整性。

缺点：

• 计算速度比对称加密慢很多。
• 只适合加密短数据或用于密钥交换。

HTTPS

HTTPS 是 HTTP 的安全版本，它在 HTTP 之上加了一层加密协议，常用的是 TLS（以前叫 SSL）。
HTTPS = HTTP + TLS -> 浏览器访问 https:// 时，实际上是在用 SSL/TLS 加密 HTTP 请求和响应。

服务器把它的公钥公开给客户端，通常通过证书发送给浏览器。
客户端用服务器的公钥来加密会话密钥或验证服务器签名。
服务器用自己的私钥来解密或签名。

HTTPS 常见场景：

0. 客户端发起请求：浏览器访问 https://example.com
   • 服务器有一对长期密钥：公钥 + 私钥
1. 客户端和服务器协商使用哪种加密算法，在 TLS 握手里，客户端和服务器协商的是一个“套件”，叫做 cipher suite，它通常包括几种算法：
   • Key Exchange（密钥交换算法），例如 RSA, ECDHE, DHE
   • Authentication（身份验证算法），通常是证书签名所用的算法，如 RSA, ECDSA
   • Bulk Encryption（对称加密算法），如 AES, ChaCha20
   • MAC/Hash（消息认证/哈希算法），如 SHA256, SHA384
2. 服务器提供证书（里面有公钥）：服务器发送自己的数字证书给浏览器
3. 客户端验证证书：确认服务器身份可信
4. 建立对称加密的会话密钥：浏览器使用服务器公钥加密一个随机对称密钥
   • 客户端生成一个临时的对称会话密钥 K
   • 客户端使用服务器的公钥保护这个会话密钥
5. 用这个会话密钥加密后续数据：服务器解密出对称密钥，后续通信用对称加密进行
   • 服务器用自己的私钥解密，得到 K

TLS 和 RSA

TLS 是一个安全协议，用来保护网络通信。
RSA 是一种加密算法，可以用于密钥交换、加密和数字签名。

在 TLS 握手阶段，可以用 RSA 实现以下功能

• 证书签名：服务器证书里常常包含 RSA 公钥，CA 会对证书签名。浏览器验证证书时，实际上是验证这个 RSA 公钥。
• 身份验证：服务器用它对应的 RSA 私钥对握手数据签名，证明它是证书里的那台服务器。
• 密钥交换：早期 TLS 版本里，客户端可以用服务器的 RSA 公钥加密一个随机的“预主密钥”，服务器用私钥解密，然后再生成对称会话密钥。

RSA 可以是密钥交换算法，也可以是身份验证算法

• 证书中公钥算法
• 客户端加密“会话密钥”给服务器
• 服务器用私钥解密
  如果服务器证书使用 RSA，浏览器验证 CA 签名后，就信任该 RSA 公钥

密钥交换协议

现在大多数 TLS 连接不会直接用服务器公钥加密会话密钥，而是用“密钥交换协议”：

• 例如 ECDHE / DHE
• 客户端和服务器各自生成一个临时的公私钥对
• 通过交换各自的临时公钥，计算出共同的会话密钥 K
• 这些临时密钥不是长期身份密钥，连接结束就废弃

所以：

• 服务器仍然有长期身份密钥对
• 客户端通常不需要长期身份密钥对
• 客户端确实会使用临时密钥材料来协商 K

CA 和证书

证书：绑定公钥与身份，并由 CA 签名证明其可信
CA：受信任第三方，负责签发与验证证书，保证客户端不会误信伪造服务器

证书是一个文件，它相当于“公钥的身份证明”，包含：

• 持有者身份（如域名 example.com）
• 持有者公钥
• 证书颁发机构（CA）签名
• 有效期、用途等信息

CA（证书颁发机构）是一个受信任的第三方机构：

• 它负责验证申请者身份、签发证书
• 浏览器和操作系统预装了大量受信任 CA 根证书

当浏览器收到服务器证书时，它会：

1. 检查证书是否由受信任 CA 签发
2. 检查证书是否针对当前域名
3. 检查证书是否在有效期内
4. 检查证书是否被撤销
   如果验证通过，浏览器就信任该服务器公钥是真的属于这个服务器
   这样客户端就能安全地用该公钥加密会话密钥，避免被中间人伪造

服务器证书通常不是直接由根 CA 签发，而是由中间 CA 签发
浏览器通过证书链一路验证到根 CA，只有链条完整、签名有效，才被认定为可信服务器

在面试中回答这个问题，建议从宏观的系统层面和微观的渲染层面两个维度来展开，并重点围绕“CPU瓶颈”与“GPU瓶颈”这两个核心概念来阐述。

系统层面

CPU与逻辑优化（解决主线程阻塞）

减少DrawCall（绘制调用）

• 这是最常见的优化点。通过静态合批（合并静态场景）、动态合批（合并同材质小模型）以及GPU Instancing（大量重复物体如草丛、子弹的实例化渲染）来大幅降低CPU向GPU发送指令的次数。

预加载

• 预加载常用的资源，比如场景中的静态资源、UI 资源、音效资源等等。
• 在场景加载阶段（Loading 界面）预先实例化核心 UI 并隐藏（SetActive(false)），这属于将提前初始化，而非延迟初始化，适合高频使用的核心界面。

异步处理与分帧加载 (Time-Slicing)

• 避免在每一帧（Update）中执行大量计算。将路径寻路、AI决策等耗时逻辑拆分到多帧执行，或者放入异步线程/WebWorker中，防止阻塞主线程导致卡顿。
• 对于包含大量子元素的列表（如背包系统），不要在同一帧初始化所有项。可以使用协程（Coroutine）每帧只初始化 2-3 个元素，避免单帧计算过载导致的掉帧。

物理与AI精简

• 关闭远处或视野外物体的物理碰撞检测和AI逻辑，只计算玩家周边的关键交互。

内存优化（杜绝泄漏与峰值溢出）

对象池

• 对象池可以提高对象创建和销毁的效率，因为对象池中的对象可以重复使用，从而避免了创建和销毁对象的开销。
• 延迟初始化后，不使用的 UI 不要直接 Destroy，而是放入对象池中。下次需要时，直接从池中取出并重新初始化，这比反复 Instantiate 性能更高。

延迟初始化

• 采用按需加载/Lazy Initialization的思路，在运行时加载需要的资源，而不是在编译时加载所有的资源。
• 仅在 UI 界面真正需要显示时，才调用 Instantiate 创建对象或从对象池中取出。

资源管理与按需加载

• 将资源采用高压缩率格式压缩，例如LZ4HC (用打包时间换空间)
• 大世界采用流式加载，只加载玩家周围一定范围内的资源；切换场景或退出副本时，强制卸载无用资源并释放内存。

网络与IO优化

协议压缩

• 使用 Protobuf 等二进制协议替代 JSON/XML，大幅减小数据包体积，解析速度更快。
• Protobuf 是基于预定义协议（契约），在“对象”和“二进制字节数组”之间进行高效、双向转换的通信标准
• Protobuf 按照提前写好的 .proto 协议文件（也就是双方约定好的“契约”），通过字段编号、数据类型等规则，进行极其精简的二进制编码。

数据差分同步

• 状态同步时只发送变化的数据（如位置偏移量、血量变化），而不是发送全量数据。

渲染层面

渲染优化的核心是减轻GPU的压力，核心指标是降低 Overdraw（过度绘制）和 FillRate（填充率）的消耗。

UI画布

动静分离

• 将频繁更新的动态 UI 与不常变动的静态 UI 拆分到不同的 Canvas 中，因为每次UI更新都会触发 Canvas 的重建。
• 这样当动态 UI 延迟加载并触发重建（Rebuild）时，不会影响到静态 Canvas 的性能。

降低 Overdraw（过度绘制）

• 控制透明层叠加：透明物体（如特效、粒子、UI流光）是 Overdraw 的重灾区。严格限制透明层的叠加数量（通常不超过2层），远距离的特效直接降低分辨率或关闭。
• 遮挡剔除（Occlusion Culling）：开启引擎的遮挡剔除功能，被墙体等物体完全挡住的物体直接不参与渲染。
• 分层渲染：将UI、场景、角色、特效划分不同的渲染层级，透明与不透明物体严格分离。

避免 Layout Group 重建

• 瞬间加载大量元素到含有 VerticalLayoutGroup 的父物体时，会导致剧烈的 Layout 重建。
• 可以先禁用 Layout 组件，等所有元素加载完毕后，使用 LayoutRebuilder.ForceRebuildLayoutImmediate 一次性刷新。

模型与纹理优化

LOD（多细节层次）

• 根据物体距离摄像机的远近，自动切换不同精度的模型。远处的物体使用低模（面数少），近处使用高模。

纹理压缩与格式选择

• 使用 GPU 友好的压缩格式（如 ASTC、ETC2、BC7），在保证画质的前提下大幅降低显存占用和带宽压力。

Shader（着色器）轻量化

简化光照计算

• 移动端尽量避免复杂的光照模型、实时阴影和高光反射。

减少分支指令

• Fragment Shader（片元着色器）中的 if/else 分支会严重影响GPU并行计算效率，尽量用数学运算替代逻辑分支。

性能分析工具

• 优化不能靠猜，必须依赖工具。
• 常用的有 Unity 的 Profiler / Frame Debugger，或者第三方的 RenderDoc、Snapdragon Profiler。
• 通过这些工具可以精准定位到当前帧的瓶颈是在 CPU（如 DrawCall 过高）还是 GPU（如 Overdraw 严重或 Shader 过于复杂），从而进行针对性的优化。

CPU-GPU 交互流程

关注点：CPU 如何告诉 GPU “要画什么”？这决定了代码架构和内存管理方式。

立刻渲染模式（Immediate Mode）

每一帧都在 Update 或 OnGUI 里写 DrawButton()，简单直观，但如果物体多，CPU 喊口令会累死。

工作原理

• 核心在于“每帧重新绘制”，无需保存图形对象的复杂状态
• 它具有简单直接、易于动态更新的优点，但因缺乏对象层级的记录，CPU负载通常较高
• 每次调用绘制命令（如 glDrawArrays、DrawPrimitive），GPU 就立即执行渲染，结果直接写入帧缓冲区。

执行流程

1

绘制物体A → 立即渲染A → 绘制物体B → 立即渲染B → 绘制物体C → 立即渲染C

特点

1. 无状态管理 - 每次绘制独立，不保存场景信息
2. 实时响应 - 调用即渲染，适合简单场景
3. 内存占用小 - 不需要额外的场景数据结构

保留模式（Retained Mode）

创建一个 GameObject 或 DOM 节点，之后除非它变了，否则你不用管它，内存占用高（要存菜单），但 CPU 负担轻，库会帮你自动优化。

工作原理

• 与立刻模式相对的渲染模式，其核心逻辑是“由图形库管理场景”
• 在这种模式下，应用程序通过构建一个场景模型（如对象树或场景图）来告诉库“要画什么”，然后库会负责具体的绘制细节、状态维护和按需重绘
  • 例如在Unity中，场景模型就是对象树，对象树中的每个对象都包含着对象模型（如Mesh）、材质（如Shader）、变换矩阵等信息

执行流程

1

构建场景图 → 提交给引擎 → 引擎优化（剔除、排序、批处理）→ 统一渲染

特点

1. 层次化管理 - 通过场景图管理物体关系
2. 自动优化 - 视锥剔除、遮挡剔除、状态排序
3. 延迟执行 - 可以批量处理多个绘制调用，适合大型场景的优化

渲染路径

GPU 收到命令后，“具体怎么算光影”？这决定了显卡的计算逻辑和画面表现。

前向渲染（Forward Rendering）

Unity URP 默认使用的是前向渲染
拿一个零件（物体），直接打磨、上色、抛光（算所有光照），彻底做完再拿下一个零件。
但如果零件受 10 盏灯照，每个零件都要算 10 遍，灯多了会慢。

工作原理

• 图形学中最传统、最基础的渲染路径。
• 它的核心逻辑是“遍历物体，直接着色”：针对场景中的每一个几何物体，依次进行顶点变换、光栅化，并直接在像素着色器中计算所有相关的光照效果，最后输出到屏幕缓冲区。

单 Pass 方式

• 一次绘制计算所有光照
• 光源数量有限（通常 4-8 个）
• 性能随光源线性下降

多 Pass 方式

1
2
3
4

Pass 1: 渲染物体 + 主光源
Pass 2: 添加光源1贡献（混合）
Pass 3: 添加光源2贡献（混合）
...

特点

1. 直接计算 - 几何和光照同时处理，适合光源较少的场景
2. 透明物体友好 - 天然支持透明度排序
3. MSAA 原生支持 - 多重采样抗锯齿直接可用

延迟渲染（Deferred Rendering / Deferred Shading）

Unity HDRP 默认使用延迟渲染
第一批人先给零件分类（记录位置、颜色到 G-Buffer）。第二批人最后统一刷漆（对着 G-Buffer 统一算光照）。
不怕灯多，适合 PC 大作；但费内存（G-Buffer 很大），且处理不了半透明物体。

工作原理

它的核心理念是“先记录信息，最后统一算光照”，流程分为以下两个阶段：

1. 几何处理阶段 (Geometry Pass)：将场景中的每个物体进行顶点变换、光栅化，并记录所有相关的几何信息（如位置、法线、漫反射颜色、粗糙度等），将物体的几何属性存储在一组被称为 G-Buffer (Geometry Buffer) 的高带宽纹理中
2. 光照处理阶段 (Lighting Pass)：将G-Buffer里的记录的光照信息进行计算，针对屏幕上的每个像素统一计算最终的光照效果并输出到屏幕缓冲区。

几何 Pass

1
2
3

对于每个物体：
    只写入几何信息到 G-Buffer
    不计算任何光照

光照 Pass

1
2
3
4

对于每个像素：
    从 G-Buffer 读取几何信息
    计算所有光照贡献
    输出最终颜色

G-Buffer 结构

1
2
3
4

RT0: RGB = Albedo颜色       A = Metallic
RT1: RGB = 法线             A = Roughness
RT2: RGB = 自发光           A = AO
RT3: RGB = 世界坐标/深度

每个渲染目标（RT）有 4 个通道：R、G、B、A

RT0: 基础材质属性

1
2
3
4
5
6
7
8
9
10
11
12
13

┌─────────────────────────────────────────────┐
│  R        G        B        A               │
│  Albedo.r  Albedo.g  Albedo.b  Metallic     │
└─────────────────────────────────────────────┘

RGB (Albedo): 物体的基础颜色（漫反射颜色）
- 例如：红色物体 → (1.0, 0.0, 0.0)
- 从纹理采样得到

A (Metallic): 金属度 (0.0 ~ 1.0)
- 0.0 = 非金属（电介质）：塑料、木材、布料
- 1.0 = 金属：金、银、铜
- 影响高光和反射计算方式

RT1: 表面细节属性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

┌─────────────────────────────────────────────┐
│  R        G        B        A               │
│  Normal.r  Normal.g  Normal.b  Roughness    │
└─────────────────────────────────────────────┘

RGB (Normal): 世界空间法线向量
- 表示表面朝向
- 单位向量，范围 [-1, 1] 映射到 [0, 1]
- 例如：(0, 1, 0) = 表面朝上
- 用于光照计算（漫反射、高光）

A (Roughness): 粗糙度 (0.0 ~ 1.0)
- 0.0 = 光滑表面：镜子、水面（清晰反射）
- 1.0 = 粗糙表面：混凝土、沙石（模糊高光）
- 控制高光的锐利程度

RT2: 发光与环境光遮蔽

1
2
3
4
5
6
7
8
9
10
11
12
13
14

┌─────────────────────────────────────────────┐
│  R        G        B        A               │
│  Emissive.r Emissive.g Emissive.b AO        │
└─────────────────────────────────────────────┘

RGB (Emissive): 自发光颜色
- 物体自身发出的光
- 例如：霓虹灯、LED、发光材质
- 不受光照影响，直接叠加到最终颜色

A (AO - Ambient Occlusion): 环境光遮蔽 (0.0 ~ 1.0)
- 0.0 = 完全遮蔽（角落、缝隙）
- 1.0 = 无遮蔽（暴露表面）
- 模拟缝隙中的阴影，增加真实感

RT3: 深度/位置信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14

┌─────────────────────────────────────────────┐
│  R        G        B        A               │
│  Position.r Position.g Position.b Depth     │
│         或仅使用 Depth 作为单通道              │
└─────────────────────────────────────────────┘

RGB (World Position): 世界坐标
- 像素在世界空间中的 XYZ 位置
- 或者从深度值重建位置（节省显存）

A (Depth): 深度值
- 像素到相机的距离
- 用于重建世界坐标
- 用于后处理效果（雾、景深）

特点

1. 解耦几何与光照 - 几何阶段只处理位置、法线等
2. 光照与物体数无关 - 光照计算只针对可见像素
3. 需要大量显存 - G-Buffer 占用显著

延迟渲染为什么处理不了半透明物体

1. G-Buffer 只能存储“最前面”的信息
   延迟渲染的第一步是把物体的几何信息（颜色、法线、深度等）存入 G-Buffer。
   硬件限制：对于屏幕上的每一个像素，G-Buffer 通常只能存储一个物体的属性。
   信息丢失：当你画一个半透明物体（如玻璃）时，G-Buffer 会记录玻璃的信息。但半透明物体的本质是让你看到它后面的东西。延迟渲染无法在一个像素位置同时存下“玻璃”和“玻璃后的墙”这两层信息。

2. 混合（Blending）需要“即时颜色”
   在前向渲染中，当你画半透明物体时，背景已经画好了。你可以直接把玻璃的颜色和背景颜色按比例混合（Alpha Blending）。
   在延迟渲染中，第一步根本不计算颜色，只存原始数据。到了第二步统一算光照时，由于 G-Buffer 里只有最前面的玻璃数据，后台已经没有“被挡住的物体”的数据了，因此无法进行物理上正确的混合计算。

3. 排序难题
   半透明物体必须遵循从后往前的顺序绘制，才能得到正确的视觉叠加效果。
   延迟渲染的初衷是“不关心顺序”，它通过深度测试只保留最前面的像素来优化性能。这与半透明物体需要的“多层有序叠加”逻辑完全冲突。

行业通用的解决方案：混合模式 (Hybrid Rendering)
为了解决这个问题，现代引擎（如 Unity 和 Unreal）通常采用混合方案：

1. 先用延迟渲染：画完场景中所有的不透明物体。
2. 再用前向渲染：在已经算好光照的底图上，再用前向渲染的方式按照从后往前的顺序，把半透明物体“贴”上去。

帧缓冲内存与瓦片渲染(Tile-Based Rendering)

TBR 是一种 GPU 渲染架构 / 帧缓冲处理方式，通过把屏幕划分为小瓦片来组织光栅化和帧缓冲访问。

• TBR 关注的是：GPU 如何在底层处理像素、深度、缓存和内存带宽。
• Retained mode 关注的是：应用如何描述场景，谁负责保存和管理可渲染对象。
• TBR 可以支持 retained mode 的渲染引擎，也可以支持 immediate mode 的渲染流。

IMR：Immediate Mode Rendering

• 定义：每次 API 提交一个三角形，就马上开始光栅化并写入颜色/深度缓冲。
• 特点：渲染顺序与三角形提交顺序一致。
• 问题：
  • 读写帧缓冲和深度缓冲时，内存访问非常分散、不可预测。
  • 重叠像素（overdraw）会被重复计算、重复写回。
  • 即使有缓存，缓存命中率也会因为几何提交顺序和屏幕空间不一致而低。

内存带宽消耗问题

• 传统 IMR 中，三角形按提交顺序处理，导致帧缓冲访问顺序混乱。
• 如果缓存行是线性排列，渲染过程会频繁加载/写回不同位置的数据，导致大量内存带宽浪费。
• 帧缓冲是按屏幕坐标组织的二维像素网格。未压缩情况下，内存里通常按行优先存储：
  • 一行像素连续
  • 不同行之间的像素不连续 -> 屏幕上的垂直相邻像素在内存中不连续
  • 如果缓存行也是“线性排列”，它就只覆盖一段连续内存，而不是一个二维小块。

Tiled Memory（瓦片化内存）

• 核心思想：把帧缓冲按“瓦片”切成多个小二维区域。
• 缓存行不再是线性像素序列，而是覆盖一个小矩形区域。
• 好处：
  • 空间局部性更好：同一瓦片内的像素更可能连续访问。
  • 缓存命中率增加。
  • 可在片上缓存内完成更多渲染操作，减少外部内存访问。

这一步是 TBR 的基础：把大帧缓冲拆成可控的小块，减少外存读写。

Rasterizing within tiles（瓦片内光栅化）

• 进一步优化：不再按照三角形整体顺序光栅化，而是先完成一个瓦片内三角形所有像素，再处理下一个瓦片。
• 一个大三角形跨多个瓦片时，会被分成多段，每段在对应瓦片处理。这样可以避免大三角形跨多瓦片时频繁换入换出缓存。
• 同一个三角形的几何信息被重用多次，但每次只处理与当前瓦片相交的部分。
  这就是“先处理瓦片，再处理三角形”的思路。

Binning（几何分箱）

• 在 TBR 中，提交几何体时并不马上光栅化。
• 先进行“分箱”：将三角形归类到它可能覆盖的瓦片中。
• 这一过程需要顶点处理来确定三角形屏幕位置，但不涉及片段着色。这样后续光栅化阶段只需按瓦片读取对应几何列表。
  Binning 是把“几何”和“像素”分离，先用几何决定哪些瓦片受影响，再按瓦片单独渲染。

Tile-based rasterization（基于瓦片的光栅化）

• 处理方式：逐瓦片渲染，每个瓦片在片上缓存中独立完成。
• 帧缓冲和深度缓冲只在瓦片处理完后写回一次。
• 优势：
  • 外部内存访问减少到“每个瓦片一次写回”。
  • 深度缓存可直接在片上使用，甚至不必写回主存。
  • 清除操作也可在瓦片内完成。
    这正是移动 GPU 的核心高效方案：把对外内存的数据流降到最低。

深度缓冲（Z-buffer）

• 每个像素位置有一个深度值
• 这个深度值表示该像素处距相机最近的物体的深度
• 光栅化三角形时，逐像素进行深度测试：
  • 读取该像素在深度缓冲中的当前深度值
  • 与新三角形在该像素的深度比较，如果新三角形更近，更新该像素的深度值和颜色
• 一个像素可能被多个三角形覆盖（overdraw），但深度缓冲只保留最近的那个三角形的深度值。

MultiSampling AA（多重采样反锯齿）

• 在瓦片渲染中，多重采样可以在片上缓存里完成采样和 resolve。
• 传统 IMR：多采样需要读写高分辨率帧缓冲（每个像素多个样本），带宽消耗巨大
• 多采样在瓦片缓存内完成（片上内存），只在最后 resolve（合并样本）时写回外部内存。外部内存只存储最终低分辨率结果，带宽大幅降低。
• 瓦片缓存（片上内存）允许在本地处理高频读写操作，只在瓦片完成时与外部内存交互一次，从而把昂贵的带宽开销控制在可控范围内

Deferred shading 与 TBR

• 传统延迟渲染需要先写入多个 G-buffer，再重新读取进行光照，带宽消耗大。
• 如果在瓦片内完成延迟渲染，则：
  • G-buffer 数据可保留在片上缓存，光照计算直接在瓦片缓存上进行
  • 最终只写出渲染结果，减少外部内存读写
  • 带宽成本与普通渲染相当
    这说明“TBDR”（Tile-Based Deferred Rendering）特别适合移动端延迟渲染场景。

G-buffer 和 瓦片缓存

1. 光照数据（光源参数，如位置、颜色、强度）是 CPU 在应用阶段通过 uniform 变量或缓冲区传给 GPU 的
2. GPU 渲染几何到 G-buffer
   • 顶点着色器负责把模型空间变换到屏幕空间（通过 MVP 矩阵）
   • 片段着色器计算每个像素的几何信息（如位置、法线、颜色），并写入 G-buffer

延迟渲染流程：

• 几何阶段：光栅化 + 片段着色 → 写入 G-buffer（存储几何信息，如位置、法线）。
• 光照阶段：使用 G-buffer 数据进行光照计算 → 输出最终颜色。

TBDR：

• 第一阶段：几何分箱 → 按瓦片光栅化 → 片段着色 → G-buffer 数据留在瓦片缓存（不写回外部内存）。
• 第二阶段：瓦片缓存直接使用这些 G-buffer 数据进行光照计算（无需读取外部 G-buffer）。

TBR 的优势

• 大幅降低帧缓冲带宽。
• 降低功耗、提高渲染速度。
• 移动端共享内存、带宽贵，TBR 是最优方案。
• 对纹理访问也有好处：一次处理一个瓦片，纹理访问局部性增强。
• 相比通用帧缓冲缓存，TBR 需要更少片上缓存空间。

TBR 的限制

• 引入渲染延迟：必须先 binning 再 rasterize。
• 需要双缓冲以避免流水线停顿。
• 对需要全局帧缓冲读取的功能不友好，如屏幕空间光线追踪、某些后处理。
• 几何分箱本身也有成本，顶点着色器瓶颈场景可能受限。
• 切换渲染目标、频繁读写 framebuffer 会迫使瓦片数据 flush。

总结

• 传统 IMR 带宽和功耗太高；瓦片渲染通过“先分箱、后按瓦片渲染”把大帧缓冲操作压缩到片上缓存
• 这对移动 GPU 极为关键，且现代 API（如 Vulkan Subpasses、OpenGL ES Pixel Local Storage）都开始支持这种模式
• 对于多采样和延迟渲染，瓦片化处理能把原本非常昂贵的带宽开销降到可控范围
• 然而瓦片化也有规则和限制，开发者要避免频繁 framebuffer 读写、避免不适合的渲染模式

Credits

https://blog.csdn.net/weixin_70073176/article/details/141165074

Unity 的粒子特效主要基于内置的 Particle System 组件。它适合创建火焰、烟雾、爆炸、雪花、魔法光效等视觉效果。
粒子系统通过一组不断生成、模拟、渲染的“粒子”来表现复杂的视觉效果，而不需要为每一个物体写单独的网格。

粒子系统的核心概念

• Emitter（发射器）：粒子从何处发射，通常由发射形状（Shape）决定。
• Lifetime（寿命）：每个粒子存在的时间。
• Velocity（速度）：粒子运动方向与速度。
• Size / Color over Lifetime：粒子在生命周期中大小和颜色的变化。
• Emission Rate（发射率）：每秒生成粒子数量。
• Renderer：粒子最终如何绘制，常见为 Billboard、Mesh、Stretch Billboard。

Unity 粒子系统常用模块

• Emission：控制发射速率、爆发次数。
• Shape：控制粒子发射区域，如 Sphere、Cone、Box 等。
• Velocity over Lifetime：设置粒子在生命周期内的速度变化。
• Color over Lifetime：设置颜色渐变。
• Size over Lifetime：控制大小随时间变化。
• Rotation over Lifetime：控制粒子旋转。
• Noise：添加噪声让粒子运动更自然。
• Collision：让粒子与世界碰撞。

混合代码与粒子系统使用方式

粒子系统通常由编辑器配置，但也可以通过脚本动态控制。下面是一个常见的代码用例：创建、配置并触发粒子效果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

using UnityEngine;

public class ParticleEffectSpawner : MonoBehaviour
{
    // `ParticleSystem` 组件可直接挂在预制体上，脚本通过 `Instantiate` 生成实例。
    public ParticleSystem particlePrefab;

    void Start()
    {
        if (particlePrefab == null)
        {
            Debug.LogWarning("请在 Inspector 中指定 particlePrefab");
            return;
        }
    }

    public void SpawnEffect(Vector3 position)
    {
        var instance = Instantiate(particlePrefab, position, Quaternion.identity);

        // `main`、`emission`、`shape` 等模块都可以在运行时通过脚本访问。
        var main = instance.main;
        main.startLifetime = 1.5f;
        main.startSpeed = 4f;
        main.startSize = 0.8f;
        main.startColor = Color.cyan;

        var emission = instance.emission;
        emission.rateOverTime = 100f;

        var shape = instance.shape;
        shape.shapeType = ParticleSystemShapeType.Cone;
        shape.angle = 20f;
        shape.radius = 0.5f;

        instance.Play();

        // `Destroy` 用于清理粒子对象，避免特效结束后残留内存。
        Destroy(instance.gameObject, main.startLifetime.constant + 0.5f);
    }
}

运行时参数控制示例

通过脚本修改粒子参数，可以实现不同风格的特效，例如爆炸效果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public void Explode(Vector3 position)
{
    var instance = Instantiate(particlePrefab, position, Quaternion.identity);
    var main = instance.main;
    main.startLifetime = 0.8f;
    main.startSpeed = 10f;
    main.startSize = 1.5f;
    main.startColor = new Color(1f, 0.5f, 0.1f);

    var emission = instance.emission;
    emission.rateOverTime = 0f;
    emission.SetBurst(0, new ParticleSystem.Burst(0f, 50, 80));

    var shape = instance.shape;
    shape.shapeType = ParticleSystemShapeType.Sphere;
    shape.radius = 0.3f;

    instance.Play();
    Destroy(instance.gameObject, main.startLifetime.constant + 0.5f);
}

与 Shader 的区别

Unity 粒子特效通常由 Particle System 来驱动整体行为，而 Shader 决定粒子的最终视觉表现。
两者搭配使用，既可以快速构建特效逻辑，也能在渲染上实现更加细腻的视觉结果。

粒子系统和 Shader 的职责不同

• Particle System：负责粒子的生成、生命周期、位置、速度、发射、碰撞、颜色和大小变化等整体行为。
• Shader：负责单个粒子的最终渲染效果，如纹理、颜色混合、透明度、光照、动画遮罩等。

粒子系统通常使用内置或自定义材质，材质中可以包含 Shader。也就是说，粒子系统负责“做出粒子”，Shader 负责“怎么画粒子”。

使用场景差异

• 粒子系统适合快速搭建常见特效、控制复杂行为、在编辑器中调整参数。
• Shader 适合实现特效的渲染细节，如渐隐、闪烁、扫描、光晕与特殊混合模式。

例如：你可以让 Particle System 负责生成烟雾粒子，而使用 Unlit 或 Additive Shader 实现在透明面上绘制柔和、发光的烟雾纹理。

性能与复杂度

• Particle System 自身封装了大量行为，适合面向特效设计师快速迭代。
• Shader 则在 GPU 上运行、效率更高，但需要编写渲染代码，对每个像素/顶点进行控制。

如果希望增强粒子表现，可以结合 Shader Graph 或自定义 Shader，使粒子面具备“流动光晕”、“波动边缘”、“复杂透明度曲线”等效果。

结合 Shader 的粒子效果

一个常见做法是：

1. 在 Particle System 中设置材质为 Particle/Additive 或自定义粒子材质。
2. 使用纹理图集、Color over Lifetime、Size over Lifetime 调整粒子表现。
3. 在 Shader 中实现附加效果，例如渐隐、扭曲、噪声贴图 UV 变换。

自定义 Shader 示例

下面是一个简单的粒子自定义 Shader，它对粒子透明度和 UV 进行了处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

Shader "Custom/ParticleSoft"
{
    Properties
    {
        _MainTex ("Texture", 2D) = "white" {}
        _Color ("Tint", Color) = (1,1,1,1)
    }
    SubShader
    {
        Tags { "Queue"="Transparent" "RenderType"="Transparent" }
        Blend SrcAlpha One
        Cull Off
        Lighting Off
        ZWrite Off

        Pass
        {
            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag
            #include "UnityCG.cginc"

            sampler2D _MainTex;
            float4 _Color;

            struct appdata
            {
                float4 vertex : POSITION;
                float2 uv : TEXCOORD0;
                float4 color : COLOR;
            };

            struct v2f
            {
                float4 pos : SV_POSITION;
                float2 uv : TEXCOORD0;
                float4 color : COLOR;
            };

            v2f vert(appdata v)
            {
                v2f o;
                o.pos = UnityObjectToClipPos(v.vertex);
                o.uv = v.uv;
                o.color = v.color * _Color;
                return o;
            }

            fixed4 frag(v2f i) : SV_Target
            {
                fixed4 tex = tex2D(_MainTex, i.uv);
                tex.rgb *= i.color.rgb;
                tex.a *= i.color.a;
                return tex;
            }
            ENDCG
        }
    }
}

这个 Shader 只负责将粒子贴图按颜色和透明度渲染出来，而粒子系统仍然负责产生位置、速度和生命周期。

实战建议

• 先用编辑器调整粒子系统参数，确认效果后再用脚本控制动画和触发时机。
• 将复杂行为拆成多个粒子系统，如火焰、烟雾、火花分别使用不同系统组合。
• 如果粒子数量大或效果复杂，可考虑粒子 Shader 优化，例如使用 Soft Particles、GPU Instancing 或 Shader Graph。
• 当粒子需要与场景光照、阴影或深度融合时，配合自定义 Shader 和深度测试设置提高表现力。

Bleeding

纹理渗色/纹理出血，这是一种图像处理或显示技术问题，指一种颜色“溢出”到相邻像素的现象，导致颜色边界不清晰、产生伪影或颜色混杂。

Texture bleeding is when pixels from outside a sprite’s intended boundary leak into the visible edge of the sprite.

Here’s why it happens. When the GPU samples a texture, it rarely samples at an exact pixel center.
Bilinear filtering works by taking the 4 nearest pixels and blending them together based on how close the sample point is to each one.
At the very edge of a sprite, one of those 4 neighbors is outside the sprite — it could be a transparent black pixel, a pixel from another sprite in an atlas, or garbage data. That outside color gets mixed into your edge pixel, producing a fringe（边缘）.

For example:

1
2
3

[ edge pixel: orange ][ outside: transparent black (0,0,0,0) ]
                      ^
              bilinear samples here → blends orange + black = dark muddy fringe

This is exactly what you saw — the logo’s colored edge pixels were bleeding into the transparent area around it, and because the shader was Opaque, those blended semi-transparent edge pixels were written as solid color instead of being discarded.

There are three common sources of bleeding:

• Wrap Mode: Repeat — the GPU wraps around and samples the opposite edge of the texture
• Atlas packing with no padding — neighboring sprites bleed into each other
• Opaque surface type with a transparent sprite — alpha is ignored so blended edge pixels render solid

Opaque vs Transparent

The GPU renders geometry in two stages: rasterization and blending.
When Surface Type is Opaque, the blending stage is skipped entirely — the GPU writes every pixel the fragment shader touches directly to the framebuffer, alpha value be damned.
Your shader was correctly computing alpha from the texture, but the pipeline threw it away before it ever reached the screen.

The “noise” you saw was bilinear filtering. At the sprite’s edges, the sampler blends the last row/column of real pixels with whatever is just outside the sprite boundary (either transparent black rgba(0,0,0,0) or neighboring texture data).
With opaque mode, those semi-transparent edge pixels get written as fully solid, so you see that fringe of mixed color.

Use Opaque when:
The object has no see-through areas at all (terrain, walls, characters without cutouts)
Performance matters — opaque objects are rendered in a single front-to-back pass and benefit from early-z culling, which skips fragment shading on occluded pixels entirely

Use Transparent when:
The object has partial or full transparency (UI sprites, glass, particles, logos with alpha)
You need the blending stage to mix the fragment color with what’s already in the framebuffer
The cost of transparent is real — transparent objects can’t use early-z, must be sorted back-to-front, and can cause overdraw issues. So don’t default everything to transparent.

Blend Mode (within Transparent)

1
2
3
4
5
6

| Mode | Formula | Use case |
| --- | --- | --- |
| Alpha     |   src.rgb * src.a + dst.rgb * (1 - src.a) | Standard transparency, sprites, UI
| Additive  |   src.rgb * src.a + dst.rgb   |   Glows, fire, particles that should brighten
| Multiply  |	src.rgb * dst.rgb   |   Darkening effects, shadows, tinted overlays
| Premultiply |	src.rgb + dst.rgb * (1 - src.a) |   Textures with premultiplied alpha baked in

The Z-Buffer

The GPU maintains a depth buffer (z-buffer) alongside the color buffer. Every pixel stores the depth of the closest thing rendered to it so far.
When a new fragment arrives, the GPU compares its depth against what’s already in the buffer — if it’s further away, it gets discarded.

Front-to-Back Pass

For opaque objects, Unity sorts them front-to-back before drawing. So the closest objects get drawn first.

1
2
3

Camera → [Chair] → [Table] → [Wall behind]
           drawn     drawn      drawn
           first     second     third

This matters because of early-z.

Early-Z Culling

Once the chair is drawn and its depth is written to the z-buffer, when the wall fragment arrives at the same pixel, the GPU checks:

1

wall depth (5.0) > z-buffer value (1.2) → discard, skip fragment shader

It never runs the fragment shader for the wall pixel at all. This is early-z culling — rejecting fragments before the expensive shading work happens.
The savings are significant. Fragment shaders do lighting, texture sampling, math — all skipped for occluded pixels.

Why transparent objects break this

Transparent objects need to blend with what’s behind them, so they must be drawn last, back-to-front:

1

Camera → [Wall] → [Table] → [Glass in front]

The glass needs the wall already in the framebuffer to blend against it. This means:

• You can’t sort front-to-back
• Early-z culling doesn’t apply
• Every transparent fragment runs the full fragment shader regardless of what’s in front of it

That’s the real performance cost of transparency — not the blending itself, but losing early-z and the overdraw that comes with back-to-front rendering.

Trail Renderer 是 Unity 中的一个组件，用于在移动对象后面创建拖尾效果，常用于粒子轨迹、运动模糊、武器轨迹等视觉效果。

主要功能

• 轨迹生成: 基于对象位置历史记录创建连续的轨迹线条
• 材质支持: 支持自定义纹理、颜色渐变和透明度
• 宽度控制: 可设置轨迹的起始和结束宽度，支持曲线调整
• 生命周期: 可控制轨迹的生存时间和淡出效果
• 性能优化: 自动批处理，适合移动平台

自动批处理

Unity 的渲染系统会自动检测并合并使用相同材质的 Trail Renderer 组件，将多个轨迹渲染合并为单个 Draw Call。

批处理条件：

• 相同的 Material（材质）
• 相同的 Shader 变体
• 相似的渲染状态（深度测试、混合模式等）
• 轨迹顶点总数不超过批处理限制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

using UnityEngine;

public class TrailBatchOptimizer : MonoBehaviour
{
    // 为相似轨迹使用同一个 Material 实例
    [SerializeField] private Material sharedTrailMaterial;
    [SerializeField] private TrailRenderer[] trailRenderers;

    void Start()
    {
        // 确保所有轨迹使用相同材质以启用批处理
        foreach (var trail in trailRenderers)
        {
            trail.material = sharedTrailMaterial;
            
            // 优化设置
            trail.minVertexDistance = 0.1f;  // 减少顶点数量避免过度细分
            trail.time = 1.0f;               // 控制轨迹长度防止轨迹过长
            trail.widthMultiplier = 1.0f;    // 统一宽度比例
        }
    }
}

使用方法

GameObject → Add Component → Effects → Trail Renderer

• Material: 设置轨迹材质
• Width: 轨迹宽度曲线
• Color: 颜色渐变
• Lifetime: 轨迹持续时间
• Min Vertex Distance: 最小顶点距离（影响轨迹平滑度）

代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

using UnityEngine;

public class TrailController : MonoBehaviour
{
    private TrailRenderer trailRenderer;

    void Start()
    {
        trailRenderer = GetComponent<TrailRenderer>();
        
        // 设置轨迹材质
        trailRenderer.material = Resources.Load<Material>("TrailMaterial");
        
        // 设置宽度（起始0.1，结束0.5）
        trailRenderer.startWidth = 0.1f;
        trailRenderer.endWidth = 0.5f;
        
        // 设置生命周期
        trailRenderer.time = 2.0f;
        
        // 设置颜色渐变
        Gradient gradient = new Gradient();
        gradient.SetKeys(
            new GradientColorKey[] { 
                new GradientColorKey(Color.red, 0.0f), 
                new GradientColorKey(Color.yellow, 0.5f), 
                new GradientColorKey(Color.blue, 1.0f) 
            },
            new GradientAlphaKey[] { 
                new GradientAlphaKey(1.0f, 0.0f), 
                new GradientAlphaKey(1.0f, 0.8f), 
                new GradientAlphaKey(0.0f, 1.0f) 
            }
        );
        trailRenderer.colorGradient = gradient;
    }

    void Update()
    {
        // 移动对象以生成轨迹
        transform.Translate(Vector3.forward * Time.deltaTime);
    }
}

注意事项：

• Trail Renderer 需要对象持续移动才会产生轨迹
• 对于高速移动对象，可调整 Min Vertex Distance 避免轨迹断裂
• 轨迹顶点数量会影响性能，建议合理设置 Lifetime
• 支持 Texture Mode 用于更复杂的纹理映射效果

Trail Renderer 和粒子系统

Trail Renderer专门用于创建移动对象的连续拖尾轨迹，基于对象位置历史记录生成线条。
而粒子系统由发射参数控制，用于发射和管理大量离散粒子（如烟雾、火花、雨滴），每个粒子独立运动。

常见结合

• 粒子轨迹: 为粒子系统中的粒子添加 Trail Renderer，创建带拖尾的粒子效果（如流星、魔法弹道）。
• 增强效果: Trail Renderer 提供连续轨迹，粒子系统提供散射效果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

using UnityEngine;

public class ParticleTrailExample : MonoBehaviour
{
    [SerializeField] private ParticleSystem particleSystem;
    [SerializeField] private TrailRenderer trailRenderer;

    void Start()
    {
        // 为粒子系统的主发射器添加轨迹
        var main = particleSystem.main;
        main.startLifetime = 2.0f;  // 粒子生命周期
        
        // 配置轨迹
        trailRenderer.time = 1.0f;
        trailRenderer.startWidth = 0.1f;
        trailRenderer.endWidth = 0.0f;
        
        // 轨迹跟随粒子发射器移动
        trailRenderer.transform.SetParent(particleSystem.transform);
    }
}

Draw Call (绘制调用): CPU 告诉 GPU “请按照这些状态，把这个网格画出来” 的一次命令。这个命令本身有开销。Draw Call 太多，CPU 就会因为一直忙于下达指令而成为瓶颈。目标：减少 Draw Call 的总次数。
SetPass Call (状态切换调用): 在 Draw Call 之前，CPU 需要告诉 GPU 使用哪个 Shader、材质属性（颜色、贴图等）是什么。切换这些状态（特别是材质）是一个非常耗时的操作。目标：减少渲染状态的切换次数。

1
2
3
4
5
6
7

CPU 准备渲染数据
    ↓
设置渲染状态（材质、Shader、纹理绑定）← SetPass Call
    ↓
提交 DrawCall（告诉 GPU 画什么、怎么画）
    ↓
GPU 执行光栅化、着色、输出像素

关键点：DrawCall 本身消耗资源，但准备阶段（SetPass Call）通常比 DrawCall 本身更耗性能。
开启批处理后，Unity 可以用一次 SetPass Call 复用同一材质状态，然后提交多个 DrawCall。所以降低 SetPass Call 往往比降低 DrawCall 更重要。

DrawCall（绘制调用）

DrawCall 是 CPU 向 GPU 发送的一次渲染指令，包含了 GPU 绘制所需的全部信息：几何数据、纹理、Shader、Buffer 等。
CPU 先准备好数据，并通过调用图形API接口命令GPU对指定物体进行渲染一次的操作，称为一次DrawCall。

每次调用 DrawMesh、DrawRenderer 等，就是一个 Draw Call。GPU 收到命令后开始渲染对应的几何体。

当收到一个DrawCall时，GPU会按照指令，根据渲染状态和输入的顶点信息，指定一个网格（Mesh）进行渲染，绘制材质。
GPU 渲染时，同一批次的对象必须使用相同的材质和纹理。一旦纹理不同，就必须切换渲染状态，触发新的 DrawCall。

1
2
3

Image A（纹理1）→ DrawCall 1
Image B（纹理2）→ DrawCall 2（纹理不同，无法合批）
Image C（纹理1）→ 可以与 A 合批，不增加 DrawCall

为了CPU和GPU可以进行并行工作，需要一个命令缓冲区，由CPU向其中添加命令，然后由GPU从中读取命令，这样就实现了通过CPU准备数据，通知GPU进行渲染。

SetPass Call

在 Draw Call 之前，如果需要切换渲染状态（shader、材质属性、纹理等），CPU 就要先做一次 SetPass Call 来通知 GPU 切换 Pass。
SetPass Call 才是真正的性能瓶颈，因为它涉及 shader 编译、状态切换等开销。

例如场景里有 5 个物体：

1
2
3
4
5

物体A - 材质1 (Shader: Standard, 纹理: tex_a)
物体B - 材质1 (同上)
物体C - 材质1 (同上)
物体D - 材质2 (Shader: Standard, 纹理: tex_b)
物体E - 材质3 (Shader: Unlit,   纹理: tex_c)

渲染顺序：

1
2
3
4
5
6
7
8

SetPass Call → 切换到材质1
  Draw Call → 绘制物体A
  Draw Call → 绘制物体B
  Draw Call → 绘制物体C
SetPass Call → 切换到材质2
  Draw Call → 绘制物体D
SetPass Call → 切换到材质3
  Draw Call → 绘制物体E

结果：5 个 Draw Call，3 个 SetPass Call。

Pass 是什么

一个 Pass 就是 shader 里的一次完整渲染流程，包含一套完整的顶点着色器 + 片元着色器，以及对应的渲染状态（混合模式、深度测试、剔除等）。
一个材质可以有多个 Pass，每个 Pass 对同一个物体渲染一遍。

• 具体例子：描边效果
  描边通常需要两个 Pass：第一个 Pass 画描边（把模型沿法线方向放大，只渲染背面），第二个 Pass 画正常颜色。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

Shader "Custom/Outline"
{
    Properties
    {
        _Color ("Color", Color) = (1,1,1,1)
        _OutlineColor ("Outline Color", Color) = (0,0,0,1)
        _OutlineWidth ("Outline Width", Float) = 0.02
    }

    SubShader
    {
        // ---- Pass 0：描边 ----
        Pass
        {
            Name "OUTLINE"
            Cull Front  // 只渲染背面，正面被裁掉

            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag

            float _OutlineWidth;
            float4 _OutlineColor;

            struct appdata { float4 vertex : POSITION; float3 normal : NORMAL; };
            struct v2f    { float4 pos : SV_POSITION; };

            v2f vert(appdata v)
            {
                v2f o;
                // 沿法线方向把顶点往外推
                float3 expanded = v.vertex.xyz + v.normal * _OutlineWidth;
                o.pos = UnityObjectToClipPos(float4(expanded, 1));
                return o;
            }

            fixed4 frag(v2f i) : SV_Target
            {
                return _OutlineColor;  // 纯色描边
            }
            ENDCG
        }

        // ---- Pass 1：正常渲染 ----
        Pass
        {
            Name "BASE"
            Cull Back   // 只渲染正面

            CGPROGRAM
            #pragma vertex vert
            #pragma fragment frag

            float4 _Color;

            struct appdata { float4 vertex : POSITION; };
            struct v2f    { float4 pos : SV_POSITION; };

            v2f vert(appdata v)
            {
                v2f o;
                o.pos = UnityObjectToClipPos(v.vertex);
                return o;
            }

            fixed4 frag(v2f i) : SV_Target
            {
                return _Color;
            }
            ENDCG
        }
    }
}

渲染这一个物体时，GPU 会走两遍：

1
2
3
4
5

SetPass Call → 激活 Pass 0 (OUTLINE)，设置 Cull Front 状态
  Draw Call  → 用 Pass 0 的 shader 绘制物体（画出描边）

SetPass Call → 激活 Pass 1 (BASE)，设置 Cull Back 状态
  Draw Call  → 用 Pass 1 的 shader 绘制物体（画出本体）

所以 1 个物体、1 个材质，产生了 2 个 SetPass Call + 2 个 Draw Call。

Sprite Atlas 图集

把多张小纹理合并成一张大纹理，GPU 渲染时所有引用该图集的 Sprite 共享同一张纹理，满足合批条件，从而将多个 DrawCall 合并为一个。

1
2
3
4
5
6
7
8
9

未使用图集：
  Sprite A（texture_a.png）→ DrawCall 1
  Sprite B（texture_b.png）→ DrawCall 2
  Sprite C（texture_c.png）→ DrawCall 3

使用图集后：
  Sprite A ─┐
  Sprite B ─┼─ atlas.png → DrawCall 1（合批）
  Sprite C ─┘

除了减少 DrawCall，图集还有两个底层优化：

• GPU 处理 2 的幂次方尺寸的纹理效率更高，图集会自动将小图打包成符合规范的大图
• 多张小图的磁盘占用通常大于一张合并后的大图（压缩算法在大块连续数据上效率更高）

Unity中的图集有2种类型

• Master（主图集）：标准图集，包含实际资源
• Variant（变体图集）：引用主图集内容，通过 Scale 缩放生成不同分辨率版本，适合高清/低清资源切换场景

代码用例

运行时加载图集（Resources）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

using UnityEngine;
using UnityEngine.UI;
using UnityEngine.U2D;

public class AtlasLoader : MonoBehaviour
{
    [SerializeField] private Image[] _images;

    void Start()
    {
        // 从 Resources 文件夹加载图集
        SpriteAtlas atlas = Resources.Load<SpriteAtlas>("UI/MainAtlas");
        if (atlas == null)
        {
            Debug.LogError("图集加载失败，检查路径是否正确");
            return;
        }

        // GetSprite 传入的是打包时的文件名（不含扩展名）
        // Single 模式：直接传文件名，如 "icon_sword"
        // Multiple 模式（Sprite Sheet）：传 "文件名_索引"，如 "icon_sword_0"
        _images[0].sprite = atlas.GetSprite("icon_sword");
        _images[1].sprite = atlas.GetSprite("icon_shield");
        _images[2].sprite = atlas.GetSprite("icon_potion");
    }
}

从 AssetBundle 加载图集

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

using UnityEngine;
using UnityEngine.UI;
using UnityEngine.U2D;

public class AtlasFromAB : MonoBehaviour
{
    [SerializeField] private Image _targetImage;

    void Start()
    {
        string bundlePath = Application.streamingAssetsPath + "/AssetBundles/ui_atlas";
        AssetBundle bundle = AssetBundle.LoadFromFile(bundlePath);

        if (bundle == null)
        {
            Debug.LogError("AB 包加载失败");
            return;
        }

        SpriteAtlas atlas = bundle.LoadAsset<SpriteAtlas>("MainAtlas");
        _targetImage.sprite = atlas.GetSprite("icon_sword");

        // 图集资源已提取，可以卸载包体（false = 保留已加载资源）
        bundle.Unload(false);
    }
}

后期绑定（Late Binding）

当图集未勾选 Include in Build 时，必须手动监听 atlasRequested 事件，否则引用该图集的 Sprite 会显示为空白。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

using UnityEngine;
using UnityEngine.U2D;
using System;

// 挂载到场景中持久存在的对象上（如 GameManager）
public class AtlasLateBinding : MonoBehaviour
{
    void OnEnable()
    {
        // 注册图集请求事件
        SpriteAtlasManager.atlasRequested += OnAtlasRequested;
        // 可选：图集注册完成后的回调
        SpriteAtlasManager.atlasRegistered += OnAtlasRegistered;
    }

    void OnDisable()
    {
        SpriteAtlasManager.atlasRequested -= OnAtlasRequested;
        SpriteAtlasManager.atlasRegistered -= OnAtlasRegistered;
    }

    // Unity 找不到图集时触发，atlasName 是图集名称
    private void OnAtlasRequested(string atlasName, Action<SpriteAtlas> callback)
    {
        Debug.Log($"请求图集: {atlasName}");

        // 从 Resources 加载（也可以换成 AB 包加载）
        SpriteAtlas atlas = Resources.Load<SpriteAtlas>(atlasName);

        if (atlas != null)
            callback(atlas); // 把图集交还给 Unity
        else
            Debug.LogError($"找不到图集: {atlasName}");
    }

    private void OnAtlasRegistered(SpriteAtlas atlas)
    {
        Debug.Log($"图集已注册: {atlas.name}");
    }
}

Editor 工具：自动打包图集

这个工具会遍历指定目录，按文件夹自动创建并更新图集，适合团队统一管理图集资源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108

// 必须放在 Editor 文件夹下
using System;
using System.Collections.Generic;
using System.IO;
using UnityEditor;
using UnityEditor.U2D;
using UnityEngine;
using UnityEngine.U2D;
using Object = UnityEngine.Object;

public class SpriteAtlasBuilder
{
    // 需要打包的图片根目录（每个子文件夹对应一个图集）
    private static readonly string SourceRoot = Application.dataPath + "/Art/Sprites/";
    // 图集输出目录
    private static readonly string OutputPath = "Assets/Art/Atlases/";

    [MenuItem("Tools/Build Sprite Atlases")]
    public static void BuildAll()
    {
        if (!Directory.Exists(SourceRoot))
        {
            Debug.LogError($"源目录不存在: {SourceRoot}");
            return;
        }

        Directory.CreateDirectory(OutputPath.Replace("Assets/", Application.dataPath + "/").Replace("Assets", ""));

        var dirs = new DirectoryInfo(SourceRoot).GetDirectories();
        for (int i = 0; i < dirs.Length; i++)
        {
            var dir = dirs[i];
            EditorUtility.DisplayProgressBar("打包图集", $"处理: {dir.Name}", (float)i / dirs.Length);

            string atlasPath = OutputPath + dir.Name + ".spriteatlas";
            SpriteAtlas atlas = AssetDatabase.LoadAssetAtPath<SpriteAtlas>(atlasPath)
                                ?? CreateAtlas(atlasPath);

            UpdateAtlasContent(atlas, SourceRoot + dir.Name);
        }

        EditorUtility.ClearProgressBar();
        AssetDatabase.SaveAssets();
        AssetDatabase.Refresh();
        Debug.Log("图集打包完成");
    }

    private static SpriteAtlas CreateAtlas(string savePath)
    {
        var atlas = new SpriteAtlas();

        // 基础打包设置
        atlas.SetPackingSettings(new SpriteAtlasPackingSettings
        {
            blockOffset = 1,
            enableRotation = false,    // 禁止旋转，避免 UI 显示异常
            enableTightPacking = false, // 禁止紧密排列，避免图片边缘互相干扰
            padding = 4,
        });

        // 纹理设置
        atlas.SetTextureSettings(new SpriteAtlasTextureSettings
        {
            readable = false,
            generateMipMaps = false,
            sRGB = true,
            filterMode = FilterMode.Bilinear,
        });

        // Android 平台压缩格式
        var androidSettings = atlas.GetPlatformSettings("Android");
        androidSettings.overridden = true;
        androidSettings.maxTextureSize = 2048;
        androidSettings.format = TextureImporterFormat.ASTC_6x6;
        atlas.SetPlatformSettings(androidSettings);

        // iOS 平台压缩格式
        var iosSettings = atlas.GetPlatformSettings("iPhone");
        iosSettings.overridden = true;
        iosSettings.maxTextureSize = 2048;
        iosSettings.format = TextureImporterFormat.PVRTC_RGB4;
        atlas.SetPlatformSettings(iosSettings);

        AssetDatabase.CreateAsset(atlas, savePath);
        return atlas;
    }

    private static void UpdateAtlasContent(SpriteAtlas atlas, string folderPath)
    {
        var existing = new HashSet<Object>(atlas.GetPackables());
        var toAdd = new List<Object>();

        foreach (var file in Directory.GetFiles(folderPath, "*", SearchOption.AllDirectories))
        {
            if (!file.EndsWith(".png") && !file.EndsWith(".jpg")) continue;

            // 转换为相对于 Assets 的路径
            string relativePath = "Assets" + file.Replace(Application.dataPath, "").Replace("\\", "/");
            var obj = AssetDatabase.LoadAssetAtPath<Object>(relativePath);

            if (obj != null && !existing.Contains(obj))
                toAdd.Add(obj);
        }

        if (toAdd.Count > 0)
            atlas.Add(toAdd.ToArray());
    }
}

运行时动态检查 DrawCall（调试用）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#if UNITY_EDITOR
using UnityEngine;
using UnityEngine.Profiling;

// 挂到场景中，运行时在 Console 输出当前帧的渲染统计
public class DrawCallMonitor : MonoBehaviour
{
    void Update()
    {
        // 需要在 Editor 的 Stats 面板查看，或通过 Profiler API
        // UnityStats 仅在编辑器下可用
        if (Time.frameCount % 60 == 0) // 每 60 帧输出一次
        {
            Debug.Log($"[渲染统计] 帧: {Time.frameCount} | " +
                      $"已分配内存: {Profiler.GetTotalAllocatedMemoryLong() / 1024 / 1024} MB");
        }
    }
}
#endif

注意事项与最佳实践

内存陷阱

图集中只要有一个 Sprite 被引用，整张图集纹理都会加载进内存。所以图集的划分策略很关键：

• 按功能模块划分（登录界面、大厅界面、战斗界面各一个图集）
• 避免把低频资源和高频资源放在同一图集
• 单个图集不要超过 2048×2048，超出部分 Unity 会自动忽略 MaxTextureSize 设置

合批失效的常见原因：

• 两个 Sprite 来自不同图集
• 中间插入了使用不同材质的对象（打断批次）
• 开启了 Tight Packing 导致 UV 计算异常

Sprite Atlas 和 Drawcall

Atlas 本身不减少 Draw Call，它是让 batching 成为可能的前提条件。

Sprite Atlas

图集解决的是纹理问题，把多张小图合并成一张大图。
原来每个 sprite 用不同纹理 → 不同材质 → 每次渲染都要 SetPass Call 切换。合并后所有 sprite 共享同一张纹理 → 同一个材质 → 为后续 batching 创造条件。

1
2
3
4
5
6
7
8
9

没有图集：
  图标A (tex_a) → SetPass → Draw
  图标B (tex_b) → SetPass → Draw   ← 纹理不同，必须切换
  图标C (tex_c) → SetPass → Draw

有图集：
  图标A (atlas) → SetPass → Draw
  图标B (atlas) →           Draw   ← 同一纹理，可以 batch
  图标C (atlas) →           Draw

Batching

Static Batching / GPU Instancing 能合并 Draw Call，但不能合并 SetPass Call 。

1
2
3

// GPU Instancing：同一材质的100个物体(DrawCall x 100)
SetPass Call × 1   ← 只切换一次状态
Draw Call × 1      ← 合并成一次绘制（instanced）

而 Dynamic Batching 同时减少两者，因为它把多个 mesh 合并成一个，用同一个材质一次画完。

• Draw Call 多 → GPU 压力大
• SetPass Call 多 → CPU 压力大（状态切换开销）
• 先降 SetPass Call（合并材质、用图集），再降 Draw Call（Batching、Instancing）

Unity Stats 窗口里显示的 “SetPass Calls” 和 “Batches” 分别对应这两个指标，看这两个数比只看 Draw Call 更有参考价值。

Sprite Atlas 如何减少 Draw Call

Sprite Atlas 确实减少 Draw Call，但不是靠自己，而是靠触发 Dynamic Batching。

Draw Call 能被合并的条件是：多个物体使用完全相同的材质（同 shader + 同纹理 + 同参数）。

没有 Atlas 时：

1
2
3

图标A → 材质A (tex_a)  ← 不同纹理 = 不同材质
图标B → 材质B (tex_b)  ← 无法 batch
图标C → 材质C (tex_c)  ← 3个 Draw Call

有了 Atlas，所有图标共享同一张纹理，材质变成一样的，Dynamic Batching 才能介入把它们合并：

1
2
3

图标A → 材质X (atlas)  ← 同一材质
图标B → 材质X (atlas)  ← Dynamic Batching 合并
图标C → 材质X (atlas)  ← 1个 Draw Call

所以准确说法是：Atlas 统一了纹理，使 batching 成为可能，batching 才是真正减少 Draw Call 的那一步。 两者缺一不可。

即使不考虑 Draw Call，Atlas 本身也有价值：

• 减少纹理切换的 SetPass Call，这个开销比 Draw Call 更重
• 减少内存碎片，GPU 显存里一张大图比十张小图更高效
• 减少文件 IO，加载一张图比加载十张快

总结

Atlas 的核心价值是”统一材质”，Draw Call 的减少是这个统一带来的副产品，真正执行合并的是 Dynamic Batching。