1. 项目概述与核心价值最近在做一个社交类的小项目需要实现一个类似微信WX风格的聊天界面。这听起来简单但真动手做起来才发现里面门道不少。不是简单摆几个文本框和头像就完事了你得考虑消息气泡的自适应、不同屏幕分辨率的适配、滑动列表的性能还有那个“对方正在输入…”的优雅动画。网上找了一圈要么是过于简单的Demo功能不全要么是商业插件代码封装得太深想改点东西都无从下手。所以我决定自己从头撸一个把踩过的坑和总结的经验都记录下来最终形成了一个功能完整、代码清晰、可直接复用的解决方案。这个项目完全基于Unity原生的UGUI系统用C#脚本驱动。它的核心价值在于“实战”二字。我不会只给你看最终效果而是会带你一步步拆解每个模块的实现逻辑从界面布局、自适应原理到消息数据管理、滚动列表优化最后还会分享如何实现那些提升体验的细节功能比如时间戳、消息状态提示和图片消息的加载。无论你是Unity初学者想通过一个完整项目练手还是有一定经验的开发者需要快速搭建一个稳定高效的聊天模块这篇文章都能给你提供直接的参考。文末会提供完整的项目源码你可以直接导入Unity工程使用或在此基础上进行二次开发。2. 界面布局与自适应设计解析2.1 WX风格聊天界面的视觉要素拆解在动手写代码之前我们先仔细观察一下目标——微信的聊天界面。它之所以看起来舒服是因为在视觉和交互上做了大量精细的设计。首先整个界面可以垂直分为三大块顶部的导航栏显示聊天对象和功能按钮、中部的聊天内容区域一个可滑动的列表、底部的输入框区域包含文本框、表情和发送按钮。我们的核心战场是中间的内容区域。内容区域里的每条消息都是一个独立的“单元”。这个单元通常包含发送者头像左或右对齐、消息气泡背景、消息文本或图片/语音等、消息发送时间可选、消息状态指示器如发送中、已送达、已读仅自己发送的消息显示。消息气泡需要根据文本内容自动调整高度和宽度但宽度有最大值避免在宽屏上出现一条横跨整个屏幕的瘦长气泡影响阅读。头像和气泡的间距、气泡的内边距、不同消息之间的垂直间距这些细微的尺寸参数共同决定了界面的“呼吸感”。2.2 使用UGUI Canvas与锚点实现全局自适应在Unity中实现自适应的基石是Canvas和RectTransform的锚点系统。我们的第一步是正确设置Canvas。我推荐使用“Scale With Screen Size”的UI缩放模式并设定一个参考分辨率例如1920x1080。这意味着我们在1080p的基准下设计界面在其他分辨率下UI元素会按比例缩放。关键在于对每个UI元素RectTransform的锚点Anchors和轴心Pivot的理解。对于聊天内容区域的Scroll View它的锚点应该设置为撑满父物体Stretch这样无论屏幕宽高比如何变化它都能始终占据导航栏和输入框之间的空间。对于消息条目这个预制体Prefab它的设计要更精细一些。消息条目预制体本身是一个水平布局组Horizontal Layout Group里面包含两个主要子物体头像Image和消息气泡父物体。气泡父物体内部又包含背景Image和显示文本的TextMeshPro - Text组件。这里的关键技巧在于头像锚点设为左侧垂直居中固定宽度和高度。这样它的水平位置固定垂直方向与气泡中心对齐。气泡父物体锚点设为左侧用于对方消息或右侧用于己方消息并靠上对齐。它的宽度不固定由子内容决定。气泡背景Image锚点设置为撑满气泡父物体Stretch这样背景图会随着气泡大小而拉伸。为了适配不同长度的文本我们需要使用九宫格Sliced类型的Sprite确保拉伸时边角不变形。文本TextMeshPro锚点设为靠左上对齐并开启“自动换行”。我们需要在脚本中动态计算文本渲染后的宽高并据此调整气泡父物体的大小。注意不要使用Unity旧版的UI Text强烈推荐TextMeshProTMP。TMP在字体渲染、自动换行、富文本支持以及性能上都有巨大优势是现在的行业标准。2.3 消息气泡宽高的动态计算逻辑这是自适应功能的核心。我们不能简单地给文本区域一个固定的宽度然后期望高度自动变化。因为当文本很少时气泡宽度应该收缩以适应内容当文本很长时气泡宽度应达到最大值后开始折行高度随之增加。具体实现步骤如下获取文本首选尺寸TMP组件有一个GetPreferredValues方法。我们可以传入文本字符串和一个最大宽度值。调用GetPreferredValues(text, maxWidth, 0)它会返回一个Vector2其中x是文本在不超过maxWidth前提下渲染后的最佳宽度y是所需的高度。计算气泡最终尺寸文本的宽高并不是气泡的最终宽高。我们需要加上气泡的内边距Padding。例如如果希望文本距离气泡左右各10像素上下各8像素那么气泡宽度 文本宽度 左Padding 右Padding气泡高度 文本高度 上Padding 下Padding应用尺寸并刷新布局将计算出的宽度与预设的最大气泡宽度取最小值然后赋值给气泡父物体的rectTransform.sizeDelta。接着必须立即调用LayoutRebuilder.ForceRebuildLayoutImmediate来强制刷新该消息条目以及其父布局组如果有的话确保所有元素的位置能根据新尺寸立即更新。处理己方与对方消息的镜像通过切换消息条目预制体中水平布局组的“Child Alignment”属性或者动态调整头像和气泡的顺序可以实现消息在左在右的布局切换。通常我们可以制作两个预制体变体或者在实例化时通过代码调整子物体顺序。// 代码片段动态调整消息气泡大小 public void SetMessage(string content, bool isMine, float maxBubbleWidth) { // ... 设置文本、头像方向等 ... // 计算文本理想尺寸传入最大文本宽度最大气泡宽度减去左右边距 float maxTextWidth maxBubbleWidth - paddingLeft - paddingRight; Vector2 preferredSize textMeshPro.GetPreferredValues(content, maxTextWidth, 0); // 计算气泡尺寸 float bubbleWidth Mathf.Min(preferredSize.x paddingLeft paddingRight, maxBubbleWidth); float bubbleHeight preferredSize.y paddingTop paddingBottom; // 应用尺寸到气泡RectTransform bubbleRectTransform.sizeDelta new Vector2(bubbleWidth, bubbleHeight); // 强制立即重建布局 LayoutRebuilder.ForceRebuildLayoutImmediate(bubbleRectTransform); LayoutRebuilder.ForceRebuildLayoutImmediate((RectTransform)transform); }3. 核心功能模块实现详解3.1 聊天数据管理与消息模型设计界面是骨架数据才是灵魂。一个清晰的模型设计能让后续的逻辑处理变得简单。我定义了一个ChatMessage类来代表单条消息。[System.Serializable] public class ChatMessage { public string MessageId; // 消息唯一ID public string SenderId; // 发送者ID public string SenderName; // 发送者昵称 public string Content; // 文本内容如果是图片/语音这里可以是URL或资源路径 public MessageType Type; // 枚举Text, Image, Audio, System public long Timestamp; // 时间戳毫秒或秒 public MessageStatus Status; // 枚举Sending, Sent, Delivered, Read public bool IsMine; // 是否为自己发送的消息 }为什么需要MessageId和Timestamp这是为了消息的排序、去重和状态更新。网络传输可能有延迟或重发通过ID可以精确更新某条消息的状态比如从“发送中”变为“已送达”。时间戳用于按时间顺序排列消息。管理所有消息的类我称之为ChatManager或MessageManager。它内部维护一个ListChatMessage。它的核心职责包括添加新消息将消息添加到列表并通知界面更新。消息排序确保列表始终按时间戳升序排列。消息状态更新根据网络回调查找特定ID的消息并更新其状态触发界面刷新。数据持久化可以将消息列表序列化成JSON保存到本地下次启动时加载实现聊天记录查看。3.2 基于ScrollRect与ObjectPool的高性能滚动列表聊天记录可能很长如果同时生成几百上千条消息的GameObject对性能将是灾难。解决方案是使用循环滚动列表即只创建可视区域内及缓冲区内的少量消息条目随着滚动动态复用它们。Unity的ScrollRect配合Content Size Fitter和Vertical Layout Group可以处理垂直布局但实现动态复用需要自己写逻辑或者使用更成熟的方案。在这个项目中我采用了相对直接但高效的ObjectPool对象池与动态计算位置相结合的方法没有引入额外的插件以便大家理解原理。实现思路对象池创建一个消息条目预制体的对象池。当需要显示新消息时从池中取出一个实例化好的条目或实例化新的设置数据后放入ScrollRect的Content下。当消息滚动出视野时不是销毁它而是将其放回池中并重置其状态。动态布局计算Content一个垂直布局组的高度需要等于所有消息条目的总高度加上间距。每当我们添加或移除一条消息都需要重新计算Content的高度并调整所有消息条目的位置。这可以通过LayoutRebuilder自动完成但为了更精细的控制和性能我们可以在ChatManager中维护一个当前内容总高度的变量手动添加新消息的高度。视口裁剪与复用这是性能优化的关键。我们需要监听ScrollRect的onValueChanged事件。在滚动时计算出当前视口Viewport在Content局部坐标系中的Y轴范围。然后遍历所有活跃的消息条目判断其位置是否在这个范围内。如果条目完全在视口上方或下方说明它不可见可以将其回收到对象池并从Content中移除。同时根据当前滚动位置和消息数据列表计算出哪些数据应该被显示然后为这些数据从对象池中获取条目设置数据并放置到Content的正确位置上。这个方法比完整的循环列表实现起来简单对于几百条聊天记录的场景性能已经足够好。如果消息量极大上万条则需要实现更复杂的“按需渲染”逻辑精确计算每个条目的位置并只更新视口内的条目。3.3 时间戳显示与消息状态提示时间戳我们不可能在每条消息下面都显示完整时间。微信的做法是仅在消息间隔较长比如超过5分钟或者每天第一条消息时显示一个时间戳条目。我们可以写一个工具方法在添加新消息时判断它与上一条消息的时间差。如果超过阈值就在消息列表中插入一个特殊的“时间戳消息”MessageType.System这个条目使用不同的预制体只显示格式化后的时间字符串如“下午2:30”、“昨天”、“2023年10月1日”。消息状态对于自己发送的消息通常会在气泡旁边或下方显示一个小图标表示发送状态。这可以通过在消息条目预制体上添加一个状态图标Image组件来实现并根据ChatMessage.Status来切换其Sprite和颜色。Sending显示一个旋转的加载圆圈或“时钟”图标。Sent显示一个灰色的对勾。Delivered显示两个灰色的对勾。Read显示两个蓝色的对勾需要对方已读回执支持。状态更新由ChatManager驱动。当网络层确认消息已发送、已送达或已读时调用ChatManager.UpdateMessageStatus(messageId, newStatus)该方法会更新数据模型并找到对应的UI条目如果它正在显示更新其状态图标。4. 交互细节与扩展功能实现4.1 输入框与消息发送逻辑底部的输入区域通常包含一个TMP InputField一个表情按钮和一个发送按钮。发送逻辑需要注意内容判空发送前Trim掉空格判断是否为空字符串。消息构造创建一个新的ChatMessage对象IsMine设为trueStatus设为MessageStatus.SendingTimestamp设为当前时间。立即显示调用ChatManager.AddMessage将这条消息添加到列表并显示出来。这提供了“即时反馈”即使网络有延迟用户也能立刻看到自己发的消息。异步发送将消息内容提交给网络管理器进行实际发送。这里要用到异步编程async/await或回调。更新状态网络发送成功或失败后通过ChatManager更新该消息的状态。如果失败可以将状态改为一个特殊的失败状态并允许用户点击重发。// 代码片段发送消息 public void OnSendButtonClicked() { string rawText inputField.text.Trim(); if (string.IsNullOrEmpty(rawText)) return; // 1. 构建本地消息 ChatMessage newMsg new ChatMessage { MessageId GenerateMessageId(), SenderId localUserId, Content rawText, Type MessageType.Text, Timestamp GetCurrentTimestamp(), Status MessageStatus.Sending, IsMine true }; // 2. 清空输入框 inputField.text ; // 3. 立即添加到UI chatManager.AddMessage(newMsg); // 4. 异步网络发送 _ SendMessageToServerAsync(newMsg); } private async Task SendMessageToServerAsync(ChatMessage msg) { bool success await networkService.SendTextMessage(msg.Content); if (success) { chatManager.UpdateMessageStatus(msg.MessageId, MessageStatus.Sent); // 可以进一步等待送达回执和已读回执... } else { chatManager.UpdateMessageStatus(msg.MessageId, MessageStatus.Failed); } }4.2 图片消息的发送与显示图片消息比文本复杂因为它涉及文件选择或拍照、上传、下载、显示和缓存。选择与预览通过Unity的NativeGallery插件移动端或简单的文件对话框编辑器/PC端选择图片文件。选择后可以在本地生成一个缩略图并立即在聊天区域显示一个“本地预览”状态的消息气泡里面显示缩略图和“发送中”的进度条。上传将图片文件转换为字节流上传到你的服务器或云存储。上传成功后服务器会返回一个图片的URL。更新消息用这个URL替换掉消息内容中的临时本地路径并将消息状态更新为已发送。同时将图片URL和本地缓存路径关联起来。显示在消息条目中使用UnityWebRequest或UnityWebRequestTexture从URL下载图片或者从本地缓存中加载。下载完成后将Texture2D赋值给气泡内的一个RawImage组件。这里同样需要做自适应限制图片显示的最大宽高并按比例缩放。实操心得图片缓存策略。频繁下载同一张图片是性能杀手。一定要实现一个简单的图片缓存机制。可以用Dictionarystring, Texture2D在内存中缓存已加载的纹理键可以是图片URL的MD5值。同时可以将下载的纹理以文件形式保存到Application.persistentDataPath下的某个目录下次启动时优先从本地加载。记得要处理缓存清理避免占用过多磁盘空间。4.3 滚动至底部与新消息提示聊天界面有两个基本交互要求当用户发送消息或收到新消息时列表应自动滚动到底部以显示最新消息但如果用户正在向上翻阅历史记录则不应突然跳到底部而应该给出一个“新消息”提示。实现方案自动滚动判断在ScrollRect的Content上我们可以计算一个“滚动归一化位置”。0表示顶部1表示底部。我们维护一个变量isUserDragging在ScrollRect的OnBeginDrag和OnEndDrag事件中更新它。当isUserDragging为false且滚动位置非常接近底部比如 0.99时我们认为用户“期望停留在底部”此时有新消息就调用ScrollRect.verticalNormalizedPosition 0来滚动到底部。新消息提示如果isUserDragging为true或者滚动位置不在底部当新消息到来时我们不自动滚动而是在列表底部上方显示一个浮动按钮或提示条例如“3条新消息”。点击这个提示再平滑滚动到底部。平滑滚动直接设置verticalNormalizedPosition会显得生硬。可以使用协程Coroutine配合Mathf.Lerp在一段时间内平滑地过渡到目标位置体验更佳。// 代码片段带条件判断的滚动到底部 public void TryScrollToBottom(bool force false) { if (!scrollRect) return; // 如果强制滚动或者用户没有在主动拖动且已经很接近底部了 if (force || (!isUserDragging scrollRect.verticalNormalizedPosition 0.01f)) { StartCoroutine(SmoothScrollToBottom()); } else { // 显示“新消息”提示 newMessageAlert.Show(unreadCount); } } IEnumerator SmoothScrollToBottom(float duration 0.3f) { float startPos scrollRect.verticalNormalizedPosition; float time 0; while (time duration) { time Time.deltaTime; scrollRect.verticalNormalizedPosition Mathf.Lerp(startPos, 0, time / duration); yield return null; } scrollRect.verticalNormalizedPosition 0; }5. 性能优化与常见问题排查5.1 UGUI合批Batching原理与优化实践UGUI的合批是影响UI性能的关键。合批是指将多个使用相同材质Material和纹理Texture的UI元素合并成一个Draw Call绘制调用提交给GPU从而大幅提升渲染效率。影响合批的因素材质与纹理这是最重要的因素。所有头像图片如果用的是同一张图集Atlas那么它们可以被合批。但如果每条消息气泡的背景图都是独立的Sprite且没有打包进图集那么每个气泡都会产生一个独立的Draw Call。渲染顺序UGUI按照Hierarchy中的顺序从上到下渲染。如果两个使用相同材质的UI中间插入了一个使用不同材质的UI合批就会被打断。针对聊天界面的优化策略使用图集将聊天界面所有常用的小图标头像框、状态图标、按钮图标以及气泡背景打包到一张或少数几张图集中。这是最重要的优化手段。可以使用Unity自带的Sprite Atlas功能。统一字体材质确保所有TMP文本组件只要字体和字重相同就尽量使用相同的Font Asset这样文本渲染也能被合批。规划Hierarchy顺序在实例化消息条目时尽量保证相同类型的条目如都是己方文本消息在Content下连续排列。避免己方消息和对方消息可能使用不同的气泡背景纹理交错排列如果无法避免可以考虑通过动态更换材质实例MaterialPropertyBlock来保持合批但这属于高级优化。避免频繁SetActive对象池的另一个好处就是避免了GameObject的频繁实例化与销毁也减少了因Active状态变化可能引起的Canvas重建。5.2 消息过多时的卡顿分析与解决即使使用了对象池当消息数据列表非常大比如上万条时单纯的数据管理和查找也可能成为瓶颈尤其是在频繁滚动、需要计算哪些数据应该显示的时候。解决方案数据分页加载不要一次性加载所有历史消息。首次只加载最近的50或100条。当用户滚动到顶部时再异步加载更早的50条并插入到列表顶部。这类似于移动App的“上拉加载更多”。使用高效的数据结构用于查找消息的字典Dictionarystring, ChatMessage键值对不宜过多。如果消息ID是顺序生成的可以考虑用ListChatMessage配合二分查找来根据时间戳或ID快速定位。简化UI复杂度对于历史消息可以考虑降低其渲染精度。例如对于远离视口的消息可以将其中的图片替换为一个低分辨率的占位符或者将富文本效果简化。将计算分散到多帧在添加一大批历史消息时不要在同一帧内完成所有条目的尺寸计算和布局重建。可以使用协程每帧处理5-10条消息避免造成主线程卡顿。5.3 常见Bug与调试技巧实录在开发过程中我遇到了不少典型问题这里记录下排查思路问题1消息气泡大小计算不准文本显示不全或留白过多。排查首先检查Padding值是否正确。其次GetPreferredValues方法传入的maxWidth参数是关键。确保这个值是你希望文本区域的最大宽度而不是气泡的最大宽度。另外检查TMP组件的“Margin”设置它也会影响布局。技巧在调试时可以临时给气泡背景加上一个带颜色的轮廓或者通过Debug.Log打印出计算出的preferredSize和最终的bubbleSize与Inspector中实际的RectTransform尺寸进行对比。问题2滚动列表在快速滚动或频繁添加消息时出现抖动、错位。排查这通常是布局重建Layout Rebuild引起的。UGUI的布局重建默认在帧末进行如果在一帧内多次修改尺寸或添加元素可能会引起多次重建或计算冲突。解决使用Canvas.ForceUpdateCanvases()在完成一帧内所有UI修改后手动调用此方法强制立即更新所有Canvas。但这要谨慎使用因为开销较大。使用ContentSizeFitter与LayoutGroup的配合有时ContentSizeFitter的延迟更新会导致问题。可以尝试在代码中直接设置Content的高度而不是完全依赖ContentSizeFitter。确保对象池回收和复用正确在将条目回池前务必重置其位置、缩放和数据避免旧数据影响新位置的计算。问题3在编辑器里运行正常打包到手机后输入框点击没反应或聊天区域不滚动。排查这通常是事件系统EventSystem或射线检测Raycast的问题。解决确保场景中有且仅有一个EventSystem。检查所有需要交互的UI元素如按钮、输入框、滚动区域是否都包含了Graphic Raycaster组件对于Canvas或Image/Mask等有RectTransform的组件它们默认提供射线检测。检查ScrollRect的Movement Type和Inertia设置在移动设备上Elastic弹性类型配合适当的阻尼Damping手感会更好。注意触摸屏的多点触控可能会与ScrollRect的拖动冲突确保没有其他UI元素意外拦截了触摸事件。问题4图片消息加载导致内存持续增长。排查每次下载图片都创建新的Texture2D且没有在适当的时候调用Destroy或UnityWebRequest.Dispose。解决实现纹理缓存如前所述。及时销毁对于不再使用的纹理比如从缓存中移除的一定要调用Destroy(texture)。使用AssetBundle或Addressables管理资源如果是项目内的表情图片使用资源管理系统可以更好地控制加载和卸载。限制图片大小在上传前或下载后对纹理进行缩放避免在UI上显示超高清的原图。UI显示512x512或1024x1024的纹理已经足够清晰。这个聊天界面项目从设计到实现涵盖了UGUI系统应用的多个核心知识点。从最基础的锚点布局到动态尺寸计算再到复杂的数据管理和性能优化每一步都需要仔细思考和测试。最终提供的源码已经整合了上述所有核心功能并附有详细的注释。你可以直接用它作为基础模块也可以根据自己项目的具体需求对UI风格、交互细节或网络层进行定制。记住好的UI体验藏在每一个像素和每一次响应的细节里。
