1. 项目背景与核心需求拆解1.1 这个标题到底在说什么“16-UI界面更新分数”这个标题乍一看像是某个开发日志里的第16条记录核心动作是“UI界面更新”核心对象是“分数”。放在AR/Unity开发语境下它大概率指向一个很具体的场景在一个基于Unity引擎、使用PlayMaker做逻辑编排、EasyAR或Vuforia做AR识别的互动项目里把屏幕上显示的分数Score通过UI系统进行刷新和呈现。这类需求在AR互动项目里极其常见。比如一个AR射击小游戏用户扫描识别图后出现靶子打中一个加10分屏幕左上角实时显示当前总分又比如一个AR教育类应用孩子完成一个拼图步骤得20分UI上的分数要立刻跳变并伴随一个缩放动画。这些都属于“UI界面更新分数”的范畴。我之所以把这个标题拆得这么细是因为“更新分数”这四个字背后藏着至少三层工作第一层是数据层分数变量存在哪里、由谁修改第二层是逻辑层什么事件触发更新、更新时要不要做插值动画第三层是表现层UI Text或TextMeshPro组件怎么绑定、怎么保证在不同分辨率下不糊不偏。很多人只做了第一层和第三层中间的逻辑层用一句text.text score.ToString()草草了事结果就是分数跳变生硬、频繁GC、甚至在某些AR设备上因为渲染顺序问题导致UI被3D模型遮挡。1.2 谁需要关注这个内容如果你正在做以下几类项目这篇内容对你直接有用AR互动营销项目用EasyAR或Vuforia做识别用户完成互动后需要积分反馈分数UI要醒目、要跟手。Unity小游戏或教育应用用PlayMaker做状态机分数作为全局变量在多个FSM之间传递UI需要监听变化。光波导AR眼镜上的应用这类设备分辨率特殊、视场角有限UI布局和刷新策略跟手机完全不同分数显示位置和刷新频率都要重新考量。Unity新手向项目很多教程只教“怎么把Text拖到脚本上”但没讲清楚更新时机、性能开销和适配问题导致做出来的东西能跑但不好用。我见过太多项目功能都实现了但分数更新那一瞬间的体验很粗糙——数字直接跳、没有缓动、没有音效配合、甚至因为每帧都在改Text导致DrawCall飙升。这些细节才是区分“能跑”和“好用”的关键。1.3 技术栈组合的典型特征从热搜词里能看出这个项目涉及的技术栈是Unity PlayMaker EasyAR/Vuforia的组合。这个组合有很鲜明的特点Unity负责渲染和UI系统UGUI是主流选择TextMeshPro因为更好的字形渲染效果逐渐取代传统Text。PlayMaker负责可视化状态机编排好处是不写代码也能做逻辑坏处是如果FSM设计得不好事件满天飞分数更新这种高频操作容易变成性能瓶颈。EasyAR和Vuforia负责AR识别与跟踪它们各自有独立的生命周期回调分数更新往往要挂在这些回调之后。这三者叠加就产生了一个典型问题AR识别是异步的、不稳定的而UI更新是同步的、要求稳定的。识别丢失时分数UI要不要隐藏重新识别后分数要不要重置这些边界情况才是实际开发中最耗时间的部分。2. 分数UI更新的核心原理与方案选型2.1 为什么不用每帧刷新先讲一个我踩过的坑。早期做AR项目时我图省事在Update()里直接写scoreText.text score.ToString()。功能上没问题分数确实在变。但Profiler一开发现每帧都有字符串分配GC Alloc那一栏一直在跳。在手机上跑还好在AR眼镜那种算力有限的设备上频繁GC直接导致画面卡顿用户转头时UI跟着抖。后来我改成事件驱动分数变化时才更新UI。具体做法是封装一个ScoreManager内部维护int currentScore对外暴露AddScore(int delta)方法方法内部修改数值后触发OnScoreChanged事件UI层订阅这个事件来刷新显示。这样每帧零开销只有真正加分时才执行一次字符串转换和赋值。注意PlayMaker里也可以用类似思路。不要在每个FSM的Update状态里轮询分数变量而是用Send Event在加分动作完成后通知UI的FSM。2.2 Text vs TextMeshPro怎么选这是另一个高频问题。传统UGUI Text用的是Arial之类的系统字体放大后边缘模糊在AR眼镜那种需要高对比度小字号的场景下尤其明显。TextMeshProTMP用的是Signed Distance Field渲染字号放大到200号依然锐利而且支持更丰富的富文本标签。但TMP也不是没代价。它的字体资源需要预生成中文字体如果字符集大图集内存占用不小。我的建议是场景推荐方案理由手机AR分数数字为主TextMeshPro数字锐利支持描边和发光AR眼镜性能敏感传统Text 位图字体开销更低但需要做多套分辨率适配需要频繁改颜色和动画TextMeshPro富文本和材质属性动画更方便项目已大量使用PlayMaker两者皆可PlayMaker对两者都有现成Action我个人的习惯是只要项目允许一律上TMP。中文字体用动态字体图集模式只把常用字打进图集不常用的按需生成内存和效果平衡得比较好。2.3 PlayMaker在分数逻辑中的角色定位PlayMaker在这个链路里最适合做的是状态编排而不是数值计算。什么意思比如“识别成功→显示靶子→用户点击→加分→播放音效→更新UI→判断是否通关”这一串流程用FSM画出来一目了然比写代码直观。但“加分”这个动作本身我建议还是用C#脚本实现PlayMaker通过Call Method或自定义Action来调用。原因很简单PlayMaker的变量系统在频繁读写时性能不如原生C#字段而且FSM状态切换本身有开销。把纯计算逻辑放在C#里PlayMaker只负责“什么时候调用”职责分离后期维护也清晰。具体做法是写一个ScoreControllerMonoBehaviour暴露public void AddScore(int amount)方法然后在PlayMaker里用Call MethodAction调用它。UI更新也在C#内部完成PlayMaker不需要知道UI的存在。这样即使以后换UI方案PlayMaker那边的FSM完全不用动。3. 实操过程与核心环节实现3.1 场景搭建与UI层级规划先建Canvas。AR项目里Canvas的Render Mode选择有讲究Screen Space - OverlayUI永远在最上层不会被3D物体遮挡。适合分数这种需要始终可见的元素。Screen Space - CameraUI由指定相机渲染可以被其他物体遮挡。适合需要融入场景的UI。World SpaceUI作为3D物体存在会随视角变化。适合AR眼镜上需要固定在空间某处的UI。分数显示我一般用Overlay保证任何情况下用户都能看到。Canvas Scaler组件设置UI Scale Mode为Scale With Screen Size参考分辨率设成项目主要目标设备的分辨率。比如主要跑在手机上就设1080x1920跑在AR眼镜上就设1920x1080。层级结构建议这样组织Canvas (Overlay) ├── ScorePanel │ ├── ScoreLabel (TextMeshPro - 分数) │ └── ScoreValue (TextMeshPro - 0) ├── ComboPanel (可选连击显示) └── EffectLayer (粒子或动画特效)把分数标签和数值分开两个TMP组件好处是标签不用频繁更新只有数值在变。虽然TMP的SetText有优化但能少一次调用就少一次。3.2 分数管理器的C#实现下面是我常用的ScoreManager核心代码去掉了项目特定逻辑保留通用部分using System; using TMPro; using UnityEngine; public class ScoreManager : MonoBehaviour { public static ScoreManager Instance { get; private set; } [SerializeField] private TextMeshProUGUI scoreText; [SerializeField] private float countDuration 0.3f; private int currentScore 0; private int displayScore 0; private float countTimer 0f; private bool isCounting false; public event Actionint OnScoreChanged; private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; } private void Start() { UpdateTextImmediate(0); } public void AddScore(int amount) { currentScore amount; OnScoreChanged?.Invoke(currentScore); StartCountAnimation(); } public void ResetScore() { currentScore 0; displayScore 0; isCounting false; UpdateTextImmediate(0); OnScoreChanged?.Invoke(0); } private void StartCountAnimation() { if (!isCounting) { isCounting true; countTimer 0f; } } private void Update() { if (!isCounting) return; countTimer Time.deltaTime; float t Mathf.Clamp01(countTimer / countDuration); // 缓动函数让数字变化先快后慢 float eased 1f - Mathf.Pow(1f - t, 3f); displayScore Mathf.RoundToInt(Mathf.Lerp(displayScore, currentScore, eased)); if (displayScore currentScore) { displayScore currentScore; isCounting false; } scoreText.SetText({0}, displayScore); } private void UpdateTextImmediate(int value) { displayScore value; scoreText.SetText({0}, value); } }这段代码有几个关键点值得展开单例模式AR项目里分数通常是全局唯一的用单例方便PlayMaker和其他脚本访问。但要注意在场景切换时不要重复创建Awake里的判重逻辑就是干这个的。数字滚动动画countDuration控制从旧分数滚到新分数的时长默认0.3秒。eased用的是三次缓出曲线数字先快后慢视觉上更自然。如果你想要更花哨的效果可以换成Mathf.SmoothStep或者自定义AnimationCurve。SetText的格式化TMP的SetText({0}, value)比text value.ToString()少一次字符串分配因为TMP内部有缓存机制。在频繁更新的场景下这个差异会被放大。事件通知OnScoreChanged事件让其他系统比如音效、成就、连击可以监听分数变化而不需要轮询。PlayMaker那边可以用Get Property或自定义Action来订阅。3.3 PlayMaker FSM的对接方式在PlayMaker里我通常建一个独立的ScoreFSM状态很少Idle状态等待事件。AddScore状态收到ADD_SCORE事件后用Call Method调用ScoreManager.Instance.AddScore(amount)amount从FSM变量读取。Reset状态收到RESET_SCORE事件后调用ResetScore()。关键配置Call MethodAction的Behaviour字段拖入场景里的ScoreManager对象。Method Name填AddScore。Parameters里传入int类型的分数值可以从FSM的Int变量取。这样PlayMaker只负责“什么时候加分”具体怎么加、UI怎么更新全部由C#层处理。FSM图非常干净后期改UI方案也不用动PlayMaker。实操心得PlayMaker的Call Method在IL2CPP打包后偶尔会有反射相关的兼容问题。如果遇到可以改用Send Message或者写一个自定义Action直接引用ScoreManager类型。自定义Action虽然多写几行代码但类型安全打包更稳。3.4 AR识别与分数重置的边界处理EasyAR和Vuforia在识别丢失时都会触发回调。这里有个设计决策识别丢失后分数要不要保留我的经验是分场景单次体验型比如扫一张图玩一局识别丢失即游戏结束分数应该保留并显示结算界面。重新识别后重置。持续互动型比如AR展览里用户来回走动识别可能短暂丢失又恢复分数应该保留不清零。多目标型不同识别图对应不同关卡切换目标时分数按关卡独立存储。实现上在EasyAR的TargetLost回调或Vuforia的OnTargetLost里不要直接调ResetScore()而是发一个事件让上层逻辑决定。我一般会加一个ScorePersistence枚举在Inspector里配置当前场景的行为。public enum ScorePersistence { ResetOnLost, // 丢失即重置 KeepOnLost, // 丢失保留 ResetOnNewTarget // 新目标出现时重置 }这个枚举在ScoreManager里读取配合AR回调使用。看起来是多了一步但实际项目里这个配置项能省掉大量改代码的时间。4. 常见问题与排查技巧实录4.1 分数显示模糊或锯齿这是最高频的问题。原因通常有三个Canvas Scaler没配好。如果参考分辨率设得太低在高分辨率设备上UI被放大TMP虽然矢量渲染但图集有最大尺寸限制超过后依然会糊。解决办法是把参考分辨率设成目标设备的主流分辨率或者用Constant Pixel Size模式配合多套布局。TMP字体图集分辨率不够。在TMP的Font Asset设置里Atlas Resolution默认是1024x1024对于大字号数字可能不够。改成2048x2048同时把Padding调到5以上边缘会更干净。材质Shader选错。TMP默认用的是TextMeshPro/Distance Field如果误改成TextMeshPro/Bitmap放大后必糊。检查材质球上的Shader。4.2 分数更新时UI闪烁或跳变如果分数是从0直接跳到100没有中间过程用户会觉得突兀。除了前面说的滚动动画还要检查是不是有多个脚本在同时改同一个TMP组件。比如PlayMaker里有一个Set Text ActionC#里又在Update里改两者打架就会闪。排查方法在TMP组件上挂一个调试脚本在OnPreRenderText回调里打Log看一帧内被改了几次。正常应该只有一次。4.3 AR眼镜上的UI位置偏移光波导AR眼镜的显示区域和普通屏幕不一样视场角有限UI如果放在屏幕边缘可能根本看不到。我的做法是把分数UI放在视野中心偏上的位置并且做安全区域适配。具体来说在Canvas下加一个SafeAreaPanel用Screen.safeArea来动态调整RectTransform的锚点。这样在不同设备上UI都会落在可视区域内。代码不复杂private void ApplySafeArea() { Rect safeArea Screen.safeArea; Vector2 anchorMin safeArea.position; Vector2 anchorMax safeArea.position safeArea.size; anchorMin.x / Screen.width; anchorMin.y / Screen.height; anchorMax.x / Screen.width; anchorMax.y / Screen.height; safeAreaPanel.anchorMin anchorMin; safeAreaPanel.anchorMax anchorMax; }在Start和屏幕方向变化时调用一次即可。4.4 常见问题速查表现象可能原因排查方向解决方案分数不更新事件未订阅/PlayMaker未调用检查OnScoreChanged订阅数确认ScoreManager实例存在且方法被调用分数更新但UI不动TMP组件引用丢失Inspector里scoreText是否为空重新拖拽赋值或代码里Find数字显示为方块字体图集缺字TMP字体资源是否包含数字重新生成字体图集加入0-9更新时卡顿每帧字符串分配Profiler看GC Alloc改用SetText并事件驱动AR丢失后分数错乱重置逻辑冲突检查TargetLost回调用ScorePersistence枚举统一管理打包后PlayMaker调用失败IL2CPP反射裁剪看打包Log有无MissingMethod改用自定义Action或Link.xml保留4.5 一个容易被忽略的细节分数变化的音效同步分数更新往往要配一个“叮”的音效。如果音效播放和UI刷新不同步用户会觉得别扭。我的做法是在AddScore方法里先触发UI更新再延迟一帧播音效。为什么延迟一帧因为UI渲染和音频播放的时序在不同设备上不一致延迟一帧能让视觉和听觉几乎同时到达。public void AddScore(int amount) { currentScore amount; OnScoreChanged?.Invoke(currentScore); StartCountAnimation(); StartCoroutine(PlayScoreSoundDelayed()); } private IEnumerator PlayScoreSoundDelayed() { yield return null; // 等一帧 AudioManager.PlayScoreSound(); }这个技巧在AR眼镜上尤其明显因为眼镜的音频输出和显示刷新可能有细微延迟不处理的话“叮”声会早于数字变化。5. 性能优化与扩展思路5.1 减少DrawCall的合批策略分数UI虽然简单但如果项目里UI元素多DrawCall一样会上去。TMP的合批规则是相同材质、相同图集的TMP组件可以合批。所以分数标签和数值如果用的是同一个字体资源它们会自动合批。但如果中间插了一个Image背景合批就断了。优化方法把分数相关的元素放在同一个Canvas下并且确保它们使用的材质和图集一致。如果分数面板有背景图把背景图放在单独的Canvas里用Sort Order控制层级这样背景和文字各自合批互不打断。5.2 分数变化的扩展表现基础的数字滚动之外还可以加这些效果成本不高但体验提升明显缩放脉冲分数变化时ScoreValue的Transform做一次DOPunchScale需要DOTween或手写协程缩放。颜色渐变从白色快速过渡到金色再回白色用TMP的color属性做插值。粒子特效在分数位置Instantiate一个短生命周期的粒子播放完自动Destroy。连击显示连续加分时显示“x2”“x3”用单独的TMP组件超时后隐藏。这些效果我建议做成可开关的配置项在低端设备上关掉粒子只保留数字滚动保证帧率。5.3 多语言与数值格式化如果项目要出海分数显示可能涉及千分位分隔符。比如1000显示成“1,000”。TMP的SetText支持格式化字符串scoreText.SetText({0:N0}, displayScore);N0表示带千分位的整数。但注意不同地区的分隔符可能不同如果需要严格本地化用CultureInfo来格式化后再SetText。中文环境下一般不需要千分位但阿拉伯语等从右往左的语言需要额外处理TMP的isRightToLeftText属性。这些细节在项目初期就要考虑后期补很麻烦。5.4 与Vuforia/EasyAR版本兼容的注意事项Vuforia和EasyAR的版本更新有时会改动回调接口。比如Vuforia从9.x到10.xITrackableEventHandler的实现方式有变化。分数重置逻辑如果挂在这些回调上升级SDK时就要跟着改。我的建议是把AR回调统一封装到一个ARTrackerAdapter类里对外暴露OnTargetFound和OnTargetLost事件ScoreManager只订阅这个适配器的事件不直接依赖Vuforia或EasyAR的接口。这样换SDK或升级版本时只需要改适配器一个文件。public class ARTrackerAdapter : MonoBehaviour { public event Action OnTargetFound; public event Action OnTargetLost; // Vuforia或EasyAR的回调里调用这两个方法 public void NotifyTargetFound() OnTargetFound?.Invoke(); public void NotifyTargetLost() OnTargetLost?.Invoke(); }这个封装层看起来多此一举但在实际项目里能省掉大量重构时间。我经历过一次Vuforia大版本升级因为有了这层适配器分数逻辑一行没改。5.5 测试与验证清单上线前我一般会跑一遍这个清单连续快速加分100次看UI是否跟得上有无卡顿。分数从0加到99999看数字宽度变化是否导致布局错位。AR识别丢失再恢复分数是否符合预期行为。在不同分辨率设备上手机横竖屏、AR眼镜看UI是否在安全区域内。打包IL2CPP后跑一遍确认PlayMaker调用和TMP显示正常。Profiler看GC Alloc分数更新时应该只有极少量或零分配。这个清单跑完基本能覆盖90%的线上问题。剩下的10%往往是设备特定的渲染差异只能靠真机测试发现。我个人在实际操作中的体会是分数UI更新这件事技术难度不高但细节密度很大。从数据层到表现层每一层都有可以优化的空间。把事件驱动、TMP格式化、安全区适配、AR回调封装这几件事做扎实后面加任何新功能都会很顺。反过来如果一开始就用Update里改Text的写法后期想加动画、加音效、加多语言每加一个都要动核心逻辑越改越乱。所以我的建议是哪怕项目再小也花半小时把ScoreManager的结构搭好这个投入回报比非常高。
Unity AR开发中UI分数更新的核心原理与性能优化实践
1. 项目背景与核心需求拆解1.1 这个标题到底在说什么“16-UI界面更新分数”这个标题乍一看像是某个开发日志里的第16条记录核心动作是“UI界面更新”核心对象是“分数”。放在AR/Unity开发语境下它大概率指向一个很具体的场景在一个基于Unity引擎、使用PlayMaker做逻辑编排、EasyAR或Vuforia做AR识别的互动项目里把屏幕上显示的分数Score通过UI系统进行刷新和呈现。这类需求在AR互动项目里极其常见。比如一个AR射击小游戏用户扫描识别图后出现靶子打中一个加10分屏幕左上角实时显示当前总分又比如一个AR教育类应用孩子完成一个拼图步骤得20分UI上的分数要立刻跳变并伴随一个缩放动画。这些都属于“UI界面更新分数”的范畴。我之所以把这个标题拆得这么细是因为“更新分数”这四个字背后藏着至少三层工作第一层是数据层分数变量存在哪里、由谁修改第二层是逻辑层什么事件触发更新、更新时要不要做插值动画第三层是表现层UI Text或TextMeshPro组件怎么绑定、怎么保证在不同分辨率下不糊不偏。很多人只做了第一层和第三层中间的逻辑层用一句text.text score.ToString()草草了事结果就是分数跳变生硬、频繁GC、甚至在某些AR设备上因为渲染顺序问题导致UI被3D模型遮挡。1.2 谁需要关注这个内容如果你正在做以下几类项目这篇内容对你直接有用AR互动营销项目用EasyAR或Vuforia做识别用户完成互动后需要积分反馈分数UI要醒目、要跟手。Unity小游戏或教育应用用PlayMaker做状态机分数作为全局变量在多个FSM之间传递UI需要监听变化。光波导AR眼镜上的应用这类设备分辨率特殊、视场角有限UI布局和刷新策略跟手机完全不同分数显示位置和刷新频率都要重新考量。Unity新手向项目很多教程只教“怎么把Text拖到脚本上”但没讲清楚更新时机、性能开销和适配问题导致做出来的东西能跑但不好用。我见过太多项目功能都实现了但分数更新那一瞬间的体验很粗糙——数字直接跳、没有缓动、没有音效配合、甚至因为每帧都在改Text导致DrawCall飙升。这些细节才是区分“能跑”和“好用”的关键。1.3 技术栈组合的典型特征从热搜词里能看出这个项目涉及的技术栈是Unity PlayMaker EasyAR/Vuforia的组合。这个组合有很鲜明的特点Unity负责渲染和UI系统UGUI是主流选择TextMeshPro因为更好的字形渲染效果逐渐取代传统Text。PlayMaker负责可视化状态机编排好处是不写代码也能做逻辑坏处是如果FSM设计得不好事件满天飞分数更新这种高频操作容易变成性能瓶颈。EasyAR和Vuforia负责AR识别与跟踪它们各自有独立的生命周期回调分数更新往往要挂在这些回调之后。这三者叠加就产生了一个典型问题AR识别是异步的、不稳定的而UI更新是同步的、要求稳定的。识别丢失时分数UI要不要隐藏重新识别后分数要不要重置这些边界情况才是实际开发中最耗时间的部分。2. 分数UI更新的核心原理与方案选型2.1 为什么不用每帧刷新先讲一个我踩过的坑。早期做AR项目时我图省事在Update()里直接写scoreText.text score.ToString()。功能上没问题分数确实在变。但Profiler一开发现每帧都有字符串分配GC Alloc那一栏一直在跳。在手机上跑还好在AR眼镜那种算力有限的设备上频繁GC直接导致画面卡顿用户转头时UI跟着抖。后来我改成事件驱动分数变化时才更新UI。具体做法是封装一个ScoreManager内部维护int currentScore对外暴露AddScore(int delta)方法方法内部修改数值后触发OnScoreChanged事件UI层订阅这个事件来刷新显示。这样每帧零开销只有真正加分时才执行一次字符串转换和赋值。注意PlayMaker里也可以用类似思路。不要在每个FSM的Update状态里轮询分数变量而是用Send Event在加分动作完成后通知UI的FSM。2.2 Text vs TextMeshPro怎么选这是另一个高频问题。传统UGUI Text用的是Arial之类的系统字体放大后边缘模糊在AR眼镜那种需要高对比度小字号的场景下尤其明显。TextMeshProTMP用的是Signed Distance Field渲染字号放大到200号依然锐利而且支持更丰富的富文本标签。但TMP也不是没代价。它的字体资源需要预生成中文字体如果字符集大图集内存占用不小。我的建议是场景推荐方案理由手机AR分数数字为主TextMeshPro数字锐利支持描边和发光AR眼镜性能敏感传统Text 位图字体开销更低但需要做多套分辨率适配需要频繁改颜色和动画TextMeshPro富文本和材质属性动画更方便项目已大量使用PlayMaker两者皆可PlayMaker对两者都有现成Action我个人的习惯是只要项目允许一律上TMP。中文字体用动态字体图集模式只把常用字打进图集不常用的按需生成内存和效果平衡得比较好。2.3 PlayMaker在分数逻辑中的角色定位PlayMaker在这个链路里最适合做的是状态编排而不是数值计算。什么意思比如“识别成功→显示靶子→用户点击→加分→播放音效→更新UI→判断是否通关”这一串流程用FSM画出来一目了然比写代码直观。但“加分”这个动作本身我建议还是用C#脚本实现PlayMaker通过Call Method或自定义Action来调用。原因很简单PlayMaker的变量系统在频繁读写时性能不如原生C#字段而且FSM状态切换本身有开销。把纯计算逻辑放在C#里PlayMaker只负责“什么时候调用”职责分离后期维护也清晰。具体做法是写一个ScoreControllerMonoBehaviour暴露public void AddScore(int amount)方法然后在PlayMaker里用Call MethodAction调用它。UI更新也在C#内部完成PlayMaker不需要知道UI的存在。这样即使以后换UI方案PlayMaker那边的FSM完全不用动。3. 实操过程与核心环节实现3.1 场景搭建与UI层级规划先建Canvas。AR项目里Canvas的Render Mode选择有讲究Screen Space - OverlayUI永远在最上层不会被3D物体遮挡。适合分数这种需要始终可见的元素。Screen Space - CameraUI由指定相机渲染可以被其他物体遮挡。适合需要融入场景的UI。World SpaceUI作为3D物体存在会随视角变化。适合AR眼镜上需要固定在空间某处的UI。分数显示我一般用Overlay保证任何情况下用户都能看到。Canvas Scaler组件设置UI Scale Mode为Scale With Screen Size参考分辨率设成项目主要目标设备的分辨率。比如主要跑在手机上就设1080x1920跑在AR眼镜上就设1920x1080。层级结构建议这样组织Canvas (Overlay) ├── ScorePanel │ ├── ScoreLabel (TextMeshPro - 分数) │ └── ScoreValue (TextMeshPro - 0) ├── ComboPanel (可选连击显示) └── EffectLayer (粒子或动画特效)把分数标签和数值分开两个TMP组件好处是标签不用频繁更新只有数值在变。虽然TMP的SetText有优化但能少一次调用就少一次。3.2 分数管理器的C#实现下面是我常用的ScoreManager核心代码去掉了项目特定逻辑保留通用部分using System; using TMPro; using UnityEngine; public class ScoreManager : MonoBehaviour { public static ScoreManager Instance { get; private set; } [SerializeField] private TextMeshProUGUI scoreText; [SerializeField] private float countDuration 0.3f; private int currentScore 0; private int displayScore 0; private float countTimer 0f; private bool isCounting false; public event Actionint OnScoreChanged; private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; } private void Start() { UpdateTextImmediate(0); } public void AddScore(int amount) { currentScore amount; OnScoreChanged?.Invoke(currentScore); StartCountAnimation(); } public void ResetScore() { currentScore 0; displayScore 0; isCounting false; UpdateTextImmediate(0); OnScoreChanged?.Invoke(0); } private void StartCountAnimation() { if (!isCounting) { isCounting true; countTimer 0f; } } private void Update() { if (!isCounting) return; countTimer Time.deltaTime; float t Mathf.Clamp01(countTimer / countDuration); // 缓动函数让数字变化先快后慢 float eased 1f - Mathf.Pow(1f - t, 3f); displayScore Mathf.RoundToInt(Mathf.Lerp(displayScore, currentScore, eased)); if (displayScore currentScore) { displayScore currentScore; isCounting false; } scoreText.SetText({0}, displayScore); } private void UpdateTextImmediate(int value) { displayScore value; scoreText.SetText({0}, value); } }这段代码有几个关键点值得展开单例模式AR项目里分数通常是全局唯一的用单例方便PlayMaker和其他脚本访问。但要注意在场景切换时不要重复创建Awake里的判重逻辑就是干这个的。数字滚动动画countDuration控制从旧分数滚到新分数的时长默认0.3秒。eased用的是三次缓出曲线数字先快后慢视觉上更自然。如果你想要更花哨的效果可以换成Mathf.SmoothStep或者自定义AnimationCurve。SetText的格式化TMP的SetText({0}, value)比text value.ToString()少一次字符串分配因为TMP内部有缓存机制。在频繁更新的场景下这个差异会被放大。事件通知OnScoreChanged事件让其他系统比如音效、成就、连击可以监听分数变化而不需要轮询。PlayMaker那边可以用Get Property或自定义Action来订阅。3.3 PlayMaker FSM的对接方式在PlayMaker里我通常建一个独立的ScoreFSM状态很少Idle状态等待事件。AddScore状态收到ADD_SCORE事件后用Call Method调用ScoreManager.Instance.AddScore(amount)amount从FSM变量读取。Reset状态收到RESET_SCORE事件后调用ResetScore()。关键配置Call MethodAction的Behaviour字段拖入场景里的ScoreManager对象。Method Name填AddScore。Parameters里传入int类型的分数值可以从FSM的Int变量取。这样PlayMaker只负责“什么时候加分”具体怎么加、UI怎么更新全部由C#层处理。FSM图非常干净后期改UI方案也不用动PlayMaker。实操心得PlayMaker的Call Method在IL2CPP打包后偶尔会有反射相关的兼容问题。如果遇到可以改用Send Message或者写一个自定义Action直接引用ScoreManager类型。自定义Action虽然多写几行代码但类型安全打包更稳。3.4 AR识别与分数重置的边界处理EasyAR和Vuforia在识别丢失时都会触发回调。这里有个设计决策识别丢失后分数要不要保留我的经验是分场景单次体验型比如扫一张图玩一局识别丢失即游戏结束分数应该保留并显示结算界面。重新识别后重置。持续互动型比如AR展览里用户来回走动识别可能短暂丢失又恢复分数应该保留不清零。多目标型不同识别图对应不同关卡切换目标时分数按关卡独立存储。实现上在EasyAR的TargetLost回调或Vuforia的OnTargetLost里不要直接调ResetScore()而是发一个事件让上层逻辑决定。我一般会加一个ScorePersistence枚举在Inspector里配置当前场景的行为。public enum ScorePersistence { ResetOnLost, // 丢失即重置 KeepOnLost, // 丢失保留 ResetOnNewTarget // 新目标出现时重置 }这个枚举在ScoreManager里读取配合AR回调使用。看起来是多了一步但实际项目里这个配置项能省掉大量改代码的时间。4. 常见问题与排查技巧实录4.1 分数显示模糊或锯齿这是最高频的问题。原因通常有三个Canvas Scaler没配好。如果参考分辨率设得太低在高分辨率设备上UI被放大TMP虽然矢量渲染但图集有最大尺寸限制超过后依然会糊。解决办法是把参考分辨率设成目标设备的主流分辨率或者用Constant Pixel Size模式配合多套布局。TMP字体图集分辨率不够。在TMP的Font Asset设置里Atlas Resolution默认是1024x1024对于大字号数字可能不够。改成2048x2048同时把Padding调到5以上边缘会更干净。材质Shader选错。TMP默认用的是TextMeshPro/Distance Field如果误改成TextMeshPro/Bitmap放大后必糊。检查材质球上的Shader。4.2 分数更新时UI闪烁或跳变如果分数是从0直接跳到100没有中间过程用户会觉得突兀。除了前面说的滚动动画还要检查是不是有多个脚本在同时改同一个TMP组件。比如PlayMaker里有一个Set Text ActionC#里又在Update里改两者打架就会闪。排查方法在TMP组件上挂一个调试脚本在OnPreRenderText回调里打Log看一帧内被改了几次。正常应该只有一次。4.3 AR眼镜上的UI位置偏移光波导AR眼镜的显示区域和普通屏幕不一样视场角有限UI如果放在屏幕边缘可能根本看不到。我的做法是把分数UI放在视野中心偏上的位置并且做安全区域适配。具体来说在Canvas下加一个SafeAreaPanel用Screen.safeArea来动态调整RectTransform的锚点。这样在不同设备上UI都会落在可视区域内。代码不复杂private void ApplySafeArea() { Rect safeArea Screen.safeArea; Vector2 anchorMin safeArea.position; Vector2 anchorMax safeArea.position safeArea.size; anchorMin.x / Screen.width; anchorMin.y / Screen.height; anchorMax.x / Screen.width; anchorMax.y / Screen.height; safeAreaPanel.anchorMin anchorMin; safeAreaPanel.anchorMax anchorMax; }在Start和屏幕方向变化时调用一次即可。4.4 常见问题速查表现象可能原因排查方向解决方案分数不更新事件未订阅/PlayMaker未调用检查OnScoreChanged订阅数确认ScoreManager实例存在且方法被调用分数更新但UI不动TMP组件引用丢失Inspector里scoreText是否为空重新拖拽赋值或代码里Find数字显示为方块字体图集缺字TMP字体资源是否包含数字重新生成字体图集加入0-9更新时卡顿每帧字符串分配Profiler看GC Alloc改用SetText并事件驱动AR丢失后分数错乱重置逻辑冲突检查TargetLost回调用ScorePersistence枚举统一管理打包后PlayMaker调用失败IL2CPP反射裁剪看打包Log有无MissingMethod改用自定义Action或Link.xml保留4.5 一个容易被忽略的细节分数变化的音效同步分数更新往往要配一个“叮”的音效。如果音效播放和UI刷新不同步用户会觉得别扭。我的做法是在AddScore方法里先触发UI更新再延迟一帧播音效。为什么延迟一帧因为UI渲染和音频播放的时序在不同设备上不一致延迟一帧能让视觉和听觉几乎同时到达。public void AddScore(int amount) { currentScore amount; OnScoreChanged?.Invoke(currentScore); StartCountAnimation(); StartCoroutine(PlayScoreSoundDelayed()); } private IEnumerator PlayScoreSoundDelayed() { yield return null; // 等一帧 AudioManager.PlayScoreSound(); }这个技巧在AR眼镜上尤其明显因为眼镜的音频输出和显示刷新可能有细微延迟不处理的话“叮”声会早于数字变化。5. 性能优化与扩展思路5.1 减少DrawCall的合批策略分数UI虽然简单但如果项目里UI元素多DrawCall一样会上去。TMP的合批规则是相同材质、相同图集的TMP组件可以合批。所以分数标签和数值如果用的是同一个字体资源它们会自动合批。但如果中间插了一个Image背景合批就断了。优化方法把分数相关的元素放在同一个Canvas下并且确保它们使用的材质和图集一致。如果分数面板有背景图把背景图放在单独的Canvas里用Sort Order控制层级这样背景和文字各自合批互不打断。5.2 分数变化的扩展表现基础的数字滚动之外还可以加这些效果成本不高但体验提升明显缩放脉冲分数变化时ScoreValue的Transform做一次DOPunchScale需要DOTween或手写协程缩放。颜色渐变从白色快速过渡到金色再回白色用TMP的color属性做插值。粒子特效在分数位置Instantiate一个短生命周期的粒子播放完自动Destroy。连击显示连续加分时显示“x2”“x3”用单独的TMP组件超时后隐藏。这些效果我建议做成可开关的配置项在低端设备上关掉粒子只保留数字滚动保证帧率。5.3 多语言与数值格式化如果项目要出海分数显示可能涉及千分位分隔符。比如1000显示成“1,000”。TMP的SetText支持格式化字符串scoreText.SetText({0:N0}, displayScore);N0表示带千分位的整数。但注意不同地区的分隔符可能不同如果需要严格本地化用CultureInfo来格式化后再SetText。中文环境下一般不需要千分位但阿拉伯语等从右往左的语言需要额外处理TMP的isRightToLeftText属性。这些细节在项目初期就要考虑后期补很麻烦。5.4 与Vuforia/EasyAR版本兼容的注意事项Vuforia和EasyAR的版本更新有时会改动回调接口。比如Vuforia从9.x到10.xITrackableEventHandler的实现方式有变化。分数重置逻辑如果挂在这些回调上升级SDK时就要跟着改。我的建议是把AR回调统一封装到一个ARTrackerAdapter类里对外暴露OnTargetFound和OnTargetLost事件ScoreManager只订阅这个适配器的事件不直接依赖Vuforia或EasyAR的接口。这样换SDK或升级版本时只需要改适配器一个文件。public class ARTrackerAdapter : MonoBehaviour { public event Action OnTargetFound; public event Action OnTargetLost; // Vuforia或EasyAR的回调里调用这两个方法 public void NotifyTargetFound() OnTargetFound?.Invoke(); public void NotifyTargetLost() OnTargetLost?.Invoke(); }这个封装层看起来多此一举但在实际项目里能省掉大量重构时间。我经历过一次Vuforia大版本升级因为有了这层适配器分数逻辑一行没改。5.5 测试与验证清单上线前我一般会跑一遍这个清单连续快速加分100次看UI是否跟得上有无卡顿。分数从0加到99999看数字宽度变化是否导致布局错位。AR识别丢失再恢复分数是否符合预期行为。在不同分辨率设备上手机横竖屏、AR眼镜看UI是否在安全区域内。打包IL2CPP后跑一遍确认PlayMaker调用和TMP显示正常。Profiler看GC Alloc分数更新时应该只有极少量或零分配。这个清单跑完基本能覆盖90%的线上问题。剩下的10%往往是设备特定的渲染差异只能靠真机测试发现。我个人在实际操作中的体会是分数UI更新这件事技术难度不高但细节密度很大。从数据层到表现层每一层都有可以优化的空间。把事件驱动、TMP格式化、安全区适配、AR回调封装这几件事做扎实后面加任何新功能都会很顺。反过来如果一开始就用Update里改Text的写法后期想加动画、加音效、加多语言每加一个都要动核心逻辑越改越乱。所以我的建议是哪怕项目再小也花半小时把ScoreManager的结构搭好这个投入回报比非常高。
