UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - 厚积薄发
type: channel
link: https://blog.uwa4d.com/category/technology
description: UWA旨在诊断与优化游戏和VR项目开发过程中潜在的运行性能问题，帮助项研发团队快速检测项目运行时的性能瓶颈，高效定位问题根源，及时反馈针对瓶颈问题的深度分析和解决方法。
items: 参数GPU Write Total Bandwidth的含义是什么，导致其值过高的因素有哪些
items: Unity IL2CPP的GC原理
items: 哪些因素和参数会影响Bloom的性能开销
items: 如何减少托管堆内存碎片
items: UE5多线程｜ThreadPool
items: 如何解决ProtoBuf反序列化中GC高的问题
items: 如何排查优化URP内置Shader冗余
items: UE5多线程｜FRunnableThread
items: 移动端反射探针格式用什么比较合理
items: 为何iPad Pro上设置目标帧率为90时无法生效

参数GPU Write Total Bandwidth的含义是什么，导致其值过高的因素有哪些
type: item
date: 2025-12-23T04:11:00+02:00
description: 1）参数GPU Write Total Bandwidth的含义是什么，导致其值过高的因素有哪些 2）对Unity项目来说，性能和效果可以兼顾的物理插件有哪些推荐 这是第458篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：GPU Write Total Bandwidth这一参数的含义，和其过高时可能的影响因素有哪些？ A：GPU Write Total Bandwidth含义： 该指标表示GPU每帧向内存（显存或系统内存）写入的总数据量，单位通常为MB/s或GB/s。它是GPU带宽压力的关键子项，反映帧渲染过程中所有写操作的带宽消耗总和，包括：帧缓冲（Color/Depth/Stencil）、RenderTexture、计算着色器输出、顶点着色器输出（如Transform Feedback）、以及部分缓存写回等。 Write Total Bandwidth 过高的常见影响因素： ✔ 高分辨率多目标渲染（MRT）或高精度帧缓冲 同时写入多个RenderTarget（如GBuffer中Albedo+Normal+Metallic+Depth），尤其使用高精度格式（RGBA16F、RGB10A2）； 主摄像机启用HDR渲染（R11G11B10或RGBA16F），大幅增加Color Buffer写入带宽； MSAA启用后（如4xMSAA），Color/Depth Buffer写入量成倍增长（需resolve前写入+resolve后写入）。 ✔ 频繁或大尺寸RenderTexture写入 全屏后处理中反复创建/清空/Blit到高分辨率RT（如2048×1536的Bloom临时纹理）； UI渲染中大量使用CanvasRenderTarget或Camera.targetTexture； 动态阴影图（Shadow Map）分辨率过高（如4096×4096）且每帧更新。 ✔ 深度/模板缓冲频繁写入与清除 每帧Clear Depth/Stencil（尤其在多Camera、多Pass场景下重复Clear）； 启用深度预通道（Z-Prepass）但未合批或存在冗余绘制，导致两次深度写入（Prepass+Main Pass）； 不合理的ZTest/ZWrite设置（如ZWrite Off缺失导致无效深度覆盖重试）。 ✔ Compute Shader高频大块写入 使用RWTexture2D/RWBuffer执行大规模粒子更新、物理模拟或图像生成，且线程组尺寸过大或Dispatch次数过多； 未使用AppendBuffer/ConsumeBuffer而采用全量写入方式。 ✔ GPU管线冗余写入行为 多个Camera渲染同一区域且未做裁剪/层级隔离，造成重复Color/Depth写入； URP/HDRP中未关闭不必要的Pass（如ShadowCaster、DepthOnly在非阴影场景仍启用）。 快速定位建议： 查看GOT Online GPU报告中Write Total曲线与Front-end Write/Texture Write/Depth Write等子项占比（若支持）； 对比FPS下降时段是否伴随Write峰值，结合GPU Freq是否因带宽瓶颈触发降频； 检查RenderPipeline Asset中是否启用了非必要高精度RT格式、MSAA或多Pass渲染； 使用UWA资源检测报告筛查高分辨率、未压缩的RenderTexture和ShadowMap资产。 优化优先级：降低RT分辨率 → 合并MRT输出 → 关闭冗余Clear/MSAA → 替换高精度格式（如RGBA8替代RGBA16F）→ 后处理降采样。 UWA GPU分析页面中还展示了很多对性能排查分析有一定参考价值的参数和其子参数，若您对这些参数的具体含义和参考价值仍有疑问，可在社区中进行查阅、或尝试使用AI问答助手解答。如以上问题，除了了解写带宽的影响因素外，您还可以提问在不同GPU架构下多种多样的读带宽子项的含义：Front-end Read、LoadStore Read、Texture Read、Vertex Read、SP Read。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=8919019e-4d69-43a2-bba1-39138791414a From UWA AI 问答 Q：对Unity项目来说，性能和效果可以兼顾的物理插件有什么推荐？ A：在Unity项目中，兼顾性能与效果的物理插件需满足三大硬性条…

Unity IL2CPP的GC原理
type: item
date: 2025-12-17T04:40:00+02:00
description: 【USparkle专栏】如果你深怀绝技，爱“搞点研究”，乐于分享也博采众长，我们期待你的加入，让智慧的火花碰撞交织，让知识的传递生生不息！ 背景：前段时间在项目内做了关于Mono内存（堆内存）的优化。从结果上将Mono内存从220MB降低到130MB，优化过程中唤起了部分关于GC的消失的回忆，虽然实际的优化工作中也许并用不到，但是更明确底层实现机制总归是一件迭代自我的过程，在这里就来回顾一下。 一、什么是垃圾回收 - GC（Garbage Collector） 在游戏运行的时候，数据主要存储在内存中，当游戏的数据在不需要的时候，存储当前数据的内存就可以被回收以再次使用。内存垃圾是指当前废弃数据所占用的内存，垃圾回收（GC）是指将废弃的内存重新回收再次使用的过程。 1. 什么时候触发垃圾回收 有三个操作会触发垃圾回收： 在堆内存上进行内存分配操作而内存不够的时候都会触发垃圾回收来利用闲置的内存。 GC会自动触发，不同平台运行频率不一样。 GC被代码强制执行。 2. GC操作带来的问题 直白点就两个问题：一个是Stop-the-world导致的“卡”；一个是内存碎片导致的“堆内存太大”。 GC操作会需要大量的时间来运行，如果堆内存上有大量的变量或者引用需要检查，则检查的操作会十分缓慢，这就会使得游戏运行缓慢。 GC可能会在关键时候运行，例如在CPU处于游戏的性能运行关键时刻，此时任何一个额外的操作都可能会带来极大的影响，使得游戏帧率下降。 另外一个GC带来的问题是堆内存的碎片。当一个内存单元从堆内存上分配出来，其大小取决于其存储的变量的大小。当该内存被回收到堆内存上的时候，有可能使得堆内存被分割成碎片化的单元。也就是说堆内存总体可以使用的内存单元较大，但是单独的内存单元较小，在下次内存分配的时候不能找到合适大小的存储单元，这也会触发GC操作或者堆内存扩展操作。 堆内存碎片会造成两个结果：一个是游戏占用的内存会越来越大；一个是GC会更加频繁地被触发。 特别是在堆内存上进行内存分配时内存单元不足够的时候，GC会被频繁触发，这就意味着频繁在堆内存上进行内存分配和回收会触发频繁的GC操作。 二、Unity托管堆 在讲具体的Unity GC机制之前再回顾一下Unity托管堆。 1. 托管堆的工作原理及其扩展原因 “托管堆”是由项目脚本运行时（Mono或IL2CPP）的内存管理器自动管理的一段内存。必须在托管堆上分配托管代码中创建的所有对象。 Unity官方文档图 在上图中，白框表示分配给托管堆的内存量，而其中的彩色框表示存储在托管堆的内存空间中的数据值。当需要更多值时，将从托管堆中分配更多空间。 GC定期运行将扫描堆上的所有对象，将任何不再引用的对象标记为删除。然后会删除未引用的对象，从而释放内存。 至关重要的是，Unity的垃圾收集是非分代的，也是非压缩的。“非分代”意味着GC在执行每遍收集时必须扫描整个堆，因此随着堆的扩展，其性能会下降。“非压缩”意味着不会为内存中的对象重新分配内存地址来消除对象之间的间隙。 内存空隙 上图为内存碎片化示例。释放对象时，将释放其内存。但是，释放的空间不会整合成为整个“可用内存”池的一部分。位于释放的对象两侧的对象可能仍在使用中。因此，释放的空间成为其他内存段之间的“间隙”（该间隙由上图中的红色圆圈指示）。因此，新释放的空间仅可用于存储与释放相同大小或更小的对象的数据。 这导致了内存碎片化这个核心问题：虽然堆中的可用空间总量可能很大，但是可能其中的部分或全部的可分配空间对象之间存在小的“间隙”。这种情况下，即使可用空间总量高于要分配的空间量，托管堆可能也找不到足够大的连续内存块来满足该分配需求。 如果分配了大型对象又没有足够的连续空间提供使用则： 运行垃圾回收器，尝试释放空间来满足分配请求。 如果在GC运行后，仍然没有足够的连续空间来满足请求的内存量，则必须扩展堆。堆的具体扩展量视平台而定。 2. Unity托管堆的问题 Unity在扩展托管堆后不会经常释放分配给托管堆的内存页, 防止再次发生大量分配时需要重新扩展堆。 在大多数平台上，Unity最终会将托管堆的空置部分使用的页面释放回操作系统。发生此行为的间隔时间是不确定的，不要指望靠这种方法释放内存。 频繁分配临时数据给托管堆，这种情况通常对项目的性能极为不利。 如果每帧分配1KB的临时内存，并且以60帧的速率运行，那么它必须每秒分配60KB的临时内存。在一分钟内，这会在内存中增加3.6MB的垃圾。对内存不足的设备而言每分钟3.6MB的垃圾也无法接受。 三、Unity的GC机制 -- Boehm GC 以前看过Unity使用的GC方案但最近才惊觉现在使用的Unity都是IL2CPP的版本了，所谓的Mono GC本来就已经不存在了。于是来看下现在的IL2…

哪些因素和参数会影响Bloom的性能开销
type: item
date: 2025-12-16T03:59:00+02:00
description: 1）哪些因素和参数会影响Bloom的性能开销 2）为何Scripting Threads的#0线程数量异常 这是第457篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：哪些因素和参数会影响bloom的性能开销？ A：Bloom（泛光）的性能开销主要来自GPU带宽、计算量与多级采样次数，其关键影响因素和可调参数如下： 一、核心性能影响因素 采样分辨率与下采样层级 Bloom默认从1/2渲染分辨率开始逐级下采样（如Blur1–Blur5），分辨率越低（如1/16）、层级越多，带宽越低但模糊质量下降；反之，高分辨率采样（如1/2）显著增加纹理读取带宽和显存吞吐压力。 移动端建议从1/4或1/8起始，减少首层采样开销。 BloomQuality级别 r.BloomQuality=5（默认）启用全部5层模糊+高质量卷积，开销最大；=1~3可禁用部分层级或使用简化高斯，大幅降低GPU耗时。 ScreenPercentage控制卷积精度 r.Bloom.ScreenPercentage=50表示FFT卷积在50%分辨率下执行；提高该值（如至100%）会线性增加计算与带宽，需谨慎权衡。 泛光卷积（Convolution）启用 启用Bloom Convolution会触发FFT卷积运算，依赖全分辨率内核纹理+额外缓冲区（r.Bloom.ConvolutionBuffer），显著提升GPU计算与显存带宽压力，仅推荐高端设备或离线渲染使用。 后处理链路叠加效应 Bloom常与Tonemapping、Depth of Field、Motion Blur等串联，导致多次全屏纹理读写。尤其在移动平台，多Pass后处理易引发带宽瓶颈（实测可达总GPU带宽的20%+）。 二、关键可调控制台变量（Unreal Engine） 三、优化建议 优先降级BloomQuality+ScreenPercentage，比关闭Bloom更能平衡画质与性能； 使用Stat GPU和Stat RHI定量定位Bloom耗时（查看PostProcessBloom阶段）； 避免在低端机启用Convolution或Dirt Mask（额外纹理采样+混合）； 结合r.VSync与帧率限制，防止Bloom在高帧率下反复重采样。 注：Bloom对GPU温度与功耗影响显著 —— 实测10GB/s带宽可贡献约1000mW功耗（占整机20%+），是移动端发热主因之一。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=f3f99f69-7e55-4af8-9a58-2531d33ec39a From UWA AI 问答 Q：请教个问题, 我们有用到线程池, 我在Profiler的时候看到在Scripting Threads里面有几十个#0的线程显示, 这个是正常的吗？ A：是不正常的，需立即排查。 Unity的Profiler中出现大量名称为#0的Scripting Threads，通常表明： 线程未正确命名或未注册：Unity默认对System.Threading.ThreadPool中的线程不自动命名，Profiler无法识别其用途，统一显示为#0（或空名+编号）。 线程泄漏风险高：若线程池长期持有大量闲置线程（尤其在Unity 2019 – 2022版本中），可能因ThreadPool.SetMinThreads调用不当、异步任务未完成/未释放、或Task.Run+长阻塞操作导致线程堆积。 非Unity管理线程被误纳入Profiler视图：#0线程无法通过Profiler.BeginThreadProfiling()注册，说明它们未被主动追踪，也意味着你无法在Timeline中定位其耗时来源。 建议动作： 检查是否滥用Task.Run或ThreadPool.QueueUserWorkItem；优先改用Unity Job System或Unity.Collections.LowLevel.Unsafe异步方案。 确认无new Thread(...).Start()后未调用Profiler.EndThreadProfiling()（否则资源泄漏且线程残留）。 在Editor中启用Call Stacks+Deep Profiling，筛选GC Alloc/CPU高耗时帧，定位创建线程的调用栈。 使用UWA GOT Online的Mono/Threading模块，查看线程数趋势与存活时间，确认是否随游戏时长持续增长。 注：Unity官方…

如何减少托管堆内存碎片
type: item
date: 2025-12-09T04:35:00+02:00
description: 1）如何减少托管堆内存碎片 2）MIX贴图中的sRGB（Color Texture）是否要取消勾选 这是第456篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：如何减少托管堆内存碎片？ A：减少托管堆内存碎片是提升游戏运行稳定性和降低GC压力的关键。内存碎片会导致堆空间利用率下降，即使总空闲内存足够，也可能因无法分配连续大块内存而触发不必要的GC或导致分配失败。 1. 识别与诊断 首先需确认是否存在严重碎片问题。使用UWA GOT Online的Mono模式进行测试，重点关注： Mono堆内存总量：观察其增长趋势。 Empty Heap Space（空闲堆空间）：若该值持续增长且占比高，表明存在大量碎片。 GC Allocated波形与实际耗时匹配性：如波峰明显但数值不高，可能因碎片导致GC效率低下。 2. 核心优化策略 避免高频小对象分配 减少byte[]、MemoryStream、DeflateStream等频繁创建的大数组操作。 使用对象池复用常用对象（如List、StringBuilder），避免重复分配与回收。 对于字符串拼接，优先使用StringBuilder并预设容量，避免多次扩容引发的复制。 优化集合类使用 预估集合大小并初始化时指定容量（如new List(100)），防止动态扩容产生临时数组。 避免在循环中调用LINQ方法（如Where、Select），因其常生成迭代器对象造成额外分配。 资源加载与数据处理 加载二进制数据时，使用预先分配的缓冲区（如UnityWebRequest配合DownloadHandlerScript传入固定byte[]），避免每帧生成新数组。 资源按需加载，避免一次性加载过多Asset导致堆膨胀。可结合Addressables实现细粒度管理。 代码层规避装箱 避免将值类型作为Object传递（如字典键值、事件参数）。 使用泛型替代非泛型集合（如Dictionary<int, T>而非Hashtable）。 扩展支持泛型参数的格式化方法（如AppendFormat），消除StringBuilder.AppendFormat中的装箱。 3. 引擎与配置调优 禁用不必要的反射：Type.GetProperty()、GetValue()易引发AOT问题且不利于剥离，尽量通过接口或委托替代。 合理设置GC策略：在移动平台启用增量式GC（Incremental GC），分散收集压力。 控制场景切换频率：频繁加载/卸载场景会加剧堆碎片，可通过异步加载与资源预加载平滑过渡。 4. 工具辅助分析 利用Unity Profiler的Memory模块截取堆快照，查看大块空闲区域分布。 结合GOT Online报告中的驻留对象分析，定位长期存活的小对象来源，针对性重构。 通过以上措施，可显著降低托管堆碎片率，提升内存利用效率和运行流畅度。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=49ae18c9-5cb3-4f4d-a4d4-a2b451551c11 From 问答社区 Q：我在排查项目中材质资源的时候发现MIX贴图中sRGB（Color Texture）有的有勾选，有的没勾选。 问了AI都是建议取消勾选，但是美术那边又说取消勾选可能效果就不对了。 这边还是问下诸位同僚，你们项目中的MIX贴图里的sRGB（Color Texture）选项是否都是取消勾选的？ A：和美术这边做了几个测试，确认是得取消勾选的。 之前导入资源时默认勾选了这个选项，导致后续都是在错误的基础上调整效果，所以一开始取消勾选会认为效果不对。 实际上是暴露了错误参数下的效果（比方说光滑度过高导致取消勾选后物件变得油腻）。 感谢题主土司喵@UWA问答社区提供了回答，有经验的朋友欢迎转至社区交流： https://answer.uwa4d.com/question/692eb082682c7e5cd61bfb78 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区，希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UW…

UE5多线程｜ThreadPool
type: item
date: 2025-12-03T10:53:00+02:00
description: 【USparkle专栏】如果你深怀绝技，爱“搞点研究”，乐于分享也博采众长，我们期待你的加入，让智慧的火花碰撞交织，让知识的传递生生不息！ 当有持续时间短，又比较杂的异步任务时，可以使用ThreadPool，用固定数量的工作线程执行任务，不每次都创建新线程。UE4和UE5的线程池有很大区别，UE4线程池会真的创建很多线程，而UE5主要线程池底层复用了TaskGraph的线程，线程池只是逻辑上的概念。 一、创建线程池 线程池在FEngineLoop::PreInitPreStartupScreen函数中创建。 GThreadPool 类型为FQueuedLowLevelThreadPool，是UE5中的新实现，线程数量由FPlatformMisc::NumberOfWorkerThreadsToSpawn()确定。 GIOThreadPool 类型为FQueuedThreadPool，线程数量由FPlatformMisc::NumberOfIOWorkerThreadsToSpawn()确定，Client为4，Server为2。 GBackgroundPriorityThreadPool 类型为FQueuedThreadPool，Client为2，Server为1。 GLargeThreadPool 类型为FQueuedLowLevelThreadPool，数量由FPlatformMisc::NumberOfCoresIncludingHyperthreads()确定。 二、使用线程池 虽然线程池实现比Runnable复杂，但使用方式也比较简单。 1. Async函数 最常见用法，Async函数可设置EAsyncExecution::ThreadPool参数，指定任务在ThreadPool里执行。 函数内部会创建TAsyncQueuedWork封装Function和Promise，然后使用AddQueuedWork接口把任务加到GThreadPool中。 AddQueuedWork是线程池最重要的接口。 2. AsyncPool函数 与Async类似，但可以指定线程池和Work优先级。 3. 手动调用AddQueuedWork AddQueuedWork函数只需要接受IQueuedWork作为参数，TAsyncQueuedWork只是一个子类，我们可以创建子类，做自定义操作，这样也能指定使用哪个线程池。 比如引擎中Encode LightMap的操作，就使用了FAsyncEncode类： 三、线程池实现 1.类型定义 类型定义可分为线程池，线程池线程，任务。 线程池 FQueuedThreadPool：线程池基类，定义了线程池的接口。 Allocate：创建线程池，类型为FQueuedThreadPoolBase。 Create：创建若干工作线程。 AddQueuedWork：向线程池添加任务。 RetractQueuedWork：撤回任务。 AddQueuedWork和RetractQueuedWork是线程池提供给外部调用的主要接口，注意会在多线程中被调用。 FQueuedThreadPool有多种实现： FQueuedThreadPoolBase 最常用，线程池的基础实现，GIOThreadPool和GBackgroundPriorityThreadPool都会使用。 成员： FThreadPoolPriorityQueue QueuedWork：待处理任务的队列。 TArray<FQueuedThread*> QueuedThreads：等待接收任务的空闲线程。 TArray<FQueuedThread*> AllThreads：所有工作线程。 FCriticalSection* SynchQueue：保护任务队列的CriticalSection，因为任务队列会被多线程修改。 FQueuedLowLevelThreadPool 底层线程使用TaskGraph的ThreadPool，UE5中GThreadPool的默认实现。 FQueuedThreadPoolWrapper FQueuedThreadPoolDynamicWrapper FQueuedThreadPoolTaskGraphWrapper 线程池线程 FQueuedThread：继承自FRunnable，表示线程池中的工作线程。可以想象，它大部分时间都处于idle状态，当有任务来时才工作。 成员： DoWorkEvent：通知线程有任务要执行的Event。 QueuedWork：当前线程正在执行的Work。 Thread：Runnable对应的线程。 函数： Run：主函数，可认为是一个等待、执行任务的循环。 DoWork：由ThreadPool调用，传入一…

如何解决ProtoBuf反序列化中GC高的问题
type: item
date: 2025-12-02T04:26:00+02:00
description: 1）如何解决ProtoBuf反序列化中的GC高的问题 2）如何在编辑器中集成实时查看Mipmap使用层级工具 这是第455篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：有没有比较好的解决ProtoBuf反序列化GC的方案？ A：在Unity项目中，使用ProtoBuf进行反序列化时产生的GC主要来源于两方面：内存分配的临时对象（如字符串、装箱操作）和反射机制的低效调用。以下是针对这些问题的成熟且高效的解决方案。 1. 使用[Preserve]与强制AOT初始化避免反射GC IL2CPP环境下，由于AOT编译限制，ProtoBuf生成代码中的泛型反射方法可能未被提前编译，导致运行时尝试动态调用而崩溃或触发大量GC。为确保所有必要的反射初始化代码被保留： using Google.Protobuf.Reflection; using UnityEngine.Scripting; [Preserve] private void ForceReflectionInitialization() { // 显式调用每个消息类型的ForceReflectionInitialization FileDescriptor.ForceReflectionInitialization<MyMessage1>(); FileDescriptor.ForceReflectionInitialization<MyMessage2>(); // 添加所有用到的消息类型 } 此方法无需调用，仅需存在即可被链接器保留。配合[Preserve]特性防止代码剥离，可有效解决因AOT缺失导致的异常及性能损耗。 2. 避免字符串与值类型装箱，实现0GC解析辅助 参考TMP文本优化思路，可对ProtoBuf解析过程中的输出处理进行定制，减少中间对象分配。例如，在自定义的日志系统或UI更新中直接复用StringBuilder写入，而非通过ToString()创建新字符串。 全局复用StringBuilder用于格式化输出。 对数字字段转字符串时，采用无GC的NumberFormatter.NumberToString(ref char[] buffer, int value)方式，将结果写入预分配字符数组。 自定义IFormatter实现，绕过装箱操作，直接处理基本类型。 3. 使用原生字节访问替代高开销API 对于高频解析场景（如网络同步），考虑绕过完整反序列化流程，直接读取字节流中的关键字段： // 使用CodedInputStream直接读取特定字段 var input = CodedInputStream.CreateInstance(data); while (!input.IsAtEnd) { var tag = input.ReadTag(); switch (tag.FieldNumber) { case 1: int hp = input.ReadInt32(); break; // 只解析必要字段 } } 这种方式跳过对象构建开销，适用于只关心部分数据的轻量级更新。 4. 缓冲池管理Message实例 频繁创建/销毁ProtoBuf对象会加剧GC压力。建议使用对象池缓存常用Message实例： public class MessagePool<T> where T : IMessage, new() { private static readonly Stack<T> _pool = new(); public static T Get() => _pool.Count > 0 ? _pool.Pop() : new T(); public static void Release(T msg) { _pool.Push(msg); } } 结合Clear()重置状态后复用，显著降低内存分配频率。 综上，核心策略是：强制AOT初始化 + 禁止代码剥离 + 复用缓冲区 + 裁剪不必要的反序列化流程。这些方法已在多个上线项目中验证，能有效将ProtoBuf相关GC降至接近零。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=228136d0-985e-4af9-8c83-f84b04834677 From 问答社区 Q：最近在优化贴图内存，请问有没有开源库或者计算方法，可以检测贴图在屏幕上的占比情况？ 比如，一张1024的贴图，如果渲染时一直使用很高层级的Mipmap，就说明其实不需要102…

如何排查优化URP内置Shader冗余
type: item
date: 2025-11-25T04:07:00+02:00
description: 1）如何排查优化URP内置Shader冗余 2）运行时Shader内存下降的原因 这是第454篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From 问答社区 Q1：请教一下Shader冗余应该怎么查，似乎好几个Shader运行时都有两份？ A：资源冗余最常见的原因是AssetBundle没有依赖打包导致的，可以使用UWA的在线AssetBundle检测进行冗余检测先试试。 Q2：测了AssetBundle，确实有冗余，但AssetBundle冗余的Shader和运行时冗余的Shader好像又不一致。实际运行时的冗余都是Hidden/Universal Render Pipeline/xxx。这又是为什么呢？ A：这些是URP的Shader，通常是URP Asset的引用导致的，因为URP Asset会引用这些Shader。而内存中出现两份Shader，说明内存中出现了两个来源路径不一样的URP Asset，通常一份是在PlayerSetting中引用的URP Asset，另外一份可能来自AssetBundle中动态加载的URP Asset。RendererData里面会引用到PostProcessData，PostProcessData就会引用这些Shader，如果代码里面动态加载的AssetBundle里面也有这种资源，也会引用一份Shader进内存，就会造成冗余。 Q3：请问这个怎么处理，直接删去吗？ A：一般只处理内存占用比较大的即可，其他的内存占用比较小，冗余开销也不大。比如Hidden/Universal Render Pipeline/Uberpost，需要删除其中用不到的Keyword来降低占用；又比如Hidden/Universal Render Pipeline/HBAO，看是否确实要用到，用不到就解除引用。 欢迎大家转至社区交流： https://answer.uwa4d.com/question/69245652244ce21ce9ec095c From 问答社区 Q：请问在游戏运行过程中不同时刻截帧后同一个Shader的内存占用为什么不一样？用UWA的资源列表观察完整生命周期曲线后更明显了，全程都在轻微但持续地下降，这是什么原因呢？ A：这是因为，内存分析工具统计到的是在Unity引擎层Native Object处的Shader内存。引擎会在ShaderCreateGPUProgram操作时，将Shader Code信息转化为运行时GPU实际要用到的信息。因此会表现为Shader本体资源内存下降，但系统层Native Heap和GFX内存都会显著上升。 这个现象在UWA DAY 2025的话题中正好有相应的原理讨论和实验，分别为： Unity移动游戏工业级性能优化指南 3.0 《心动小镇》内存优化经验谈 欢迎大家转至社区交流： https://answer.uwa4d.com/question/69245c90244ce21ce9ec095f 无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区，希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。 封面图来源于网络 今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。 UWA官网：www.uwa4d.com UWA社区：community.uwa4d.com UWA学堂：edu.uwa4d.com 官方技术QQ群：793972859

UE5多线程｜FRunnableThread
type: item
date: 2025-11-19T08:27:00+02:00
description: 【USparkle专栏】如果你深怀绝技，爱“搞点研究”，乐于分享也博采众长，我们期待你的加入，让智慧的火花碰撞交织，让知识的传递生生不息！ UE游戏包与编辑器中都有众多线程，多线程可以充分利用CPU多核特性，提升游戏表现，而且现代CPU核数越来越多，游戏多线程就更有必要了。 一、线程类型 线程可分为专用线程和线程池中线程。 专用线程为GameThread，RenderThread，StatsThread等，它们各自都干专门的事情，比如GameThread用于驱动游戏逻辑，RenderThread用于渲染，StatsThread用于干性能分析。在事情干完后会进入阻塞状态，不消耗CPU资源。 线程池线程包括PoolThread和TaskGraphThread，每个线程用于干多种异步任务。游戏中许多任务并发量大，但持续时间短，比如求解动画蓝图，每帧都开几个线程求解，求解完再销毁线程无疑很浪费。另外有很多琐碎的多线程任务，单独为它们开线程也很浪费。因此UE使用了线程池，池中线程会循环利用，不断执行不同的异步任务，当没有任务时也处于阻塞状态。 使用多线程时，UE已对底层平台接口进行了封装，开发者无需关注平台差异，直接使用UE提供的统一接口即可。 常用的多线程方式包括：RunnableThread、ThreadPool 和 TaskGraph。这三者在底层线程的实现机制上有所不同，对外提供的接口种类丰富，部分接口还支持通过参数指定所使用的线程实现方式。 二、FRunnable & FRunnableThread 基本的线程使用方式为FRunnable与FRunnableThread的组合，用于创建专用线程，比如AsyncLoadingThread与渲染线程等。FRunnable负责逻辑，FRunnableThread负责具体线程，线程承载了逻辑，两者一一对应，好处是上层逻辑与底层平台接口分离。 FRunnable FRunnable类本身代表一个抽象的“可运行”对象，只有几个接口，不涉及线程细节，是我们写逻辑的地方，理论上可以在任意线程执行。 接口如下： Init Runnable的初始化，初始化可能成功，可能失败，失败会立即返回，线程结束。 Run执行逻辑主体，初始化成功后执行。 Exit Run中任务执行完后的正常退出接口，执行清理操作。 Stop由其他线程调用，用于中途停止该Runnable以及背后的线程，但具体如何停止要我们自己实现。 GetSingleThreadInterface，当UE强制单线程模式时，返回用于Tick执行的实例，用的不多。 上述接口不用我们调用，对应线程创建好后会自动调用。 示例FAsyncloadingThread： 该类用于处理异步资源加载，会另开一个线程加载资源，继承了FRunnable，内部的Thread变量存储线程。 Init函数没做什么，Run函数如下： 主体是一个while循环，StopTaskCounter是循环退出条件，为Atomic计数器，当未被设置时就不断处理加载，被设置后即退出。 Stop函数如下，会设置StopTaskCounter变量： 创建线程，启动Run逻辑。 只需要下面一行代码即可，详细会在下文介绍： FRunnableThread FRunnableThread是平台线程的抽象，也是基类，与平台相关的线程操作由多个子类完成，包括： FRunnableThreadWin FRunnableThreadUnix FRunnableThreadApple FRunnableThreadAndroid 我们不需要继承和修改这些类，使用即可。 成员变量： FString ThreadName：线程名。 FRunnable* Runnable：对应Runnable。 FEvent* ThreadInitSyncEvent：同步的Event。 EThreadPriority ThreadPriority：线程优先级，UE自己抽象了几个枚举。 接口： Kill：结束线程，UE建议不要用操作系统的Kill接口，强杀线程会导致泄露和死锁，应该调用Runnable的Stop方法。 WaitForCompletion：忙等，直到线程执行完。 Suspend：让线程挂起或继续执行。 SetThreadPriority：设置线程优先级。 FRunnableThreadWin 看下常见的Windows平台子类如何实现。 Windows平台的线程为内核对象，通过HANDLE持有索引，这里的Thread就是底层的线程。 Kill方法内调用了Runnable的Stop，该函数由我们自己实现，然后可选忙等，最后调用操作系统的CloseHandle方法释放线程内核对象。 Windows有TerminateThr…

移动端反射探针格式用什么比较合理
type: item
date: 2025-11-18T04:06:00+02:00
description: 1）移动端反射探针格式用什么比较合理 2）不同平台打包热更容灾问题的解决方案 这是第453篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：移动端反射探针格式用什么比较合理？ A：在移动端使用反射探针时，选择合理的纹理格式是平衡画质与性能的关键。不恰当的格式会显著增加内存占用和带宽消耗，影响帧率和功耗。 一、推荐格式 1. ASTC（Adaptive Scalable Texture Compression） 推荐理由： 这是目前移动平台（尤其是iOS和现代Android设备）上最理想的选择。ASTC具有极高的灵活性，支持从4x4到12x12等多种压缩比率，并且能同时处理RGB、RGBA以及HDR数据。 应用场景： LDR探针：可选用ASTC 6x6或8x8，在保证足够清晰度的同时将体积压缩到最小。 HDR探针：必须使用支持HDR的格式。ASTC 4x4 HDR是最佳选择，它能在较低的内存开销下保留高光等重要细节，非常适合需要真实感反射的场景。 2. ETC2/EAC 推荐理由： 作为OpenGL ES 3.0的标准，ETC2兼容性极佳，几乎所有现代Android设备都支持。对于需要广泛兼容性的项目，它是可靠的备选方案。 应用场景： LDR探针：使用ETC2 RGB。虽然压缩效率略逊于ASTC，但兼容性最好。 注意：ETC2本身不支持原生HDR。如果必须在不支持ASTC HDR的设备上使用HDR探针，通常引擎会回退到未压缩的RGB16F或RGB111110F格式，但这会极大增加内存消耗，应尽量避免。 二、核心优化策略 优先启用ASTC：在Unity的Player Settings中，为iOS和Android分别设置首选的ASTC格式。这能确保在支持的设备上自动使用最优的压缩方案。 谨慎使用HDR：仅对需要捕捉强烈高光（如金属车漆、水面反光）的关键探针开启HDR。大部分环境反射使用LDR的ASTC格式即可满足需求，能大幅降低内存占用。 控制分辨率：根据探针的作用范围和距离玩家的远近来调整分辨率。远离玩家或覆盖大范围区域的探针可使用64x64甚至32x32；而用于特写或关键物体（如角色）附近的探针才使用128x128或256x256。分辨率是影响内存和渲染时间的最主要因素。 利用盒体投影（Box Projection）：对于室内或空间受限的环境，启用盒体投影能让一个探针更准确地模拟出角落和墙壁的反射，从而减少所需探针的数量，间接优化了整体性能。 综上所述，ASTC是移动端反射探针的首选格式，特别是结合其HDR特性，能在性能和视觉质量之间取得最佳平衡。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=c97db263-6273-40bd-8d91-b9737aa44a16 From UWA AI 问答 Q：目前，不同平台的热更打包工作分散在不同的机器上进行。考虑到容灾需求，如果机器挂了或者硬盘挂了，重新打包可能导致玩家需要再次下载几GB的热更新资源。除了定期备份整个工程或Library文件夹之外，是否有更好的应对方案？另外，有没有什么方法能够确保不同机器、不同工程环境下，可以打出一致的AssetBundle包（Meta文件已经受版本管理控制）？ A：为确保多台机器在不同环境或地理位置下能打出一致的AssetBundle（AB包），并有效应对机器或硬盘故障导致的热更风险，需从构建一致性、缓存管理和容灾备份三个层面进行系统性设计。 1. 确保构建一致性 统一构建环境：所有打包机器必须使用完全相同的Unity版本、操作系统补丁、JDK/Python等依赖环境。建议通过Docker镜像或虚拟机模板固化环境，避免因环境差异导致GUID或序列化数据不一致。 共享与锁定Library：Library文件夹中的ScriptAssemblies、BeeTreeCache等缓存直接影响AB生成。应将关键缓存目录设为只读，并通过网络存储（如NFS）或CI/CD流水线统一分发，确保所有打包机基于相同中间产物构建。 禁用随机因子：关闭Random Seed、时间戳嵌入等可能导致输出差异的功能。若使用Addressables，确保Build Script和Provider配置完全一致。 2. 构建缓存与增量复用 集中式构建缓存服务：采用Unity Cloud Build Cache或自建Artifactory/Nexus服务器，存储每次成功构建的AB包及其元数据（Hash、清单）。当某台打包机故障…

为何iPad Pro上设置目标帧率为90时无法生效
type: item
date: 2025-11-11T04:22:00+02:00
description: 1）为何iPad Pro上设置目标帧率为90时无法生效 2）为什么在Dedicated Server发布的程序中内存数值异常 这是第452篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From 问答社区 Q1：为什么iPad Pro上设置目标帧率为90时无法生效，仍然以120帧运行？ 在使用Application.targetFrameRate设置目标帧率为90时，在iPad Pro M2芯片上无法生效，目标帧率变为120，在iPhone 14 Pro上测试则能够以80的帧率运行。 在和平精英上用PerfDog采集，可以设置为90的选项，实际以80的帧率在跑，但在Demo中测试无法达到同样的效果。 A：使用UWA AI问答的功能尝试解读这个问题。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=f3ea7cc1-879f-4f94-aeb5-b29860099ae2 该问题通常由垂直同步（VSync）与帧率控制机制的交互导致，尤其是在高刷新率设备如iPad Pro上。 核心原因分析 在Unity引擎中，Application.targetFrameRate是控制移动平台帧率的主要方式。然而，当垂直同步（VSync）开启时，它会优先于targetFrameRate生效。系统会强制将应用的帧率锁定到屏幕刷新率的整数分之一（如120Hz、60Hz、40Hz等），以避免画面撕裂。因此，即使设置了targetFrameRate=90，系统也无法稳定输出非刷新率整除的帧率（90不是120的整除因子），最终会退回到设备支持的最高帧率（120fps）或下一个可行的分频值。 此外，部分iOS设备（尤其是支持ProMotion技术的iPad Pro）具有动态刷新率调节能力，其底层图形驱动可能进一步影响帧率锁定行为，使得targetFrameRate的控制不够精确。 解决方案 1. 关闭VSync并依赖 targetFrameRate 确保在项目设置或运行时关闭垂直同步： QualitySettings.vSyncCount = 0; // 关闭VSync Application.targetFrameRate = 90; // 设置目标帧率为90 这是实现非标准帧率（如90fps）最直接的方法。关闭VSync后，targetFrameRate将正常生效。 2. 使用引擎级帧平滑（Frame Pacing） 在使用虚幻引擎时，可通过CVar精确控制帧率。对于目标帧率90，在配置文件中设置： r.setframepace 90 此方法直接对接设备刷新周期，能更可靠地在支持的设备上实现90fps。 3. 验证设备与系统支持 确认当前iPad Pro型号及iOS系统版本是否完整支持90Hz的输出模式。某些情况下，操作系统或驱动可能限制了非标准刷新率的使用。 4. 监控实际帧率 使用UWA GOT Online报告中的“FPS均值”和“>40ms帧数占比”指标，结合真机性能测试，验证帧率是否真正稳定在90fps，并评估GPU负载与功耗表现。 综上，欲在iPad Pro上稳定运行90fps，关键在于关闭VSync并通过Application.targetFrameRate明确指定目标帧率，同时确保引擎和设备层面的支持。 Q2：如果已经关闭垂直同步，还可能是什么原因？ A：即使已关闭垂直同步（VSync），在iPad Pro上设置Application.targetFrameRate = 90仍可能无法生效，原因如下： 1. 动态刷新率机制（ProMotion）的底层限制 iPad Pro搭载的ProMotion技术允许屏幕刷新率在120Hz、60Hz、40Hz、30Hz等特定档位间动态切换。系统倾向于选择最接近目标帧率的标准分频值。由于90不是120的整除因子，系统可能无法为90fps创建稳定的刷新周期，最终退回到默认的120Hz模式。 2. Unity引擎的帧时间计算与平台适配问题 根据Unity文档，移动平台上的targetFrameRate实际效果受限于屏幕刷新率的整数分频。即使VSync关闭，Unity的帧调度器仍可能因无法精确匹配90Hz的间隔而出现抖动或回落至120Hz。此外，若未将targetFrameRate设置为屏幕刷新率的约数（如120 → 60, 40, 30），系统可能忽略该设置。 3. 后台进程或系统策略干预 iOS系统可能会因性能管理、温控或后台任务（如应用更新、索引服务）临时提升设备性能至最大刷…