Google Protocol Buffers（简称 Protobuf）是一套“数据结构定义 + 代码生成 + 二进制序列化”工具。
先在 .proto 文件里约定字段，再生成 C#、Java、Go 等语言的读写代码，让客户端和服务端遵守同一份协议。

数据定义

以这份玩家数据为例：

1

{"chips":150,"money":12.5,"bonus":0}

不带空格的 UTF-8 JSON 是 34 字节。
JSON 是文本格式，字段名、数值、字符串以及标点，最终都编码成文本字节传输。

比如 {“chips”:150} 的chips字段，除了字段名本身，还需要两个字节传输引号。 连同冒号，”chips”: 共占 8 字节。

这里 150 是 JSON 数值，占 3 字节。
接收方解析后，才会把数值文本 150 转换为内存中的数字；它在 JSON 传输时并不是一个固定 4 字节的整数。
类似地，12.5 传的是四个字符 1、2、.、5，JSON 本身也不区分 float 和 double，由接收程序决定怎么存储。

你的protobuf数据可以定义为：

1
2
3
4
5
6
7

syntax = "proto3";

message PlayerBalance {
  int32 chips = 1;
  float money = 2;
  float bonus = 3;
}

这里的 1、2、3 是固定的字段编号，不是字段值。

按上面的协议，Protobuf 二进制通常只需要 8 字节：

这个例子里的 8 字节，chips 占 3 字节，money 占 5 字节，bonus 不占空间。（每个字段标签占1字节）
Protobuf的标签不包含字段名，也不一定直接包含字段长度。标签包含这个字段的部分元数据：字段编号和底层编码方式。

整条消息的结束位置则由外层提供，例如 HTTP 响应体的长度或嵌套消息的长度前缀。Protobuf 本身没有一个通用的“消息结束符”，所以在连续的 TCP 字节流中发送多条消息时，需要另外约定每条消息的长度。

数据结构

字段编号与字段名的对应关系需要额外存储。
Protobuf 的关键是：把这份映射提前放在客户端和服务端的协议定义、生成代码里，而不是每次发送数据时重复传输。

所以它用“双方提前约定数据结构”的成本，换取“每条消息更小”的收益。

但缩小比例取决于数据：大量重复字段名、数字、列表通常收益明显；很长的字符串内容仍然要传。
Protobuf 不是压缩算法，也不是加密算法，还可以与 gzip 等压缩一起使用。
若用 Protobuf 的 JSON 输出模式，传输的仍是 JSON，拿不到上述二进制收益。

接入时需要注意这几件事：

1. 客户端和服务端共同支持协议。 如果服务端仍然只接受表单和 JSON，单独换 Unity 序列化方式无法使用。
2. 网络层改为处理字节。 通常用 UploadHandlerRaw 发送，读取 downloadHandler.data 接收；Protobuf 也可以继续通过普通 HTTP 使用，不要求 gRPC。
3. Unity 可以使用 Google.Protobuf，但接入后仍需验证程序集引用和目标平台的 IL2CPP 构建

字段映射

开发时，.proto 文件就是协议定义：

通过 protoc 编译器，可以为客户端生成 C# 类，为服务端生成对应语言的类。

字段名还可能保存在生成的描述信息中，用于反射、JSON 转换等功能。这些内容属于程序代码和元数据，不需要跟着每条网络消息发送。
可以理解为双方事先约定：

1

“编号 1 表示筹码，编号 2 表示余额，编号 3 表示奖励余额。”

此后每次通信只发送“编号和值”。

JSON 则会在每次通信时重复发送：

1

“chips 的值是 150，money 的值是 12.5……”

因此，Protobuf 并没有消灭映射，而是把映射从每条消息里移到了双方程序里。

以及二进制里并不是只有字段值，Protobuf 不能直接把 150 和 12.5 连起来，因为接收方需要知道：

• 这是哪个字段？
• 这个字段的值占多少字节？
• 读完后下一个字段在哪里？

所以每个实际发送的字段，基本结构是：

1

字段标签 tag + 字段值

对于字符串等可变长度的数据，则是：

1

字段标签 tag + 内容长度 + 内容

Unity热更新可以通过Lua框架（xLua, toLua等）或者HybridCLR实现。

xLua 下载的是 Lua 脚本，由 Lua VM 执行。
HybridCLR 下载的是 C# DLL，由 HybridCLR 在 IL2CPP 中解释执行。

主要流程

如果你项目使用 Addressables，那么 catalog.json、AB 包、New Build / Update Build 的流程，对两者都一样。
Addressables 不关心文件是 Lua 还是 DLL；它只负责把指定地址的资源拿回来。

1
2
3
4
5
6
7
8
9

Player 内置启动器
  ↓
检查远端 catalog.hash / catalog.json
  ↓
下载变化的 AssetBundle
  ↓
从 AB 取出热更新文件
  ↓
加载并运行热更新逻辑

首次发布Android平台远端资源时，可以这样做：

1
2
3
4
5

Addressables → New Build
  ↓
ServerData/Android/
  ↓
将其中内容部署到 Cloudflare/CDN 的 Android 资源目录

例如：

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

本地：
ServerData/Android/
  catalog_xxx.json
  catalog_xxx.hash
  hotcode_a1.bundle
  ui_b1.bundle

CDN：
https://assets.example.com/aa/Android/
  catalog_xxx.json
  catalog_xxx.hash
  hotcode_a1.bundle
  ui_b1.bundle

需要确保以下两点：

1. 指定远端资源构建。需要启用 Build Remote Catalog，并将需要热更的 Group 设置为：

1
2

Build Path = Remote.BuildPath
Load Path = Remote.LoadPath

仅在当前项目点击 New Build，因远端 Catalog 关闭、默认 Group 是 Local，未必会产生可部署的 ServerData/Android 完整热更新内容。

2. Remote.LoadPath 必须在构建前指向真实 CDN 地址，例如：

1

https://assets.example.com/aa/[BuildTarget]

不要先用 localhost 构建，再直接把文件传到 Cloudflare；Catalog 中会保留构建时写入的 LoadPath。

首次发布后，后续的操作不同：

1
2
3
4
5

Update Previous Build
  ↓
只产生新增/变化的 Bundle 与新 Catalog
  ↓
合并到服务器已有 Android 资源目录

不要清空服务器 Android 目录，也不要只部署本次 Update Build 的少量输出。新 Catalog 文件替换，旧 Bundle 保留。

xLua：Lua 驱动 C#

xLua 的核心是把 Lua VM 放进 Player：

1
2
3
4
5
6
7
8
9

C# AOT Player
  ↓
LuaEnv
  ↓
下载 Main.lua、Login.lua、Battle.lua
  ↓
Lua 脚本解释执行
  ↓
通过绑定层调用 Unity/C#

游戏启动时，C# 通常创建一个全局 LuaEnv
所以它不是“把 Lua 脚本编译进原生 Player”；而是 Player 预先带着 Lua 解释器，后续下载 Lua 脚本，解释器负责运行这些新脚本。

Lua 与 C# 的交互通常需要配置生成：

• CSharpCallLua：让 C# 调用 Lua。
• LuaCallCSharp：让 Lua 高效调用 C#。
• Delegate、Interface、泛型、重载等都要处理绑定与代码生成。

xLua 的两种“热更新”

• Lua 业务热更新
  这是最常见、最稳的方式：

1
2

C#：框架、Unity 封装、网络、资源管理
Lua：UI 流程、活动、战斗规则、业务逻辑

后续下载新的 Lua 文件即可生效。
优点是包小、更新快；代价是业务层需要长期使用 Lua 开发，并维护 Lua/C# 边界。

• xLua Hotfix：Lua 覆盖 C# 方法
  xLua 还有 Hotfix 注入机制。你在发包前标记/生成可热修复的 C# 方法，构建时 xLua 向这些方法插入跳板：

1
2
3
4
5

原 C# 方法
  ↓
预先注入 Hotfix 检查点
  ↓
运行时 Lua 可替换该方法实现

例如 Lua 可以通过 xlua.hotfix(…) 替换一个已预留的 C# 方法。
关键限制是：xLua 不能在 Player 发布后，任意修改一个当初没有注入 Hotfix 跳板的 C# 方法。
也就是说，它是“预埋可替换点”，不是发布后任意加载新 C# 代码。

HybridCLR：运行新的 C# 逻辑

HybridCLR 则更接近“可加载新的 C# 程序集”，但同样受基础 Player 的 API、裁剪、泛型、桥接代码约束。

1
2
3
4
5
6
7
8
9

C# AOT Player
  ↓
HybridCLR Runtime
  ↓
下载 Game.HotUpdate.dll.bytes
  ↓
Assembly.Load
  ↓
解释执行新的 C# IL

热更新代码仍是 C#：

• 可以新增普通 C# 类、接口、业务系统。
• 可以使用熟悉的 C# 语法、async、LINQ、泛型、异常等。
• 可以直接引用已有 AOT 层 API。
• 主体逻辑通常无需改写成另一种语言。
  但它不能改变已经编译进 Player 的原生 AOT 代码；它解决的是“新增/替换热更新程序集中的逻辑”。

Catalog 与 AB包

假设热更入口地址为 HotEntry。

• xLua

1
2
3
4
5
6
7
8

catalog.json
  "HotEntry"
    → lua_main_abc.bundle

lua_main_abc.bundle
  → Main.lua
  → Login.lua
  → Battle.lua

运行时：

1

luaEnv.DoString(luaTextAsset.text, "Main.lua");

• HybridCLR

1
2
3
4
5
6

catalog.json
  "HotEntry"
    → hotcode_abc.bundle

hotcode_abc.bundle
  → Game.HotUpdate.dll.bytes

运行时：

1

Assembly.Load(hotDllTextAsset.bytes);

HybridCLR 可能还多一组

1
2
3

aotmetadata_abc.bundle
  → Game.Runtime.dll.bytes
  → System.dll.bytes

这些 AOT 元数据要在加载热更新 DLL 前处理。

New Build / Update Build 对比

它们的发布方式一致。第一次发包：

1
2
3
4
5
6
7
8

xLua：
New Build → Lua AB + Catalog → 打入/上传

HybridCLR：
生成 HybridCLR 必要代码
→ 构建 Player
→ 打包热更新 DLL / AOT 元数据到 AB
→ New Build → Catalog + AB

后续只改热更逻辑：

1
2
3
4
5
6
7

xLua：
改 Lua → Update Previous Build → 上传新 Lua AB + Catalog

HybridCLR：
编译新 HotUpdate.dll
→ Update Previous Build
→ 上传新 DLL AB + Catalog

两者都不是二进制增量补丁：

• 修改一个 Lua 文件，通常重下它所在的整个 Lua Bundle。
• 修改一个 DLL，通常重下它所在的整个 DLL Bundle。
• Bundle 划分越细，下载越小；Bundle 越大，依赖和管理越简单。

点到直线距离

方法一：投影 + 勾股定理

利用点到直线上某点的向量长度，以及它在直线方向上的投影长度，用勾股定理求出垂直分量。

1
2
3
4
5
6

// 点到直线距离
public static float DistancePoint2Line(Vector3 point, Vector3 linePoint1, Vector3 linePoint2)
{
    float fProj = Vector3.Dot(point - linePoint1, (linePoint1 - linePoint2).normalized);
    return Mathf.Sqrt((point - linePoint1).sqrMagnitude - fProj * fProj);
}

原理：|d|² = |斜边|² - |投影|²（勾股定理）。

注意：在浮点误差下 sqrMagnitude - fProj² 可能出现极小的负数，导致 Mathf.Sqrt 返回 NaN，必要时可对被开方数做一次 Mathf.Max(0, ...) 保护。

方法二：叉乘（面积法）

两向量叉乘的模等于它们所构成平行四边形的面积，面积除以底边长度即为高（也就是点到直线的距离）。这种方式在 3D 中最推荐，代码简洁且数值稳定。

1
2
3
4
5
6

public static float DistancePoint2Line_Cross(Vector3 point, Vector3 linePoint1, Vector3 linePoint2)
{
    Vector3 dir = linePoint2 - linePoint1;
    Vector3 v = point - linePoint1;
    return Vector3.Cross(v, dir).magnitude / dir.magnitude;
}

原理：距离 = 平行四边形面积 / 底 = |v × dir| / |dir|。

方法三：先求投影点，再求两点距离

先算出点在直线上的投影点坐标，再直接用 Vector3.Distance。好处是能顺便拿到最近点（投影点）。

1
2
3
4
5
6

public static float DistancePoint2Line_Project(Vector3 point, Vector3 linePoint1, Vector3 linePoint2)
{
    Vector3 dir = (linePoint2 - linePoint1).normalized;
    Vector3 projPoint = linePoint1 + Vector3.Dot(point - linePoint1, dir) * dir;
    return Vector3.Distance(point, projPoint);
}

补充：以上三种求的都是无限长直线的距离。如果要的是**线段（Segment）**距离，需要把投影参数 t 用 Mathf.Clamp01 限制在 [0, 1] 之间，再求点到该最近点的距离。

点到面距离

点到平面的距离公式：d = |Ax0 + By0 + Cz0 + D| / √(A² + B² + C²)。

平面的一般式方程为 Ax + By + Cz + D = 0，平面的法向量为 (A, B, C)。

如果一个非零向量 n 与平面 a 垂直，则称向量 n 为平面 a 的法向量。垂直于平面的直线所表示的向量即为该平面的法向量。每一个平面存在无数个法向量。

方法一：用 Plane 类

Unity 内置的 Plane 类可以由三点构造，并直接求点到平面的（有符号）距离。

1
2
3
4
5

public static float DisPoint2Surface_Plane(Vector3 point, Vector3 surfacePoint1, Vector3 surfacePoint2, Vector3 surfacePoint3)
{
    Plane plane = new Plane(surfacePoint1, surfacePoint2, surfacePoint3);
    return plane.GetDistanceToPoint(point);
}

方法二：用法线 + 点乘

由平面上两条边叉乘得到法向量，再把「点到平面上一点」的向量投影到法向量方向上，其绝对值即为距离。

1
2
3
4
5
6

public static float DisPoint2Surface_Normal(Vector3 point, Vector3 surfacePoint1, Vector3 surfacePoint2, Vector3 surfacePoint3)
{
    Vector3 cross = Vector3.Cross(surfacePoint1 - surfacePoint2, surfacePoint1 - surfacePoint3);
    float proj = Vector3.Dot(point - surfacePoint1, cross.normalized);
    return Mathf.Abs(proj);
}

核心架构差异

UGUI：每个 UI 元素是一个 GameObject

• UI 就是场景里的 GameObject，挂 RectTransform + Canvas Renderer + 各种组件（Image、Text、Button…）。
• 一个复杂界面 = 成百上千个 GameObject，纳入正常的场景层级、Prefab 系统。
• 优点：概念统一，和场景其它对象一致，容易理解、容易挂脚本。
• 缺点：GameObject/Component 开销大，元素多了内存和遍历成本高。

UI Toolkit：一棵轻量的 VisualElement 树

• UI 是一棵 VisualElement 树，不是 GameObject，是纯 C# 轻量对象。
• 结构（UXML）、样式（USS）、逻辑（C#）三者分离，像 Web 的 HTML/CSS/JS。
• 优点：元素轻量，海量元素也省内存；结构/样式/逻辑解耦。
• 缺点：不在场景层级里，不能直接给单个元素挂 MonoBehaviour，思路要转变。

渲染机制

UGUI的渲染单元是Canvas，按 Canvas 合批

• 合批：依赖 Canvas 内元素的层级/材质，容易被打断，需手动优化（拆 Canvas、图集）
• 重建：一个元素变化可能触发整个 Canvas rebuild（著名的性能坑）

UI Toolkit的渲染单元是统一的 UIR（UI Renderer）网格系统

• 合批：通过引擎自动生成网格并合批，通常 drawcall 更少
• 重建：局部脏标记，只重建变化部分

更新UI样式

UGUI的样式序列化在每个GameObject/组件字段上

• 复用：改一处只影响一个游戏对象，批量改要靠 Prefab 或脚本
• 热重载：组件字段改了即时可见（Inspector）
• 逻辑分离：样式和结构混在场景/预制体里

UI Toolkit的样式存保存于独立的 USS 文本文件中

• 复用：一个选择器（class）改一处，所有匹配元素全局生效
• 热重载：存盘热重载，且可运行时动态换 USS
• 逻辑分离：样式（USS）/结构（UXML）/逻辑（C#）三文件分离

UI Toolkit 让”改样式”变成改一个集中的、可选择器批量作用、可热重载、可运行时切换的文本文件，且和 C# 逻辑彻底分离

样式和结构可以脱离 C# 迭代，但数据源和逻辑仍在 C# 里:

• 纯视觉（颜色、间距、字体、布局、:hover 效果）→ 改 USS 即可，不碰 C#。
• 改结构（增删元素、换控件）→ 改 UXML，通常也不用重编译 C#（如果不新增需要 C# 引用的元素）。
• 改数据绑定关系：如果绑定写在 UXML 里，改绑定路径也不用重编译；但如果绑定写在 C# 里（SetBinding(…)），那就要重编译。
• 改 ViewModel / [CreateProperty] 属性 / 业务逻辑 → 必须重编译 C#。

数据绑定

UGUI 根本没有内置数据绑定系统。你在 UGUI 里做的所有”数据显示到 UI”都是手写命令式代码。
UI Toolkit（Unity 6 起）则提供了声明式的数据绑定。所以优势不是”绑定做得更好”，而是”从无到有”。

UGUI 的写法（命令式，手动同步）

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

public class Player : MonoBehaviour
{
    public int health = 100;
    public int maxHealth = 100;

    public Slider healthSlider;   // 拖引用
    public Text healthLabel;      // 拖引用

    public void TakeDamage(int dmg)
    {
        health -= dmg;
        RefreshUI();   // 每次改数据都得记得手动刷新
    }

    void RefreshUI()
    {
        healthSlider.value = (float)health / maxHealth;
        healthLabel.text  = $"{health}/{maxHealth}";
    }
}

• 数据和 UI 强耦合：Player 逻辑类里塞了 Slider/Text 引用。
• 容易漏刷新：任何地方改了 health 都得记得调 RefreshUI()，漏一处就显示错。
• UI 引用靠拖拽：换了 UI 结构容易丢引用、报 NullReference。

UI Toolkit 的写法（声明式，自动同步）

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

public class PlayerViewModel : INotifyBindablePropertyChanged
{
    int _health = 100;

    [CreateProperty]
    public int Health
    {
        get => _health;
        set
        {
            if (_health == value) return;
            _health = value;
            Notify(); // 只管喊一声"我变了"
        }
    }

    [CreateProperty]
    public float HealthRatio => _health / 100f; // 派生属性也能绑

    public event EventHandler<BindablePropertyChangedEventArgs> propertyChanged;
    private void Notify([CallerMemberName] string name = "") {
        propertyChanged?.Invoke(this, new BindablePropertyChangedEventArgs(name));
    }
}

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

var vm = new PlayerViewModel();
root.dataSource = vm;

var bar = root.Q<ProgressBar>("healthBar");
bar.SetBinding("value", new DataBinding
{
    dataSourcePath = new PropertyPath(nameof(PlayerViewModel.HealthRatio)),
    bindingMode = BindingMode.ToTarget
});

var label = root.Q<Label>("healthLabel");
label.SetBinding("text", new DataBinding
{
    dataSourcePath = new PropertyPath(nameof(PlayerViewModel.Health)),
    bindingMode = BindingMode.ToTarget
});

之后业务代码只写 vm.Health -= 10;，血条和文字自动更新。逻辑层再也不碰任何 UI 引用。
这些绑定也可以直接写在 UXML 里，做到 UI 结构和绑定关系纯声明式、和 C# 逻辑完全分离。

UI Toolkit的数据绑定优势

1. 解耦：数据源（ViewModel）完全不知道 UI 存在，可单独测试、复用。
2. 声明式 + 少样板：绑定关系集中声明（甚至写在 UXML），不用到处写刷新代码，也不会漏刷新。
3. 双向绑定：BindingMode.TwoWay，输入框改了值自动回写数据源，UGUI InputField得手动写 onValueChanged 回调。
4. 无反射、低 GC：底层用 Unity.Properties（[CreateProperty]），不走反射，运行时开销小。
5. 派生属性/转换器：可以绑派生属性或加 converter 做格式转换（如 100 → “100/100”），不用在数据里存冗余字段。

UI Toolkit 真正的工作流优势在于三层各自独立迭代：

• USS (Styles) → 美术/UI 改，热重载，不碰 C#
• UXML (Structure) → 布局/绑定调整，多数不碰 C#
• C# (ViewModel) → 程序改数据源，需重编译

而 UGUI 里，样式（组件字段）、结构（Prefab 层级）、刷新逻辑（C# 里的 RefreshUI）纠缠在一起，想修改外观往往还是要回到 C# 手动加刷新代码。

UGUI 用 INotifyPropertyChanged数据绑定

INotifyPropertyChanged 本身只是一个”我变了”的通知接口，它不会自动更新任何 UI。
要在 UGUI 上复现 UI Toolkit 的体验，你需要自己写一个绑定层：

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

public class TextBinder : MonoBehaviour
{
    public Text target;
    INotifyPropertyChanged _source;
    string _propName;

    public void Bind(INotifyPropertyChanged src, string propName)
    {
        _source = src;
        _propName = propName;
        src.PropertyChanged += OnChanged;
        UpdateNow();
    }

    void OnChanged(object s, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == _propName) UpdateNow();
    }

    void UpdateNow()
    {
        // 还得用反射或委托去取值
        var val = _source.GetType().GetProperty(_propName).GetValue(_source);
        target.text = val.ToString();
    }

    void OnDestroy() { if (_source != null) _source.PropertyChanged -= OnChanged; }
}

也就是说，用 INotifyPropertyChanged 你需要自己解决：

• 取值/赋值：要么反射（有 GC 和性能开销），要么每个属性写委托；UI Toolkit 用 Unity.Properties 免了这层。
• 绑定注册/注销：手动管理事件订阅，注意 OnDestroy 里退订，否则内存泄漏。
• 双向绑定：还得反向监听 UI 的 onValueChanged 再写回，自己防循环更新。
• 每种控件/属性都要写对应 binder。

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)。

UnityPerDraw 和 UnityPerMaterial

UnityPerDraw 和 UnityPerMaterial 都是 Shader 使用的常量缓冲区（CBUFFER），区别在于数据更新频率和来源。

关系可以理解为：

1
2
3
4

Renderer
├─ Mesh / Transform ──────> UnityPerDraw
└─ Material
   └─ Shader Properties ──> UnityPerMaterial

例如两个 Renderer 共用一个 Material：

1
2
3

Renderer A：自己的 UnityPerDraw ─┐
                                ├─ 共用 UnityPerMaterial
Renderer B：自己的 UnityPerDraw ─┘

因此它们颜色、粗糙度等材质属性相同，但模型矩阵不同。

Renderer 是产生绘制任务的组件。Unity准备 Draw Call 时：

1. 从 Renderer、Transform、Lightmap 等获得每物体数据。
2. 写入或绑定 UnityPerDraw。
3. 从 Renderer 使用的 Material 获得材质参数。
4. 绑定 UnityPerMaterial。
5. 使用 Shader 绘制 Mesh。

不过“PerDraw”不完全等于“PerRenderer”。一个 Renderer 可能因为多个 SubMesh、Pass 或阴影阶段产生多个 Draw Call。

兼容 SRP Batcher 的 Shader 通常要求：

• Unity内置的每物体属性集中在一个 UnityPerDraw CBUFFER。
• 所有材质属性集中在一个 UnityPerMaterial CBUFFER。
• 不要把材质属性零散放进其他 CBUFFER。

URP 自定义 Shader 常见写法：

1
2
3
4
5

CBUFFER_START(UnityPerMaterial)
    float4 _BaseColor;
    float4 _BaseMap_ST;
    float _Smoothness;
CBUFFER_END

UnityPerDraw 通常已经由 URP/HDRP 的公共 include 文件声明，不应自己重复声明。

SRP Batcher 会缓存 UnityPerMaterial 数据，在连续绘制使用同一 Shader Variant 的 Renderer 时，主要切换 UnityPerDraw。这样减少 CPU 向 GPU 设置状态和上传参数的成本。

需要注意：

• SRP Batcher通常不会合并 Draw Call，只是降低每个 Draw Call 的 CPU 成本。
• GPU Instancing 才侧重于把多个相似 Renderer 合并为实例化绘制。
• MaterialPropertyBlock 可以给不同 Renderer 设置不同属性，但通常会使该 Renderer 无法走标准 SRP Batcher 路径。
• 多个 Renderer 共用 Material，更有利于缓存和批处理。
• renderer.material 会创建材质实例；renderer.sharedMaterial 使用共享材质。

一句话总结：Renderer 决定“画什么以及在哪里画”，UnityPerDraw 保存这次绘制的物体数据，UnityPerMaterial 保存材质数据，而 SRP Batcher 利用这种数据分组来降低渲染提交成本。

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 和深度测试设置提高表现力。