简介面向Unity开发者的实用功能包聚焦Scroll View内长列表连续截图并合成为一张完整长图保存到本地的实现方案。资源针对UI导出、长图生成、内容分享等常见需求适合有一定UGUI基础、需要处理滚动内容导出的中高级开发者。包体共包含2000个文件以946个md说明文档为主配合527个bin资源文件、155个txt文本、99个json配置、34个asset场景资源等rar压缩包整体716.55MB结构覆盖原理讲解、脚本实现与工程配套文件md文档详细记录了滚动画布、截帧协程、图像拼接的关键步骤bin与asset文件则提供了可直接参考的工程素材。已有162人学习下载。内容从Content位置控制与每帧屏幕捕捉入手详细说明Texture2D图像拼接及边缘对齐处理并延伸到PDF导出思路与运行时性能优化策略整体思路可复用至商城截图、聊天记录保存、整页报表生成等实际场景帮助开发者快速落地可靠的长图导出功能。1. 滚动列表长图与其说截图不如说是在“重演”滚动过程策划丢过来一个需求“把左边这个排行榜的完整列表导成一张长图我要拿去评审 UI 和配色。”我扫一眼就明白这跟用浏览器插件截长网页本质上是同一件事但在 Unity 里没有现成的“整页截图”按钮。Scroll View 本身只渲染可视区域截屏只能拿到一屏的画面。想拿到滚动列表里的全部内容就得让列表自己“滚一遍”滚动过程中一帧一帧地抓取视口画面最后按位置拼成一张长图。这个方案对 Unity 中 Scroll View 下连续截图、保存本地、生成长图的需求都成立适合要批量导出 UI 验收图、制作素材预览、或者做自动化测试的开发者和 TA。2. 为什么不能直接拍一张RenderTexture、Mask裁剪与UI重建2.1 uGUI截图绕不开的三道坎第一次接触“截长图”的人最先想到的办法往往是把 content 的尺寸临时改成全量高度然后一次性截图。这个做法在 Scroll View 上直接翻车uGUI 的 Mask 组件会把视口之外的网格裁掉你放大 content 只是让所有内容在逻辑上可见渲染时依然只画视口内那一小块。截图出来的内容还是原样既不是长图还会把布局和滚动条状态搞得一团糟。第二条路是直接给 content 挂一个大尺寸 RenderTexture指望它自己把全部内容画进去。这里有个隐藏问题Scroll View 的 RectTransform 尺寸是视口大小不管你怎么改Mask 的 stencil buffer 只放行视口矩形内的像素。超出部分压根不会进入渲染管线自然也不会出现在纹理里。所以路径只剩一条把滚动过程拆成若干帧每一帧截一个“当前可视视口”然后用代码把这些竖条拼接起来。这里涉及三个绕不开的关键点滚动怎么步进、截屏时机怎么等、拼接基准怎么对齐。滚动步进决定长图的行分辨率截屏时机决定画面是否完整更新拼接基准决定最终长图有没有黑带或重叠。2.2 先定方案再写码滚动步进、等待帧与拼接基准我一般先画一个流程草稿把 Scroll View 拉到最顶部截图作为第一块然后向下滚动一个“像素步长”等待画面稳定后再截第二块如此循环直到滚到底部。最后把所有截图按“它在 content 里的 y 坐标”依次贴到一个新建的 Texture2D 上。听起来并不复杂但落地时有一堆细节。滚动步进上最稳妥的基准不是“每次滚动 1%”而是“每个 Item 的高度”。比如排行榜每个条目高 100 像素那步长就取 100。这样相邻两张截图刚好差一整行或多半行拼接时条目的上下沿不容易被切断。如果 Item 高度不固定就先算所有子节点在 content 内的累计高度差再取每次滚动的目标 y 值来驱动位置。等待帧数上时序是关键。uGUI 的网格重建、Canvas 的顶点更新、GPU 的渲染都是异步的如果你在滚动位置改完的同一帧立刻做 ReadPixels拿到的很可能是上一帧的画面。所以我习惯在改完滚动位置后至少等两次 EndOfFrame再执行截图。这个等待帧数不是玄学是踩过坑之后的经验值。拼接基准上不能用 ScrollRect.verticalNormalizedPosition 的小数直接做拼接。这个值是浮点数叠加上 content 高度有小数位时会出现一个像素的累计误差滚动几十次之后画面就斜了。我一般自己维护一个“累计滚动像素量”每次用 ScrollRect.content 的 rect 高度、viewport 高度和归一化位置反算出当前视口顶部的 y 坐标用它决定下一块拼图的落点。// 当前视口顶部在 content 坐标系里的像素位置 // normalizedPosition 0 时在最底部, 1 时在最顶部 float viewportTop contentRect.rect.height - viewportHeight scrollRect.verticalNormalizedPosition * (contentRect.rect.height - viewportHeight);这句代码是后面所有拼接工作的坐标原点。长图最终长什么样就是把这些顶部位置按顺序排列出来。如果你能在动手写代码之前把这三件事想清楚下面写代码就只是体力活。3. 用协程把滚动过程拆成单帧核心代码与三个必调参数3.1 最小截图脚本滚动、等帧、抓屏、存帧我通常先用协程把“滚一格、等一帧、抓一屏”做出来跑通后再接拼接和保存。这段代码是先决基础也最容易出错建议直接复制到一个空场景里验证。using System.Collections; using System.IO; using UnityEngine; using UnityEngine.UI; public class ScrollViewLongScreenshot : MonoBehaviour { [Header(拖入要截图的 ScrollRect)] public ScrollRect scrollRect; [Tooltip(每次滚动的像素步长建议等于单个 Item 的高度)] public float stepPixels 100f; [Tooltip(滚动后等待的渲染帧数建议 2~5 帧)] public int waitFrames 3; [Tooltip(是否把单帧截图存到本地方便排查拼接错位)] public bool saveDebugFrames true; private RectTransform contentRect; private RectTransform viewportRect; void Start() { contentRect scrollRect.content; viewportRect scrollRect.viewport ! null ? scrollRect.viewport : contentRect.parent as RectTransform; StartCoroutine(CaptureRoutine()); } IEnumerator CaptureRoutine() { // 先停掉惯性否则滚动位置会有额外偏移 scrollRect.inertia false; // 拿到视口在屏幕上的实际像素尺寸 Vector2 viewportPixels GetViewportPixelSize(); // 创建与视口像素等大的 RenderTexture RenderTexture rt new RenderTexture( (int)viewportPixels.x, (int)viewportPixels.y, 24, RenderTextureFormat.ARGB32); Texture2D frameTex new Texture2D(rt.width, rt.height, TextureFormat.RGBA32, false); float prevPos scrollRect.verticalNormalizedPosition; // 记录起点 // 从顶部开始, 先截第一帧 yield return new WaitForEndOfFrame(); CaptureFrame(rt, frameTex); if (saveDebugFrames) SaveFrame(frameTex, 0); // 计算可滚动像素总量 float scrollablePixels contentRect.rect.height - viewportRect.rect.height; int index 1; while (index * stepPixels scrollablePixels stepPixels) { float targetNormalized 1f - (index * stepPixels) / scrollablePixels; targetNormalized Mathf.Clamp01(targetNormalized); scrollRect.verticalNormalizedPosition targetNormalized; // 等渲染稳定再截 for (int i 0; i waitFrames; i) yield return new WaitForEndOfFrame(); CaptureFrame(rt, frameTex); if (saveDebugFrames) SaveFrame(frameTex, index); index; } // 最后补一帧最底部 scrollRect.verticalNormalizedPosition 0f; for (int i 0; i waitFrames; i) yield return new WaitForEndOfFrame(); CaptureFrame(rt, frameTex); if (saveDebugFrames) SaveFrame(frameTex, index); rt.Release(); Destroy(rt); } void CaptureFrame(RenderTexture rt, Texture2D tex) { RenderTexture.active rt; tex.ReadPixels(new Rect(0, 0, rt.width, rt.height), 0, 0); tex.Apply(); RenderTexture.active null; } void SaveFrame(Texture2D tex, int index) { byte[] bytes tex.EncodeToPNG(); string dir Application.dataPath /../Screenshots/debug_frames; if (!Directory.Exists(dir)) Directory.CreateDirectory(dir); File.WriteAllBytes(dir $/frame_{index:000}.png, bytes); } Vector2 GetViewportPixelSize() { Camera cam null; Canvas canvas GetComponentInParentCanvas(); // 非 Overlay 模式需要拿到渲染相机才能换算屏幕坐标 if (canvas ! null canvas.renderMode ! RenderMode.ScreenSpaceOverlay) cam canvas.worldCamera; Vector3[] corners new Vector3[4]; viewportRect.GetWorldCorners(corners); Vector2 min RectTransformUtility.WorldToScreenPoint(cam, corners[0]); Vector2 max RectTransformUtility.WorldToScreenPoint(cam, corners[2]); return max - min; } }这段代码做了四件事停掉 inertia 保证滚动步进可控把视口实际屏幕像素算出来作为 RenderTexture 的尺寸用 WaitForEndOfFrame 等 UI 渲染落盘后再抓屏把单帧存成 PNG 方便定位问题。GetViewportPixelSize 是很多粗暴实现的盲区它把 ScrollRect.viewport 的四个世界角点转成屏幕坐标解决了 CanvasScaler 缩放后逻辑尺寸和物理像素不一致的问题。如果不做这一步你新建的 RenderTexture 尺寸可能只有屏幕的一半或两倍拼出来的长图要么发虚要么有黑边。3.2 拼接主逻辑与保存本地从Debug单帧到最终PNG调试帧能存出来之后事情就完成了一半。现在要把这些内存里的 Texture2D 直接拼到最终长图上不需要走一遍磁盘再读回来。拼接的核心是维护一个“当前已写入的像素高度 offset”每拿一帧就往这个大纹理里 Blit 一行。Texture2D BuildLongImage(int totalHeightPixels, Texture2D[] frames) { // totalHeightPixels 是 content 总高度换算成物理像素后的值 // 注意移动端大纹理的上限问题, 超过限制要分两段处理 Texture2D longTex new Texture2D(frames[0].width, totalHeightPixels, TextureFormat.RGBA32, false); Color[] buffer new Color[frames[0].width * frames[0].height]; int offsetY 0; for (int i 0; i frames.Length; i) { // 从帧纹理里读出像素 Color[] pixels frames[i].GetPixels(0, 0, frames[i].width, frames[i].height); // 只有首尾两帧可能需要截半行, 中间帧直接整块粘贴 // 当帧高度超过剩余拼接空间时, 只粘贴需要的高度区域 int needHeight Mathf.Min(frames[i].height, totalHeightPixels - offsetY); int frameOffsetY frames[i].height - needHeight; // 顶部对齐 for (int y 0; y needHeight; y) { int srcStart (frameOffsetY y) * frames[i].width; int dstStart (offsetY y) * longTex.width; System.Array.Copy(pixels, srcStart, buffer, dstStart, frames[i].width); } offsetY needHeight; } longTex.SetPixels(buffer); longTex.Apply(); return longTex; }这里有个细节循环里最后补的那一帧像素高度可能超出 totalHeightPixels 的剩余部分。如果直接整帧粘贴纹理目标越界会直接抛异常。所以代码里用 needHeight 截断了尾部同时假设帧内容是从顶部对齐的。正常情况下滚动步长等于 Item 高度且总高度能被整除时这个裁剪不会生效但写上了能让脚本对各种高度都健壮。最终保存的代码很简单byte[] bytes BuildLongImage(totalHeightPixels, frames).EncodeToPNG(); string dir Application.dataPath /../Screenshots/result; if (!Directory.Exists(dir)) Directory.CreateDirectory(dir); File.WriteAllBytes(dir /long_image_ System.DateTime.Now.ToString(HHmmss) .png, bytes);保存路径我习惯放在项目根目录的 Screenshots 文件夹而不是 Assets 里。这样截图不会触发 Unity 的资源导入和编译扫描批量跑几十张图也不会卡编辑器。如果你希望图片直接进 Assets可以改成 Application.dataPath /Screenshots/但记得导入后要及时清理避免打入版本库。3.3 三个必调参数滚动步长、等待帧数、最大纹理高度第一个参数是 stepPixels它决定长图的纵向分辨率和拼图次数。步长越小帧数越多拼接越精细但耗时和内存也越大。我一般直接把 Item 的 rect.height 复制进来这样每一帧的交界处恰好压在 Item 边缘肉眼几乎看不出拼缝。如果步长比 Item 高度小就要在 BuildLongImage 里对帧做采样复杂度上一个台阶。第二个参数是 waitFrames。这个值哪怕设成 1在部分机器上也会出现“图片晚一帧”的问题具体表现是拼出来的图里某一段内容是上一帧的残留。我测试下来PC 上 2 帧足够Android 上 3~5 帧才稳。这个帧数本质是在为 CanvasRebuild 和 GPU 异步渲染买单没有统一的公式换设备就要实测。第三个参数不是写在 Inspector 里的而是设备的 Texture2D.maxTextureSize 上限。PC 上你可以拼到 16384 像素高但很多移动 GPU 只支持 4096 或 8192超了之后 ReadPixels 或 SetPixels 会直接报错甚至整张纹理花掉。遇到特别长的列表我的做法是分成两段拼接先拼前一半存成小图再拼后一半最后如果外部工具需要完整长图再用图片处理脚本合。Unity 内存里不要强行维持一张超大纹理移动端很容易黑匣子式崩溃。4. 长图拼接与落盘避坑现象、原因、解决4.1 截出来的全是黑图或旧画面现象单帧 PNG 能生成但打开全是黑的偶尔能看到内容却是上一帧或滚动前的老画面。原因最常见是读取 RenderTexture 的时机不对。ReadPixels 必须发生在 GPU 把画面画进 RT 之后而 WaitForEndOfFrame 只保证渲染命令提交不保证 GPU 已经完成写回。另外有些人复用同一个 RT 却没有在每次 CaptureFrame 前清空导致上一帧残影和黑块叠加。解决先确认截图在 WaitForEndOfFrame 之后执行再把 waitFrames 提到 3 帧以上逐帧观察。如果每次都是固定全黑检查 RenderTextureFormat 是不是 ARGB32有些格式在移动端只写深度不写颜色。若画面是残影需要在 ReadPixels 前调用一次 Graphics.Blit 配合备用 RT 清屏或者在 CaptureFrame 开头执行一次RenderTexture.active null再重新激活。4.2 拼接处出现横向黑带或内容交错现象相邻两张图接缝处有一条横向黑带或者下一张图和上一张图内容重叠了十几像素条目被切了半截。原因滚动步进与 content 实际滚过的像素量不一致。ScrollRect 的 verticalNormalizedPosition 在设置后受布局刷新和 rounding 影响实际偏移量和理论值有几个像素的误差。差值是固定的话拼接时只会在接缝处多一条重复内容差值累计的话长图会越拼越斜。解决改用“内容坐标驱动 实际偏移记录”。每次滚动前记录lastNormalizedPos滚动后立刻读取真实位置算出实际像素差用它更新 offsetY 而不是直接用 stepPixels。这么做多几行代码但能保证每个接缝都能和上一帧对齐因为拼图位置永远基于“已经发生的滚动”而不是“期望发生的滚动”。float currentPos scrollRect.verticalNormalizedPosition; float movedPixels (lastPos - currentPos) * scrollablePixels; offsetY movedPixels; // 用真实滚动距离累计 lastPos currentPos;4.3 手机上报错纹理尺寸超限与ReadPixels黑匣子现象PC 编辑器上一切正常打包到 Android 真机跑十几秒后日志报Failed to create 2D texture或者直接闪退。原因长图纹理的宽或高超过了设备的 maxTextureSize。这个值在老旧机型上是 2048 或 4096高刷屏新机多支持 8192但列表内容动辄五六千像素高longTex 创建时就爆了。更隐蔽的是 RenderTexture 尺寸它的限制和 Texture2D 不完全一致部分驱动对 RT 的宽高比有隐形的 1:16 上限竖向长条 RT 可能先于 Texture2D 崩。解决截图前先查询SystemInfo.maxTextureSize如果总高度超限就把拼接分成两段先拼前半段保存再拼后半段保存最后用外部脚本合并。RT 的宽高比超过 1:8 时宁可每帧截两次也要拆开别在图省事时埋雷。这条经验是翻过车才得出的移动端对纹理尺寸的限制比编辑器严苛得多不要用 Editor 的表现推断真机行为。4.4 动态内容滚动时高度反复横跳拼完图错半行现象带 ContentSizeFitter 的列表或者滚动过程中还有网络图片加载的列表边滚边拼时中途 content.rect.height 变了前几帧和后几帧的拼接错位整张长图像被拉伸过。原因ContentSizeFitter 会根据子物体布局动态调整 content 高度。你在滚动过程中改了位置或等帧布局系统重新计算高度导致 scrollablePixels 不再是初始值坐标基准就乱了。解决截图开始前强制做一次布局重建随后把 content 高度锁死。具体做法是LayoutRebuilder.ForceRebuildLayoutImmediate(contentRect)然后把 content.sizeDelta 的 y 存进临时变量截图期间不让 LayoutGroup 改它。更省事的做法是截长图前先把所有 Item 的图片预加载完再进入滚动流程。内容变化导致高度漂移这个问题在动态列表上是避无可避的提前锁定是唯一可靠的后悔药。5. 校验长图质量的土办法和一个Editor一键出图技巧5.1 用Python做重叠区差分校验不用肉眼盯拼接脚本写完先别急着拿给 UI 看。手工滚动列表和脚本滚动在像素级别不可能完全一致只要接缝处差异在一定范围内就能过关。我习惯在 debug_frames 目录里留两份相邻帧写一个几行的 Python 脚本做重叠区差分用数据判断拼接有没有漏块或偏移。from PIL import Image import numpy as np a np.array(Image.open(debug_frames/frame_002.png).convert(RGB), dtypenp.int16) b np.array(Image.open(debug_frames/frame_003.png).convert(RGB), dtypenp.int16) # 检查 frame_002 底部 8 行和 frame_003 顶部 8 行的像素差异 diff np.abs(a[-8:, :, :] - b[:8, :, :]) bad_ratio (diff.mean(axis2) 40).mean() print(fdifference ratio: {bad_ratio:.3f})差异比例在 0.05 以下说明接缝处基本是连续的超过 0.1说明这个地方肯定有错位或者内容缺口回去看 debug 帧就能定位到具体 Item。这个校验脚本胜在快不用肉眼在几十张图之间来回比比用编辑器反复 Play 省时间。5.2 Editor菜单一键出图把截图从运行时搬到开发期运行时截图要拖场景、进 Play 模式、等协程跑完反复操作很烦。我的做法是把启动函数挂到 Editor 菜单上在 Edit Mode 里直接生成长图。大致思路是把 Chapter 3 的脚本逻辑抽到一个静态方法里然后加一个 MenuItem 入口运行时用EditorApplication.isPlaying判断非运行时手动调用。#if UNITY_EDITOR using UnityEditor; public static class LongScreenshotEditor { [MenuItem(Tools/UI/Generate ScrollView Long Image)] static void RunFromEditor() { ScrollViewLongScreenshot comp Object.FindObjectOfTypeScrollViewLongScreenshot(); if (comp null) return; comp.StartCoroutine(comp.CaptureAndBuild()); } } #endif把截图逻辑收进一个可复用的协程方法后Editor 菜单和运行时入口共用同一套代码。这样策划和 UI 同学不需要打开运行模式直接在编辑器里选中场景、点一下菜单长图就落到 Screenshots 目录。我现在接到这类需求都会先问一句内容高度会不会超过设备纹理限制——这个问题不搞清楚晚些时候打包上真机才发现就要重新跑一遍整条滚动流程了。提前确认再配合 Editor 出图这个方向值得投入能省下不少沟通和返工时间。希望帮到你。本文还有配套的精品资源点击获取