企业官网建设流程全解析

1. 从"16-UI界面更新分数"这个标题说起

第一次看到"16-UI界面更新分数"这个标题，很多人可能会觉得信息量太少——没有说明是什么项目、用什么引擎、分数怎么更新。但恰恰是这种极简的标题，往往对应着一个非常具体的开发场景：在一个已经跑起来的交互项目里，把某个计分逻辑和UI显示打通。结合关键词里的Unity、PlayMaker、EasyAR、Vuforia、AR，基本可以判断这是一个AR互动类项目中的UI计分模块迭代。

我在实际做AR互动项目的时候，遇到过大量类似的需求：用户完成一次识别、触发一次交互、或者走完一轮流程，界面上要实时把分数刷出来。听起来简单，但真正落地时会牵扯到数据源在哪、UI用什么组件、刷新频率怎么控制、AR识别和UI渲染怎么协调这几个问题。这篇内容就围绕这个场景，把"UI界面更新分数"这件事从设计到实现到踩坑完整拆一遍。

适合阅读这篇内容的人包括：正在做Unity AR项目、需要把计分逻辑接到界面上的开发者；用PlayMaker做可视化逻辑编排、但不确定状态机怎么和UI通信的策划或TA；以及刚接触Unity UI系统、想搞清楚Text、TextMeshPro、Canvas刷新机制的新手。我会尽量把每个选择背后的理由讲清楚，而不是只丢一段代码让你抄。

需要提前说明的是，下面涉及的具体组件和参数，一部分来自我自己的项目实践，一部分是基于Unity通用开发惯例的合理补充。不同项目结构不一样，你可以按自己的实际情况调整。

2. 分数数据从哪里来：先理清数据源再谈UI

2.1 AR交互项目里分数的三种典型来源

在动手改UI之前，最容易被忽略的一步是确认分数到底由谁产生。我见过不少项目，UI改了半天没反应，最后发现是分数压根没被计算出来。AR互动项目里，分数来源通常有三类。

第一类是识别触发型。比如用EasyAR或Vuforia识别到一张图片、一个物体，就加固定分。这种逻辑最简单，识别成功的回调里直接累加即可。第二类是行为判定型，比如用户在屏幕上点击了正确区域、完成了拖拽、在规定时间内做出了反应，由判定逻辑给出分数。第三类是连续计分型，比如根据交互持续时长、距离目标的接近程度实时计算，分数是连续变化的。

这三种来源决定了UI刷新的策略完全不同。固定加分可以事件驱动，来一次刷一次；连续计分则需要考虑刷新频率，不能每帧都去改Text，否则性能和可读性都会出问题。

2.2 PlayMaker状态机与C#脚本的分工

关键词里出现了PlayMaker，说明这个项目很可能用了可视化状态机来编排逻辑。PlayMaker处理分数有个天然优势：状态切换直观，策划也能看懂。但它和UI的通信需要设计好边界。

我的建议是：分数计算逻辑放在PlayMaker的FSM里，UI刷新交给一个专门的C#脚本或PlayMaker的Set Property动作。不要让FSM直接去操作Canvas下的Text组件，因为一旦UI结构变动，FSM里的引用就会断，排查起来很痛苦。更稳的做法是维护一个中间层，比如一个全局的ScoreManager，FSM只负责往里写值，UI脚本监听这个值的变化。

如果坚持全PlayMaker实现，可以用"Set Fsm Float"配合"Get Fsm Float"在状态机之间传值，再在UI所在的FSM里用"Set Property"更新Text的text属性。但要注意PlayMaker的变量作用域，全局变量和局部变量混用是新手最容易翻车的地方。

2.3 分数存储：内存变量还是持久化

还有一个决策点：分数要不要存下来。如果只是单局游戏内的临时分数，一个int或float变量就够了。但如果涉及多关卡累计、排行榜、断点续玩，就需要考虑PlayerPrefs或者更正式的存储方案。

PlayerPrefs适合存简单的整数分数，用PlayerPrefs.SetInt("Score", score)和PlayerPrefs.GetInt("Score", 0)就能搞定。但它的缺点是明文存储、容易被改，做正式项目时如果分数涉及排名，建议加一层简单的校验或者用服务端记录。这个取舍在项目初期就要想清楚，后期再改存储方案，牵扯的代码量会很大。

3. UI组件选型：Text、TextMeshPro还是别的

3.1 传统Text组件的适用边界

Unity自带的UI Text组件（UnityEngine.UI.Text）是最容易上手的，拖一个Canvas，建一个Text，脚本里拿到引用改text属性就行。它的优点是轻量、依赖少、和旧版UI系统完全兼容。但缺点也很明显：缩放后容易糊、不支持富文本的高级排版、字体图集管理麻烦。

如果你的AR项目UI元素不多、分数显示就是几个数字、对清晰度要求不高，用传统Text完全够用。我早期做的一些Demo就是直接用Text，跑起来没问题。但一旦UI要适配多种分辨率，或者分数旁边还要显示图标、进度条，Text的短板就会暴露。

3.2 TextMeshPro在分数显示上的实际优势

TextMeshPro（TMP）现在是Unity官方推荐的文本方案。它在分数显示这个场景下的优势很具体：字体渲染清晰，即使用大字号也不会糊；支持富文本标签，可以轻松实现"分数+单位"混排、颜色高亮；性能更好，因为它用的是SDF字体，缩放时不需要重新生成图集。

关键词里出现了"unity 图文混排"，这正好是TMP的强项。比如你想显示"得分：1200 分"，其中数字用大号加粗、文字用小号灰色，用TMP的富文本标签几行就搞定。传统Text要实现同样效果，得拆成多个Text组件手动对齐，维护成本高得多。

不过TMP也有坑。它需要导入TMP Essentials资源包，中文字体需要自己生成字体资产（Font Asset），否则中文会显示成方块。生成中文字体资产时要注意字符集范围，全量中文字库文件很大，建议只包含项目实际用到的字符。

3.3 选型对比表

我的实际经验是：新项目直接上TMP，别犹豫。老项目如果UI已经用Text搭好了、改动成本高，那就维持现状，但新加的分数显示模块可以用TMP单独做。

4. 刷新机制：什么时候更新，怎么更新

4.1 事件驱动刷新与轮询刷新的取舍

UI更新分数，核心问题是"什么时候刷"。最朴素的做法是在Update里每帧把分数赋给Text，但这会造成不必要的开销——分数没变的时候也在刷。更好的方式是事件驱动：分数变化时触发一个事件，UI收到事件才更新。

在C#里可以用event或者Action来实现。定义一个OnScoreChanged事件，分数计算逻辑在改变分数后调用它，UI脚本订阅这个事件。这样只有真正变化时才刷新，性能更好，逻辑也更清晰。

如果项目用PlayMaker，可以用"Send Event"动作在分数变化的状态里发一个事件，UI所在的FSM监听这个事件后执行"Set Property"。效果是一样的，只是用可视化方式表达。

4.2 连续计分场景下的刷新节流

前面提到连续计分的情况，比如分数随交互时长平滑增长。这种场景下分数每帧都在变，如果每帧都刷UI，Text的重新布局和重绘会带来明显开销，尤其在移动端AR项目里，性能本来就紧张。

解决办法是节流：不追求每帧刷新，而是每隔固定时间刷一次，比如每0.1秒或0.2秒。用一个计时器累加Time.deltaTime，超过阈值才更新UI。人眼对分数跳动的感知没那么敏感，0.1秒的间隔看起来已经很流畅了。

还有一种做法是只在整数位变化时刷新。如果分数是浮点数但只显示整数部分，那么只有整数部分变了才更新Text，能省下大量无意义的刷新。

4.3 数字滚动动画的实现思路

很多项目希望分数不是瞬间跳变，而是有个滚动增长的效果，视觉上更有反馈感。实现思路是：维护一个"显示值"和一个"目标值"，每帧让显示值向目标值逼近，逼近速度可以用Lerp或者MoveTowards控制。

void Update() { if (Mathf.Abs(displayScore - targetScore) > 0.01f) { displayScore = Mathf.MoveTowards(displayScore, targetScore, rollSpeed * Time.deltaTime); scoreText.text = Mathf.RoundToInt(displayScore).ToString(); } }

这段逻辑放在UI脚本里，分数变化时只更新targetScore，滚动动画自动完成。注意rollSpeed要调好，太快看不出效果，太慢玩家会觉得卡。我一般用目标值和当前值差值的函数来动态调整速度，差值大时快、差值小时慢，收尾更自然。

5. AR识别与UI刷新的协同问题

5.1 识别成功瞬间的UI响应延迟

AR项目里一个典型问题是：识别到目标后，分数应该立刻更新，但玩家感觉UI反应慢半拍。原因往往不是UI本身慢，而是识别回调、逻辑处理、UI刷新串行执行，中间有延迟。

优化思路是把UI刷新从识别回调里解耦出来。识别回调只负责改分数值和发事件，UI刷新在下一帧或事件触发时执行。这样识别线程不会被UI操作阻塞，响应更快。另外要检查Canvas的渲染模式，World Space的Canvas在AR场景里刷新开销比Screen Space大，如果UI不需要跟随3D物体，尽量用Screen Space - Overlay。

5.2 多目标识别下的分数归属

如果场景里有多个可识别目标，每个目标对应不同分数，就要处理分数归属问题。常见做法是给每个识别目标绑定一个ID，识别回调里带上ID，分数逻辑根据ID决定加多少分。UI这边通常只显示总分，不需要区分来源，但如果要做"本次得分"的提示，就需要短暂显示单次得分再合并到总分。

这里有个容易忽略的点：识别丢失再重新识别，分数要不要重复加。如果不做去重，玩家把镜头移开再移回来，分数会重复累加。解决办法是记录已识别目标的集合，同一个目标在一次会话里只计一次分，或者设置冷却时间。

5.3 性能敏感场景下的UI优化

移动端AR项目对性能很敏感。UI这块的优化点包括：减少Canvas重建，把频繁变化的分数Text单独放在一个Canvas下，避免它变化时导致整个UI重建；关闭不需要的Raycast Target，分数Text不需要接收点击，把Raycast Target取消能省一点开销；控制字体图集大小，中文字体资产如果包含太多字符，内存占用会很高。

我踩过的一个坑是：分数Text和一堆静态UI放在同一个Canvas下，每次分数变化整个Canvas都重建，帧率明显下降。后来把分数Text拆到独立Canvas，问题就解决了。这个经验在UI元素多的项目里特别有用。

6. 踩坑实录：那些让我加班到深夜的问题

6.1 分数显示为方块或乱码

这是中文项目最常见的问题。原因通常是字体资产没有包含中文字符，或者TMP的默认字体不支持中文。解决步骤：用Window > TextMeshPro > Font Asset Creator生成中文字体资产，字符集选择Custom Characters，把项目用到的中文字符填进去，或者用Character Set里的Unicode Range指定中文区间。生成后把字体资产赋给Text组件。

如果用的是传统Text，检查Font是否设置了支持中文的字体，以及Font Size是否太小导致渲染异常。

6.2 分数更新了但界面没变

这个问题的排查链路我走过很多次。第一步，确认分数变量真的变了，在赋值处打Log。第二步，确认UI脚本拿到的Text引用不是空的，空引用不会报错但也不会更新。第三步，确认事件订阅在UI初始化之后才发生，如果订阅时机太早，事件发出时UI还没准备好。第四步，检查是否有多个脚本在改同一个Text，互相覆盖。

PlayMaker项目里还要检查FSM是否真的进入了更新UI的状态，有时候事件发了但状态机没响应，是因为事件名拼写不一致或者FSM没激活。

6.3 打包后分数UI错位

编辑器里跑得好好的，打包到设备上UI就错位，这通常是Canvas Scaler的设置问题。AR项目里UI要适配各种屏幕比例，Canvas Scaler的UI Scale Mode建议用Scale With Screen Size，Reference Resolution设成设计稿的分辨率，Match值根据项目横竖屏取0或1，或者取中间值平衡。

另外检查锚点（Anchor）设置，分数Text如果锚点没设好，在不同分辨率下位置会飘。把锚点固定在某个角或边，配合Rect Transform的Pos值，能保证相对位置稳定。

6.4 PlayMaker与C#混用时的引用丢失

PlayMaker的FSM里如果直接引用了场景里的Text组件，一旦UI结构变动或者预制体重新实例化，引用就会丢。我的做法是尽量用标签（Tag）或名称查找来获取引用，或者在UI脚本里暴露一个公共方法供PlayMaker调用，PlayMaker只传分数值，不直接碰UI组件。这样UI结构怎么改，FSM都不用动。

7. 一套可复用的分数UI模块设计

7.1 模块结构划分

把分数UI做成一个独立模块，包含三个部分：ScoreManager负责分数数据的存储和变更通知；ScoreUI负责监听变化并刷新显示；ScoreRoller负责滚动动画。三者通过事件解耦，任何一方替换都不影响其他部分。

ScoreManager用单例或者静态类实现，提供AddScore、SetScore、ResetScore方法，内部维护当前分数并在变化时触发OnScoreChanged事件。ScoreUI在Start里订阅事件，收到后更新targetScore。ScoreRoller在Update里做插值。

7.2 关键代码骨架

public class ScoreManager : MonoBehaviour { public static ScoreManager Instance; public int CurrentScore { get; private set; } public event Action<int> OnScoreChanged; void Awake() { if (Instance == null) Instance = this; else Destroy(gameObject); } public void AddScore(int amount) { CurrentScore += amount; OnScoreChanged?.Invoke(CurrentScore); } public void ResetScore() { CurrentScore = 0; OnScoreChanged?.Invoke(CurrentScore); } }

public class ScoreUI : MonoBehaviour { public TextMeshProUGUI scoreText; private int targetScore; private float displayScore; public float rollSpeed = 200f; void Start() { if (ScoreManager.Instance != null) ScoreManager.Instance.OnScoreChanged += HandleScoreChanged; } void OnDestroy() { if (ScoreManager.Instance != null) ScoreManager.Instance.OnScoreChanged -= HandleScoreChanged; } void HandleScoreChanged(int newScore) { targetScore = newScore; } void Update() { if (Mathf.Abs(displayScore - targetScore) > 0.5f) { displayScore = Mathf.MoveTowards(displayScore, targetScore, rollSpeed * Time.deltaTime); scoreText.text = Mathf.RoundToInt(displayScore).ToString(); } else if (scoreText.text != targetScore.ToString()) { displayScore = targetScore; scoreText.text = targetScore.ToString(); } } }

这套骨架的好处是职责清晰。PlayMaker那边只需要调用ScoreManager的AddScore方法，可以用"Call Method"动作实现，传一个整数参数即可。UI怎么显示、有没有动画，FSM完全不用关心。

7.3 与PlayMaker对接的具体做法

在PlayMaker里，用"Call Method"动作，指定目标为挂载ScoreManager的GameObject，Method选AddScore，Parameters填分数值。如果分数值是动态的，可以用FSM变量传入。这样策划在状态机里就能控制加分逻辑，不需要写代码。

需要注意的是，Call Method动作对方法签名有要求，参数类型要匹配。如果AddScore接收int，传float会报错。另外确保ScoreManager在场景里已经初始化，否则Instance为空会报空引用。

8. 一些容易被忽略的细节和我的个人习惯

分数UI看起来是个小功能，但细节决定体验。我习惯在分数变化时加一个轻微的缩放动画或者颜色闪烁，让玩家明确感知到"分数变了"。这个用DOTween或者简单的协程就能实现，成本很低但反馈感提升明显。

另一个习惯是把分数格式统一处理。比如超过一千显示"1,234"而不是"1234"，读起来更清晰。用score.ToString("N0")就能加千分位分隔符。如果要做国际化，还要考虑不同地区的数字格式差异。

还有一点是关于测试。分数逻辑一定要在真机上测，编辑器里跑得再顺，真机上可能因为性能、分辨率、输入延迟出现各种问题。我一般会在项目早期就把分数UI放到真机上验证，而不是等到最后打包才发现问题。

最后说一个关于版本管理的经验。UI预制体和分数脚本经常被多人同时修改，Git合并时容易冲突。建议把UI预制体拆得细一点，分数相关的部分单独成预制体，减少冲突概率。关键词里提到的"git unity项目 lf、crlf告警"也是类似的问题，Unity项目里文本文件的换行符要统一，建议在项目根目录加.gitattributes文件，把Unity相关文件标记为强制文本或二进制，避免换行符导致的假改动。

这套分数UI模块我在几个AR互动项目里复用下来，改动最多的是滚动动画的参数和字体资产，核心逻辑基本没动过。如果你正在做类似的功能，可以先把数据流理清楚，再动手写UI，能省下不少返工的时间。