一两年前我第一次认真整理工程项目里的编辑器脚本时发现光是“给美术资源改名”这个需求工程里就躺着五个版本。有人把逻辑写在 MenuItem 里有人写在自定义窗口的按钮回调里还有人干脆每次手动改完再复制一份备份。正是这种混乱让我下定决心做一个统一的 Dan_Tools一套面向 Unity 编辑器的工具集把资源批处理、场景巡检、数据监控和项目健康检查这些高频操作统一封装成稳定可复用的函数。这个工具集的目标不是“什么都能做”而是让 80% 的重复编辑器操作变成一个菜单点击。无论你是团队里的工具开发者还是独立项目做到中期急着提升效率这篇文章都值得继续读下去。我在开发过程中逐渐意识到很多编辑器工具不是写不出来而是没有一套好用的骨架去承载。今天我把 Dan_Tools 的模块划分、核心函数实现思路、接入方式和踩坑记录都翻出来当作一次复盘也给有同样需求的人一个可以直接参考的方案。1. 项目背景与工具集整体设计思路1.1 编辑器脚本失控是时候做一次收口了Unity 项目跑到中期最容易出现的问题不是玩法代码屎山而是“编辑器脚本灾难”。每个程序在进项目时都会顺手写几个小工具有人做 UI 的写了批量替换字体有人做战斗的写了刷怪点导出有人做寻路的写了路径预览。这些脚本一开始都很好用但后来问题逐渐暴露第一重复实现。团队五个人可能写了五份功能类似的工具各自叫 BatchRenameTool、MassRenameWindow、RenamerX美术同学根本分不清该用哪个。第二行为不一致。同样是把图片压成 ASTCA 工具保留 mipmapB 工具默认关闭 mipmap不同的人跑出来的资源效果不一样最后反馈到表现层就是一团乱麻。第三维护成本。你三个月后回来看自己写的脚本想改个功能得先花半小时回忆当时的变量命名逻辑。Dan_Tools 最开始就是冲着“收口”这两个字去的。我给自己定了几条规矩所有工具入口统一挂在 Tools/Dan_Tools 菜单下所有对外功能都走静态函数接口核心逻辑不依赖编辑器窗口实例能批量就不要单点操作。这三条规矩看似简单实际执行下来效果非常好后来团队里新来的同学只需要看一遍菜单结构就知道哪个功能在哪个位置。1.2 四层模块划分入口、逻辑、操作、回显工具集的功能数量一旦多起来最怕的就是每个窗口各写各的没有统一的代码结构。我在重构 Dan_Tools 时把它拆成了四个层次这个思路我觉得比具体代码更值得分享。入口层负责一切用户交互入口包括 MenuItem、自定义快捷键、右键菜单。入口层不应该有任何业务逻辑它只负责接收参数、做参数校验、然后调用下一层。逻辑层是纯 C# 的数据处理比如计算一张贴图的宽高比、生成资源依赖关系图、统计场景内物体数量这一层不引用任何 UnityEngine 的编辑器 API目的是方便单元测试和逻辑复用。操作层真正对 Unity 资源或场景做修改比如 AssetDatabase 导入、预制体实例化、序列化属性修改所有改数据的行为都在这一层完成。回显层最后才是 EditorWindow 或自定义 Inspector 的 UI 绘制它只负责把操作层算出来的结果展示出来。为什么非要分这么细因为编辑器工具最恶心的场景就是你改了一处 UI 的显示文案不小心影响了真正改数据的代码你给窗口加了一个进度条结果批处理函数被拖慢了 30%。拆开之后逻辑层和操作层完全不依赖 UIUI 重构只是换皮核心函数纹丝不动。我自己重构过几次之后最深的体会是分层不会让你写代码变快但会让你改代码变快十倍。1.3 IMGUI 与 UI Toolkit 之间的技术选型取舍Unity 编辑器扩展的技术栈现在其实有两个选择一类是传统的 IMGUIOnGUI、GUILayout、EditorGUILayout另一类是新的 UI ToolkitUXML、USS、VisualElement。Dan_Tools 最终选择了 IMGUI 作为主要交互层原因有两条。第一兼容性。UI Toolkit 在部分老版本 Unity 项目里跑起来有兼容问题而我们团队既有 2020 LTS 的项目也有 2021 LTS 的项目IMGUI 从 5.x 时代就稳定存在任何版本都不会出幺蛾子。第二灵活性。IMGUI 写起来非常直觉化一个 EditorWindow 里用 EditorGUILayout 就能快速堆出一个好用的面板不需要额外维护 UI 文件对工具类项目来说效率第一。但我也不是完全排斥 UI Toolkit。在 DataDashboard 这类需要大量列表滚动、频繁刷新显示的面板上UI Toolkit 的样式一致性确实更好。我的建议是如果你的工具是给少量内部用户用的功能型工具IMGUI 完全够用如果未来要交付一个带品牌感和复杂交互的编辑器产品那就值得用 UI Toolkit 认真做一套。工具集本身不一定要绑死一个框架核心函数层和表现层分离的好处在这里也体现出来了。2. 核心功能函数的实现拆解2.1 资源批处理函数BatchProcessor资源批处理是 Dan_Tools 里使用频率最高的一块它解决的痛点很典型几百张贴图要统一压低内存几十个材质要修改渲染队列多个 Sprite 图集要切换平台格式手工操作一次就容易漏。BatchProcessor 的核心设计是“先选中后执行”。你在 Project 窗口选中一批资源然后在菜单里点击对应批处理项工具会遍历 Selection.objects 拿到资源路径再通过 AssetImporter 做属性修改。这里有一个很重要的原则所有操作都要走 AssetDatabase而不是直接走 File.IO 操作文件。原因是 AssetDatabase 会维护 Unity 的资源索引、导入状态和依赖关系你用系统 API 直接改文件Unity 的缓存不会及时感知最后要么报 meta 文件错乱要么资源丢失引用。下面是我在实际项目里用的贴图压缩函数片段环境是 Unity 2021.3using UnityEngine; using UnityEditor; namespace DanTools { public static class BatchProcessor { [MenuItem(Tools/Dan_Tools/资源批处理/一键压缩选中贴图)] public static void CompressSelectedTextures() { var selected Selection.objects; if (selected.Length 0) { EditorUtility.DisplayDialog(Dan_Tools, 请先在 Project 窗口选中要处理的贴图资源, 我知道了); return; } int count 0; foreach (var obj in selected) { string path AssetDatabase.GetAssetPath(obj); if (string.IsNullOrEmpty(path) || path.EndsWith(.meta)) continue; var importer AssetImporter.GetAtPath(path) as TextureImporter; if (importer null) continue; importer.textureCompression TextureImporterCompression.Compressed; importer.compressionQuality 60; importer.SaveAndReimport(); count; } AssetDatabase.SaveAssets(); EditorUtility.DisplayDialog(Dan_Tools, $处理完成共压缩 {count} 张贴图, 好的); } } }这段代码看起来很简单但有几个细节决定成败。SaveAndReimport必须在修改属性之后立刻调用而且每个资源单独调用一次千万不要攒到最后统一调用 AssetDatabase.Refresh否则某些平台设置不会正确落盘。另外如果一次选中了上千张资源建议用 EditorUtility.DisplayProgressBar 包一层进度条不然工具跑起来界面会无响应团队同事第一反应就是你写的代码卡死了。2.2 场景巡检函数SceneAuditor场景巡检是我个人认为对团队质量提升最大的一块。它的定位是打开一个场景扫描出所有潜在问题问题列表直接展示在编辑器窗口里部分问题可以通过按钮一键修复。我在做巡检函数时最深的体会是场景里的“空引用”远比想象中多得多。策划摆弄 Prefab 时手滑删了一个组件美术改完模型后旧场景还留着失效的 Mesh程序重构脚本后 Inspector 上被丢弃的引用显示为 None这些都是巡检能直接抓到的典型问题。SceneAuditor 的核心实现思路分三步。第一步通过 EditorSceneManager.GetActiveScene() 获取当前场景的所有根节点用栈展开场景层级树。第二步遍历每个节点上的 MonoBehaviour用 SerializedObject 读取所有可见序列化属性检查 ObjectReference 类型属性上是否为空值。第三步把异常对象的具体信息拼成文本输出到报告窗口。这里尤其要小心的是不是所有空引用都该被当成错误。有些字段设计上就是允许为空的比如“可选音效”“首选项配置”如果一概报错会产生海量误报。我最终的方案是在函数里维护一个白名单数组允许调用方传入可空字段名灵活度一下就起来了。模板如下while (prop.NextVisible(true)) { if (prop.propertyType SerializedPropertyType.ObjectReference prop.objectReferenceValue null) { if (allowNullNames.Contains(prop.name)) continue; report.AppendLine(${root.name} | {comp.GetType().Name} | {prop.name}); issues; } }巡检查出来的问题我一般不会直接让工具全自动修复而是只定位并手动确认。原因很简单自动补引用有风险比如把字段赋成一个同名组件但实际语义不对后期查起来比空引用还要命。所以巡检函数只负责把问题列出来修复动作留给人来判断这一点我认为是工具集的基本伦理。2.3 数据面板函数DataDashboardDataDashboard 是一个轻量级的数据可视化面板它解决的问题是调试阶段“数值看得见、变化摸得着”。你在游戏运行期间想实时看玩家当前血量、金币数、某个技能 CD 或者服务端下发的实时性能指标用 Debug.Log 打点效率太低用 Profiler 又太重这时一个滚动刷新数据面板最好用。这个函数总结起来就是两件事一个 EditorWindow加上一个 EditorApplication.update 的轮询回调。update 每次触发时调用逻辑层去拉取目标数据存到窗口类持有的局部变量里然后 Repaint。它的核心价值在于能让你随时把开发机上运行时的关键数据拖到编辑器界面上看不用频繁打断操作去看 IDE 控制台。private void OnEnable() { EditorApplication.update OnEditorUpdate; } private void OnDisable() { EditorApplication.update - OnEditorUpdate; } private void OnEditorUpdate() { if (!Application.isPlaying) return; _currentHp GetPlayerHealth(); // 自定义数据获取逻辑尽量轻量 _frameTimeMs (Time.deltaTime * 1000f); Repaint(); }写这个东西的教训是轮询方法一定要轻不要在里面做任何资源加载、反射调用、LINQ 复杂查询否则编辑器会明显变卡。还有一个我亲测有效的细节窗口内容超过一屏时数据项按时间推进会有一种滚动刷新的效果实现方式是维护一个固定长度的队列每次 update 推入新数据队头数据出队用 GUILayout 顺序渲染即可。它不复杂但对调试体验的提升非常大。2.4 项目健康检查函数ProjectHealthReport团队项目做久了最怕的就是死代码、死资源、超大场景堆积。ProjectHealthReport 这个函数就是我每个月例行跑一次的“项目体检”。它会扫描整个 Assets 目录输出一份报告哪些资源在场景里没有被引用哪些贴图格式不适合目标平台哪些 FBX 模型尺寸异常哪些场景文件超过了几十 MB。这个功能的实现关键不在代码技巧而在“依赖分析”。Unity 提供了 AssetDatabase.GetDependencies你可以拿到任意资源依赖的资源列表。反过来通过遍历所有场景和 Prefab我们可以统计出每个资源被哪些对象引用从而找出来零引用的孤儿资源。这里要注意的是GetDependencies 返回结果里除了业务资源还包含引擎内置资源、包体资源要用路径前缀过滤掉。报告我一般做两种格式一是编辑器内直接展示的文本面板二是导出成 Markdown 文件放到项目根目录。第二种格式非常有用因为可以直接贴到团队周报或者飞书文档里。整个函数的生命周期控制在几秒钟到十几秒如果项目资源量非常大可以搭配异步分帧扫描但我个人倾向于保留同步阻塞因为跑体检的时候本来就是一个专门的维护时点不需要同时干别的事。3. 接入 Dan_Tools 并扩展自己的函数3.1 目录结构与 asmdef 隔离接入 Dan_Tools 的第一步是目录规划。Unity 官方约定放在Assets/Editor文件夹下的脚本只在编辑器编译。但如果你直接把几十个文件全丢进这个目录会产生两个问题一是和项目其他编辑器脚本混在一起容易互相污染二是没有程序集隔离的话编辑器代码之间的类名很容易冲突。所以我强烈建议用程序集定义文件asmdef包裹整个工具集目录路径大概是Assets/Dan_Tools/ Editor/ Dan_Tools.Editor.asmdef BatchProcessor.cs SceneAuditor.cs DataDashboard.cs ProjectHealthReport.cs Runtime/ Dan_Tools.Runtime.asmdef DataModels.csRuntime 程序集里是纯数据结构和可复用的非编辑器逻辑Editor 程序集则引用 Runtime 程序集。这里有个细节Editor 程序集必须显式引用 UnityEditor 和 UnityEngine 的Editor预定义程序集而 Runtime 程序集不要引用任何编辑器 API否则在打包 AOT 环节会出问题。分两个程序集的另一个好处是编译速度更快改编辑器代码时不会触发全量编译。3.2 核心函数调用清单与参数说明下面这张表是我整理的核心函数清单方便你在自己项目里快速定位函数入口。这些函数签名在设计时保持了一致性参数最少化、返回值统一化、全部静态化我相信这种设计对使用者最友好。函数名所属模块关键参数返回值用途BatchProcessor.CompressSelected资源批处理无依赖 Selection.objectsint压缩选中的贴图资源BatchProcessor.RenameByPattern资源批处理pattern:string, startIndex:intvoid按规则批量重命名SceneAuditor.CollectNullRef场景巡检allowNullNames:string[]StringBuilder收集场景空引用列表DataDashboard.SetDataSource数据面板getDataFunc:Funcstringvoid绑定自定义数据源ProjectHealthReport.Generate健康检查outputPath:stringReportResult生成项目健康报告ProjectHealthReport.FindOrphans健康检查includePackages:boolListstring查找无引用资源这里我特别想讲一个常见误区很多人喜欢把一个函数写成“万能入口”把参数堆到七八个调用方每次都要查文档。Dan_Tools 做了个相反的决定——凡是能从当前编辑器上下文拿到的信息比如选中的资源、当前打开的场景、当前平台的 BuildTarget一律不要作为参数传递。函数内部自己拿。这样调用方使用时心智负担极低不容易传错参数。3.3 新增一个工具函数的标准流程团队里的业务同学经常会问我想给 Dan_Tools 加一个功能怎么弄我给他们的标准流程是四步走照着走基本不会出大错。第一步判断这是数据计算还是编辑器操作。如果只是算数值比如统计战斗数值期望、计算技能范围直接写到 Runtime 程序集封装一个纯函数。如果是操作也要先把“改什么”“怎么改”写成逻辑函数再想办法接入编辑器。第二步写一个静态方法作为入口并在方法顶上贴 MenuItem 特性绑定菜单路径入口方法内先校验参数、做异常保护。第三步调用操作层 API 完成修改。所有批量操作必须用 Undo.RecordObjects 做预记录这一点太关键了我在第四节会专门展开。第四步在窗口或菜单回调里打点反馈至少给一个弹窗或状态栏提示不要让用户点了半天不知道工具到底有没有跑起来。我自己在实际项目里新增函数时通常会先写一个最小可运行的 EditorWindow 原型跑通了再迁移到标准封装里。这样调试更快也不容易把测试代码污染到正式函数。规范的好处就在这里团队里的同事现在看到 Tools/Dan_Tools 下的新增菜单心里默认条件反射“这一定是一个封装规范、参数明确、可以放心使用的函数。”4. 实战中踩过的坑与排查记录4.1 撤销系统带来的连锁反应编辑器工具开发里最痛的坑是我迄今为止唯一能让整个工程出错的大坑批量修改资源或场景对象时没有用 Undo 做记录导致修改后无法撤销。试想一下美术同学花了半天调整完一堆参数的 Prefab你一个工具函数跑了三分钟把所有 Prefab 里的 MeshRenderer 材质统一替换了然后他 CtrlZ 想退回去发现按烂了都没有反应。这种问题出现一次整个团队对工具的信心就会崩塌。解决方式其实很简单任何对对象数据的修改都要在修改前调用 Undo.RecordObjects(targets, 修改说明)。这段话我几乎每次分享会都会强调但依然会有人踩坑因为大家容易把焦点放在“我这段代码是对的”上忘了代码对不代表操作可回退。我自己的封装习惯是在操作层再包一层ModifyWithUndo的辅助方法里面统一处理 Undo 和 Dirty 标记业务函数不用各写各的。另一个容易忽略的细节是Undo.RecordObjects的调用时机。如果你在遍历循环里记录一次然后循环里改了 50 个物体这 50 次修改会被合并成一个撤销步骤吗实际看 Unity 的实现逻辑如果你想一个批处理作为一个撤销步骤最好是Undo.RecordObjects传数组如果你想取消单个对象修改才在循环内部逐对象调用。我实际用下来绝大多数批处理场景用整体记录一次就够了。4.2 编辑器缓存导致假报错与刷新不及时还有一类问题特别烦人——资源文件明明改成功了但编辑器界面显示的还是旧数据有时候甚至编译都报“找不到命名空间”重启一次编辑器又好了。这类问题绝大多数可以归结为编辑器缓存或刷新时机不对。我处理这样的问题通常按优先级排查第一步看 AssetDatabase.Refresh 有没有被调用但要注意 Refresh 不等于 ImportAsset。第二步看是否因为批处理循环内调用了 SaveAndReimport而循环外又调用了一次造成二次导入冲突。第三步看资源是否被 Unity 的“缓存服务器”或“Shader 缓存”劫持了。最容易被忽略的是第四点某些资源是异步导入的比如场景大文件、预制体依赖的模型在导入未完成时你去读它的数据拿到的自然是旧副本。我的个人建议是工具函数修改资源后不要立即在同一个帧里立刻读取验证除非你用了AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceSynchronousImport)强制同步导入。这个选项虽然会拖慢速度但在关键流程里值得加保证“改完立即可验证”的体验。否则你写了半天用户拿到的还是一个看似没生效的结果这种反馈比工具直接报错还要糟糕。4.3 多人协作时编辑器脚本冲突处理多人协作的场景下编辑器脚本冲突是一件费力不讨好的事。工具函数大多部署在Assets/Editor目录这个目录是多人共用仓库中最容易产生合并冲突的区域之一。你改了一个面板样式同事改了一个批处理函数两个人不在同一个上下文里工作冲突不可避免。我的实际经验是结合 Git 的工作流来解决。首先把 Dan_Tools 尽量按功能模块拆成独立文件一个功能一个文件文件内部也不要搞动辄几百行的巨型类。第二把团队中容易频繁调整的部分独立成模块比如“美术资源批处理”、“关卡工具”、“UI 工具”各自拥有独立的 asmdef这样合并冲突时影响面最小。第三在提交信息里明确写到改动范围和影响场景比如“BatchProcessor按需同步导入贴图配置”同事一看就知道有没有关联。最后如果项目组里有人改的代码注定会和别人撞车那就约定这个模块由指定的人负责维护其他人提需求别直接改源码。这个方案不是完美的但它确实降低了我们项目里工具脚本的合并冲突频率。我见过最惨的一次是两个人同时改了 SceneAuditor 的空引用白名单机制一个改了命名空间一个改了逻辑判断合并后编译错误叠了七八条排查了半小时才发现只是字段名不一致。这种低级冲突其实在提交前多看一眼 diff 就能避免。4.4 性能瓶颈与底层 API 选择编辑器工具的性能问题通常在资源量小的时候完全无感等场景有上万物体、贴图有几百张时一下暴露出来。我给一个判断基准单个函数执行时间如果超过 8 秒用户就会觉得卡超过 30 秒很多人会以为程序崩溃了。所以工具函数一定要做耗时评估。我在开发 Dan_Tools 过程中用 Stopwatch 对比过几个常见方案的耗时。比如查找一个 GameObject 上的组件无脑用GetComponentInParentT()和直接操作序列化对象的底层 API 耗时差距非常大。在 5000 个带 Collider 的物体上逐层向上找某一组件用GetComponentInParent耗时约 230 毫秒而如果改成在已知对象树结构的情况下按路径索引查找可以压到 40 毫秒以内。这只是其中一个小例子。另一个性能大坑是序列化遍历。SerializedObject 读取属性本身不慢但如果你在遍历循环内部不断创建新的 SerializedObject分配开销会让执行时间指数上升。正确做法是循环外先创建一份循环内复用同一个对象去 NextVisible。还有一点编辑器代码里尽量不要用foreach去迭代 LINQ 查询结果改用for循环加本地集合GC 压力能小不少。编辑器工具虽然不用关心真机内存但一次批处理几万个对象的 GC 耗时也是肉眼可见的。最后再说两句实在话工具集的维护说到底是习惯问题。我在实际使用中发现真正让团队离不开 Dan_Tools 的不是哪一两个炫酷的函数而是它逼着我们把“规范”两个字刻进了日常操作批处理必须带撤销巡检结果必须可复现函数封装必须分层次。这套工具从最初只有压缩贴图一个函数慢慢长成现在覆盖资源、场景、数据、项目健康四塊核心能力中间最大的成本不是写代码而是整理边界和守住规范。如果你也打算在自己的项目里搭一套编辑器工具我建议别一上来就规划终极形态。先把最痛的那个操作做成第一个函数跑通一条完整路径。用起来顺手了再继续加第二个、第三个。等你的工具集长到十个函数以上你自然会遇到模块化的需求到时候再做分层、做架构一切水到渠成。这是我自己做 Dan_Tools 最真实的过程也是给想动手做工具集的朋友最朴素的一条建议。
一两年前我第一次认真整理工程项目里的编辑器脚本时发现光是“给美术资源改名”这个需求工程里就躺着五个版本。有人把逻辑写在 MenuItem 里有人写在自定义窗口的按钮回调里还有人干脆每次手动改完再复制一份备份。正是这种混乱让我下定决心做一个统一的 Dan_Tools一套面向 Unity 编辑器的工具集把资源批处理、场景巡检、数据监控和项目健康检查这些高频操作统一封装成稳定可复用的函数。这个工具集的目标不是“什么都能做”而是让 80% 的重复编辑器操作变成一个菜单点击。无论你是团队里的工具开发者还是独立项目做到中期急着提升效率这篇文章都值得继续读下去。我在开发过程中逐渐意识到很多编辑器工具不是写不出来而是没有一套好用的骨架去承载。今天我把 Dan_Tools 的模块划分、核心函数实现思路、接入方式和踩坑记录都翻出来当作一次复盘也给有同样需求的人一个可以直接参考的方案。1. 项目背景与工具集整体设计思路1.1 编辑器脚本失控是时候做一次收口了Unity 项目跑到中期最容易出现的问题不是玩法代码屎山而是“编辑器脚本灾难”。每个程序在进项目时都会顺手写几个小工具有人做 UI 的写了批量替换字体有人做战斗的写了刷怪点导出有人做寻路的写了路径预览。这些脚本一开始都很好用但后来问题逐渐暴露第一重复实现。团队五个人可能写了五份功能类似的工具各自叫 BatchRenameTool、MassRenameWindow、RenamerX美术同学根本分不清该用哪个。第二行为不一致。同样是把图片压成 ASTCA 工具保留 mipmapB 工具默认关闭 mipmap不同的人跑出来的资源效果不一样最后反馈到表现层就是一团乱麻。第三维护成本。你三个月后回来看自己写的脚本想改个功能得先花半小时回忆当时的变量命名逻辑。Dan_Tools 最开始就是冲着“收口”这两个字去的。我给自己定了几条规矩所有工具入口统一挂在 Tools/Dan_Tools 菜单下所有对外功能都走静态函数接口核心逻辑不依赖编辑器窗口实例能批量就不要单点操作。这三条规矩看似简单实际执行下来效果非常好后来团队里新来的同学只需要看一遍菜单结构就知道哪个功能在哪个位置。1.2 四层模块划分入口、逻辑、操作、回显工具集的功能数量一旦多起来最怕的就是每个窗口各写各的没有统一的代码结构。我在重构 Dan_Tools 时把它拆成了四个层次这个思路我觉得比具体代码更值得分享。入口层负责一切用户交互入口包括 MenuItem、自定义快捷键、右键菜单。入口层不应该有任何业务逻辑它只负责接收参数、做参数校验、然后调用下一层。逻辑层是纯 C# 的数据处理比如计算一张贴图的宽高比、生成资源依赖关系图、统计场景内物体数量这一层不引用任何 UnityEngine 的编辑器 API目的是方便单元测试和逻辑复用。操作层真正对 Unity 资源或场景做修改比如 AssetDatabase 导入、预制体实例化、序列化属性修改所有改数据的行为都在这一层完成。回显层最后才是 EditorWindow 或自定义 Inspector 的 UI 绘制它只负责把操作层算出来的结果展示出来。为什么非要分这么细因为编辑器工具最恶心的场景就是你改了一处 UI 的显示文案不小心影响了真正改数据的代码你给窗口加了一个进度条结果批处理函数被拖慢了 30%。拆开之后逻辑层和操作层完全不依赖 UIUI 重构只是换皮核心函数纹丝不动。我自己重构过几次之后最深的体会是分层不会让你写代码变快但会让你改代码变快十倍。1.3 IMGUI 与 UI Toolkit 之间的技术选型取舍Unity 编辑器扩展的技术栈现在其实有两个选择一类是传统的 IMGUIOnGUI、GUILayout、EditorGUILayout另一类是新的 UI ToolkitUXML、USS、VisualElement。Dan_Tools 最终选择了 IMGUI 作为主要交互层原因有两条。第一兼容性。UI Toolkit 在部分老版本 Unity 项目里跑起来有兼容问题而我们团队既有 2020 LTS 的项目也有 2021 LTS 的项目IMGUI 从 5.x 时代就稳定存在任何版本都不会出幺蛾子。第二灵活性。IMGUI 写起来非常直觉化一个 EditorWindow 里用 EditorGUILayout 就能快速堆出一个好用的面板不需要额外维护 UI 文件对工具类项目来说效率第一。但我也不是完全排斥 UI Toolkit。在 DataDashboard 这类需要大量列表滚动、频繁刷新显示的面板上UI Toolkit 的样式一致性确实更好。我的建议是如果你的工具是给少量内部用户用的功能型工具IMGUI 完全够用如果未来要交付一个带品牌感和复杂交互的编辑器产品那就值得用 UI Toolkit 认真做一套。工具集本身不一定要绑死一个框架核心函数层和表现层分离的好处在这里也体现出来了。2. 核心功能函数的实现拆解2.1 资源批处理函数BatchProcessor资源批处理是 Dan_Tools 里使用频率最高的一块它解决的痛点很典型几百张贴图要统一压低内存几十个材质要修改渲染队列多个 Sprite 图集要切换平台格式手工操作一次就容易漏。BatchProcessor 的核心设计是“先选中后执行”。你在 Project 窗口选中一批资源然后在菜单里点击对应批处理项工具会遍历 Selection.objects 拿到资源路径再通过 AssetImporter 做属性修改。这里有一个很重要的原则所有操作都要走 AssetDatabase而不是直接走 File.IO 操作文件。原因是 AssetDatabase 会维护 Unity 的资源索引、导入状态和依赖关系你用系统 API 直接改文件Unity 的缓存不会及时感知最后要么报 meta 文件错乱要么资源丢失引用。下面是我在实际项目里用的贴图压缩函数片段环境是 Unity 2021.3using UnityEngine; using UnityEditor; namespace DanTools { public static class BatchProcessor { [MenuItem(Tools/Dan_Tools/资源批处理/一键压缩选中贴图)] public static void CompressSelectedTextures() { var selected Selection.objects; if (selected.Length 0) { EditorUtility.DisplayDialog(Dan_Tools, 请先在 Project 窗口选中要处理的贴图资源, 我知道了); return; } int count 0; foreach (var obj in selected) { string path AssetDatabase.GetAssetPath(obj); if (string.IsNullOrEmpty(path) || path.EndsWith(.meta)) continue; var importer AssetImporter.GetAtPath(path) as TextureImporter; if (importer null) continue; importer.textureCompression TextureImporterCompression.Compressed; importer.compressionQuality 60; importer.SaveAndReimport(); count; } AssetDatabase.SaveAssets(); EditorUtility.DisplayDialog(Dan_Tools, $处理完成共压缩 {count} 张贴图, 好的); } } }这段代码看起来很简单但有几个细节决定成败。SaveAndReimport必须在修改属性之后立刻调用而且每个资源单独调用一次千万不要攒到最后统一调用 AssetDatabase.Refresh否则某些平台设置不会正确落盘。另外如果一次选中了上千张资源建议用 EditorUtility.DisplayProgressBar 包一层进度条不然工具跑起来界面会无响应团队同事第一反应就是你写的代码卡死了。2.2 场景巡检函数SceneAuditor场景巡检是我个人认为对团队质量提升最大的一块。它的定位是打开一个场景扫描出所有潜在问题问题列表直接展示在编辑器窗口里部分问题可以通过按钮一键修复。我在做巡检函数时最深的体会是场景里的“空引用”远比想象中多得多。策划摆弄 Prefab 时手滑删了一个组件美术改完模型后旧场景还留着失效的 Mesh程序重构脚本后 Inspector 上被丢弃的引用显示为 None这些都是巡检能直接抓到的典型问题。SceneAuditor 的核心实现思路分三步。第一步通过 EditorSceneManager.GetActiveScene() 获取当前场景的所有根节点用栈展开场景层级树。第二步遍历每个节点上的 MonoBehaviour用 SerializedObject 读取所有可见序列化属性检查 ObjectReference 类型属性上是否为空值。第三步把异常对象的具体信息拼成文本输出到报告窗口。这里尤其要小心的是不是所有空引用都该被当成错误。有些字段设计上就是允许为空的比如“可选音效”“首选项配置”如果一概报错会产生海量误报。我最终的方案是在函数里维护一个白名单数组允许调用方传入可空字段名灵活度一下就起来了。模板如下while (prop.NextVisible(true)) { if (prop.propertyType SerializedPropertyType.ObjectReference prop.objectReferenceValue null) { if (allowNullNames.Contains(prop.name)) continue; report.AppendLine(${root.name} | {comp.GetType().Name} | {prop.name}); issues; } }巡检查出来的问题我一般不会直接让工具全自动修复而是只定位并手动确认。原因很简单自动补引用有风险比如把字段赋成一个同名组件但实际语义不对后期查起来比空引用还要命。所以巡检函数只负责把问题列出来修复动作留给人来判断这一点我认为是工具集的基本伦理。2.3 数据面板函数DataDashboardDataDashboard 是一个轻量级的数据可视化面板它解决的问题是调试阶段“数值看得见、变化摸得着”。你在游戏运行期间想实时看玩家当前血量、金币数、某个技能 CD 或者服务端下发的实时性能指标用 Debug.Log 打点效率太低用 Profiler 又太重这时一个滚动刷新数据面板最好用。这个函数总结起来就是两件事一个 EditorWindow加上一个 EditorApplication.update 的轮询回调。update 每次触发时调用逻辑层去拉取目标数据存到窗口类持有的局部变量里然后 Repaint。它的核心价值在于能让你随时把开发机上运行时的关键数据拖到编辑器界面上看不用频繁打断操作去看 IDE 控制台。private void OnEnable() { EditorApplication.update OnEditorUpdate; } private void OnDisable() { EditorApplication.update - OnEditorUpdate; } private void OnEditorUpdate() { if (!Application.isPlaying) return; _currentHp GetPlayerHealth(); // 自定义数据获取逻辑尽量轻量 _frameTimeMs (Time.deltaTime * 1000f); Repaint(); }写这个东西的教训是轮询方法一定要轻不要在里面做任何资源加载、反射调用、LINQ 复杂查询否则编辑器会明显变卡。还有一个我亲测有效的细节窗口内容超过一屏时数据项按时间推进会有一种滚动刷新的效果实现方式是维护一个固定长度的队列每次 update 推入新数据队头数据出队用 GUILayout 顺序渲染即可。它不复杂但对调试体验的提升非常大。2.4 项目健康检查函数ProjectHealthReport团队项目做久了最怕的就是死代码、死资源、超大场景堆积。ProjectHealthReport 这个函数就是我每个月例行跑一次的“项目体检”。它会扫描整个 Assets 目录输出一份报告哪些资源在场景里没有被引用哪些贴图格式不适合目标平台哪些 FBX 模型尺寸异常哪些场景文件超过了几十 MB。这个功能的实现关键不在代码技巧而在“依赖分析”。Unity 提供了 AssetDatabase.GetDependencies你可以拿到任意资源依赖的资源列表。反过来通过遍历所有场景和 Prefab我们可以统计出每个资源被哪些对象引用从而找出来零引用的孤儿资源。这里要注意的是GetDependencies 返回结果里除了业务资源还包含引擎内置资源、包体资源要用路径前缀过滤掉。报告我一般做两种格式一是编辑器内直接展示的文本面板二是导出成 Markdown 文件放到项目根目录。第二种格式非常有用因为可以直接贴到团队周报或者飞书文档里。整个函数的生命周期控制在几秒钟到十几秒如果项目资源量非常大可以搭配异步分帧扫描但我个人倾向于保留同步阻塞因为跑体检的时候本来就是一个专门的维护时点不需要同时干别的事。3. 接入 Dan_Tools 并扩展自己的函数3.1 目录结构与 asmdef 隔离接入 Dan_Tools 的第一步是目录规划。Unity 官方约定放在Assets/Editor文件夹下的脚本只在编辑器编译。但如果你直接把几十个文件全丢进这个目录会产生两个问题一是和项目其他编辑器脚本混在一起容易互相污染二是没有程序集隔离的话编辑器代码之间的类名很容易冲突。所以我强烈建议用程序集定义文件asmdef包裹整个工具集目录路径大概是Assets/Dan_Tools/ Editor/ Dan_Tools.Editor.asmdef BatchProcessor.cs SceneAuditor.cs DataDashboard.cs ProjectHealthReport.cs Runtime/ Dan_Tools.Runtime.asmdef DataModels.csRuntime 程序集里是纯数据结构和可复用的非编辑器逻辑Editor 程序集则引用 Runtime 程序集。这里有个细节Editor 程序集必须显式引用 UnityEditor 和 UnityEngine 的Editor预定义程序集而 Runtime 程序集不要引用任何编辑器 API否则在打包 AOT 环节会出问题。分两个程序集的另一个好处是编译速度更快改编辑器代码时不会触发全量编译。3.2 核心函数调用清单与参数说明下面这张表是我整理的核心函数清单方便你在自己项目里快速定位函数入口。这些函数签名在设计时保持了一致性参数最少化、返回值统一化、全部静态化我相信这种设计对使用者最友好。函数名所属模块关键参数返回值用途BatchProcessor.CompressSelected资源批处理无依赖 Selection.objectsint压缩选中的贴图资源BatchProcessor.RenameByPattern资源批处理pattern:string, startIndex:intvoid按规则批量重命名SceneAuditor.CollectNullRef场景巡检allowNullNames:string[]StringBuilder收集场景空引用列表DataDashboard.SetDataSource数据面板getDataFunc:Funcstringvoid绑定自定义数据源ProjectHealthReport.Generate健康检查outputPath:stringReportResult生成项目健康报告ProjectHealthReport.FindOrphans健康检查includePackages:boolListstring查找无引用资源这里我特别想讲一个常见误区很多人喜欢把一个函数写成“万能入口”把参数堆到七八个调用方每次都要查文档。Dan_Tools 做了个相反的决定——凡是能从当前编辑器上下文拿到的信息比如选中的资源、当前打开的场景、当前平台的 BuildTarget一律不要作为参数传递。函数内部自己拿。这样调用方使用时心智负担极低不容易传错参数。3.3 新增一个工具函数的标准流程团队里的业务同学经常会问我想给 Dan_Tools 加一个功能怎么弄我给他们的标准流程是四步走照着走基本不会出大错。第一步判断这是数据计算还是编辑器操作。如果只是算数值比如统计战斗数值期望、计算技能范围直接写到 Runtime 程序集封装一个纯函数。如果是操作也要先把“改什么”“怎么改”写成逻辑函数再想办法接入编辑器。第二步写一个静态方法作为入口并在方法顶上贴 MenuItem 特性绑定菜单路径入口方法内先校验参数、做异常保护。第三步调用操作层 API 完成修改。所有批量操作必须用 Undo.RecordObjects 做预记录这一点太关键了我在第四节会专门展开。第四步在窗口或菜单回调里打点反馈至少给一个弹窗或状态栏提示不要让用户点了半天不知道工具到底有没有跑起来。我自己在实际项目里新增函数时通常会先写一个最小可运行的 EditorWindow 原型跑通了再迁移到标准封装里。这样调试更快也不容易把测试代码污染到正式函数。规范的好处就在这里团队里的同事现在看到 Tools/Dan_Tools 下的新增菜单心里默认条件反射“这一定是一个封装规范、参数明确、可以放心使用的函数。”4. 实战中踩过的坑与排查记录4.1 撤销系统带来的连锁反应编辑器工具开发里最痛的坑是我迄今为止唯一能让整个工程出错的大坑批量修改资源或场景对象时没有用 Undo 做记录导致修改后无法撤销。试想一下美术同学花了半天调整完一堆参数的 Prefab你一个工具函数跑了三分钟把所有 Prefab 里的 MeshRenderer 材质统一替换了然后他 CtrlZ 想退回去发现按烂了都没有反应。这种问题出现一次整个团队对工具的信心就会崩塌。解决方式其实很简单任何对对象数据的修改都要在修改前调用 Undo.RecordObjects(targets, 修改说明)。这段话我几乎每次分享会都会强调但依然会有人踩坑因为大家容易把焦点放在“我这段代码是对的”上忘了代码对不代表操作可回退。我自己的封装习惯是在操作层再包一层ModifyWithUndo的辅助方法里面统一处理 Undo 和 Dirty 标记业务函数不用各写各的。另一个容易忽略的细节是Undo.RecordObjects的调用时机。如果你在遍历循环里记录一次然后循环里改了 50 个物体这 50 次修改会被合并成一个撤销步骤吗实际看 Unity 的实现逻辑如果你想一个批处理作为一个撤销步骤最好是Undo.RecordObjects传数组如果你想取消单个对象修改才在循环内部逐对象调用。我实际用下来绝大多数批处理场景用整体记录一次就够了。4.2 编辑器缓存导致假报错与刷新不及时还有一类问题特别烦人——资源文件明明改成功了但编辑器界面显示的还是旧数据有时候甚至编译都报“找不到命名空间”重启一次编辑器又好了。这类问题绝大多数可以归结为编辑器缓存或刷新时机不对。我处理这样的问题通常按优先级排查第一步看 AssetDatabase.Refresh 有没有被调用但要注意 Refresh 不等于 ImportAsset。第二步看是否因为批处理循环内调用了 SaveAndReimport而循环外又调用了一次造成二次导入冲突。第三步看资源是否被 Unity 的“缓存服务器”或“Shader 缓存”劫持了。最容易被忽略的是第四点某些资源是异步导入的比如场景大文件、预制体依赖的模型在导入未完成时你去读它的数据拿到的自然是旧副本。我的个人建议是工具函数修改资源后不要立即在同一个帧里立刻读取验证除非你用了AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceSynchronousImport)强制同步导入。这个选项虽然会拖慢速度但在关键流程里值得加保证“改完立即可验证”的体验。否则你写了半天用户拿到的还是一个看似没生效的结果这种反馈比工具直接报错还要糟糕。4.3 多人协作时编辑器脚本冲突处理多人协作的场景下编辑器脚本冲突是一件费力不讨好的事。工具函数大多部署在Assets/Editor目录这个目录是多人共用仓库中最容易产生合并冲突的区域之一。你改了一个面板样式同事改了一个批处理函数两个人不在同一个上下文里工作冲突不可避免。我的实际经验是结合 Git 的工作流来解决。首先把 Dan_Tools 尽量按功能模块拆成独立文件一个功能一个文件文件内部也不要搞动辄几百行的巨型类。第二把团队中容易频繁调整的部分独立成模块比如“美术资源批处理”、“关卡工具”、“UI 工具”各自拥有独立的 asmdef这样合并冲突时影响面最小。第三在提交信息里明确写到改动范围和影响场景比如“BatchProcessor按需同步导入贴图配置”同事一看就知道有没有关联。最后如果项目组里有人改的代码注定会和别人撞车那就约定这个模块由指定的人负责维护其他人提需求别直接改源码。这个方案不是完美的但它确实降低了我们项目里工具脚本的合并冲突频率。我见过最惨的一次是两个人同时改了 SceneAuditor 的空引用白名单机制一个改了命名空间一个改了逻辑判断合并后编译错误叠了七八条排查了半小时才发现只是字段名不一致。这种低级冲突其实在提交前多看一眼 diff 就能避免。4.4 性能瓶颈与底层 API 选择编辑器工具的性能问题通常在资源量小的时候完全无感等场景有上万物体、贴图有几百张时一下暴露出来。我给一个判断基准单个函数执行时间如果超过 8 秒用户就会觉得卡超过 30 秒很多人会以为程序崩溃了。所以工具函数一定要做耗时评估。我在开发 Dan_Tools 过程中用 Stopwatch 对比过几个常见方案的耗时。比如查找一个 GameObject 上的组件无脑用GetComponentInParentT()和直接操作序列化对象的底层 API 耗时差距非常大。在 5000 个带 Collider 的物体上逐层向上找某一组件用GetComponentInParent耗时约 230 毫秒而如果改成在已知对象树结构的情况下按路径索引查找可以压到 40 毫秒以内。这只是其中一个小例子。另一个性能大坑是序列化遍历。SerializedObject 读取属性本身不慢但如果你在遍历循环内部不断创建新的 SerializedObject分配开销会让执行时间指数上升。正确做法是循环外先创建一份循环内复用同一个对象去 NextVisible。还有一点编辑器代码里尽量不要用foreach去迭代 LINQ 查询结果改用for循环加本地集合GC 压力能小不少。编辑器工具虽然不用关心真机内存但一次批处理几万个对象的 GC 耗时也是肉眼可见的。最后再说两句实在话工具集的维护说到底是习惯问题。我在实际使用中发现真正让团队离不开 Dan_Tools 的不是哪一两个炫酷的函数而是它逼着我们把“规范”两个字刻进了日常操作批处理必须带撤销巡检结果必须可复现函数封装必须分层次。这套工具从最初只有压缩贴图一个函数慢慢长成现在覆盖资源、场景、数据、项目健康四塊核心能力中间最大的成本不是写代码而是整理边界和守住规范。如果你也打算在自己的项目里搭一套编辑器工具我建议别一上来就规划终极形态。先把最痛的那个操作做成第一个函数跑通一条完整路径。用起来顺手了再继续加第二个、第三个。等你的工具集长到十个函数以上你自然会遇到模块化的需求到时候再做分层、做架构一切水到渠成。这是我自己做 Dan_Tools 最真实的过程也是给想动手做工具集的朋友最朴素的一条建议。
