1. 项目概述为什么我们需要“打印”富文本在Unity UI开发中TextMeshPro简称TMP早已成为处理高质量文本显示的事实标准。它解决了传统UI Text在字体渲染、排版和性能上的诸多痛点。然而当我们拿到一个包含颜色、大小、加粗、下划线甚至动画标签的富文本字符串时直接将其赋值给TMP_Text.text属性所有效果会瞬间呈现。这虽然简单但在很多需要“演出感”的场景下就显得生硬了。比如角色对话需要逐字显示以营造氛围任务提示需要逐条高亮出现或者日志系统需要模拟打字机效果让信息有条不紊地呈现给玩家。这就是“TMP富文本打印”功能的核心价值所在。它不是一个内置功能而是一种通过编程实现的、可控的文本逐字或逐词显示效果。其本质是在单帧内只更新部分文本内容利用协程或异步任务控制更新的节奏同时确保TMP的富文本标签如color#FF0000,size150%,b,i等在“打印”过程中被正确解析和渲染不会出现标签被当作普通字符显示出来的尴尬情况。我接手过不少需要强化叙事表现的项目从视觉小说到沉浸式RPG这个功能几乎是标配。自己实现一遍不仅能解决眼前的需求更能深入理解TMP的文本解析流程和Unity的协程机制对于处理更复杂的UI动画序列也大有裨益。接下来我将拆解从设计思路到具体实现再到避坑优化的完整过程。2. 核心思路与方案选型协程驱动的状态机实现逐字打印最直观的想法就是用一个循环每次在文本末尾追加一个字符。但面对富文本事情就复杂了。你不能简单地按字符切割字符串因为像colorredHello/color这样的字符串如果你从开始切就会破坏标签结构导致渲染错误。因此核心思路必须围绕“如何在不破坏富文本标签结构的前提下逐段推进可见文本”展开。经过多次迭代我总结出一个稳定可靠的方案基于协程的状态机配合TMP对富文本标签的解析能力。2.1 方案对比与选型理由在项目初期我评估过几种常见方案字符串拼接法每帧在原完整文本字符串上做Substring(0, index)然后赋值。这是最朴素的方法但每次Substring和赋值都会产生新的字符串在打印长文本时会产生可观的GC Alloc垃圾回收分配对性能敏感的游戏如移动端不友好。并且需要自己处理富文本标签的嵌套和闭合极易出错。预解析标签法在打印前先将完整的富文本字符串解析成一个结构体列表列表中的元素可能是“普通字符”或“标签”。打印时遍历这个列表。这种方法GC开销小逻辑清晰是性能最优的方案但实现复杂度最高需要自己写一个简易的富文本解析器。利用TMP内部解析法这是我最推荐也是下文详细展开的方案。其核心是利用TMP_Text的textInfo属性它包含了TMP引擎对当前文本进行解析后的所有信息包括字符、行、链接以及富文本标签的起止索引。我们可以依赖TMP的解析结果来安全地推进文本。我选择方案三理由如下可靠性高直接使用TMP官方的解析结果避免了自行解析可能带来的标签匹配错误兼容TMP支持的所有标签。实现相对简洁无需自己造轮子解析HTML风格的标签逻辑集中在“如何利用解析信息”上。性能可接受虽然每次推进需要重新设置maxVisibleCharacters或重新构建部分文本但通过优化如分帧处理其GC开销在大多数非极端情况下是可管理的。2.2 关键组件TMP_TextInfo 与标签栈理解这个方案需要先了解两个关键概念。TMP_TextInfo这是TMP_Text组件的一个属性类型为TMP_TextInfo。当你设置TMP_Text.text后TMP引擎会立即对其进行解析结果就存储在这里面。对我们最重要的子属性是characterInfo: 一个TMP_CharacterInfo[]数组包含了屏幕上每个字符的详细信息位置、顶点索引等。数组长度等于可见字符数注意富文本标签不计入。linkInfo,wordInfo,lineInfo等分别存储链接、单词、行的信息。重要提示TMP_TextInfo是在TMP_Text的GenerateTextMesh或ComputeMarginSize等内部方法调用后才会被填充。通常在设置text属性后需要手动调用TMP_Text.ForceMeshUpdate()来立即强制更新textInfo数据确保我们能拿到最新的解析结果。标签栈Tag StackTMP在解析文本时会维护一个“标签状态栈”。例如遇到b标签就将“加粗”状态入栈遇到/b就将该状态出栈。这个栈保证了嵌套标签的正确渲染如colorredb文本/b/color。我们的打印逻辑必须模拟这个过程在打印到标签的闭合位置时要确保之前打开的标签效果被正确移除。3. 核心实现一个健壮的富文本打印器下面我将实现一个名为TMPTypewriter的组件。它将被挂载到含有TMP_Text的GameObject上提供可配置的打印速度、开始/停止控制以及回调事件。3.1 组件结构与初始化首先我们定义组件的框架和必要的字段。using UnityEngine; using UnityEngine.Events; using TMPro; using System.Collections; using System.Text; [RequireComponent(typeof(TMP_Text))] public class TMPTypewriter : MonoBehaviour { [Header(打印设置)] [Tooltip(每秒打印的字符数)] public float charactersPerSecond 30f; [Tooltip(打印开始前的延迟秒)] public float startDelay 0f; [Tooltip(是否在Awake时自动开始打印)] public bool playOnAwake false; [Header(高级设置)] [Tooltip(为true时会逐字打印为false时会等待标签完整后再打印)] public bool printTagCharactersIndividually false; [Tooltip(打印完成后是否保留此组件便于重复使用)] public bool keepComponentOnComplete true; [Header(事件)] public UnityEvent onPrintStarted; public UnityEvent onCharacterPrinted; // 每打印一个可见字符触发 public UnityEvent onPrintCompleted; private TMP_Text m_TextComponent; private string m_OriginalText; private Coroutine m_TypewriterCoroutine; private bool m_IsPrinting false; private void Awake() { m_TextComponent GetComponentTMP_Text(); // 保存原始文本但先清空显示等待打印 m_OriginalText m_TextComponent.text; m_TextComponent.text ; m_TextComponent.ForceMeshUpdate(); // 关键强制更新Mesh以清空textInfo if (playOnAwake) { StartCoroutine(StartPrintWithDelay()); } } private IEnumerator StartPrintWithDelay() { if (startDelay 0) yield return new WaitForSeconds(startDelay); StartPrint(); } }这里有几个关键点RequireComponent确保挂载此组件的GameObject上一定有TMP_Text。保存与清空在Awake中我们将TMP_Text的原始文本保存到m_OriginalText然后将其清空。这是为了从头开始打印。清空后立即调用ForceMeshUpdate()确保TMP的内部状态特别是textInfo被重置。协程控制使用Coroutine来控制异步的打印流程并用m_IsPrinting标志位来防止重复启动。3.2 打印流程的核心协程这是整个组件的灵魂。我们将实现一个名为TypewriterCore的协程。public void StartPrint() { if (m_IsPrinting || m_TextComponent null) return; // 如果已有协程在运行先停止 if (m_TypewriterCoroutine ! null) { StopCoroutine(m_TypewriterCoroutine); } m_TypewriterCoroutine StartCoroutine(TypewriterCore()); } public void StopPrint(bool showFullText false) { if (m_TypewriterCoroutine ! null) { StopCoroutine(m_TypewriterCoroutine); m_TypewriterCoroutine null; } m_IsPrinting false; if (showFullText) { m_TextComponent.text m_OriginalText; m_TextComponent.ForceMeshUpdate(); onPrintCompleted?.Invoke(); } } private IEnumerator TypewriterCore() { m_IsPrinting true; onPrintStarted?.Invoke(); // 第一步设置完整文本并强制TMP解析以获取正确的textInfo m_TextComponent.text m_OriginalText; m_TextComponent.maxVisibleCharacters 0; // 先隐藏所有字符 m_TextComponent.ForceMeshUpdate(); // 关键生成包含所有标签信息的Mesh和textInfo TMP_TextInfo textInfo m_TextComponent.textInfo; int totalVisibleCharacters textInfo.characterCount; // 可见字符总数不含标签 int currentVisibleCount 0; // 计算每打印一个字符需要等待的时间 float delayPerCharacter (charactersPerSecond 0) ? 1f / charactersPerSecond : 0f; // 第二步逐字推进 while (currentVisibleCount totalVisibleCharacters) { currentVisibleCount; m_TextComponent.maxVisibleCharacters currentVisibleCount; // 触发每字符打印事件 onCharacterPrinted?.Invoke(); // 等待 if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); else yield return null; // 如果速度为0则每帧打印一个字符 } // 打印完成 m_IsPrinting false; m_TypewriterCoroutine null; onPrintCompleted?.Invoke(); // 清理 if (!keepComponentOnComplete) { // 可选打印完成后销毁此组件保留最终的TMP文本状态 Destroy(this); } }这个基础版本已经能工作了但它有一个致命缺陷它直接使用了maxVisibleCharacters。这个属性确实可以控制显示多少个字符但TMP在处理富文本时maxVisibleCharacters是按textInfo.characterInfo数组的索引来计算的。而这个数组不包含富文本标签字符。所以如果我们有一段文本colorredHello/colorcharacterInfo里只有5个字符H, e, l, l, o标签被过滤掉了。我们的循环会正确地显示这5个字符。这看起来没问题对吗问题在于交互性和样式提前生效。考虑一个场景文本中包含一个可点击的链接linkidClick Here/link。在打印过程中如果maxVisibleCharacters只覆盖了“Click ”部分“Here”还未显示但此时整个链接的矩形区域根据完整文本计算可能已经可以交互了这会导致逻辑错误。更复杂的样式嵌套也可能出现渲染瑕疵。3.3 进阶实现正确处理标签与可见字符为了解决上述问题我们需要更精细地控制“打印指针”的移动。我们不能简单地按可见字符索引推进而需要遍历原始的富文本字符串识别标签和可见字符并相应地更新TMP的文本。以下是改进后的核心协程逻辑private IEnumerator TypewriterCoreAdvanced() { m_IsPrinting true; onPrintStarted?.Invoke(); // 清空文本从头开始构建 m_TextComponent.text ; m_TextComponent.ForceMeshUpdate(); StringBuilder displayedText new StringBuilder(); string fullText m_OriginalText; int readIndex 0; // 在完整文本中的读取位置 bool insideTag false; StringBuilder tagBuffer new StringBuilder(); float delayPerCharacter (charactersPerSecond 0) ? 1f / charactersPerSecond : 0f; while (readIndex fullText.Length) { char currentChar fullText[readIndex]; // 情况1遇到标签开始符 且不在另一个标签内 if (currentChar !insideTag) { insideTag true; tagBuffer.Clear(); tagBuffer.Append(currentChar); readIndex; continue; // 继续读取标签内的下一个字符 } // 情况2当前正在读取一个标签 if (insideTag) { tagBuffer.Append(currentChar); // 情况2a遇到标签结束符 if (currentChar ) { // 标签读取完毕 string fullTag tagBuffer.ToString(); displayedText.Append(fullTag); // 立即更新TMP文本让标签生效但可能还不可见 m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 如果是自闭合标签如br或打印设置允许可以触发事件 if (printTagCharactersIndividually) { onCharacterPrinted?.Invoke(); if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); } insideTag false; readIndex; continue; } // 情况2b还在标签内部继续读取下一个字符 readIndex; continue; } // 情况3普通可见字符或转义字符这里简化处理 displayedText.Append(currentChar); m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 每次更新文本后都需要强制刷新Mesh onCharacterPrinted?.Invoke(); if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); else yield return null; readIndex; } // 循环结束打印完成 m_IsPrinting false; m_TypewriterCoroutine null; onPrintCompleted?.Invoke(); if (!keepComponentOnComplete) { Destroy(this); } }这个版本的逻辑更健壮逐字符扫描遍历原始富文本字符串的每一个字符。状态机用insideTag标志位跟踪是否正在读取一个标签。用tagBuffer缓存标签内容。即时生效每当一个完整的标签以结尾被读取后立即将其追加到displayedText并更新TMP_Text.text。这意味着colorred这个标签一旦被完整读取其后的所有字符即使还未“打印”出来在TMP的解析树中都已经带上了红色属性。这保证了样式的正确性。可见字符打印遇到非标签的普通字符才执行“打印”动作追加、更新文本、触发事件、等待。这样displayedText中始终保持着当前已解析的完整富文本字符串。注意这个版本每次更新文本都调用了ForceMeshUpdate()在打印长文本时可能产生性能开销。在实际项目中可以优化为累积几个字符后再更新一次或者在yield return null时由Unity在帧末自动更新但可能造成样式更新延迟。这是一个典型的性能与效果平滑度的权衡。3.4 添加音效与字符回调为了增强表现力我们经常需要在打印每个字符时播放一个打字音效或者在特定字符位置如标点处增加额外延迟。[Header(音效与回调)] public AudioClip typeSound; public AudioSource audioSource; // 如果不指定会尝试从自身或父物体获取 public float punctuationPauseFactor 3f; // 遇到标点符号时延迟时间乘以此因子 private void PlayTypeSound() { if (typeSound ! null) { if (audioSource null) audioSource GetComponentAudioSource() ?? gameObject.AddComponentAudioSource(); audioSource.PlayOneShot(typeSound); } } // 在 TypewriterCoreAdvanced 协程中打印可见字符的部分加入 // ... 打印可见字符的逻辑开始 displayedText.Append(currentChar); m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 播放音效 PlayTypeSound(); // 判断是否为需要额外停顿的标点 float currentDelay delayPerCharacter; if (IsPunctuation(currentChar)) { currentDelay * punctuationPauseFactor; } onCharacterPrinted?.Invoke(); if (currentDelay 0) yield return new WaitForSeconds(currentDelay); else yield return null; // ... 打印可见字符的逻辑结束 private bool IsPunctuation(char c) { // 简单的标点判断可根据需要扩展 return c , || c . || c ! || c ? || c ; || c :; }4. 性能优化与高级技巧基础功能实现后我们需要关注性能和灵活性。直接每字符更新Mesh在移动端或处理大量文本时可能成为瓶颈。4.1 性能优化减少Mesh更新频繁调用ForceMeshUpdate()和直接赋值text属性是性能消耗的主要来源。优化策略是批量更新。private IEnumerator TypewriterCoreOptimized() { // ... 初始化部分同上 ... StringBuilder displayedText new StringBuilder(); string fullText m_OriginalText; int readIndex 0; bool insideTag false; StringBuilder tagBuffer new StringBuilder(); // 新增批量更新相关变量 int charactersSinceLastUpdate 0; const int BATCH_UPDATE_COUNT 5; // 每积累5个可见字符更新一次Mesh while (readIndex fullText.Length) { // ... 标签和字符的处理逻辑同 TypewriterCoreAdvanced ... // 在追加普通可见字符后 displayedText.Append(currentChar); charactersSinceLastUpdate; // 批量更新条件积累了一定数量的字符或者遇到了必须立即更新的标签如样式变化大的标签 bool isCriticalTag fullTag.StartsWith(color) || fullTag.StartsWith(size) || fullTag.StartsWith(b) || fullTag.StartsWith(i); if (charactersSinceLastUpdate BATCH_UPDATE_COUNT || isCriticalTag) { m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); charactersSinceLastUpdate 0; } // 注意如果不满足条件文本内容已更新在StringBuilder中但TMP组件还未渲染。 // 为了确保事件触发时文本是最新的我们仍然更新但可以跳过ForceMeshUpdate。 // 更精细的做法是区分“文本内容”和“渲染状态”。 // ... 播放音效、等待 ... } // 循环结束后确保最终文本被渲染 if (charactersSinceLastUpdate 0) { m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); } // ... 完成逻辑 ... }此外如果文本极其长可以考虑使用TMP_Text.text的StringBuilder重载版本如果可用或者使用ObjectPool回收字符串构建过程中产生的垃圾但这些属于更极致的优化。4.2 支持跳过与加速玩家通常没有耐心等待长文本慢慢打印。我们需要提供跳过立即完成和加速功能。public void SkipToEnd() { if (!m_IsPrinting) return; StopPrint(true); // 调用之前的StopPrint方法并传入true以显示全文 } public void SetPrintSpeedMultiplier(float multiplier) { charactersPerSecond * multiplier; // 注意这会影响到正在运行的协程中使用的delayPerCharacter变量。 // 更严谨的做法是在协程内每帧读取一个可变的speedFactor而不是在开始时缓存delay。 }更优雅的加速实现是在协程内部使用一个可变的速率因子private float m_SpeedMultiplier 1.0f; public float SpeedMultiplier { get m_SpeedMultiplier; set m_SpeedMultiplier Mathf.Max(0.1f, value); // 设置最小值防止除零 } // 在协程的等待部分 float effectiveDelay delayPerCharacter / m_SpeedMultiplier; if (effectiveDelay 0) yield return new WaitForSeconds(effectiveDelay); else yield return null;4.3 处理特殊标签与动画TMP支持一些特殊标签如sprite精灵图和anim简单动画。对于sprite它被视为一个“字符”存在于characterInfo中。我们的基础maxVisibleCharacters方案和进阶的字符扫描方案都能很好地处理它它会作为一个整体被显示或隐藏。对于anim标签它通常依赖于时间的推移。在逐字打印的上下文中如果动画标签内的字符还未完全显示动画可能不会播放或播放异常。一个稳妥的做法是在打印到包含动画的文本段时暂时禁用或重置动画待该部分完全显示后再启用。这需要对TMP的动画标签有更深入的理解和定制处理。5. 实战问题排查与心得在实际项目集成中你肯定会遇到一些预料之外的情况。这里记录几个我踩过的坑和解决方案。5.1 问题一文本闪烁或布局跳动现象在打印过程中尤其是字体大小变化或样式切换时文本整体位置会发生轻微跳动或闪烁。原因每次ForceMeshUpdate()都会导致TMP重新计算文本的几何形状和布局。如果前后两次更新的布局结果有细微差异由于字体纹理生成、空格宽度计算等就会造成视觉上的跳动。解决方案确保字体资产设置正确在TMP Font Asset Creator中导入字体时确保“Sampling Point Size”与你在项目中实际使用的大小相匹配并生成足够的字体图集尺寸避免运行时动态缩放。使用TMP_Text.autoSizeTextContainer如果文本区域是动态大小的在打印开始前将其设置为false打印完成后再设为true或者直接使用固定大小的RectTransform。布局组件干扰检查父物体是否有ContentSizeFitter、LayoutGroup等组件。在打印期间可以考虑暂时禁用它们或使用Canvas.ForceUpdateCanvases()在合适时机强制更新布局。5.2 问题二与UI动画系统的冲突现象打印组件所在的UI元素同时在进行缩放、淡入等Dotween或Unity动画导致打印位置不准或效果混乱。原因UI动画可能修改了Transform或CanvasGroup的属性与TMP每帧的Mesh更新产生竞争。解决方案错开更新时机确保打印协程的yield return null即每帧更新与UI动画的关键帧更新不在同一时间点。可以考虑将打印协程的等待改为yield return new WaitForEndOfFrame()在所有动画和布局计算完成后才更新文本。优先级控制设计一个简单的更新管理器确保文本内容更新在UI视觉更新之后。5.3 问题三大量文本打印时的卡顿现象打印非常长的日志或对话时游戏帧率明显下降。原因每字符或每批字符都调用ForceMeshUpdate()和重新构建MeshCPU开销大。解决方案增大批量更新阈值将上述优化中的BATCH_UPDATE_COUNT从5提高到10或15。分帧处理与其每打印N个字符等待一段时间不如每帧固定打印M个字符。这可以通过在协程中使用for循环配合yield return null来实现能更好地利用CPU时间片避免单帧过载。int charsPerFrame 2; // 每帧打印2个字符 while (currentIndex totalLength) { for (int i 0; i charsPerFrame currentIndex totalLength; i) { // ... 处理一个字符的逻辑 ... currentIndex; } yield return null; // 下一帧继续 }对象池与预处理对于需要反复打印的文本如重复的任务提示可以预先将其解析成中间格式如字符和标签的序列打印时直接遍历该序列避免每次都对原始字符串进行解析和状态判断。5.4 一个实用的调试技巧在开发过程中为了看清打印指针到底在哪我经常添加一个临时的调试方法在OnValidate或一个调试按钮中将maxVisibleCharacters设置为一个特定值然后高亮当前应打印的字符例如通过修改其顶点颜色。这能帮你快速确认标签解析和字符推进逻辑是否正确。private void OnValidate() { if (!Application.isPlaying) return; if (m_TextComponent ! null) { // 假设你想查看打印到第50个可见字符时的状态 m_TextComponent.maxVisibleCharacters 50; m_TextComponent.ForceMeshUpdate(); // 可以在这里添加代码将第50个字符的颜色改为红色以便观察 } }实现一个鲁棒的TMP富文本打印器远不止一个while循环加yield return那么简单。它涉及到对TMP内部工作机制的理解、字符串处理的精细操作、协程的生命周期管理以及性能的平衡。从最基础的maxVisibleCharacters方案到能够正确处理所有富文本标签的字符扫描状态机每一步的进化都是为了解决实际项目中遇到的具体问题。最重要的是根据你的项目需求是移动端轻量级视觉小说还是PC端大量日志显示选择合适的实现策略和优化程度。把这个组件打磨好它将成为你UI工具箱里一个非常得力的助手让游戏的文字表达充满生命力。
1. 项目概述为什么我们需要“打印”富文本在Unity UI开发中TextMeshPro简称TMP早已成为处理高质量文本显示的事实标准。它解决了传统UI Text在字体渲染、排版和性能上的诸多痛点。然而当我们拿到一个包含颜色、大小、加粗、下划线甚至动画标签的富文本字符串时直接将其赋值给TMP_Text.text属性所有效果会瞬间呈现。这虽然简单但在很多需要“演出感”的场景下就显得生硬了。比如角色对话需要逐字显示以营造氛围任务提示需要逐条高亮出现或者日志系统需要模拟打字机效果让信息有条不紊地呈现给玩家。这就是“TMP富文本打印”功能的核心价值所在。它不是一个内置功能而是一种通过编程实现的、可控的文本逐字或逐词显示效果。其本质是在单帧内只更新部分文本内容利用协程或异步任务控制更新的节奏同时确保TMP的富文本标签如color#FF0000,size150%,b,i等在“打印”过程中被正确解析和渲染不会出现标签被当作普通字符显示出来的尴尬情况。我接手过不少需要强化叙事表现的项目从视觉小说到沉浸式RPG这个功能几乎是标配。自己实现一遍不仅能解决眼前的需求更能深入理解TMP的文本解析流程和Unity的协程机制对于处理更复杂的UI动画序列也大有裨益。接下来我将拆解从设计思路到具体实现再到避坑优化的完整过程。2. 核心思路与方案选型协程驱动的状态机实现逐字打印最直观的想法就是用一个循环每次在文本末尾追加一个字符。但面对富文本事情就复杂了。你不能简单地按字符切割字符串因为像colorredHello/color这样的字符串如果你从开始切就会破坏标签结构导致渲染错误。因此核心思路必须围绕“如何在不破坏富文本标签结构的前提下逐段推进可见文本”展开。经过多次迭代我总结出一个稳定可靠的方案基于协程的状态机配合TMP对富文本标签的解析能力。2.1 方案对比与选型理由在项目初期我评估过几种常见方案字符串拼接法每帧在原完整文本字符串上做Substring(0, index)然后赋值。这是最朴素的方法但每次Substring和赋值都会产生新的字符串在打印长文本时会产生可观的GC Alloc垃圾回收分配对性能敏感的游戏如移动端不友好。并且需要自己处理富文本标签的嵌套和闭合极易出错。预解析标签法在打印前先将完整的富文本字符串解析成一个结构体列表列表中的元素可能是“普通字符”或“标签”。打印时遍历这个列表。这种方法GC开销小逻辑清晰是性能最优的方案但实现复杂度最高需要自己写一个简易的富文本解析器。利用TMP内部解析法这是我最推荐也是下文详细展开的方案。其核心是利用TMP_Text的textInfo属性它包含了TMP引擎对当前文本进行解析后的所有信息包括字符、行、链接以及富文本标签的起止索引。我们可以依赖TMP的解析结果来安全地推进文本。我选择方案三理由如下可靠性高直接使用TMP官方的解析结果避免了自行解析可能带来的标签匹配错误兼容TMP支持的所有标签。实现相对简洁无需自己造轮子解析HTML风格的标签逻辑集中在“如何利用解析信息”上。性能可接受虽然每次推进需要重新设置maxVisibleCharacters或重新构建部分文本但通过优化如分帧处理其GC开销在大多数非极端情况下是可管理的。2.2 关键组件TMP_TextInfo 与标签栈理解这个方案需要先了解两个关键概念。TMP_TextInfo这是TMP_Text组件的一个属性类型为TMP_TextInfo。当你设置TMP_Text.text后TMP引擎会立即对其进行解析结果就存储在这里面。对我们最重要的子属性是characterInfo: 一个TMP_CharacterInfo[]数组包含了屏幕上每个字符的详细信息位置、顶点索引等。数组长度等于可见字符数注意富文本标签不计入。linkInfo,wordInfo,lineInfo等分别存储链接、单词、行的信息。重要提示TMP_TextInfo是在TMP_Text的GenerateTextMesh或ComputeMarginSize等内部方法调用后才会被填充。通常在设置text属性后需要手动调用TMP_Text.ForceMeshUpdate()来立即强制更新textInfo数据确保我们能拿到最新的解析结果。标签栈Tag StackTMP在解析文本时会维护一个“标签状态栈”。例如遇到b标签就将“加粗”状态入栈遇到/b就将该状态出栈。这个栈保证了嵌套标签的正确渲染如colorredb文本/b/color。我们的打印逻辑必须模拟这个过程在打印到标签的闭合位置时要确保之前打开的标签效果被正确移除。3. 核心实现一个健壮的富文本打印器下面我将实现一个名为TMPTypewriter的组件。它将被挂载到含有TMP_Text的GameObject上提供可配置的打印速度、开始/停止控制以及回调事件。3.1 组件结构与初始化首先我们定义组件的框架和必要的字段。using UnityEngine; using UnityEngine.Events; using TMPro; using System.Collections; using System.Text; [RequireComponent(typeof(TMP_Text))] public class TMPTypewriter : MonoBehaviour { [Header(打印设置)] [Tooltip(每秒打印的字符数)] public float charactersPerSecond 30f; [Tooltip(打印开始前的延迟秒)] public float startDelay 0f; [Tooltip(是否在Awake时自动开始打印)] public bool playOnAwake false; [Header(高级设置)] [Tooltip(为true时会逐字打印为false时会等待标签完整后再打印)] public bool printTagCharactersIndividually false; [Tooltip(打印完成后是否保留此组件便于重复使用)] public bool keepComponentOnComplete true; [Header(事件)] public UnityEvent onPrintStarted; public UnityEvent onCharacterPrinted; // 每打印一个可见字符触发 public UnityEvent onPrintCompleted; private TMP_Text m_TextComponent; private string m_OriginalText; private Coroutine m_TypewriterCoroutine; private bool m_IsPrinting false; private void Awake() { m_TextComponent GetComponentTMP_Text(); // 保存原始文本但先清空显示等待打印 m_OriginalText m_TextComponent.text; m_TextComponent.text ; m_TextComponent.ForceMeshUpdate(); // 关键强制更新Mesh以清空textInfo if (playOnAwake) { StartCoroutine(StartPrintWithDelay()); } } private IEnumerator StartPrintWithDelay() { if (startDelay 0) yield return new WaitForSeconds(startDelay); StartPrint(); } }这里有几个关键点RequireComponent确保挂载此组件的GameObject上一定有TMP_Text。保存与清空在Awake中我们将TMP_Text的原始文本保存到m_OriginalText然后将其清空。这是为了从头开始打印。清空后立即调用ForceMeshUpdate()确保TMP的内部状态特别是textInfo被重置。协程控制使用Coroutine来控制异步的打印流程并用m_IsPrinting标志位来防止重复启动。3.2 打印流程的核心协程这是整个组件的灵魂。我们将实现一个名为TypewriterCore的协程。public void StartPrint() { if (m_IsPrinting || m_TextComponent null) return; // 如果已有协程在运行先停止 if (m_TypewriterCoroutine ! null) { StopCoroutine(m_TypewriterCoroutine); } m_TypewriterCoroutine StartCoroutine(TypewriterCore()); } public void StopPrint(bool showFullText false) { if (m_TypewriterCoroutine ! null) { StopCoroutine(m_TypewriterCoroutine); m_TypewriterCoroutine null; } m_IsPrinting false; if (showFullText) { m_TextComponent.text m_OriginalText; m_TextComponent.ForceMeshUpdate(); onPrintCompleted?.Invoke(); } } private IEnumerator TypewriterCore() { m_IsPrinting true; onPrintStarted?.Invoke(); // 第一步设置完整文本并强制TMP解析以获取正确的textInfo m_TextComponent.text m_OriginalText; m_TextComponent.maxVisibleCharacters 0; // 先隐藏所有字符 m_TextComponent.ForceMeshUpdate(); // 关键生成包含所有标签信息的Mesh和textInfo TMP_TextInfo textInfo m_TextComponent.textInfo; int totalVisibleCharacters textInfo.characterCount; // 可见字符总数不含标签 int currentVisibleCount 0; // 计算每打印一个字符需要等待的时间 float delayPerCharacter (charactersPerSecond 0) ? 1f / charactersPerSecond : 0f; // 第二步逐字推进 while (currentVisibleCount totalVisibleCharacters) { currentVisibleCount; m_TextComponent.maxVisibleCharacters currentVisibleCount; // 触发每字符打印事件 onCharacterPrinted?.Invoke(); // 等待 if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); else yield return null; // 如果速度为0则每帧打印一个字符 } // 打印完成 m_IsPrinting false; m_TypewriterCoroutine null; onPrintCompleted?.Invoke(); // 清理 if (!keepComponentOnComplete) { // 可选打印完成后销毁此组件保留最终的TMP文本状态 Destroy(this); } }这个基础版本已经能工作了但它有一个致命缺陷它直接使用了maxVisibleCharacters。这个属性确实可以控制显示多少个字符但TMP在处理富文本时maxVisibleCharacters是按textInfo.characterInfo数组的索引来计算的。而这个数组不包含富文本标签字符。所以如果我们有一段文本colorredHello/colorcharacterInfo里只有5个字符H, e, l, l, o标签被过滤掉了。我们的循环会正确地显示这5个字符。这看起来没问题对吗问题在于交互性和样式提前生效。考虑一个场景文本中包含一个可点击的链接linkidClick Here/link。在打印过程中如果maxVisibleCharacters只覆盖了“Click ”部分“Here”还未显示但此时整个链接的矩形区域根据完整文本计算可能已经可以交互了这会导致逻辑错误。更复杂的样式嵌套也可能出现渲染瑕疵。3.3 进阶实现正确处理标签与可见字符为了解决上述问题我们需要更精细地控制“打印指针”的移动。我们不能简单地按可见字符索引推进而需要遍历原始的富文本字符串识别标签和可见字符并相应地更新TMP的文本。以下是改进后的核心协程逻辑private IEnumerator TypewriterCoreAdvanced() { m_IsPrinting true; onPrintStarted?.Invoke(); // 清空文本从头开始构建 m_TextComponent.text ; m_TextComponent.ForceMeshUpdate(); StringBuilder displayedText new StringBuilder(); string fullText m_OriginalText; int readIndex 0; // 在完整文本中的读取位置 bool insideTag false; StringBuilder tagBuffer new StringBuilder(); float delayPerCharacter (charactersPerSecond 0) ? 1f / charactersPerSecond : 0f; while (readIndex fullText.Length) { char currentChar fullText[readIndex]; // 情况1遇到标签开始符 且不在另一个标签内 if (currentChar !insideTag) { insideTag true; tagBuffer.Clear(); tagBuffer.Append(currentChar); readIndex; continue; // 继续读取标签内的下一个字符 } // 情况2当前正在读取一个标签 if (insideTag) { tagBuffer.Append(currentChar); // 情况2a遇到标签结束符 if (currentChar ) { // 标签读取完毕 string fullTag tagBuffer.ToString(); displayedText.Append(fullTag); // 立即更新TMP文本让标签生效但可能还不可见 m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 如果是自闭合标签如br或打印设置允许可以触发事件 if (printTagCharactersIndividually) { onCharacterPrinted?.Invoke(); if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); } insideTag false; readIndex; continue; } // 情况2b还在标签内部继续读取下一个字符 readIndex; continue; } // 情况3普通可见字符或转义字符这里简化处理 displayedText.Append(currentChar); m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 每次更新文本后都需要强制刷新Mesh onCharacterPrinted?.Invoke(); if (delayPerCharacter 0) yield return new WaitForSeconds(delayPerCharacter); else yield return null; readIndex; } // 循环结束打印完成 m_IsPrinting false; m_TypewriterCoroutine null; onPrintCompleted?.Invoke(); if (!keepComponentOnComplete) { Destroy(this); } }这个版本的逻辑更健壮逐字符扫描遍历原始富文本字符串的每一个字符。状态机用insideTag标志位跟踪是否正在读取一个标签。用tagBuffer缓存标签内容。即时生效每当一个完整的标签以结尾被读取后立即将其追加到displayedText并更新TMP_Text.text。这意味着colorred这个标签一旦被完整读取其后的所有字符即使还未“打印”出来在TMP的解析树中都已经带上了红色属性。这保证了样式的正确性。可见字符打印遇到非标签的普通字符才执行“打印”动作追加、更新文本、触发事件、等待。这样displayedText中始终保持着当前已解析的完整富文本字符串。注意这个版本每次更新文本都调用了ForceMeshUpdate()在打印长文本时可能产生性能开销。在实际项目中可以优化为累积几个字符后再更新一次或者在yield return null时由Unity在帧末自动更新但可能造成样式更新延迟。这是一个典型的性能与效果平滑度的权衡。3.4 添加音效与字符回调为了增强表现力我们经常需要在打印每个字符时播放一个打字音效或者在特定字符位置如标点处增加额外延迟。[Header(音效与回调)] public AudioClip typeSound; public AudioSource audioSource; // 如果不指定会尝试从自身或父物体获取 public float punctuationPauseFactor 3f; // 遇到标点符号时延迟时间乘以此因子 private void PlayTypeSound() { if (typeSound ! null) { if (audioSource null) audioSource GetComponentAudioSource() ?? gameObject.AddComponentAudioSource(); audioSource.PlayOneShot(typeSound); } } // 在 TypewriterCoreAdvanced 协程中打印可见字符的部分加入 // ... 打印可见字符的逻辑开始 displayedText.Append(currentChar); m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); // 播放音效 PlayTypeSound(); // 判断是否为需要额外停顿的标点 float currentDelay delayPerCharacter; if (IsPunctuation(currentChar)) { currentDelay * punctuationPauseFactor; } onCharacterPrinted?.Invoke(); if (currentDelay 0) yield return new WaitForSeconds(currentDelay); else yield return null; // ... 打印可见字符的逻辑结束 private bool IsPunctuation(char c) { // 简单的标点判断可根据需要扩展 return c , || c . || c ! || c ? || c ; || c :; }4. 性能优化与高级技巧基础功能实现后我们需要关注性能和灵活性。直接每字符更新Mesh在移动端或处理大量文本时可能成为瓶颈。4.1 性能优化减少Mesh更新频繁调用ForceMeshUpdate()和直接赋值text属性是性能消耗的主要来源。优化策略是批量更新。private IEnumerator TypewriterCoreOptimized() { // ... 初始化部分同上 ... StringBuilder displayedText new StringBuilder(); string fullText m_OriginalText; int readIndex 0; bool insideTag false; StringBuilder tagBuffer new StringBuilder(); // 新增批量更新相关变量 int charactersSinceLastUpdate 0; const int BATCH_UPDATE_COUNT 5; // 每积累5个可见字符更新一次Mesh while (readIndex fullText.Length) { // ... 标签和字符的处理逻辑同 TypewriterCoreAdvanced ... // 在追加普通可见字符后 displayedText.Append(currentChar); charactersSinceLastUpdate; // 批量更新条件积累了一定数量的字符或者遇到了必须立即更新的标签如样式变化大的标签 bool isCriticalTag fullTag.StartsWith(color) || fullTag.StartsWith(size) || fullTag.StartsWith(b) || fullTag.StartsWith(i); if (charactersSinceLastUpdate BATCH_UPDATE_COUNT || isCriticalTag) { m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); charactersSinceLastUpdate 0; } // 注意如果不满足条件文本内容已更新在StringBuilder中但TMP组件还未渲染。 // 为了确保事件触发时文本是最新的我们仍然更新但可以跳过ForceMeshUpdate。 // 更精细的做法是区分“文本内容”和“渲染状态”。 // ... 播放音效、等待 ... } // 循环结束后确保最终文本被渲染 if (charactersSinceLastUpdate 0) { m_TextComponent.text displayedText.ToString(); m_TextComponent.ForceMeshUpdate(); } // ... 完成逻辑 ... }此外如果文本极其长可以考虑使用TMP_Text.text的StringBuilder重载版本如果可用或者使用ObjectPool回收字符串构建过程中产生的垃圾但这些属于更极致的优化。4.2 支持跳过与加速玩家通常没有耐心等待长文本慢慢打印。我们需要提供跳过立即完成和加速功能。public void SkipToEnd() { if (!m_IsPrinting) return; StopPrint(true); // 调用之前的StopPrint方法并传入true以显示全文 } public void SetPrintSpeedMultiplier(float multiplier) { charactersPerSecond * multiplier; // 注意这会影响到正在运行的协程中使用的delayPerCharacter变量。 // 更严谨的做法是在协程内每帧读取一个可变的speedFactor而不是在开始时缓存delay。 }更优雅的加速实现是在协程内部使用一个可变的速率因子private float m_SpeedMultiplier 1.0f; public float SpeedMultiplier { get m_SpeedMultiplier; set m_SpeedMultiplier Mathf.Max(0.1f, value); // 设置最小值防止除零 } // 在协程的等待部分 float effectiveDelay delayPerCharacter / m_SpeedMultiplier; if (effectiveDelay 0) yield return new WaitForSeconds(effectiveDelay); else yield return null;4.3 处理特殊标签与动画TMP支持一些特殊标签如sprite精灵图和anim简单动画。对于sprite它被视为一个“字符”存在于characterInfo中。我们的基础maxVisibleCharacters方案和进阶的字符扫描方案都能很好地处理它它会作为一个整体被显示或隐藏。对于anim标签它通常依赖于时间的推移。在逐字打印的上下文中如果动画标签内的字符还未完全显示动画可能不会播放或播放异常。一个稳妥的做法是在打印到包含动画的文本段时暂时禁用或重置动画待该部分完全显示后再启用。这需要对TMP的动画标签有更深入的理解和定制处理。5. 实战问题排查与心得在实际项目集成中你肯定会遇到一些预料之外的情况。这里记录几个我踩过的坑和解决方案。5.1 问题一文本闪烁或布局跳动现象在打印过程中尤其是字体大小变化或样式切换时文本整体位置会发生轻微跳动或闪烁。原因每次ForceMeshUpdate()都会导致TMP重新计算文本的几何形状和布局。如果前后两次更新的布局结果有细微差异由于字体纹理生成、空格宽度计算等就会造成视觉上的跳动。解决方案确保字体资产设置正确在TMP Font Asset Creator中导入字体时确保“Sampling Point Size”与你在项目中实际使用的大小相匹配并生成足够的字体图集尺寸避免运行时动态缩放。使用TMP_Text.autoSizeTextContainer如果文本区域是动态大小的在打印开始前将其设置为false打印完成后再设为true或者直接使用固定大小的RectTransform。布局组件干扰检查父物体是否有ContentSizeFitter、LayoutGroup等组件。在打印期间可以考虑暂时禁用它们或使用Canvas.ForceUpdateCanvases()在合适时机强制更新布局。5.2 问题二与UI动画系统的冲突现象打印组件所在的UI元素同时在进行缩放、淡入等Dotween或Unity动画导致打印位置不准或效果混乱。原因UI动画可能修改了Transform或CanvasGroup的属性与TMP每帧的Mesh更新产生竞争。解决方案错开更新时机确保打印协程的yield return null即每帧更新与UI动画的关键帧更新不在同一时间点。可以考虑将打印协程的等待改为yield return new WaitForEndOfFrame()在所有动画和布局计算完成后才更新文本。优先级控制设计一个简单的更新管理器确保文本内容更新在UI视觉更新之后。5.3 问题三大量文本打印时的卡顿现象打印非常长的日志或对话时游戏帧率明显下降。原因每字符或每批字符都调用ForceMeshUpdate()和重新构建MeshCPU开销大。解决方案增大批量更新阈值将上述优化中的BATCH_UPDATE_COUNT从5提高到10或15。分帧处理与其每打印N个字符等待一段时间不如每帧固定打印M个字符。这可以通过在协程中使用for循环配合yield return null来实现能更好地利用CPU时间片避免单帧过载。int charsPerFrame 2; // 每帧打印2个字符 while (currentIndex totalLength) { for (int i 0; i charsPerFrame currentIndex totalLength; i) { // ... 处理一个字符的逻辑 ... currentIndex; } yield return null; // 下一帧继续 }对象池与预处理对于需要反复打印的文本如重复的任务提示可以预先将其解析成中间格式如字符和标签的序列打印时直接遍历该序列避免每次都对原始字符串进行解析和状态判断。5.4 一个实用的调试技巧在开发过程中为了看清打印指针到底在哪我经常添加一个临时的调试方法在OnValidate或一个调试按钮中将maxVisibleCharacters设置为一个特定值然后高亮当前应打印的字符例如通过修改其顶点颜色。这能帮你快速确认标签解析和字符推进逻辑是否正确。private void OnValidate() { if (!Application.isPlaying) return; if (m_TextComponent ! null) { // 假设你想查看打印到第50个可见字符时的状态 m_TextComponent.maxVisibleCharacters 50; m_TextComponent.ForceMeshUpdate(); // 可以在这里添加代码将第50个字符的颜色改为红色以便观察 } }实现一个鲁棒的TMP富文本打印器远不止一个while循环加yield return那么简单。它涉及到对TMP内部工作机制的理解、字符串处理的精细操作、协程的生命周期管理以及性能的平衡。从最基础的maxVisibleCharacters方案到能够正确处理所有富文本标签的字符扫描状态机每一步的进化都是为了解决实际项目中遇到的具体问题。最重要的是根据你的项目需求是移动端轻量级视觉小说还是PC端大量日志显示选择合适的实现策略和优化程度。把这个组件打磨好它将成为你UI工具箱里一个非常得力的助手让游戏的文字表达充满生命力。
)
