在 Unity 客户端开发中UI 是迭代最频繁、工作量最容易被低估的部分。一张 PSD 设计稿出来后程序需要手动切图、导入资源、摆 UI 层级、逐项绑定控件、再写一堆获取和事件注册代码设计稿一旦调整这套流程还要重来一遍。ETYIUI 这类工具解决的就是这个问题它读取 PSD 的分层信息自动生成 UI 预制体自动完成控件绑定并生成对应的 C# 代码骨架把“看设计稿手拼 UI”变成“一键导入生成”。本文会围绕这套工作流展开说明它背后分成哪几个环节每个环节要解决什么问题并给出可落地的命名规范、生成规则、代码结构和排错清单。这套方案主要适合三类读者频繁对接 PSD 设计稿的 Unity 客户端开发、想减少重复 UI 搭建工作的技术负责人以及准备在团队内部建设 UI 自动化生成工具的工程师。读完这篇文章你可以掌握一套“PSD 分层 - 解析 - 生成预制体 - 绑定控件 - 生成代码”的完整思路并能在自己的项目里复刻最小可用版本。1. 先弄清楚自动化生成工作流的四个环节1.1 PSD 分层里到底藏了哪些可控信息一张规范设计的 PSD不只是“一张图”它本质上是带有层级信息的资源描述文件。每一层都可能包含以下信息图层名称设计稿里最有价值的信息。只要团队约定好命名后缀工具就能靠图层名判断当前层应该生成 Button、Image、Text 还是 EmptyNode。图层尺寸和坐标决定最终 UI 节点在预制体中的 RectTransform 位置、宽高和锚点。图层顺序PSD 中从上到下的顺序通常对应 UI 中从后到前的显示顺序需要反转为 Unity 的层级顺序。图层可见性隐藏图层通常不导出但可以约定“以 _hide 后缀保留隐藏状态”用于特殊逻辑。图层分组PSD 中的组可以映射为 UI 中的空节点、Panel 节点或 ScrollView 的内容节点。文本图层如果直接用 PSD 的文字层工具可以生成 Unity Text 或 TMP 组件并保留位置和尺寸。所以真正的自动生成本质是“把设计稿的分层信息翻译成 Unity 场景中的节点树和组件参数”。翻译规则越清晰自动化程度越高。1.2 自动化链条解析、导入、生成、绑定一套完整的 ETYIUI 方案通常会拆成下面四个环节。解析层读取 PSD 二进制结构或解析从 Photoshop 导出的中间文件把图层名称、类型、坐标、尺寸、层级、可见性、字体信息提取成统一的数据结构。导入层把 PSD 中的可见图层导出为 PNG 等 Unity 可识别资源写入指定目录并完成 Texture Type、Sprite Mode、Packing Tag、九宫格 border 等导入设置。生成层根据解析出来的节点树在 Unity Editor 中创建空 GameObject挂载 RectTransform、CanvasRenderer、Image、Button、Text 等组件生成 UI 预制体。绑定层根据命名规则生成绑定映射表再生成 C# 代码把预制体中的控件引用、事件监听和初始化逻辑写进代码。这四个环节可以有各自独立的脚本也可以合并成一个一键执行的菜单入口。实际项目中建议拆开因为设计稿调整时解析层和生成层经常要比绑定层执行更频繁。1.3 什么场景适合全自动什么场景需要半自动全自动生成并不适合所有 UI。下面按场景区分场景自动化程度原因活动页、公告页、静态展示界面全自动结构固定、控件类型简单、不涉及复杂交互弹窗、常规设置页、个人信息页高自动 少量手动控件以 Button、Text、Image、Slider 为主可自动生成再手工补逻辑复杂战斗 HUD、捏脸、跨场景编辑器 UI半自动涉及大量动态生成、多语言、特殊动画全部自动会过度设计图表、地图、自定义绘制的 UI不建议自动核心逻辑在代码绘制或数据驱动PSD 只作为背景参考遇到复杂 UI可以只自动生成初始预制体和代码骨架再手动补充交互细节。最忌讳的是设计稿本身就混乱期望靠工具一键解决所有问题。2. 环境准备依赖、目录和设计稿规范2.1 Unity 与依赖环境ETYIUI 的落地需要一套相对干净的环境。以下是一个基础参考项目建议要求说明Unity 版本2021.3 LTS 或更高涉及 UGUI 和 Editor 脚本较多新版本 API 差异集中在 RectTransform 和 AssetDatabase 上UI 方案UGUI 或 UI Toolkit多数工具方案基于 UGUI本文以 UGUI 为例PSD 解析库自行解析或使用 PSD 解析库如果只需要“文字层 图片层 分组”信息可以自行实现轻量解析文本组件TextMeshPro 或 UGUI Text建议统一使用 TMP生成代码和资源管线更一致代码语言C#Editor 脚本与运行时脚本可放同一程序集注意按功能拆开注意如果原始项目没有统一 UI 规范先不要直接上全量自动化。建议先在一个子模块试点把命名规则和生成结果跑通再逐步推广。2.2 工程目录设计目录结构会影响脚本扫描路径和资源导入位置建议在一个固定根目录下组织所有生成产物。Assets/ ├── ETYIUI/ │ ├── Editor/ │ │ ├── PSDImporter.cs │ │ ├── UIBuilder.cs │ │ ├── CodeGenerator.cs │ │ └── BindingTableGenerator.cs │ ├── Runtime/ │ │ ├── UIBindNode.cs │ │ ├── UIBase.cs │ │ └── UIComponentMap.cs │ ├── Templates/ │ │ ├── UIPanelTemplate.txt │ │ └── BindingMapTemplate.json │ └── Settings/ │ └── ETYIUI_Settings.asset ├── UIRes/ │ ├── PSD/ // 源文件放置目录 │ ├── Prefabs/ // 生成的预制体 │ ├── Atlas/ // 自动生成的图集资源 │ └── Sprites/ // 自动导出的单张图片 └── Scripts/ └── AutoGenerated/ // 自动生成的 UI 绑定代码PSD 源文件放在UIRes/PSD生成产物分别落到 Prefabs、Atlas、Sprites 和 AutoGenerated 四个目录。这样清理和回滚都比较方便也不会污染手写代码目录。2.3 设计稿与 PSD 导出规范自动化工具的天敌是命名混乱。如果一个按钮图层叫“图层 12”工具无法判断应该生成 Button 还是 Image。下面是一套比较稳妥的命名规范图层名后缀生成类型说明_btnButton可点击按钮生成 Image Button 可绑定事件_imgImage静态图片无点击逻辑_txtText/TMP文本生成 TMP_Text 组件并绑定到代码_sliderSlider滑条生成 Slider 及子节点结构_inputTMP_InputField输入框_scrollScrollView可滚动区域_node空节点辅助层级结构或容器_bgImage背景图通常位于层级最底部_hide保留但不显示生成节点但初始隐藏用于动态内容实际项目还可以进一步扩展比如_icon_img表示带特效的图标、_progress_fill表示进度条填充部分。命名规则越固定生成规则就越简单。3. 核心实现一解析 PSD 并生成 UI 预制体3.1 解析分层数据并识别控件类型第一步是读取 PSD 文件把图层信息转换成中间数据结构。这里给出一个简化版示例目的是说明“解析 - 识别 - 转换”的流程。实际项目中要根据自己的 PSD 解析库调整。public class PsdLayerItem { public string Name; public string GroupPath; public bool Visible; public float X; public float Y; public float Width; public float Height; public PsdLayerType LayerType; public string FontName; public int FontSize; public string TextContent; } public enum PsdLayerType { Image, Text, Group }把 PSD 原始层转成PsdLayerItem后再根据命名后缀识别控件类型。public static string ResolveComponentType(string layerName) { if (layerName.EndsWith(_btn)) return Button; if (layerName.EndsWith(_slider)) return Slider; if (layerName.EndsWith(_txt)) return TMP_Text; if (layerName.EndsWith(_input)) return TMP_InputField; if (layerName.EndsWith(_scroll)) return ScrollView; if (layerName.EndsWith(_img) || layerName.EndsWith(_bg)) return Image; if (layerName.EndsWith(_node)) return Empty; if (layerName.EndsWith(_hide)) return Hidden; return Image; }需要强调几点。图层坐标在 PSD 中通常以左上角为原点而 Unity 的 RectTransform 锚点和 pivot 会影响最终位置所以坐标转换时要先统一坐标空间。图层分组映射到空节点时分组的尺寸对子节点布局非常重要建议尽可能输出分组的 bounds。如果 PS 脚本能直接把图层导出成 JSON 描述文件解析环节会更稳定因为可以避开不同 PSD 版本带来的二进制结构差异。3.2 生成 Sprite、处理九宫格和图集解析完成后需要把图片图层导出成 Unity 资源。常见做法有两种直接用 C# 读取 PSD 指定图层并保存为 PNG。在 Photoshop 里运行导出脚本先导出一批带透明通道的 PNG再交给 Unity 工具生成 Sprite 和图集。推荐第二种兼容性更好尤其是遇到智能对象、图层样式、混合模式等情况时直接解析 PSD 很难百分之百还原视觉。生成 Sprite 时关键是设置导入参数。一个典型的参数设置如下TextureImporter importer (TextureImporter)AssetImporter.GetAtPath(spritePath); importer.textureType TextureImporterType.Sprite; importer.spriteImportMode SpriteImportMode.Single; importer.mipmapEnabled false; importer.filterMode FilterMode.Bilinear; importer.textureCompression TextureImporterCompression.Compressed; importer.spritePackingTag panelAtlasName; importer.spriteBorder borderValue; // 九宫格边界来自 PSD 图层配置或手动设置 AssetDatabase.ImportAsset(spritePath, ImportAssetOptions.ForceUpdate);如果按钮背景需要九宫格必须在 PSD 图层命名或配套配置里声明 border。否则生成出来的 Image 会被默认当普通图使用拉伸后边缘会变形。生成到 Atlas 目录的 Sprite可以进一步通过 Sprite Atlas 系统打图集。注意如果同一个面板存在多个同名图层或命名冲突图集 Sprite 也会冲突最后预制体会引用错图。3.3 构建预制体层级和 UI 组件中间数据结构准备好之后生成预制体就变成一个“按树状结构创建 GameObject”的过程。public static GameObject BuildUIPrefab(PsdNodeTree tree, string prefabPath) { GameObject root new GameObject(tree.Name); RectTransform rootRect root.AddComponentRectTransform(); rootRect.sizeDelta new Vector2(tree.Width, tree.Height); foreach (PsdNode child in tree.Children) { GameObject childGo CreateNodeFromPsd(child, root.transform); // 内部会根据 child 的类型挂载 Image、Button、Text 等组件 } PrefabUtility.SaveAsPrefabAsset(root, prefabPath); Object.DestroyImmediate(root); return AssetDatabase.LoadAssetAtPathGameObject(prefabPath); }生成节点时的核心逻辑包括设置name为图层名去掉后缀避免运行时查找名字时还要拼后缀。设置RectTransform.anchorMin和anchorMax。如果设计稿有明确的对齐方式可以根据图层坐标和父节点尺寸计算锚点。设置pivot。UI 编辑器里通常用中心点但 PSD 图层坐标是左上角需要转换。根据控件类型挂载组件。比如_slider不只是挂一个 Slider还需要生成 Background、Fill Area、Handle Slide Area 等子结构。生成完成后会出现一个可以正常打开的预制体。在这一步先不要急着生成代码而是先在 Unity 里拖动检查节点层级、图片引用和锚点是否符合预期。3.4 命名规则和关键参数表下面这张表整理了图层解析阶段常用的参数和影响便于后续排查。参数默认值调大影响调小影响错误配置表现锚点计算精度自动对齐不适用可能出现边缘浮点偏差缩放后子节点偏移PSD 坐标缩放1最终 UI 变大最终 UI 变小布局与设计稿不一致图集 Tag面板名合图数量变少合图数量变多Sprite 引用跨包混乱九宫格 Border0拉伸时边缘变形小边缘拉伸变形圆角被拉成直角生成预制体阶段最容易出现的问题有三个锚点没算对导致不同分辨率下位置漂移图层名重复导致覆盖图集 Tag 设置错误导致 Sprite 引用异常。下一节会涉及代码生成这里先保证预制体本身是正确的。4. 核心实现二自动绑定与代码生成4.1 绑定规则设计的核心思路UI 预制体生成后还要让代码能方便地拿到控件并监听事件。手动在 Inspector 拖拽引用最大的问题是预制体重做后引用丢失、多人协作时冲突多。自动绑定要解决的就是这个问题。绑定方式有三种常见思路。按路径查找运行时通过transform.Find(xxx)查找控件性能差且改名后失效。按映射表绑定生成一个 JSON 或 ScriptableObject 映射表记录“控件名 - 路径 - 组件类型”运行时统一绑定。按代码生成强引用直接生成 C# 字段和初始化代码让 IDE 能感知到所有控件。ETYIUI 推荐使用“映射表 生成代码”组合。映射表解决“控件在哪”生成代码解决“代码里怎么使用”。这样即使预制体微调只要路径不变代码就没有影响。4.2 生成绑定映射表每个面板对应一张绑定映射表典型 JSON 结构如下。{ panelName: MainMenuPanel, prefabPath: Assets/UIRes/Prefabs/MainMenuPanel.prefab, bindings: [ { fieldName: StartBtn, path: Root/StartBtn, componentType: UnityEngine.UI.Button }, { fieldName: TitleText, path: Root/TitleText, componentType: TMPro.TMP_Text }, { fieldName: PlayerIcon, path: Root/Head/PlayerIcon, componentType: UnityEngine.UI.Image } ] }这段 JSON 里每个字段都有明确含义fieldName是生成后的 C# 字段名会从图层名去掉后缀并转换为大驼峰风格。path是控件在预制体中的相对路径运行时会按照这个路径查找。componentType是组件类型决定绑定完成后赋值给哪个字段。生成绑定表的逻辑可以基于之前解析的节点树直接序列化。注意如果图层名包含非法字符或与 C# 关键字冲突需要在生成字段名时做一次清洗和去重。4.3 生成 C# 控件代码与事件代码拿到映射表之后可以根据模板生成面板的基类代码。下面是简化后的模板产物。// auto-generated // 由 ETYIUI 生成不要手动修改此文件。 // 修改后运行生成工具会被覆盖。 // /auto-generated public partial class MainMenuPanel : UIBase { public UnityEngine.UI.Button StartBtn; public TMPro.TMP_Text TitleText; public UnityEngine.UI.Image PlayerIcon; public override void BindUI(Transform root) { StartBtn root.Find(Root/StartBtn).GetComponentUnityEngine.UI.Button(); TitleText root.Find(Root/TitleText).GetComponentTMPro.TMP_Text(); PlayerIcon root.Find(Root/Head/PlayerIcon).GetComponentUnityEngine.UI.Image(); } }事件代码可以在生成的 partial 类里补充。例如生成一个空方法开发者在另一个文件中实现public partial class MainMenuPanel : UIBase { public override void RegisterEvent() { StartBtn.onClick.AddListener(OnStartBtnClicked); } partial void OnStartBtnClicked(); }这样做的价值在于绑定代码是自动生成的事件处理逻辑是手写的。再次生成时只覆盖自动生成的文件手写逻辑放在另一个 partial 文件里互不干扰。4.4 局部刷新与重复生成保护重复生成最容易带来两个灾难文件被覆盖但内容已经被手改过同一个面板生成了多个重复代码文件导致编译错误。推荐在生成脚本里做三重保护每个生成文件头部写入// auto-generated标记生成前检查目标是否被修改必要时输出警告。文件名带面板名生成前先删除旧的同名前缀文件避免残留。字段名重复时追加序号并输出警告日志提醒设计者修改命名。一个简单的生成保护逻辑如下if (File.Exists(targetPath)) { string oldContent File.ReadAllText(targetPath); if (!oldContent.Contains(auto-generated)) { Debug.LogWarning($跳过覆盖非自动生成文件: {targetPath}); return; } }这样既能保证重复生成的稳定性也能防止工具误覆盖开发者整理过的代码。5. 运行验证与常见问题排查5.1 生成后必须做的验证清单生成并不是终点运行时正确才是终点。每次生成后建议按下面的清单验证。预制体能否在场景中正常打开节点层级是否与 PSD 分组一致。所有 Image 是否引用到了正确 Sprite是否进入预期的图集。文本控件是否绑定了正确的字体资源中文字体是否缺失。Button 等控件是否有独立的可点击范围Image Raycast Target 是否正确。在 16:9、18:9、刘海屏等比例下锚点和拉伸是否正常。运行后打开面板检查 BindUI 绑定过程是否输出空引用日志。比较高效的方式是写一个 Editor 校验脚本在生成后自动扫描预制体列出所有GetComponent可能失败的点。例如缺少 RectTransform、Image 引用空 Sprite、Button 没有关联点击区域。5.2 高频问题与处理方案下面这些坑在实际落地中非常常见建议直接整理成开发文档。问题现象常见原因检查方式处理建议生成后按钮没有点击效果Button 的 Image Raycast Target 被关闭或子物体挡住了点击检查热区节点、EventSystem 配置确保 Image Raycast Target 开启确认 Blocking 层级九宫格图片拉伸后边缘变形导入时 spriteBorder 未设置查看 TextureImporter.spriteBorder在 PSD 图层配置里声明 border 或按按钮尺寸计算文本字体丢失或变成默认字体生成代码里只写了 TMP_Text没有赋值字体资源检查预制体 Text 组件在映射表里增加字体字段生成时统一赋值不同分辨率下位置漂移锚点和 pivot 计算错误切换 Game 视图分辨率测试根据设计稿对齐规则计算 anchorMin/anchorMax同名图层互相覆盖图层名重复字段名冲突查看生成日志是否提示去重要求设计稿命名唯一必要时用路径前缀隔离图集内 Sprite 引用错乱spritePackingTag 设置错误检查 SpriteAtlas 引用按面板或模块设置 packTag不要所有素材打一个包5.3 从现象倒推根因的排查链路遇到生成后的 UI 问题时不要直接改预制体先按下面顺序排查。确认 PSD 源文件是否为最新版本重新解析后的 JSON 是否符合设计稿。确认生成日志里是否有“图层未识别”“字段名重复”“路径不存在”等警告。打开预制体看节点层级是否完整是否缺少_node容器或_scroll内部结构。检查 Sprite 导入参数Texture Type、Sprite Mode、Packing Tag、Border。检查图集设置是否启用了 Include in Build是否多个面板共用冲突 Tag。运行下面代码片段检查绑定是否完整。[ContextMenu(Dump Bindings)] public void DumpBindings() { BindUI(transform); Debug.Log($StartBtn: {StartBtn ! null}); Debug.Log($TitleText: {TitleText ! null}); Debug.Log($PlayerIcon: {PlayerIcon ! null}); }如果绑定结果为 null优先看root.Find的路径是不是和预制体实际层级一致。很多问题不是代码生成错而是生成时节点路径用错了分隔符或前面多了根节点名。6. 生产环境里的落地建议与扩展方向6.1 命名规范和图层结构规范要让工具长期稳定运行最重要的不是代码写得有多复杂而是团队愿意遵守命名和分层规范。建议在项目文档里固定下面几条。一个 PSD 对应一个 UI 面板预制体不要在一个 PSD 里堆多个弹窗。所有可交互控件必须有明确后缀且后缀固定写在图层名结尾。文本图层建议使用统一字体避免一个面板里出现多种字符集。背景、内容、遮罩、关闭按钮等常见层级放在固定分组里方便工具按固定规则处理。每个 PSD 提交到版本库时附带一份 JSON 导出文件避免依赖 PS 插件版本。对于设计侧和程序侧的分工可以这样约定设计负责保证图层命名、分组和可见性正确程序负责维护解析规则、生成模板和绑定规则。工具使用过程中出现的生成异常按照 5.3 的排查链路处理即可。6.2 代码生成后的维护策略自动生成的代码不建议直接手改。如果你需要追加逻辑使用 partial 类或者扩展方法避免生成时覆盖。推荐的文件结构如下MainMenuPanel/ ├── MainMenuPanel.cs // 手写 Partial事件逻辑 ├── MainMenuPanel.Bindings.cs // 自动生成字段绑定 ├── MainMenuPanel.Events.cs // 自动生成事件注册骨架 └── MainMenuPanel.BindingMap.json // 自动生成映射表自动生成文件统一使用auto-generated标记并且只在项目构建和 PSD 更新时重新生成。日常开发只改手写文件。另外不要在生产环境里让生成工具监听文件变化后自动执行否则多人修改 PSD 时会导致生成冲突。建议改成手动菜单触发ETYIUI/Generate All、ETYIUI/Generate Current Panel、ETYIUI/Generate Bindings Only。6.3 版本管理与自动化检查入库阶段建议做一次静态检查保证生成内容处于可发布状态。可以写一个 Editor 批处理在打包前运行。检查所有 PSD 源文件是否已导出为预制体是否存在源文件更新但产物未生成的情况。检查所有生成代码文件是否包含了自动生成标记防止手改文件被覆盖。检查资源目录里是否存在孤立 Sprite、孤立图集和未使用的预制体。检查 UI 绑定映射表和预制体路径是否一致防止路径漂移。这一步可以用 Unity 的 BatchMode 在 CI 上跑/Applications/Unity/Hub/Editor/2021.3.30f1/Unity.app/Contents/MacOS/Unity \ -batchmode \ -projectPath /path/to/project \ -executeMethod ETYIUI.Editor.UICheckTools.RunAllChecks \ -quit在代码里检查工具遍历UIRes/Prefabs和Scripts/AutoGenerated任何不一致都输出错误并返回非零退出码。6.4 扩展方向多格式、差异检测、UI 测试ETYIUI 落到稳定之后可以继续向下面几个方向扩展。支持 Figma、Sketch 插件导出 JSON甚至支持蓝湖、即时设计等平台的结构化导出这样不局限于 Photoshop。增加预制体差异检测。对比上一版生成结果输出“新增节点、删除节点、字段名变化、路径变化”降低回归风险。与自动化 UI 测试结合。生成代码时顺便输出控件路径清单测试框架可以按路径查找控件减少写 UI 测试用例的成本。接入多语言。生成 TMP 文本时直接绑定本地化 key而不是写死字符串内容。对于一个长期维护的项目来说PSD 转 UI 的自动化工具不是一次性的效率工具而是 UI 工程化的一部分。设计稿规范、生成规则、绑定映射、代码模板和 CI 检查需要一起演进才能让“设计稿到代码”的链路保持稳定。实际落地时先拿两个低风险面板跑通全流程再逐步扩大范围不要一开始就试图覆盖所有复杂 UI。工具的价值不在于把所有界面一次生成完整而在于把重复性工作变成可维护、可回滚、可校验的工程流程。下一阶段团队还可以把这套工具扩展成 UI 资产管理平台把设计稿、预制体、绑定代码和测试用例放在同一条流水线里管理那才是自动化生成真正的长期收益。