简介：面向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 = GetComponentInParent<Canvas>(); // 非 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"), dtype=np.int16) b = np.array(Image.open("debug_frames/frame_003.png").convert("RGB"), dtype=np.int16) # 检查 frame_002 底部 8 行和 frame_003 顶部 8 行的像素差异 diff = np.abs(a[-8:, :, :] - b[:8, :, :]) bad_ratio = (diff.mean(axis=2) > 40).mean() print(f"difference 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.FindObjectOfType<ScrollViewLongScreenshot>(); if (comp == null) return; comp.StartCoroutine(comp.CaptureAndBuild()); } } #endif把截图逻辑收进一个可复用的协程方法后，Editor 菜单和运行时入口共用同一套代码。这样策划和 UI 同学不需要打开运行模式，直接在编辑器里选中场景、点一下菜单，长图就落到 Screenshots 目录。我现在接到这类需求，都会先问一句内容高度会不会超过设备纹理限制——这个问题不搞清楚，晚些时候打包上真机才发现，就要重新跑一遍整条滚动流程了。提前确认，再配合 Editor 出图，这个方向值得投入，能省下不少沟通和返工时间。希望帮到你。
本文还有配套的精品资源，点击获取
