1. 为什么我会攒下这6个UI动效提效脚本做Unity UI动效这行的朋友大概都有同感真正花在K帧上的时间可能还不到整个流程的三成。剩下七成去哪了全耗在等编辑器响应、手动压缩贴图、反复切图集、对动画末帧这些琐事上。尤其是项目进入中后期UI动效师一天要保存几百次工程每次保存卡个两三秒一天下来就是十几二十分钟的纯等待美术给的PNG动辄2048×2048一张图几MB打进包里体积直接爆炸图集估算全靠猜等到打包才发现超了尺寸要重排。我最初也是硬扛后来实在受不了就陆续写了几个Editor脚本挂在项目里。用了一年多迭代了七八个版本最后沉淀下来6个比较稳的自动保存、图片压缩、图集估算、动画末帧对齐、动画偏移修正、动效预览快照。它们都不依赖任何第三方插件纯C# UnityEditor API拷进工程就能跑。这篇东西不是官方文档的复述而是我把这6个脚本的设计思路、踩过的坑、参数怎么定、什么场景别用全部摊开讲一遍。适合已经写过一点Editor脚本、想给自己项目做提效工具的Unity开发者如果你刚入门照着抄也能跑起来我会把关键API和注意事项都标清楚。核心关键词就这几个Unity、UI动效、自动保存、图片压缩、图集估算全文围绕它们展开。先说一个反直觉的结论这6个脚本里真正省时间的不是自动保存而是图集估算和动画末帧对齐。自动保存只是省了手速后两个是直接帮你避免返工。下面逐个拆。2. 自动保存脚本别再用CtrlS续命了2.1 自动保存到底该保存什么很多人一听自动保存第一反应是定时调一下AssetDatabase.SaveAssets()不就行了。我一开始也这么写结果踩了个大坑SaveAssets()只保存资源数据库里被标记为dirty的资源它不会保存场景。也就是说你改了UI预制体、调了动画曲线场景本身没存Unity崩了照样丢。正确的做法是分两层场景层EditorSceneManager.SaveScene(SceneManager.GetActiveScene())或者用EditorSceneManager.MarkSceneDirty配合保存。资源层AssetDatabase.SaveAssets()把预制体、动画片段、材质这些脏资源刷盘。我最终的脚本逻辑是这样的监听EditorApplication.update累计一个计时器超过设定间隔默认180秒且编辑器处于非播放、非编译状态时执行一次保存。同时监听EditorApplication.playModeStateChanged在进入播放模式前强制保存一次——这个很关键很多人调动画时直接点播放结果播放中改的东西退出播放就没了。[InitializeOnLoad] public static class AutoSave { static double nextSaveTime; const double Interval 180.0; static AutoSave() { EditorApplication.update Tick; EditorApplication.playModeStateChanged OnPlayModeChanged; } static void Tick() { if (EditorApplication.timeSinceStartup nextSaveTime) return; if (EditorApplication.isPlayingOrWillChangePlaymode) return; if (EditorApplication.isCompiling || EditorApplication.isUpdating) return; DoSave(); nextSaveTime EditorApplication.timeSinceStartup Interval; } static void DoSave() { var scene SceneManager.GetActiveScene(); if (scene.isDirty) EditorSceneManager.SaveScene(scene); AssetDatabase.SaveAssets(); } static void OnPlayModeChanged(PlayModeStateChange state) { if (state PlayModeStateChange.ExitingEditMode) DoSave(); } }2.2 三个必须加的保护条件上面代码里那三个return不是凑数的每一个都对应一次血泪教训。第一播放模式判断。如果你在播放中触发保存Unity会把运行时对场景的临时修改也写进去退出播放后场景就乱了。我见过有人自动保存把播放中的粒子位置存进场景的打开工程一脸懵。第二编译和更新判断。isCompiling为true时保存可能保存到一半的编译产物isUpdating为true时比如正在导入资源保存会阻塞导入线程编辑器直接卡死。这两个判断加上稳定性提升一大截。第三场景dirty判断。不加这个每次定时都无脑存一遍硬盘IO白白浪费。加个scene.isDirty没改动就跳过。提示自动保存间隔别设太短。我试过60秒结果每次刚敲完代码切回编辑器就触发保存反而打断思路。180秒是个比较舒服的值你也可以做成菜单项让每个人自己调。2.3 自动保存和版本管理的配合这里有个容易被忽略的点自动保存会让Git的diff变得很碎。如果你用Git管理Unity工程建议把自动保存的间隔调长一点比如300秒或者干脆只在ExitingEditMode时保存不做定时。另外Unity的.meta文件在自动保存时也会更新记得把Library/、Temp/这些目录加进.gitignore不然仓库会被撑爆。我自己现在的配置是定时300秒 播放前强制保存。这样既不会太频繁又保证了关键节点不丢东西。3. 图片压缩脚本把UI贴图体积砍下来的实操3.1 为什么UI贴图是包体大头一个中等规模的Unity项目UI贴图占包体30%到50%太正常了。原因很简单美术出图默认PNGPNG是无损压缩一张2048×2048的带透明通道UI图轻松上到3-5MB。几十张这样的图堆一起包体直接起飞。但UI贴图有个特点大部分是纯色块、渐变、圆角矩形颜色数很少。这种图用PNG就是浪费转成带压缩的格式能砍掉70%以上体积。Unity本身提供了TextureImporter的压缩设置问题是要一张张手动改几十上百张图改到怀疑人生。3.2 批量压缩脚本的核心逻辑我的思路是遍历指定目录下所有贴图根据贴图用途UI、图标、背景套用不同的压缩预设然后重新导入。核心API是TextureImporter。public static void CompressTextures(string folder, TexturePreset preset) { var guids AssetDatabase.FindAssets(t:Texture2D, new[] { folder }); foreach (var guid in guids) { var path AssetDatabase.GUIDToAssetPath(guid); var importer AssetImporter.GetAtPath(path) as TextureImporter; if (importer null) continue; ApplyPreset(importer, preset); importer.SaveAndReimport(); } AssetDatabase.Refresh(); }ApplyPreset里根据预设设置几个关键参数参数UI图推荐值图标推荐值背景图推荐值TextureTypeSpriteSpriteSpriteCompressionNormal QualityNormal QualityHigh QualityMaxSize10242562048Format (Android)ASTC 6x6ASTC 4x4ASTC 8x8Format (iOS)ASTC 6x6ASTC 4x4ASTC 8x8sRGBtruetruetrueMip Maps关闭关闭关闭3.3 压缩格式怎么选ASTC还是ETC2这是被问最多的问题。简单说结论新项目一律用ASTC老设备兼容需求才考虑ETC2。ASTC的优势是块大小可调6x6在质量和体积之间平衡最好适合大多数UI图4x4质量更高但体积大给需要精细显示的小图标用8x8体积最小但会有明显块状只适合大面积的纯色背景。ETC2的问题是它固定4x4块压缩率不如ASTC灵活而且对带Alpha的图支持一般。如果你的项目还要兼容很老的机型那没办法只能用ETC2但要在质量上做妥协。注意压缩格式是分平台的。上面表格里Android和iOS我都写了ASTC但如果你要出WebGL或者PC包格式要另设。PC上一般用DXT5带Alpha或DXT1不带AlphaWebGL看浏览器支持。3.4 压缩后一定要做的验证批量压缩最怕的是压完发现某张图糊了。我的做法是压缩后生成一份对比报告记录每张图压缩前后的体积、尺寸、格式输出成CSV。然后重点检查两类图带细文字的图和带锐利边缘的图这两类最容易在压缩后出现锯齿或模糊。还有个坑SaveAndReimport()是同步的图多了会卡很久。建议分批处理每批50张处理完AssetDatabase.Refresh()一次。我试过一次性压300张编辑器直接无响应了五分钟。4. 图集估算脚本打包前就知道会不会超4.1 图集超尺寸为什么这么难提前发现Unity的Sprite Atlas在打包时才会真正生成编辑器里你看到的只是引用关系。等到打包报错说atlas exceeds maximum size往往已经临近发版改起来手忙脚乱。问题的本质是你不知道所有Sprite的实际像素面积加起来是多少。Unity的图集打包算法默认是Rectangle有填充、有旋转优化但基本盘还是总面积。如果所有Sprite的面积和超过了图集最大尺寸的平方那肯定放不下。4.2 估算脚本的计算方法我的估算逻辑分三步遍历图集配置里引用的所有Sprite读取每个Sprite的原始像素尺寸注意是原始尺寸不是导入后的MaxSize。累加面积同时考虑图集打包的填充率。实测下来Rectangle打包的实际利用率大概在70%-85%之间取75%作为保守估计。用累加面积除以利用率再开平方得到理论最小边长和配置的最大尺寸对比。public static AtlasEstimate Estimate(SpriteAtlas atlas) { var sprites new ListSprite(); atlas.GetSprites(sprites); long totalArea 0; foreach (var s in sprites) { var rect s.rect; totalArea (long)(rect.width * rect.height); } float utilization 0.75f; long neededArea (long)(totalArea / utilization); int minSide Mathf.CeilToInt(Mathf.Sqrt(neededArea)); return new AtlasEstimate { SpriteCount sprites.Count, TotalArea totalArea, MinSide minSide, MaxSize atlas.GetPackingSettings().maxTextureSize }; }4.3 估算结果怎么解读拿到MinSide和MaxSize之后判断就简单了MinSide MaxSize * 0.8安全还有余量。MaxSize * 0.8 MinSide MaxSize警告接近上限建议拆图集或压缩。MinSide MaxSize危险肯定放不下必须处理。我一般会在CI流程里加一步打包前跑一遍所有图集的估算有危险项就中断打包并输出报告。这样问题在提交阶段就暴露了不会拖到发版。提示这个估算对Unity默认的Rectangle打包比较准如果你用了TightPacking或者自定义打包器利用率要重新标定。TightPacking利用率更高能到85%-90%但会有更多旋转和重叠估算时可以把utilization调到0.85。4.4 图集拆分的经验法则估算发现超了怎么办两个方向压缩单图或者拆图集。我的经验是优先压缩因为拆图集会导致DrawCall增加。如果非要拆按功能拆比按尺寸拆好。比如把主界面UI和战斗界面UI分成两个图集而不是把大图和小图分开。按功能拆的好处是同一个界面用到的图在一个图集里渲染时不会来回切换图集DrawCall更可控。5. 动画末帧对齐与偏移修正动效师的救命脚本5.1 末帧对不齐到底有多烦做UI动效的都知道一个动画播完如果末帧和下一段动画的首帧对不上就会出现跳一下的视觉瑕疵。手动对齐的方法是打开Animation窗口把时间轴拖到最后一帧记下所有关键帧的值再打开下一段动画把首帧改成一样的值。一个动画对下来五分钟十个动画就是五十分钟。更麻烦的是偏移修正。有时候动画整体偏了比如一个弹窗动画设计稿要求最终停在屏幕中央但实际K完发现偏了20像素。你得把所有关键帧的X值统一加20手动改就是灾难。5.2 末帧对齐脚本的实现思路很直接读取A动画最后一帧的所有曲线值写入B动画的第一帧。public static void AlignLastFrameToFirst(AnimationClip from, AnimationClip to) { var fromBindings AnimationUtility.GetCurveBindings(from); var toBindings AnimationUtility.GetCurveBindings(to); foreach (var fb in fromBindings) { var fromCurve AnimationUtility.GetEditorCurve(from, fb); if (fromCurve null || fromCurve.length 0) continue; float lastValue fromCurve[fromCurve.length - 1].value; var tb FindMatchingBinding(toBindings, fb); if (tb null) continue; var toCurve AnimationUtility.GetEditorCurve(to, tb); if (toCurve null || toCurve.length 0) continue; var keys toCurve.keys; keys[0].value lastValue; toCurve.keys keys; AnimationUtility.SetEditorCurve(to, tb, toCurve); } }FindMatchingBinding负责匹配两个动画里相同的属性路径和属性名。这里有个细节属性路径可能因为节点改名而不一致所以匹配时要容错比如忽略大小写、忽略前后空格。5.3 偏移修正的批量处理偏移修正的核心是遍历所有关键帧对指定轴的值统一加减。但要注意几个坑第一只改位置曲线别动旋转和缩放。我见过有人写脚本把所有曲线都偏移了结果动画整个变形。第二注意曲线类型。位置曲线是m_LocalPosition.x/y/z要精确匹配属性名别把m_LocalScale也改了。第三处理关键帧的切线。直接改key.value不会影响切线但如果偏移量很大切线可能需要重新计算。简单场景下不管切线也没问题复杂曲线建议用AnimationUtility.SetKeyLeftTangentMode重置一下。public static void OffsetPosition(AnimationClip clip, Vector3 offset) { var bindings AnimationUtility.GetCurveBindings(clip); foreach (var b in bindings) { if (!b.propertyName.StartsWith(m_LocalPosition)) continue; var curve AnimationUtility.GetEditorCurve(clip, b); var keys curve.keys; float delta b.propertyName.EndsWith(.x) ? offset.x : b.propertyName.EndsWith(.y) ? offset.y : offset.z; for (int i 0; i keys.Length; i) keys[i].value delta; curve.keys keys; AnimationUtility.SetEditorCurve(clip, b, curve); } }5.4 这两个脚本的适用边界末帧对齐脚本适合序列动画比如弹窗打开→弹窗停留→弹窗关闭这种链式动画。如果两段动画本来就不该衔接硬对齐反而会出问题。偏移修正适合整体位移的场景比如设计稿改版导致所有弹窗位置下移。但如果动画里有相对位移比如元素在弹窗内移动整体偏移会破坏相对关系这时候要谨慎。提示这两个脚本都会直接修改AnimationClip资源操作前记得让用户确认或者先复制一份备份。我一般会在脚本里加个EditorUtility.DisplayDialog确认框避免误操作。6. 动效预览快照不用进播放模式也能看效果6.1 为什么需要预览快照调UI动效最烦的是每次看效果都要进播放模式等加载、等初始化看完退出又要等。一个下午下来真正看动画的时间没多少全在等编辑器。预览快照的思路是在编辑器里直接采样动画的某一帧把结果渲染到一张贴图上在Inspector里显示。这样不用进播放模式拖时间轴就能看效果。6.2 采样与渲染的实现核心是用AnimationClip.SampleAnimation把动画采样到目标GameObject上然后用RenderTexture渲染。public static Texture2D CaptureFrame(GameObject target, AnimationClip clip, float time) { clip.SampleAnimation(target, time); var cam Camera.main; var rt RenderTexture.GetTemporary(512, 512, 24); var prev cam.targetTexture; cam.targetTexture rt; cam.Render(); var tex new Texture2D(512, 512, TextureFormat.RGBA32, false); RenderTexture.active rt; tex.ReadPixels(new Rect(0, 0, 512, 512), 0, 0); tex.Apply(); cam.targetTexture prev; RenderTexture.ReleaseTemporary(rt); RenderTexture.active null; return tex; }6.3 采样后必须还原状态SampleAnimation会直接修改GameObject的Transform和组件属性。如果你采样完不还原场景里的对象就停在采样帧的状态了下次打开工程一脸懵。我的做法是采样前记录所有相关组件的状态采样后还原。简单点的话可以记录Transform的position/rotation/scale采样后恢复。复杂点的话用EditorUtility.CopySerialized做深拷贝。还有个更省事的方案在场景里复制一份临时对象对副本采样采样完销毁副本。这样完全不影响原对象。缺点是复制对象有开销但预览场景下可以接受。6.4 快照的实用场景这个脚本我主要用在两个场景一是快速对比。同一个动画的不同版本各截一张图放一起看比来回切播放模式直观多了。二是给策划/美术看效果。他们不一定装了Unity或者不想进播放模式直接发几张关键帧截图沟通效率高很多。提示快照分辨率别设太高512×512足够看UI动效了。设成2048×2048的话每次采样渲染都要好几秒反而慢。7. 这6个脚本怎么组织进项目7.1 目录结构和依赖关系这6个脚本我放在Assets/Editor/UITools/下每个脚本一个文件共用一个UIToolsSettings的ScriptableObject存配置。依赖关系很简单都只依赖UnityEditor和UnityEngine没有互相依赖可以单独用。Assets/Editor/UITools/ ├── AutoSave.cs ├── TextureCompressor.cs ├── AtlasEstimator.cs ├── AnimationAligner.cs ├── AnimationOffsetter.cs ├── AnimationPreviewer.cs └── UIToolsSettings.csUIToolsSettings里存自动保存间隔、压缩预设、图集利用率这些可调参数用ScriptableSingleton实现这样配置能跟着工程走换台机器不用重设。7.2 菜单项怎么挂每个脚本都挂一个菜单项放在Tools/UITools/下。比如[MenuItem(Tools/UITools/Compress Textures)] public static void CompressMenu() { ... }菜单项的好处是不用记快捷键鼠标点两下就行。常用的可以加%Ctrl/Cmd快捷键比如自动保存开关设成%#S。7.3 团队协作时的注意事项这几个脚本如果要在团队里推广有几个点要注意第一自动保存要能关。不是所有人都喜欢自动保存给个开关默认开但允许关。第二压缩脚本要有预览。批量压缩前先列出会影响的文件让用户确认。我见过有人误点压缩把整个工程的图都压了一遍回滚都来不及。第三图集估算要能导出报告。光在控制台打印不够要能导出CSV方便在CI里做判断。第四动画脚本要备份。修改AnimationClip前自动备份一份到Temp/出问题能恢复。7.4 性能开销实测最后说下这几个脚本的性能开销都是我实测的数据脚本触发频率单次耗时影响自动保存每300秒0.5-2秒可忽略图片压缩手动每张0.1-0.5秒批量时明显图集估算手动/CI每个图集0.1秒可忽略末帧对齐手动每个动画0.05秒可忽略偏移修正手动每个动画0.05秒可忽略预览快照手动每帧0.3秒可忽略自动保存的耗时主要在SaveAssets()工程越大越慢。如果工程特别大几千个资源建议把间隔调到600秒或者只在播放前保存。图片压缩是唯一有明显耗时的因为SaveAndReimport()会触发资源重新导入。批量处理时建议分批每批50张中间让编辑器喘口气。这套脚本用下来我个人的体感是每天至少省出半小时到一小时的机械操作时间而且因为图集估算和末帧对齐的存在返工率明显下降。如果你也在做Unity UI动效建议先从自动保存和图集估算这两个开始投入产出比最高。压缩脚本因为涉及资源修改推广时要谨慎点最好先在测试分支上跑一遍验证效果。