尧图网页设计 
简介这份资源面向在Unity引擎中开发文档查看类应用的开发者尤其是需要处理Word、Excel、PDF、PPT等格式的教育、信息展示类项目。由于Android平台原生不支持这些文件类型的直接显示资源围绕第三方库集成、文件读取、格式转换与WebView渲染等环节提供了可参考的工程实现思路。压缩包共约2000个文件整体172.43MB包含cs脚本、dll动态库、unity场景、prefab预制体、asset资源以及json、xml配置等另有docx、pdf、pptx、xlsx示例文档用于验证显示效果meta与info文件则保留了完整的资源导入信息。目前已有914人学习下载。读者可从中获取Unity与Android平台适配的工程结构、JNI交互与性能优化思路以及分页加载、手势交互等实现参考适合具备一定Unity基础、希望快速搭建文档查看功能的开发者对照研究。1. Unity 里显示 Word、Excel、PDF、PPT先想清楚“显示”到底指什么很多团队接到“在 Unity 里显示 Word、Excel、PDF、PPT”这个需求时第一反应是找一个插件把文件丢进去渲染出来。真做过一轮就会发现Unity 本身没有内置 Office 文档渲染能力它只有 Texture、Mesh、UI 和一套脚本运行时。所谓“显示”在工程上至少要拆成三种完全不同的目标第一种是把文档当图片贴到 UI 上只求看得见第二种是保留排版、字体、表格、公式要求还原度第三种是还要能翻页、缩放、搜索、选中文字。目标不同选型差出十万八千里。这篇笔记就按一线落地的顺序把 Unity 显示 Word、Excel、PDF、PPT 这几类文件的可行路径、参数设置和踩坑点讲清楚适合正在做数字孪生、工业看板、培训课件、展厅大屏的开发者。2. 先分清四类文件的渲染难度与选型逻辑2.1 Word、Excel、PPT、PDF 的渲染难度排序在动手之前先建立一个判断这四类文件在 Unity 里的渲染难度不是同一档。PDF 是“版式固定”的格式页面尺寸、字体、图形位置在生成时就定死了所以它最容易做到高还原度显示。Word 和 Excel 是“流式排版”同一份文件在不同字体、不同纸张、不同行高下会重排渲染器必须实现一套排版引擎难度陡增。PPT 更特殊它本质是幻灯片加动画时间轴静态显示一页不难难的是动画和切换效果。文件类型版式特性静态显示难度动态/交互难度常见落地方式PDF固定版式低中转图片或原生渲染Word流式排版中高高转 PDF 再转图片Excel流式表格高高转 PDF 或转 HTMLPPT幻灯片动画中极高转图片序列从这张表能看出一个务实结论如果你的需求只是“让用户看到内容”最稳的路线是先把 Office 文档转成 PDF再把 PDF 转成图片或纹理Unity 只负责显示图片。这样绕开了在 Unity 里重写排版引擎这件几乎不可能短期完成的事。2.2 三条主流技术路线对比第一条路线是“服务端/编辑器预转换”。在 Unity 外部用 LibreOffice、Office COM 组件或在线转换服务把 Word、Excel、PPT 统一转成 PDF再把 PDF 按页转成 PNG。Unity 运行时只加载图片性能可控还原度高。缺点是文件更新后需要重新转换实时性差。第二条路线是“运行时原生渲染”。在 Unity 里集成 PDF 渲染库直接解析 PDF 页面并生成纹理。这条路对 PDF 可行对 Word、Excel、PPT 基本不可行因为缺少成熟的跨平台排版引擎。第三条路线是“嵌入 WebView”。在 Unity 里嵌入一个浏览器内核把文档转成 HTML 或直接用浏览器打开再把 WebView 的画面渲染到纹理上。这条路交互能力强但包体、内存、平台兼容性都要付出代价。我一般会这样选展厅大屏、工业看板这类“内容固定、更新不频繁”的场景走第一条路线需要用户翻页、缩放、搜索 PDF 的场景走第二条路线需要复杂交互且能接受包体增大的场景才考虑第三条。2.3 最小可跑通的转换与显示流程先给一个最小闭环用 LibreOffice 命令行把 Word 转 PDF再用 Python 的 pdf2image 把 PDF 转 PNG最后在 Unity 里用 RawImage 显示。这套流程不依赖任何 Unity 付费插件适合先验证需求。# 用 LibreOffice 无界面模式把 docx 转成 pdf # --headless 表示不弹窗--convert-to 指定目标格式 soffice --headless --convert-to pdf --outdir ./output ./demo.docx# pdf2image 依赖 popplerWindows 下需要把 poppler 的 bin 目录加入 PATH from pdf2image import convert_from_path # dpi 决定输出图片清晰度150 适合屏幕显示300 适合打印 pages convert_from_path(./output/demo.pdf, dpi150) for i, page in enumerate(pages): # 按页码命名方便 Unity 按索引加载 page.save(f./output/page_{i:03d}.png, PNG)// Unity 侧把转换好的图片按页加载到 RawImage using UnityEngine; using UnityEngine.UI; public class DocViewer : MonoBehaviour { public RawImage display; // 用于显示页面的 UI 组件 public string folderPath; // 图片所在目录 private int currentPage 0; private int totalPages 10; // 实际项目里应动态读取文件数量 void Start() { ShowPage(0); } public void ShowPage(int index) { // 图片命名与 Python 脚本保持一致 string file ${folderPath}/page_{index:000}.png; // 实际项目建议用 UnityWebRequest 或 File.ReadAllBytes 加载 byte[] data System.IO.File.ReadAllBytes(file); Texture2D tex new Texture2D(2, 2); tex.LoadImage(data); display.texture tex; currentPage index; } }这段代码里dpi是最关键的参数太低会糊太高会让纹理内存暴涨。一张 A4 页面在 150 dpi 下约 1240×1754 像素RGBA32 格式占用约 8.7 MB如果一页 300 dpi占用接近 35 MB。一个 50 页的文档如果全部常驻内存就是 1.7 GB必然翻车。所以实际项目里必须做纹理的按需加载和释放不能一次性全部 LoadImage。3. 把 PDF 在 Unity 里原生渲染出来的关键步骤3.1 为什么 PDF 适合原生渲染PDF 的页面内容是用一套与设备无关的绘图指令描述的包括路径、填充、字体、图像。只要有一个解析器把这些指令翻译成像素就能在任何平台上得到一致的显示效果。这意味着 Unity 里可以集成一个 PDF 解析库把每一页渲染成 Texture2D而不需要外部转换。常见做法是使用基于 PDFium 或 MuPDF 的封装库这类库在 Windows、Android、iOS 上都有成熟实现。原生渲染的好处是实时性强用户打开文件就能看不需要等待转换。坏处是包体会增大PDFium 的动态库在 Android 上大约几 MBiOS 上类似。另外渲染是 CPU 密集型操作如果直接在主线程渲染大页面会卡顿必须放到子线程或分帧处理。3.2 渲染到 Texture2D 的参数与内存控制下面是一个典型的原生渲染调用示例假设使用了一个提供RenderPage接口的封装库。重点看参数和内存释放。// 假设 pdfLib 是封装好的 PDF 渲染库实例 // pageIndex 从 0 开始scale 是渲染缩放比例 int pageIndex 0; float scale 1.5f; // 1.0 约等于 72 dpi1.5 约等于 108 dpi // 渲染页面返回 RGBA 像素数据 byte[] pixels pdfLib.RenderPage(pageIndex, scale, out int width, out int height); // 创建纹理注意格式要与像素数据匹配 Texture2D tex new Texture2D(width, height, TextureFormat.RGBA32, false); tex.LoadRawTextureData(pixels); tex.Apply(); // 显示到 RawImage display.texture tex; // 关键旧纹理必须显式销毁否则内存持续增长 // 在切换页面前调用 Destroy(oldTex)scale参数直接决定清晰度和内存。以 A4 页面为例72 dpi 下是 595×842RGBA32 约 2 MBscale 设为 2.0 时约 1190×1684约 8 MB。如果同时缓存 10 页就是 80 MB在移动端已经接近警戒线。我的习惯是只保留当前页和前后各一页的纹理其余全部Destroy并调用Resources.UnloadUnusedAssets。3.3 翻页、缩放与异步加载的落地写法翻页和缩放不能每帧都重新渲染否则 CPU 会跑满。正确做法是把渲染请求放进队列在子线程完成像素生成再回到主线程创建纹理。下面是一个简化的异步加载结构。using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; public class PdfAsyncViewer : MonoBehaviour { public RawImage display; private Queueint renderQueue new Queueint(); private bool isRendering false; public void RequestPage(int pageIndex) { // 同一页重复请求时忽略避免队列堆积 if (!renderQueue.Contains(pageIndex)) { renderQueue.Enqueue(pageIndex); } if (!isRendering) { StartCoroutine(ProcessQueue()); } } IEnumerator ProcessQueue() { isRendering true; while (renderQueue.Count 0) { int page renderQueue.Dequeue(); // 在子线程渲染像素避免阻塞主线程 byte[] pixels null; int w 0, h 0; yield return System.Threading.Tasks.Task.Run(() { pixels pdfLib.RenderPage(page, 1.5f, out w, out h); }); // 回到主线程创建纹理 Texture2D old display.texture as Texture2D; Texture2D tex new Texture2D(w, h, TextureFormat.RGBA32, false); tex.LoadRawTextureData(pixels); tex.Apply(); display.texture tex; // 释放旧纹理这是避免内存泄露的关键一步 if (old ! null) Destroy(old); yield return null; } isRendering false; } }这段代码里有两个容易忽略的点。第一Task.Run里调用的渲染库必须是线程安全的如果库本身不是线程安全就要加锁或改用独立进程。第二Destroy(old)之后纹理并不会立刻从显存释放Unity 会在下一帧回收所以不要在同一帧反复创建和销毁大量纹理。4. Word、Excel、PPT 的转换链路与参数调优4.1 用 LibreOffice 批量转换的稳定参数LibreOffice 的命令行转换是免费方案里最稳的但默认参数在批量转换时容易出问题。比如中文字体缺失会导致排版错乱Excel 的打印区域设置不对会丢列。下面是一组我常用的参数组合。# 指定用户配置目录避免多进程冲突 # -env:UserInstallation 让每个转换进程有独立配置 soffice --headless \ -env:UserInstallationfile:///tmp/lo_profile_$$ \ --convert-to pdf:calc_pdf_Export \ --outdir ./output \ ./report.xlsx对于 Excelcalc_pdf_Export会按工作表打印区域导出如果表格很宽需要先在 Excel 里设置好缩放为“适合一页宽”。对于 Word默认导出会保留分页但如果文档里用了非系统字体转换服务器上必须安装对应字体否则会回退成默认字体排版全变。对于 PPT--convert-to pdf会把每张幻灯片导成一页 PDF动画会丢失这是预期行为。4.2 转换后图片的命名、缓存与版本管理转换产物需要一套命名规则否则 Unity 侧无法可靠加载。我一般用“文档哈希 页码”作为文件名这样同一份文档重复转换不会产生冗余不同版本也不会互相覆盖。import hashlib import os def file_hash(path): # 用文件内容哈希作为版本标识避免同名不同内容冲突 h hashlib.md5() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest()[:12] doc_path ./demo.docx version file_hash(doc_path) out_dir f./cache/{version} os.makedirs(out_dir, exist_okTrue) # 后续转换和图片输出都放到这个版本目录下Unity 侧加载时先读取一个清单文件里面记录版本号和页数再按版本目录加载图片。这样文档更新后旧缓存可以整体删除不会出现“新文档配旧图片”的玄学问题。4.3 高分辨率与大文档的性能取舍分辨率不是越高越好。展厅大屏可能要求 4K 显示但一张 4K 图片的 RGBA32 内存是 3840×2160×4 字节约 33 MB。如果文档有 100 页不可能全部常驻。我的做法是只对当前可见页生成高分辨率纹理预加载的相邻页用低分辨率翻页后再替换成高分辨率。这样既保证当前页清晰又控制内存峰值。另外图片格式也有讲究。PNG 无损但文件大JPG 有损但小。对于文字为主的文档JPG 在高质量参数下压缩比很好但边缘可能出现振铃。如果对文字锐度要求高可以用 PNG但要在加载后及时压缩纹理格式比如在 Android 上用 ETC2在 iOS 上用 ASTC能显著降低显存占用。5. 避坑与排查那些让文档显示翻车的细节5.1 现象转换后的 PDF 中文变成方框原因转换服务器上没有安装文档里使用的中文字体LibreOffice 回退到默认字体而默认字体不含中文字形。解决在服务器上安装常用中文字体比如思源黑体、文泉驿并在 LibreOffice 的字体替换表里配置好映射。转换前可以用fc-list检查字体是否可用。5.2 现象Excel 转 PDF 后右侧列被截断原因Excel 的打印区域默认按 A4 纵向宽表格超出页面宽度后被截断。解决在转换前用脚本设置工作表的PageSetup把FitToPagesWide设为 1Zoom设为 false。如果不想改原文件可以在 LibreOffice 转换时传入筛选参数强制按内容宽度缩放。5.3 现象Unity 里纹理内存持续增长最终闪退原因每次翻页都new Texture2D但没有销毁旧纹理或者销毁后没有调用Resources.UnloadUnusedAssets。解决维护一个纹理池限制同时存在的纹理数量切换页面时先销毁不可见纹理在场景切换或文档关闭时调用Resources.UnloadUnusedAssets。用 Profiler 的 Memory 模块观察 Texture 内存曲线正常应该是锯齿状而不是持续上升。5.4 现象PPT 转 PDF 后动画全部丢失原因PDF 是静态页面格式不承载 PPT 的动画时间轴。解决如果必须保留动画只能走 WebView 路线在浏览器里播放 PPT 转换后的 HTML5 版本或者用视频录制的方式把动画导出成视频Unity 播放视频。前者交互好但包体大后者简单但不可交互按场景取舍。5.5 现象移动端加载大图时卡顿明显原因在主线程用LoadImage解码大尺寸 PNG解码耗时可能几十毫秒甚至上百毫秒。解决把解码放到子线程或者改用UnityWebRequestTexture异步加载同时控制单页图片尺寸移动端建议不超过 2048×2048。如果必须显示更大页面可以分块加载只解码当前视口区域。6. 进阶技巧用一张“文档纹理图集”把翻页做到丝滑前面讲的都是按页加载翻页时会有一次纹理创建的开销。如果文档页数不多比如 20 页以内可以把所有页面缩放到统一尺寸后拼成一张图集Unity 只加载一张大纹理翻页时只改 UV 偏移。这样翻页几乎没有卡顿代价是内存换流畅。具体做法在转换阶段把每页图片缩放到相同宽度比如 1024 像素然后按垂直方向拼接成一张长图。Unity 侧创建一个Texture2D用RawImage的uvRect控制显示哪一页。// 假设图集总高度为 totalHeight每页高度为 pageHeight // 显示第 index 页时计算 uvRect int pageCount 20; float pageHeight 1f / pageCount; int index 5; // uvRect 的 y 坐标从底部开始所以需要翻转 display.uvRect new Rect(0, 1f - (index 1) * pageHeight, 1, pageHeight);这个技巧的边界是图集总尺寸不能超过 GPU 的最大纹理尺寸移动端通常是 4096 或 8192。如果每页 1024 宽、20 页总高度可能超过 8192就需要分多张图集。另外图集方案不适合页数多、分辨率要求高的场景因为缩放会损失清晰度。验证方法很简单在 Profiler 里看Texture2D的内存占用是否稳定翻页时SetPassCall是否没有明显波动。如果翻页时帧率掉到 30 以下说明纹理创建或上传仍然是瓶颈需要回到按需加载方案。我自己踩过最深的坑是早期图省事把所有页面一次性LoadImage进内存结果在低端 Android 设备上打开一个 30 页的 PPT 直接闪退。后来改成纹理池加异步加载才把内存峰值压到 200 MB 以内。做这类需求永远先把内存预算算清楚再谈显示效果。希望帮到你。本文还有配套的精品资源点击获取 Unity 中显示 Word、Excel、PDF、PPT 的完整技术方案与避坑指南
简介这份资源面向在Unity引擎中开发文档查看类应用的开发者尤其是需要处理Word、Excel、PDF、PPT等格式的教育、信息展示类项目。由于Android平台原生不支持这些文件类型的直接显示资源围绕第三方库集成、文件读取、格式转换与WebView渲染等环节提供了可参考的工程实现思路。压缩包共约2000个文件整体172.43MB包含cs脚本、dll动态库、unity场景、prefab预制体、asset资源以及json、xml配置等另有docx、pdf、pptx、xlsx示例文档用于验证显示效果meta与info文件则保留了完整的资源导入信息。目前已有914人学习下载。读者可从中获取Unity与Android平台适配的工程结构、JNI交互与性能优化思路以及分页加载、手势交互等实现参考适合具备一定Unity基础、希望快速搭建文档查看功能的开发者对照研究。1. Unity 里显示 Word、Excel、PDF、PPT先想清楚“显示”到底指什么很多团队接到“在 Unity 里显示 Word、Excel、PDF、PPT”这个需求时第一反应是找一个插件把文件丢进去渲染出来。真做过一轮就会发现Unity 本身没有内置 Office 文档渲染能力它只有 Texture、Mesh、UI 和一套脚本运行时。所谓“显示”在工程上至少要拆成三种完全不同的目标第一种是把文档当图片贴到 UI 上只求看得见第二种是保留排版、字体、表格、公式要求还原度第三种是还要能翻页、缩放、搜索、选中文字。目标不同选型差出十万八千里。这篇笔记就按一线落地的顺序把 Unity 显示 Word、Excel、PDF、PPT 这几类文件的可行路径、参数设置和踩坑点讲清楚适合正在做数字孪生、工业看板、培训课件、展厅大屏的开发者。2. 先分清四类文件的渲染难度与选型逻辑2.1 Word、Excel、PPT、PDF 的渲染难度排序在动手之前先建立一个判断这四类文件在 Unity 里的渲染难度不是同一档。PDF 是“版式固定”的格式页面尺寸、字体、图形位置在生成时就定死了所以它最容易做到高还原度显示。Word 和 Excel 是“流式排版”同一份文件在不同字体、不同纸张、不同行高下会重排渲染器必须实现一套排版引擎难度陡增。PPT 更特殊它本质是幻灯片加动画时间轴静态显示一页不难难的是动画和切换效果。文件类型版式特性静态显示难度动态/交互难度常见落地方式PDF固定版式低中转图片或原生渲染Word流式排版中高高转 PDF 再转图片Excel流式表格高高转 PDF 或转 HTMLPPT幻灯片动画中极高转图片序列从这张表能看出一个务实结论如果你的需求只是“让用户看到内容”最稳的路线是先把 Office 文档转成 PDF再把 PDF 转成图片或纹理Unity 只负责显示图片。这样绕开了在 Unity 里重写排版引擎这件几乎不可能短期完成的事。2.2 三条主流技术路线对比第一条路线是“服务端/编辑器预转换”。在 Unity 外部用 LibreOffice、Office COM 组件或在线转换服务把 Word、Excel、PPT 统一转成 PDF再把 PDF 按页转成 PNG。Unity 运行时只加载图片性能可控还原度高。缺点是文件更新后需要重新转换实时性差。第二条路线是“运行时原生渲染”。在 Unity 里集成 PDF 渲染库直接解析 PDF 页面并生成纹理。这条路对 PDF 可行对 Word、Excel、PPT 基本不可行因为缺少成熟的跨平台排版引擎。第三条路线是“嵌入 WebView”。在 Unity 里嵌入一个浏览器内核把文档转成 HTML 或直接用浏览器打开再把 WebView 的画面渲染到纹理上。这条路交互能力强但包体、内存、平台兼容性都要付出代价。我一般会这样选展厅大屏、工业看板这类“内容固定、更新不频繁”的场景走第一条路线需要用户翻页、缩放、搜索 PDF 的场景走第二条路线需要复杂交互且能接受包体增大的场景才考虑第三条。2.3 最小可跑通的转换与显示流程先给一个最小闭环用 LibreOffice 命令行把 Word 转 PDF再用 Python 的 pdf2image 把 PDF 转 PNG最后在 Unity 里用 RawImage 显示。这套流程不依赖任何 Unity 付费插件适合先验证需求。# 用 LibreOffice 无界面模式把 docx 转成 pdf # --headless 表示不弹窗--convert-to 指定目标格式 soffice --headless --convert-to pdf --outdir ./output ./demo.docx# pdf2image 依赖 popplerWindows 下需要把 poppler 的 bin 目录加入 PATH from pdf2image import convert_from_path # dpi 决定输出图片清晰度150 适合屏幕显示300 适合打印 pages convert_from_path(./output/demo.pdf, dpi150) for i, page in enumerate(pages): # 按页码命名方便 Unity 按索引加载 page.save(f./output/page_{i:03d}.png, PNG)// Unity 侧把转换好的图片按页加载到 RawImage using UnityEngine; using UnityEngine.UI; public class DocViewer : MonoBehaviour { public RawImage display; // 用于显示页面的 UI 组件 public string folderPath; // 图片所在目录 private int currentPage 0; private int totalPages 10; // 实际项目里应动态读取文件数量 void Start() { ShowPage(0); } public void ShowPage(int index) { // 图片命名与 Python 脚本保持一致 string file ${folderPath}/page_{index:000}.png; // 实际项目建议用 UnityWebRequest 或 File.ReadAllBytes 加载 byte[] data System.IO.File.ReadAllBytes(file); Texture2D tex new Texture2D(2, 2); tex.LoadImage(data); display.texture tex; currentPage index; } }这段代码里dpi是最关键的参数太低会糊太高会让纹理内存暴涨。一张 A4 页面在 150 dpi 下约 1240×1754 像素RGBA32 格式占用约 8.7 MB如果一页 300 dpi占用接近 35 MB。一个 50 页的文档如果全部常驻内存就是 1.7 GB必然翻车。所以实际项目里必须做纹理的按需加载和释放不能一次性全部 LoadImage。3. 把 PDF 在 Unity 里原生渲染出来的关键步骤3.1 为什么 PDF 适合原生渲染PDF 的页面内容是用一套与设备无关的绘图指令描述的包括路径、填充、字体、图像。只要有一个解析器把这些指令翻译成像素就能在任何平台上得到一致的显示效果。这意味着 Unity 里可以集成一个 PDF 解析库把每一页渲染成 Texture2D而不需要外部转换。常见做法是使用基于 PDFium 或 MuPDF 的封装库这类库在 Windows、Android、iOS 上都有成熟实现。原生渲染的好处是实时性强用户打开文件就能看不需要等待转换。坏处是包体会增大PDFium 的动态库在 Android 上大约几 MBiOS 上类似。另外渲染是 CPU 密集型操作如果直接在主线程渲染大页面会卡顿必须放到子线程或分帧处理。3.2 渲染到 Texture2D 的参数与内存控制下面是一个典型的原生渲染调用示例假设使用了一个提供RenderPage接口的封装库。重点看参数和内存释放。// 假设 pdfLib 是封装好的 PDF 渲染库实例 // pageIndex 从 0 开始scale 是渲染缩放比例 int pageIndex 0; float scale 1.5f; // 1.0 约等于 72 dpi1.5 约等于 108 dpi // 渲染页面返回 RGBA 像素数据 byte[] pixels pdfLib.RenderPage(pageIndex, scale, out int width, out int height); // 创建纹理注意格式要与像素数据匹配 Texture2D tex new Texture2D(width, height, TextureFormat.RGBA32, false); tex.LoadRawTextureData(pixels); tex.Apply(); // 显示到 RawImage display.texture tex; // 关键旧纹理必须显式销毁否则内存持续增长 // 在切换页面前调用 Destroy(oldTex)scale参数直接决定清晰度和内存。以 A4 页面为例72 dpi 下是 595×842RGBA32 约 2 MBscale 设为 2.0 时约 1190×1684约 8 MB。如果同时缓存 10 页就是 80 MB在移动端已经接近警戒线。我的习惯是只保留当前页和前后各一页的纹理其余全部Destroy并调用Resources.UnloadUnusedAssets。3.3 翻页、缩放与异步加载的落地写法翻页和缩放不能每帧都重新渲染否则 CPU 会跑满。正确做法是把渲染请求放进队列在子线程完成像素生成再回到主线程创建纹理。下面是一个简化的异步加载结构。using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; public class PdfAsyncViewer : MonoBehaviour { public RawImage display; private Queueint renderQueue new Queueint(); private bool isRendering false; public void RequestPage(int pageIndex) { // 同一页重复请求时忽略避免队列堆积 if (!renderQueue.Contains(pageIndex)) { renderQueue.Enqueue(pageIndex); } if (!isRendering) { StartCoroutine(ProcessQueue()); } } IEnumerator ProcessQueue() { isRendering true; while (renderQueue.Count 0) { int page renderQueue.Dequeue(); // 在子线程渲染像素避免阻塞主线程 byte[] pixels null; int w 0, h 0; yield return System.Threading.Tasks.Task.Run(() { pixels pdfLib.RenderPage(page, 1.5f, out w, out h); }); // 回到主线程创建纹理 Texture2D old display.texture as Texture2D; Texture2D tex new Texture2D(w, h, TextureFormat.RGBA32, false); tex.LoadRawTextureData(pixels); tex.Apply(); display.texture tex; // 释放旧纹理这是避免内存泄露的关键一步 if (old ! null) Destroy(old); yield return null; } isRendering false; } }这段代码里有两个容易忽略的点。第一Task.Run里调用的渲染库必须是线程安全的如果库本身不是线程安全就要加锁或改用独立进程。第二Destroy(old)之后纹理并不会立刻从显存释放Unity 会在下一帧回收所以不要在同一帧反复创建和销毁大量纹理。4. Word、Excel、PPT 的转换链路与参数调优4.1 用 LibreOffice 批量转换的稳定参数LibreOffice 的命令行转换是免费方案里最稳的但默认参数在批量转换时容易出问题。比如中文字体缺失会导致排版错乱Excel 的打印区域设置不对会丢列。下面是一组我常用的参数组合。# 指定用户配置目录避免多进程冲突 # -env:UserInstallation 让每个转换进程有独立配置 soffice --headless \ -env:UserInstallationfile:///tmp/lo_profile_$$ \ --convert-to pdf:calc_pdf_Export \ --outdir ./output \ ./report.xlsx对于 Excelcalc_pdf_Export会按工作表打印区域导出如果表格很宽需要先在 Excel 里设置好缩放为“适合一页宽”。对于 Word默认导出会保留分页但如果文档里用了非系统字体转换服务器上必须安装对应字体否则会回退成默认字体排版全变。对于 PPT--convert-to pdf会把每张幻灯片导成一页 PDF动画会丢失这是预期行为。4.2 转换后图片的命名、缓存与版本管理转换产物需要一套命名规则否则 Unity 侧无法可靠加载。我一般用“文档哈希 页码”作为文件名这样同一份文档重复转换不会产生冗余不同版本也不会互相覆盖。import hashlib import os def file_hash(path): # 用文件内容哈希作为版本标识避免同名不同内容冲突 h hashlib.md5() with open(path, rb) as f: for chunk in iter(lambda: f.read(8192), b): h.update(chunk) return h.hexdigest()[:12] doc_path ./demo.docx version file_hash(doc_path) out_dir f./cache/{version} os.makedirs(out_dir, exist_okTrue) # 后续转换和图片输出都放到这个版本目录下Unity 侧加载时先读取一个清单文件里面记录版本号和页数再按版本目录加载图片。这样文档更新后旧缓存可以整体删除不会出现“新文档配旧图片”的玄学问题。4.3 高分辨率与大文档的性能取舍分辨率不是越高越好。展厅大屏可能要求 4K 显示但一张 4K 图片的 RGBA32 内存是 3840×2160×4 字节约 33 MB。如果文档有 100 页不可能全部常驻。我的做法是只对当前可见页生成高分辨率纹理预加载的相邻页用低分辨率翻页后再替换成高分辨率。这样既保证当前页清晰又控制内存峰值。另外图片格式也有讲究。PNG 无损但文件大JPG 有损但小。对于文字为主的文档JPG 在高质量参数下压缩比很好但边缘可能出现振铃。如果对文字锐度要求高可以用 PNG但要在加载后及时压缩纹理格式比如在 Android 上用 ETC2在 iOS 上用 ASTC能显著降低显存占用。5. 避坑与排查那些让文档显示翻车的细节5.1 现象转换后的 PDF 中文变成方框原因转换服务器上没有安装文档里使用的中文字体LibreOffice 回退到默认字体而默认字体不含中文字形。解决在服务器上安装常用中文字体比如思源黑体、文泉驿并在 LibreOffice 的字体替换表里配置好映射。转换前可以用fc-list检查字体是否可用。5.2 现象Excel 转 PDF 后右侧列被截断原因Excel 的打印区域默认按 A4 纵向宽表格超出页面宽度后被截断。解决在转换前用脚本设置工作表的PageSetup把FitToPagesWide设为 1Zoom设为 false。如果不想改原文件可以在 LibreOffice 转换时传入筛选参数强制按内容宽度缩放。5.3 现象Unity 里纹理内存持续增长最终闪退原因每次翻页都new Texture2D但没有销毁旧纹理或者销毁后没有调用Resources.UnloadUnusedAssets。解决维护一个纹理池限制同时存在的纹理数量切换页面时先销毁不可见纹理在场景切换或文档关闭时调用Resources.UnloadUnusedAssets。用 Profiler 的 Memory 模块观察 Texture 内存曲线正常应该是锯齿状而不是持续上升。5.4 现象PPT 转 PDF 后动画全部丢失原因PDF 是静态页面格式不承载 PPT 的动画时间轴。解决如果必须保留动画只能走 WebView 路线在浏览器里播放 PPT 转换后的 HTML5 版本或者用视频录制的方式把动画导出成视频Unity 播放视频。前者交互好但包体大后者简单但不可交互按场景取舍。5.5 现象移动端加载大图时卡顿明显原因在主线程用LoadImage解码大尺寸 PNG解码耗时可能几十毫秒甚至上百毫秒。解决把解码放到子线程或者改用UnityWebRequestTexture异步加载同时控制单页图片尺寸移动端建议不超过 2048×2048。如果必须显示更大页面可以分块加载只解码当前视口区域。6. 进阶技巧用一张“文档纹理图集”把翻页做到丝滑前面讲的都是按页加载翻页时会有一次纹理创建的开销。如果文档页数不多比如 20 页以内可以把所有页面缩放到统一尺寸后拼成一张图集Unity 只加载一张大纹理翻页时只改 UV 偏移。这样翻页几乎没有卡顿代价是内存换流畅。具体做法在转换阶段把每页图片缩放到相同宽度比如 1024 像素然后按垂直方向拼接成一张长图。Unity 侧创建一个Texture2D用RawImage的uvRect控制显示哪一页。// 假设图集总高度为 totalHeight每页高度为 pageHeight // 显示第 index 页时计算 uvRect int pageCount 20; float pageHeight 1f / pageCount; int index 5; // uvRect 的 y 坐标从底部开始所以需要翻转 display.uvRect new Rect(0, 1f - (index 1) * pageHeight, 1, pageHeight);这个技巧的边界是图集总尺寸不能超过 GPU 的最大纹理尺寸移动端通常是 4096 或 8192。如果每页 1024 宽、20 页总高度可能超过 8192就需要分多张图集。另外图集方案不适合页数多、分辨率要求高的场景因为缩放会损失清晰度。验证方法很简单在 Profiler 里看Texture2D的内存占用是否稳定翻页时SetPassCall是否没有明显波动。如果翻页时帧率掉到 30 以下说明纹理创建或上传仍然是瓶颈需要回到按需加载方案。我自己踩过最深的坑是早期图省事把所有页面一次性LoadImage进内存结果在低端 Android 设备上打开一个 30 页的 PPT 直接闪退。后来改成纹理池加异步加载才把内存峰值压到 200 MB 以内。做这类需求永远先把内存预算算清楚再谈显示效果。希望帮到你。本文还有配套的精品资源点击获取