第 1 章 Looking Back, Looking Forward：从旧 GUI 到新 UI

问题：为什么作者用近半章回顾旧 GUI，而不是直接介绍 Canvas

先预测：同一个按钮如果在 OnGUI 每帧声明一次，与作为场景中的 Button 组件长期存在，调试状态、动画、焦点和扩展方式会有什么不同？第一章用旧系统的完整轮廓回答这个问题。旧 GUI 并非毫无能力，它提供 Label、Texture、Button、TextField、Box、Toggle、Toolbar、Slider、Scrollbar、ScrollView、Window、Style、Skin、事件与自动布局；问题在于状态与绘制混在即时调用中，复杂界面会迅速失去可见结构。

原书边界与小节库存

原章先盘点 State of play 与 GUI controls，逐项走过 Label、Texture drawing、Button、Text、Box、Toggle/checkbox、Toolbar panels、Slider/Scrollbar、ScrollView、Rich Text Formatting、分组、命名、焦点、Tooltips、Window、GUI styles and skins、GUI events and properties、BeginArea 与横纵布局。随后才进入 New layouts、Rect Transform、Canvas、Groups、Masking、New controls、New UnityEvent system、Control extensibility 和 Animation，并用当时的 Asset Store 生态结束比较。

• State of play；GUI controls；Label、Texture drawing、Button、Text、Box 与 Toggle/checkbox
• Toolbar panels；Slider/Scrollbar；ScrollView；Rich Text Formatting 与 common control features
• Grouping controls；Naming controls；Getting in focus；Tooltips；Window
• GUI styles and skins；GUI events and properties；Layout controls；BeginArea；Horizontal and Vertical layout groups
• New layouts；Rect Transform；Canvas；Groups；Masking；New controls
• New UnityEvent system；Control extensibility；Animation；当时的 Asset Store 扩展

这份库存用于唯一归属，而不是逐字转载。每个条目只在一个原章中计数，页面用重新组织的解释、实验和图示复现其核心问题。读者应能从条目回到页面证据，也能从页面结论指出对应的原始范围。

即时声明与保留对象的差异

旧 IMGUI 每帧执行 OnGUI，代码同时声明控件、读取事件并决定绘制；新 UI 则把 GameObject、RectTransform、Graphic、CanvasRenderer 与事件组件保存在场景中。前者便于快速调试面板，后者让层级、序列化引用、动画轨道、导航和美术协作变得可见。核心变化不是“函数变组件”这么简单，而是状态拥有者从瞬时调用转成持久对象，布局从调用顺序转成父子约束，事件从 Event.current 分支转成可路由的 UnityEvent 与接口。

五个核心术语与责任边界

不是孤立术语。它要放回本章的数据流中，说明谁产生它、谁修改它、谁消费它，以及配置错误时会出现什么可观察结果。

不是孤立术语。它要放回本章的数据流中，说明谁产生它、谁修改它、谁消费它，以及配置错误时会出现什么可观察结果。

不是孤立术语。它要放回本章的数据流中，说明谁产生它、谁修改它、谁消费它，以及配置错误时会出现什么可观察结果。

不是孤立术语。它要放回本章的数据流中，说明谁产生它、谁修改它、谁消费它，以及配置错误时会出现什么可观察结果。

不是孤立术语。它要放回本章的数据流中，说明谁产生它、谁修改它、谁消费它，以及配置错误时会出现什么可观察结果。

术语必须能落到对象和状态，而不能只背定义。阅读 Inspector、运行日志或源码时，为每个术语写出输入、拥有者、输出和失败信号；若无法指出责任对象，就还没有形成可调试的心智模型。

关键对象与数据流

比较实验应保持视觉目标一致：先用 OnGUI 做一个含文本、按钮、滑条和滚动区的面板，再用 Canvas 层级复现。记录代码位置、可视层级、焦点、样式复用、动画和事件连接。观察不是为了宣判旧系统“错误”，而是确认复杂度在何处增长，以及新系统把哪些隐式关系变成了 Inspector 中可检查的对象。

同一个视觉现象可能来自不同链路：位置错误通常来自几何写入者，点击错误来自射线与事件，显示顺序来自 Canvas 和相机，版本错误来自历史载体与现代 API 混写。实验必须先选定要证明的链，再控制无关变量。

正常、边界与失败样本

一个完整实验至少包含正常输入、极端输入和故意破坏配置。正常样本证明主路径可用，边界样本说明数值或设备范围，失败样本则暴露隐式依赖。只保留成功截图会让后续读者无法区分偶然成功和稳定契约。

从 2015 年到现代 Unity

今天复现时可以用 TextMeshPro 替代旧 Text，用新输入系统模块替代 StandaloneInputModule，但应保留“持久层级、矩形约束、可路由事件”这三个不变量。当时列举的 TextMeshPro 还是付费 Asset Store 扩展，今天已成为常用包；这是一项版本变化，不能倒写成原书发布时的默认事实。旧 OnGUI 仍可用于少量运行时调试，而生产界面通常选择 uGUI 或 UI Toolkit。

迁移记录必须把“原书说了什么”和“今天怎样实现”并排放置。允许替换 API、包和资源，不允许删除原问题或把新版能力倒写成 2015 年事实；无法等价时应保留差异和失败证据，而不是强行宣布一一对应。

验收证据

验收证据应包含同一界面的旧、新实现，至少一次焦点切换、一次遮挡命中、一次动画或样式变化，并能说明状态由谁持有。关闭 EventSystem 后按钮不响应、启用 Raycast Target 的透明图像拦截输入，都应作为失败样本保存。

证据包还应包含 Unity 版本、目标平台、场景路径、复现步骤和预期结果。交给另一位读者后，他不需要猜测隐藏参数就能得到同样结论，才算从“理解文字”进入“掌握系统”。

对照实验的判定标准

IMGUI 与 uGUI 的对照必须保持功能等价：相同菜单项、相同输入序列、相同禁用规则和相同输出状态。记录时分别标出声明发生的位置、状态保存的位置、布局计算时机、样式来源和事件消费者。若只让 uGUI 版本使用动画、Prefab 与可视化绑定，却不给 IMGUI 对应需求，结论会混入功能差异；反之只比较一行 Button 调用，也会忽略对象树、序列化和编辑器迭代价值。正确结果不是宣判谁永远更快，而是说明在何种复杂度和创作流程下，新系统解决了哪些旧约束。

小结

• 第一章完整回顾旧 GUI，目的是建立公平的架构对照
• 新 UI 的关键改变是持久对象、矩形约束、Canvas 渲染和可扩展事件
• 旧控件与新控件可以实现相似外观，但状态、布局和协作成本不同
• 现代包变化只能写进迁移边界，不能篡改 2015 年原始事实