写这篇复盘之前，先交代一下项目背景。这是一个以 Unity 为引擎、由我担任游戏主程的悬疑推理向项目，整体玩法偏剧情驱动，玩家需要在场景中搜索线索、与角色对话、组合证据、解开谜题，最终根据推理结果走向不同结局。技术栈以 Unity 2021 LTS 为主，包含少量自研编辑器工具，覆盖从原型验证到成包上线的完整流程。这篇文章不打算写成 API 手册，而是把主程视角下真正花过时间、踩过坑、最终沉淀下来的东西整理出来，从架构设计到具体系统实现，再到性能优化和团队协作，尽量给到能直接参考的结论。
如果你正准备做同类叙事驱动游戏，或者刚接手一个以剧情和谜题为核心玩法的 Unity 项目，这篇文章应该能帮你少走不少弯路。文章里提到的很多决策，单独看可能不起眼，但组合起来决定了项目后期是否还能快速迭代。
1. 项目开局：选型与工程架构
1.1 为什么选 Unity，以及版本和渲染管线怎么定
悬疑推理游戏不像重战斗的动作游戏那样对渲染有极致要求，它更看重的是跨平台能力、成熟的 UI 系统、以及大量叙事内容的管理工具链。Unity 在这三方面都有比较成熟的积累，尤其是 UGUI + TextMeshPro 的组合，做对话、线索面板、证据陈列这类高频 UI 交互非常顺手。项目团队里既有程序也有策划，Unity 的编辑器易用性也让策划能直接参与场景摆放和对话调试，不需要额外搭一套编辑器工具链。
版本选型上，我直接锁定了 Unity 2021.3 LTS。这个版本在稳定性、Burst/Job System 支持、以及各平台导出兼容性上都比较均衡。没有选 2022 LTS 的原因是当时项目中期正好赶上 2022 版本迭代，团队不希望在这个节骨眼上承受升级风险。渲染管线用的是内置渲染管线（Built-in Render Pipeline），原因也很简单：项目画面风格是偏写实但也偏静态的场景，大量使用预烘焙光照贴图，不需要 GPU Instancing 的大规模植被，也不需要 Scriptable Render Pipeline 的自定义渲染特性。内置管线在这个量级的项目里反而是最稳妥的，Shader 兼容性最好，移动端适配问题也最少。
1.2 工程目录划分与核心框架选择
主程接手项目的第一件事就是重新划分工程目录。没有合理的目录结构，后期几十个场景、上百个 prefab 会让人崩溃。我们的目录按照功能域划分，而不是按资源类型划分：
- Assets/Scenes 只放场景文件，按章节子目录再分
- Assets/Scripts 分为 GamePlay、UI、Data、Editor、Tools 五个子域
- Assets/Art 下按角色、场景、特效、UI 图素分类，且每个子类再按 prefab 与源文件分开
- Assets/Config 放所有 ScriptableObject 配置，包括对话、谜题、物品、章节流程等
框架层面没有上特别重的 MVVM 框架，而是采用了一轻一重的组合：轻量消息事件总线 + 状态机驱动的流程控制器。事件总线负责各模块之间的解耦，比如“线索被发现”这个事件，会同时被任务系统、音频系统和 UI 系统监听，彼此之间不用直接引用。流程控制器则负责章节内的阶段流转，例如“进入房间 -> 获得线索 A -> 解锁对话选项 B -> 触发剧情 C”，用一个可配置的 Step 数组驱动。这个设计在后面调整剧情节奏时帮了大忙，策划改配置就能改变流程，不需要动代码。
1.3 几个必须在开工前想清楚的前期决策
悬疑推理游戏有几个特性会深刻影响架构：非线性探索、多分支剧情、以及随时可能被玩家“跳着玩”的场景顺序。如果前期不做好设计约束，后面改起来是伤筋动骨的。
第一个决策是“场景切换模式”。我们最终采用多场景并存的架构——主菜单一个场景，每个章节一个独立场景，章节内再拆分逻辑子场景（不一定对应 Unity Scene），避免一个场景塞过多内容。这里要注意的是，多场景加载要统一走异步加载接口，由自研的 SceneLoader 组件控制进度条和 Loading UI，不能直接调用 SceneManager.LoadScene，否则场景切换时内存峰值会很难看。
第二个决策是“存档的最小粒度”。推理游戏必须有非常细的变量记录，比如“玩家是否已经看过某封信”“某个证物是否被组合过”“NPC 是否已经移动到另一个房间”。这些状态不能只靠保存场景内 GameObject 的启停来实现，因为场景一旦重新加载，所有运行时状态都会被清掉。我们采用了一个全局 GameState 对象，以字典方式保存所有剧情变量的值，存档时序列化整个 GameState，并绑定时间戳和版本号，加载时再根据这份数据重建所有场景内的状态。这个决策是整个项目架构里最重要的一环，后面存档系统会详细讲。
第三个决策是“叙事表现方式”。悬疑推理游戏需要大量特写镜头、物品高亮、对话人物的近景演出，我们在前期就确定以 Cinemachine + Timeline 作为主要的演出工具，而不是为每个镜头手写插值代码。这条决策极大提升了叙事演出效率，也让策划可以直接在 Timeline 上调整镜头焦段和节奏。
2. 对话系统与线索系统：悬疑游戏的核心玩法底座
2.1 对话系统从写死到配置驱动
悬疑推理游戏的对话不是简单的“你说一句我说一句”，它包含人物头像、名字、语音、表情动画、剧情分支选项、条件判断（满足某条件才出现某选项）、以及对话结束后的回调事件。我们的第一个原型版本把对话硬编码在 C# 类里，每条对话一个方法，调试起来很灵活，但策划完全没法自己调整。项目进入内容量产阶段后，这种模式直接崩了——策划改一句话都要找程序，迭代效率没法看。
后来我们花了一周时间把对话系统重构为配置驱动。核心数据结构是一个 DialogueNode，包含节点编号、讲话人、文本内容、语音资源引用、表情动画 ID、可选的选项列表。选项列表里每一项都带一个 ShowCondition，指向 GameState 中的某个条件表达式。节点之间的流转支持顺序、跳转、分支三种模式，用 GUID 而不是数组下标做引用，避免在中间插入节点导致后续全部错位。
这里有一个很典型的坑：如果对话数据用 JSON 并使用 System.Text.Json 或者 Newtonsoft.Json 反序列化，字段增删时要格外小心版本兼容。我们最后把对话配置全部做成了 ScriptableObject，利用 Unity 的 Inspector 做可视化编辑，并写了一个自定义 Editor 窗口来预览对话流程树。这比让策划直接改 JSON 友好得多，也杜绝了格式错误导致运行时崩溃的问题。
2.2 线索系统与推理面板的数据流
线索系统需要同时服务玩法层和表现层。玩法上，玩家拾取线索后，该线索进入背包；表现上，线索通常对应场景里某个可交互物品的高亮状态和调查动画。我们做了一个 InteractableObject 基类，所有可交互物体都继承自它，并持有三个关键字段：ObjectId、ClueId、InteractionRule。
ObjectId 是场景内唯一标识，ClueId 是线索配置表里的主键，InteractionRule 则定义了这个物体在不同 GameState 下的表现行为。例如一个抽屉，在玩家没有钥匙时交互结果是“上锁了”，拿到钥匙后交互结果是“打开并获得物品 X”，打开后再次交互则是“空无一物”。这套数据流在实际开发中非常实用：表现层只根据 ObjectId 和当前 GameState 查询交互规则，不需要关心推理逻辑本身，让场景美术和程序开发可以并行。
推理面板则是一个独立的 UI 系统，负责展示所有已收集线索、人物档案、以及线索之间的关联关系。这个面板的数据来源不是背包里的物品列表，而是 GameState 中维护的一个 ClueCollection，每次玩家获得新线索时通过事件总线通知 UI 刷新。为了支持玩家推理时做“连线”“归组”这类操作，我们在 UI 层使用了一个简单的拖拽组件，并在拖拽结束时做一次规则匹配。如果匹配成功，GameState 会写入一条新的推理记录，并触发对应的演出片段。
2.3 谜题系统需要抽象到什么程度
市面上悬疑游戏的谜题类型很多：密码锁、齿轮拼图、找不同、逻辑连线、物品组合、对话套话等等。如果每种谜题单独一套代码，那维护成本会翻好几倍。我们的做法是抽象出一个 PuzzleBase 类，定义 Initialize、CheckSolution、OnSolved、OnFailed 四个主要接口，每种谜题作为一个子类实现。
配置层上，每道谜题都是一个 PuzzleConfig ScriptableObject，里面包含谜题类型、对应的场景交互点、可能需要的道具 ID、以及解谜成功后的奖励线索 ID。运行时有一个 PuzzleManager 负责统一管理当前激活的谜题，接收来自玩家操作的事件，把操作结果转发给当前 PuzzleBase 子类做判断。这么做的好处是，新增一种谜题只需要写一个新的 PuzzleBase 子类和对应的配置资产，不需要改任何现有流程。项目后期增加了四五种谜题类型，几乎没有引入过回归 Bug。
有一点要特别提醒：谜题 UI 与场景交互经常互相干扰。比如玩家正在解一个密码锁，这时候如果触发了一个 NPC 对话，界面层级就会乱掉。我们的解决方案是引入一个 UIStack 管理器，所有全屏或者模态 UI 在打开时都向栈里注册，关闭时从栈里弹出。任何新的交互请求先检查当前栈顶是否允许被覆盖，不允许的话暂时存入队列，等待模态 UI 关闭后再执行。这套机制虽然实现很简单，却是保证交互不乱套的功臣。
3. 存档系统：叙事分支游戏的生命线
3.1 存档结构设计：纯数据存档 + 时间戳 + 版本号
悬疑推理游戏的存档和动作游戏有很大不同。动作游戏的存档可以只保存关卡进度和角色属性，但推理游戏必须保存成百上千个剧情变量的状态，否则玩家读档后会看到各种逻辑矛盾，比如人都消失了证物还在背包里。
我们的存档以一整份 JSON 为最小单位，包含以下部分：
- SaveVersion：存档结构版本号，用于存档兼容和迁移
- Timestamp：存档时间，用于 S/L 界面排序
- ChapterId 和 StepId：当前进度位置
- GameStateDictionary：所有剧情变量的字典快照
- InventoryData：背包物品的完整列表
- ObjectiveData：任务日志状态
- 各章节场景内的特殊状态记录，例如“某房间门是否打开”“某物体是否已调查”
这里有个设计取舍：我们选择纯数据存档，不保存场景对象的无损快照。也就是说，读档时只恢复数据层的状态，再根据数据层状态去驱动场景内对象的表现。这样做最大的好处是存档体积小、兼容性强，即使某个场景在后续版本里被改了结构，老存档依然能正确读出来。缺点是，加载后必须有一套“场景状态重建机制”，对每个可交互物体在 OnEnable 时执行一次 RefreshByState，从 GameState 里读取自己当前应有的状态。
3.2 剧情分支管理：全局变量表 + 事件监听
剧情分支管理的核心是全局变量表。我们用了一个枚举集合定义所有剧情变量，内部用 HashSet 或 Dictionary<string, bool/int> 存储值。每次剧情推进时，由 LogicTrigger 统一写入变量并广播变更事件。UI 和场景对象通过监听变量变更事件来自动更新表现，而不是每帧去轮询。
这套设计听起来简单，实战里有个容易翻车的地方：变量的写入顺序。比如“拿到钥匙”和“打开抽屉”这两个事件，如果因为代码顺序问题先写了“抽屉已打开”再写“拿到钥匙”，一旦中间有异常，存档里可能出现“钥匙还在背包但抽屉已经空了”的矛盾。所以我们给所有 LogicTrigger 加上了依赖声明：每个触发器执行前必须声明它依赖哪些变量处于什么状态，执行后它会设置哪些变量。启动时用一个拓扑排序器检查所有触发器之间的依赖环，如果有环就在编辑器里直接报错。这个机制在项目后期帮我们抓到了两个会导致软锁的剧情 Bug。
3.3 多结局与回溯机制的实现
多结局是悬疑推理游戏的标配。我们的项目设计了四个主要结局和若干小结局，结局分支取决于一系列关键推理变量的取值组合，而不是单一的最终选项。
实现上，我们在 GameState 里维护了一个 EndFlagScore 字典，每个关键推理节点会累加不同结局倾向的分数。最终章开始前，系统读取所有分数，选择分数最高的结局作为可进入分支。这个方案的好处是结局的解锁条件对玩家来说是隐性的，不会因为一句关键对话选错就彻底错过某个结局，玩家体验更自然。
回看功能方面，我们做了一个结局解锁图鉴，每个结局对应一组“已解锁条件提示”，玩家可以查看自己达成或未达成的推理关键点。这样既保留了重玩价值，也不会因为剧透破坏第一遍的体验。
4. 场景演出与摄像机：让玩家走进故事
4.1 摄像机与镜头语言的实现方案
悬疑推理游戏很像互动电影，镜头语言直接决定叙事氛围。我们放弃了单一跟随摄像机的方案，改用 Cinemachine 的虚拟相机系统。每个章节里预先配置多个虚拟相机：常规探索视角、对话近景、物品特写、以及走廊监控式的固定机位。通过 Cinemachine Brain 的优先级切换，我们可以非常自然地推动镜头从探索状态进入对话状态，不需要手写插值。
物品特写这个环节有点讲究。玩家点击一个可疑物品时，镜头要快速推到物品上方并稍微旋转一个角度，给玩家一种“仔细端详”的感觉。这个动作我们用一个专门的 InteractCamera 虚拟相机完成，开启时设置 LookAt 为目标物品，并启用一个小幅度 PerlinNoise 噪声模拟手持呼吸感。热词里提到的 PerlinNoise 正好派上用场——Cinemachine 的 Noise Profile 本质上也是噪声算法，合理调节 Frequency 和 Amplitude 可以让特写镜头显得很自然，不会死板地固定在某个角度。
4.2 Timeline 演出与任务指引的配合
剧情动画我们统一用 Timeline 制作，但有一个团队内部约定：所有 Timeline 必须通过 GameState 的变量监听来驱动，不能在 Timeline 里直接硬编码打开某个 UI 或播放某段音效，最多只能发事件。这样做的原因是，Timeline 是表现层，而游戏逻辑在数据层。如果 Timeline 里直接修改游戏逻辑，一旦玩家在演出过程中打开菜单或者触发跳过，逻辑状态就会和数据层脱节。
任务指引系统相对简单，用的是经典的三元组：目标 ID、目标描述、目标位置。每次 GameState 变化时，如果涉及到当前任务的更新，ObjectiveManager 会发出通知，UI 左上角的任务栏会更新文本和追踪标记。为了避免导航线穿墙这种尴尬效果，我们用的是“屏幕边缘箭头 + 小地图标记”的组合，而不是 3D 寻路导航线。
4.3 对话演出与 UI 的交互节奏
对话演出是整个项目里最容易显得“廉价”的部分。如果只是立绘 + 文本框交替出现，玩家的沉浸感会大打折扣。我们做了一套简单的对话演出控制器，支持逐字打字机效果、停顿指令、自动翻页、以及对话过程中的镜头偏移。打字机效果不是每帧简单截取字符串，而是用协程逐字显示文本，并支持在文本中插入 <wait=0.5>、之类的标记，让策划可以控制读句的节奏。
UI 交互上，我们遵循一个原则：任何时候玩家按下确认键，响应必须即时。哪怕是打字机效果还没有播完，按下确认也要立刻完整显示当前句，再按一次才进入下一句。这个细节初看不起眼，但实测下来非常影响手感。另外在对话过程中，移动、旋转镜头等操作会被锁住，但打开系统菜单始终是被允许的，这需要 UGUI 的输入模块做一层输入分发控制。
5. 性能优化与渲染细节：中后期的主程日常
5.1 UI 性能优化：合批、图集与字体
悬疑推理游戏有大量的 UI 界面，对话、背包、线索、系统设置、章节切换，UI 性能做不好会直接拉低帧率。我们的 UI 优化主要做了三件事：图集规划、字体处理、以及动静分离。
图集规划上，所有 UI 图素必须打进图集（Sprite Atlas），不允许散图直接挂到 UI 上。我们按界面功能拆成多个图集，对话专用一个、背包线索一个、通用组件一个，每个图集大小控制在 2048 以内，避免移动端显存占用过高。这里有个容易踩的坑：如果一个图集引用在场景中没有被打包，切换场景时会出现 UI 图片闪白。解决方案是让所有图集进入 Always Included，或者在启动时统一加载到 Resources 里。
字体方面，TextMeshPro 使用动态字体时要注意字体回退。中文文本量大的对话界面，如果动态字体的 Atlas 尺寸不够大，会出现文字越打越糊的情况。我们为对话和剧情文本单独分配了 4096 的 Atlas 尺寸，并在打包时用 Font Asset Creator 预烘焙了项目里常用字的前 3500 字。这个预烘焙操作把对话界面的运行时字体重建率降到了几乎为零。
动静分离是指把常驻 UI 和动态刷新 UI 分开打 Canvas。常驻的 HUD 和背景层放一个静态 Canvas，打开菜单时只刷新内容区域，避免整个界面重建网格。每次打开背包时，我们只更新内容区的子物体，而不是重新实例化整个背包界面。这一条做得好的话，可以明显减少打开界面时的卡顿。
5.2 场景加载、内存与资源管线的优化
项目的每个章节场景大小差异很大，有些线性流程场景要加载上百个物件。我们统一使用 AssetBundle 做资源管理，并按章节拆分 Bundle 粒度，每个章节一个 Bundle，公共资源和 UI 单独打包。加载流程上：
- 先加载公共 Bundle，常驻内存，不释放
- 再加载章节 Bundle，进入该章节时异步加载，进度条显示的是 Bundle 加载进度和场景 Asset 加载进度的加权和
- 离开章节时卸载非公共 Bundle，并调用 Resources.UnloadUnusedAssets 清理引用
这套方案在 PC 端问题不大，但在移动端仍然会遇到小内存设备的压力。我们的应对措施是严格限制同屏物件数量，把过大的场景拆成多个子场景，通过门、走廊等自然分隔做局部加载。另一个经验是，阴影贴图在移动端尽量用 2048 以下，光照贴图压缩格式用 ASTC，特别是低端安卓机上，阴影质量和高光质量该降就降。热词里提到 Unity 阴影问题，我想说大部分场景里的阴影闪烁和漏光，都不是 Shader 的问题，而是阴影距离和级联阴影参数没有按场景尺寸调好，这个需要每个场景单独测，不能套一个全局参数走天下。
5.3 烘焙光照、后期效果与画质分级
画面表现上，悬疑推理游戏需要比较强的光影氛围。我们室内场景全部使用烘焙光照，动态物体用 Light Probes，部分需要动态阴影的角色单独加一个实时平行光并且只影响角色层。烘焙光照贴图的参数挺折腾：光照贴图分辨率、间接强度、反弹次数、以及 UV2 是否展开了。有时候场景没 UV2，烘焙出来一片黑，排查后发现是模型导入设置里 Generate Lightmap UVs 没勾。
后期效果用了 Post Processing Stack v2。颜色分级（Color Grading）、泛光（Bloom）、环境光遮蔽（Ambient Occlusion）和暗角（Vignette）是悬疑氛围的核心，泛光强度不能太高，否则会让暗场景显得浑浊。移动端我们关闭了环境光遮蔽，并且把泛光降到最低档，因为移动端 GPU 的 fillrate 很吃紧。
画质分级做得比较粗：PC 端最高画质开全特效；移动端根据设备内存和 GPU 型号自动选择低或中画质。我们没有做细粒度的手动画质档位，因为这个游戏类型对帧率的要求没有竞技游戏高，稳定在 30 帧以上就不会影响体验。
6. 工具链与协作流程：主程的另一半工作
6.1 对话编辑器、谜题配置工具与自定义 Inspector
团队规模不大的时候，主程除了写游戏逻辑，还要承担相当一部分编辑器工具开发。我们做的最值得的工具是一个对话编辑器窗口。它不仅能编辑对话树，还能直接在编辑器里模拟运行分支条件，查看某个节点在当前 GameState 下是否可见。这个工具让策划在出文本内容的同时就能自查逻辑，减少了大量测试反馈往返。
谜题配置工具相对简单，是一个 Wizard 窗口，输入谜题类型、场景交互点、谜题参数后，自动生成 PuzzleConfig 资产，并注册到章节流程里。相比手动创建资产再填字段，这种方式能避免很多低级错误，比如场景交互点的 ObjectId 写错、奖励线索 ID 不存在等等。
自定义 Inspector 方面，我们为 InteractableObject 做了场景内预览功能。编辑模式下选中一个可交互物体时，Inspector 下方会出现一个“模拟 GameState”区域，输入不同的变量值后，场景中的物体表现会实时更新。这个工具在验证“同一个物体在不同剧情阶段的表现”时非常高效，美术和策划不用频繁启动游戏就能检查表现。
6.2 文本导入、多语言与版本管理
对话文本如果直接让策划在 ScriptableObject 里填，翻译和排版会非常痛苦。我们做了文本导出/导入工具，支持把项目内所有对话和 UI 文本导出为 CSV，策划和本地化同学在 CSV 里维护，再导回项目中生成语言资产。这个流程在项目接近上线的本地化阶段帮了大忙，四国语言在一个星期内全部灌入，没有为翻译单独写一行代码。
版本管理用的是 Git + LFS。美术资源体量大，必须用 LFS 管理，否则仓库体积会失控。我们约定场景和 prefab 允许冲突合并且使用 Unity 的 YamlMerge 作为合并工具，但代码层面必须严格要求单人单模块，避免多人同时改同一个脚本。还有一个团队规范：所有配置资产的 Inspector 字段不能直接改 GUID，因为 GUID 是资产引用的核心，一旦改了场景里的引用全断，排查起来极其耗时。
6.3 自动化构建与多渠道打包的踩坑
自动化构建用 Unity 命令行批处理实现。我们搭了一个简单的构建脚本，支持 PC、Android、以及抖音侧边栏小游戏和微信小游戏这几个主要目标平台。构建脚本里封装了版本号注入、AssetBundle 构建、启动场景替换、以及平台相关后处理步骤。
踩过的坑有几个：一是 Android 打包时的 Gradle 配置，Unity 版本和 Gradle 版本要配套，否则构建报错会让人一头雾水；二是 AssetBundle 的变体管理，如果同一个资源被多个 Bundle 引用，要开启 Deterministic Asset Bundle 并统一依赖打包，避免重复资源被多次打进包体；三是抖音侧边栏和微信小游戏这类平台，本质上是 WebGL/小游戏环境，很多时候不能用完整的 C# 反射和文件 IO，需要针对这些平台写适配层。比如文件存档在小游戏平台上要改成用平台提供的存储接口，不能直接用 File.WriteAllText。
7. 上线前的排雷清单：那些容易忽略又致命的细节
7.1 常见问题速查表
整理一份我们项目里真实出现过的问题清单，按模块归类，方便大家对照排查：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 对话选项界面无法弹出 | UIStack 顶层的模态界面未关闭 | 检查所有调用 OpenUI 的地方是否成对调用 CloseUI |
| 读档后场景物体状态不对 | Scene 对象的 RefreshByState 未实现或遗漏 | 所有 InteractableObject 必须在 OnEnable 时调用状态重建 |
| 切换场景后内存持续上涨 | 场景资源没有卸载干净 | 使用 Addressables/AssetBundle 时检查引用计数，添加卸载日志 |
| 阴影闪烁或漏光 | 级联阴影距离设置不对或 Lightmap 参数问题 | 按场景尺寸单独调整 Shadow Distance，检查 UV2 |
| 小游戏平台存档丢失 | 使用了 File IO 而非平台存储接口 | 写平台适配层，切换存档读写实现 |
| UI 中文乱码 | 动态字体 Atlas 尺寸不够或者字体 Fallback 配置缺失 | 预烘焙常用字，并配置 Fallback 字体资产 |
| 长时间游玩后帧率下降 | 对象池使用不当导致泄漏或频繁 GC | 用 Profiler 抓 Hot Path，检查生成对象是否放回池中 |
7.2 平台适配：从 PC 到移动端再到小游戏
多平台发布是Unity项目的常态。我们一开始只准备做 PC，后来加了移动端，最终又进了抖音侧边栏和微信小游戏渠道。这个过程中最痛苦的不是渲染差异，而是输入和存档差异。PC 上用鼠标点击交互，移动端要用触屏，小游戏则要兼容浏览器的安全区。我们的解决方案是抽象了一个 InputAdapter，统一提供点击、长按、拖拽、返回键等语义化输入接口，底层根据平台不同分别实现。
UI 适配也踩了不少坑。悬疑推理游戏的任务栏、对话文本、背包网格在窄屏上很容易挤成一团。我们用 Unity 的 Canvas Scaler 以宽度适配为主，针对平板和 PC 大屏额外做了 SafeArea 适配。小游戏平台要特别注意刘海屏和安全区，不然按钮会顶到屏幕边缘点不到。
7.3 性能 Profile 实战案例
项目中期接到测试反馈，说某个章节场景在低端安卓机上帧率掉到 15 帧以下。我用 Profiler 抓了一轮，定位到一个很典型的问题：场景里有大量可交互物品，每个物品都在 Update 里做射线检测和描边高亮，CPU 消耗被这些高频检测打爆了。
优化方案分两步：第一步，把高亮描边的判断改成只在玩家靠近时触发，用 OnTriggerEnter/OnTriggerExit 替代每帧距离检测；第二步，把可交互物品的更新频率做分级管理，屏幕中心附近的物品每帧检测，其他物品每 0.2 秒检测一次。这两步优化直接把该场景的 CPU 耗时降了一半以上。另一个案例是对话中出现卡顿，抓包发现是每次对话加载时都会实例化大量 UI 组件。改成 UI 对象池后，对话打开耗时从 300ms 降到了 50ms 左右。
8. 项目复盘：如果让我重做一遍，会改什么
做完整整一个项目周期，回看当初的架构决策，有几个地方如果重来我会调整。
第一，会把资源管理直接上 Addressables，而不是自己封装 AssetBundle。自研方案在项目初期确实灵活，但中后期随着资源依赖越来越复杂，引用计数和依赖管理占用了不少维护精力。Addressables 的弱引用管理和自动依赖加载可以省掉这部分成本。
第二，会更早地引入自动化测试。推理游戏的剧情分支和变量组合非常多，纯靠人工回归测试根本覆盖不过来。我们后期补了一些 PlayMode 测试，但只覆盖了核心流程。如果项目启动时就搭建好基于场景的自动化冒烟测试，每次改剧情配置后跑一遍，能省下大量的修 Bug 时间。
第三，路径与工具的统一要在团队里更早形成共识。像字体预烘焙、图集规范、场景检查清单这些东西，如果美术和策划能从项目第一天就遵守，后期返工会减少很多。
最后再分享一个小技巧：给所有场景和 UI 界面都加上一个开发者调试快捷键，可以在运行时查看当前 GameState 的全部变量值，也可以直接修改任意变量来跳剧情。这个功能从开发第一天起只花了半天时间做，但整个项目周期里，它帮我们节省的时间绝对是数以周计的。每次测试报 Bug，我第一件事就是用调试面板把 GameState 拉到出问题的状态，立刻复现，定位速度极快。如果你也在做分支剧情类游戏，这个调试工具值得优先做。
