UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技
type: channel
link: https://blog.uwa4d.com/
description: UWA博客，UWA旗下官方博客。针对游戏及VR应用性能优化等内容记录、交流，以及案例分享。博客主要分为：厚积薄发、万象更新、博观约取、充电一刻、博物纳新等几个模块。
items: GPM 2.0功能尝新｜AI识图精准捕获材质丢失，全链路护航游戏品质！
items: UE5多线程｜FRunnableThread
items: 移动端反射探针格式用什么比较合理
items: Gears 实测室：第六期・《黑色沙漠》手游如何精准决策性能优化
items: 为何iPad Pro上设置目标帧率为90时无法生效
items: 游戏AI行为决策——MLP（多层感知机/人工神经网络）
items: 导致Resources文件夹的资源在Android打包后丢失的原因
items: Gears 实测室：第五期・模块化思维助力《永恒灵魂》性能分析
items: 为什么Android游戏画面在30帧运行时有抖动现象
items: UWA GPM 2.0 核心功能全景指南｜重塑游戏性能主动管控能力

GPM 2.0功能尝新｜AI识图精准捕获材质丢失，全链路护航游戏品质！
type: item
date: 2025-11-20T04:34:00+02:00
description: 游戏上线后，UI缺失、模型部件丢失等美术材质问题，常因机型适配复杂、触发场景隐蔽，成为人工测试难以触及的“隐形痛点”。这些看似微小的故障，不仅会破坏玩家沉浸体验，更可能引发投诉与流失，等收到反馈时已造成不可逆的口碑损耗 — 这正是游戏研发团队普遍面临的棘手难题。 现在，UWA GPM 2.0全新AI识图功能重磅登场！依托GPM 2.0原生的性能无损截帧技术，结合UWA自主研发的AI识别算法，无需额外增加游戏性能开销，即可从海量玩家端截帧数据中，自动筛选出材质丢失、UI缺失、模型异常等美术问题，将“隐形故障”精准锁定，助力研发团队从“玩家投诉后救火”全面升级为“问题萌芽时解决”。 三大核心优势，完胜人工测试 全域覆盖无死角：突破人工测试在机型、场景、时长上的局限，借助GPM 2.0全量玩家设备覆盖能力，即便发生率仅0.01%的低频问题，也能被精准捕获，不留排查盲区。 精准识别效率翻倍：AI算法直接锁定材质丢失关键帧，搭配GPM 2.0原生的多维度筛选功能，无需研发人员逐帧排查海量数据，从问题发现到定位全程自动化，大幅缩短响应周期。 无损体验不打扰：延续GPM 2.0性能无损截帧技术优势，所有识别分析均在私有云服务器端完成，不占用游戏主线程资源，既保证分析精准高效，又完全不影响玩家正常游戏体验。 全链路性能保障，不止于美术问题排查 GPM 2.0作为全方位性能监测平台，AI识图功能并非孤立存在，而是与核心功能形成协同闭环，提供从问题发现到根源解决的全流程支持： 异常筛查体系：AI锁定美术问题后，可联动崩溃分析、ANR分析等功能，排查是否伴随性能异常，精准定位问题根源。 硬件分析能力：结合硬件性能分析、智能设备分档功能，快速锁定问题高发机型/芯片，为针对性适配优化提供数据支撑。 数据对比与统计：通过版本/场景对比功能，直观验证修复效果，确保问题彻底解决，避免二次复发。 真实案例佐证，小问题也能快速锁定 某卡牌游戏通过GPM 2.0 AI识图功能，短期内即精准捕获3类典型美术问题： 大厅场景UI丢失（华为 CDYAN00 机型） 牌局场景UI缺失（荣耀 ALIAN00 机型） 树木模型的材质丢失（小米23113RKC6C机型） 这些低频问题若依赖人工测试极易遗漏，而AI识图功能快速完成筛选定位，为研发团队争取了黄金修复时间，有效避免了问题扩散与玩家流失。 限时招募体验官，UWA全程协助落地 目前，GPM 2.0 AI识图功能正处于内测阶段，现面向所有GPM 2.0老用户及感兴趣的游戏研发团队，限时招募体验官！ 体验期间，UWA技术团队将提供一站式全程支持：协助对接截帧数据、完成AI识别分析、联动其他核心功能定位问题根源、输出优化方案，让你零成本体验高效美术问题排查与全链路性能优化服务。 报名方式 邮件报名：发送项目名称 + 联系人 + 联系方式至sales@uwa4d.com 微信报名：添加微信号17502188376（备注“AI识图体验”） 抢先解锁AI赋能的美术问题排查新方式，玩转GPM 2.0全链路性能保障能力，让游戏品质再上新台阶，从根源筑牢玩家体验与项目口碑！ 关于GPM 2.0 UWA GPM 2.0是专为上线及测试阶段游戏项目打造的高性能监测平台。它不仅能深度捕捉宏观性能数据，更创新采用性能无损截帧技术，在不影响玩家体验的前提下，助力开发者全面掌握玩家端运行关键细节，从多维度优化游戏性能，实现从“玩家投诉后救火” 到 “问题发生前预警” 的核心转变。 GPM 2.0新功能 集锦 《UWA GPM 2.0 核心功能全景指南｜重塑游戏性能主动管控能力》 《UWA GPM 2.0 崩溃上报功能全面升级｜全场景覆盖+免费开放，让崩溃排查不再卡壳》 《大R流失、问题难复现？GPM 2.0「指标 - Session直连」功能，让异常定位效率翻倍！》 《从 “被动救火” 到 “主动掌控”：GPM 2.0 如何重塑游戏性能竞争力？》 《GPM 2.0 告警功能：游戏性能的智能守护者》 《无限接近真相｜GPM 2.0 功能上新》 《崩溃现场全回溯｜GPM 2.0「崩溃上报分析」上线，终结“无法复现”的噩梦》 《GPM 2.0 全新发布「卡顿帧堆栈」功能｜精准高效定位游戏玩家端性能》 《深入解析「卡顿帧堆栈」》 《解锁GPM 2.0「卡顿帧堆栈」｜代码示例与实战分析》 《如何精准打点解决卡牌、SLG、开放大世界、放置类游戏卡顿难题》 《不妥协每一毫秒的性能 不浪费每一字节的流量》 《GPM 2.0 重新定义性能监测与优化｜从未知到已知，从被动到主动》 GPM 2.0案例精讲 集锦 《我们的目标是不耗电、不发烫、不闪退》 《冒险闯关类玩家关注的四大体验》 《玩家端性能数据 一手掌握》 《造成设备功耗高的罪魁祸首》 《海外市场设备适配性优化实战…

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、清单）。当某台打包机故障…

Gears 实测室：第六期・《黑色沙漠》手游如何精准决策性能优化
type: item
date: 2025-11-12T04:15:00+02:00
description: MMO游戏画面精美、系统复杂，其手游版本的性能优化是一项极其复杂且系统性的工程。在进行性能优化时，仅凭直觉调整，常会耗费大量时间在错误的方向上，无法真正解决卡顿、发热与功耗问题。 合适的性能分析工具，正是帮助团队走出这种“经验迷宫”的关键。它能够将性能表现数据化、可视化，让优化决策摆脱猜测，回归事实。 本文将借助《黑色沙漠》手游的新手流程实测案例，展示如何通过Gears性能分析工具，实现从“经验猜测”到“数据决策”的优化过程。 工具声明 UWA Gears的性能数据采集与评测，旨在展示工具功能并为研发团队提供优化参考。相关数据结论并不构成对游戏品质的整体评价。 测试环境 测试设备：Lenovo Legion Duel（高通骁龙865） 画质配置：高画质 测试关卡：新手20分钟 性能总览：快速定位玩家感知最强的问题 Gears提供了覆盖CPU、GPU、内存与功耗的全面性能参数，帮助开发者一目了然地掌握游戏整体运行状况。面对海量数据，精准的优化始于聚焦关键问题。在本测试中，我们首先锁定以下几个与玩家体验最息息相关的核心指标作为切入点： FPS 测试前半段帧率平稳，后半段出现明显波动，部分场景持续在50帧左右。 卡顿 卡顿集中在场景切换时，单帧耗时不高，说明无严重逻辑卡顿。 温度 GPU芯片温度显著高于CPU，部分场景温度急剧上升。 耗电 前期耗电较低，13分钟后耗电速度大幅上升。 内存 启动时内存占用达1.8GB，之后迅速回落并保持平稳。 初步结论：游戏的发热情况亟需排查，测试后半段的帧率波动和异常耗电情况也需要重点关注。 深入分析：定位性能瓶颈根源 在明确优化方向后，我们借助Gears提供的深度剖析能力，将宏观的性能指标进行关联分析。这一过程如同将分散的线索串联成完整的证据链条，使我们能够穿透表面现象，精准锁定引发性能瓶颈的根本原因。 1. 发热分析：GPU是主要热源 测试过程中GPU温度持续高于CPU温度，部分场景温度大幅上涨，峰值达到80.2°C，说明项目可能存在显著的GPU压力。 进一步查看GPU Clocks曲线和GPU带宽曲线，发现其走势与GPU芯片温度基本一致。这表明GPU的高负载是设备发热的主要原因。更关键的是，Read Total显著高于Write Total，其中读纹理带宽（Texture Read）又显著高于其他子参数。这一发现为后续优化指明了明确方向。 2. 帧率波动：发热降频是诱因 测试前半段帧率平稳，但后半段出现明显帧率波动，符合发热降频的现象。在CPU频率曲线中，也可以明显看到测试后半段CPU发生了降频。 在隐藏GPU温度曲线后可以观察到，CPU在测试过程中同样存在发热，其温度最高达到71.18°C。鉴于GPU是主要热源，且移动设备中芯片距离极近，热扩散效应显著，GPU压力实为整个系统发热降频的根源。因此，优化GPU负载将是解决发热问题的关键，并有望同时改善CPU的温控表现。 3. 耗电分析：与降频同步加剧 测试前半段耗电较低，13分钟左右耗电速度大幅增加，该时间点和设备降频时间基本一致。这表明系统在高温下为维持运行而增加了功耗，开发者可以调整应用的运行策略，减少不必要的耗电，提供更好的用户体验。 Gears的核心价值：从猜测到验证的完整闭环 通过本次《黑色沙漠》的实测分析，我们深刻体会到Gears在游戏性能优化中的独特价值： 无侵入分析：无需代码嵌入，不改变游戏结构，保障数据真实可靠； 全面性能洞察：覆盖FPS、温度、功耗、内存、芯片负载等关键指标； 精准问题定位：通过帧级数据快速定位瓶颈，避免盲目试错； 迭代验证支持：为优化方案提供可靠的数据反馈，确保每次优化都产生实际效果。 在性能优化这场没有硝烟的战场上，数据是最可靠的武器。通过《黑色沙漠》手游的深度实测，我们见证了Gears如何将性能优化从“经验驱动”升级为“数据驱动” —— 不再依赖猜测，而是基于详实的性能指标做出精准判断。 正是基于这样的精准判断能力，Gears能够为各类游戏项目提供从发现问题、定位根源到验证效果的全流程支持，无论是尚在研发阶段的项目，还是已上线的游戏，都能借助这一完整解决方案为长期稳定运营保驾护航。 数据说明：本文数据基于《黑色沙漠》公开测试版本，测试环境为实验室可控条件，结果仅反映单台设备在测试场景下的性能表现，仅供游戏研发团队优化参考。 无论您的团队需要优化跨设备流畅度，还是细化场景级性能表现，UWA Gears都能提供“数据驱动”的优化依据，免费使用门槛低，助力轻量游戏在全平台实现“体验均衡”。 若您希望针对自家游戏进行类似性能测试，或了解UWA Gears的更多功能细节，可点击阅读原文获得产品下载链接与使用指南。 更多讨论可以前往UWA社区：https://answer.uwa4d.com；或者联系UWA微信号：…

为何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系统可能会因性能管理、温控或后台任务（如应用更新、索引服务）临时提升设备性能至最大刷…

游戏AI行为决策——MLP（多层感知机/人工神经网络）
type: item
date: 2025-11-06T04:22:00+02:00
description: 【USparkle专栏】如果你深怀绝技，爱“搞点研究”，乐于分享也博采众长，我们期待你的加入，让智慧的火花碰撞交织，让知识的传递生生不息！ 你一定听说过神经网络的大名，你有想过将它用于游戏AI的行为决策上吗？其实在（2010年发布的）《最高指挥官2》中就有应用了，今天请允许我班门弄斧一番，与大家一同用C# 实现最经典的神经网络 —— 多层感知机（Multilayer Perceptron，简称MLP）。 一、前言 神经网络或者深度学习，总给人一种「量子力学」的感觉，总感觉它神秘无比，又无所不能。我未学习神经网络之前，总以为它是某种能够修改自身代码的代码，否则怎么能做到从「不会」变成「会」的呢？但在亲自学习后才会明白，它并没有做到这种地步，但依旧十分神奇。多层感知机是最基础的神经网络，很多其它类别的神经网络都是在这之上的变形。可以说，学会它是迈入深度学习的第一步。 多层感知机虽说经典，但并不过时。提到神经网络，大多数人脑海里想到的大概也就是类似这样的图片： 这就是一张典型的多层感知机结构图，看着好像很复杂，但实现它所需要用到的数学原理和编程知识都不难，早年间，研究神经网络的学者们还用C语言实现呢！ 二、什么是多层感知机 现在进入正题，我们先来简单讲讲MLP的原理（如果你对此十分熟悉，只是对代码实现感兴趣，那可以跳过这部分）。 既然叫「多层感知机」，那有单个的感知机吗？那是自然，单个感知机的结构十分简单： 它其实就是个算式（为方便理解，我将其分成两部分）： 将传入感知机的多个输入x，与对应的权重w相乘（输入的数量与权重的数量是一样的，且数量是任意的，本例中用了3个），再加上偏置b就可以得出一个计算值sum。再将这个计算值传入一个函数f(x)就可得到感知机的最终输出out。 相信你肯定能理解，只是可能对f(x)函数有些好奇，它具体内容是什么呢？这个函数也被称为「激活函数」，为什么叫这个名字？这就得提感知机的另一个名字 —— 人工神经元。其实感知机正是受神经元结构启发而被提出来的： 神经元会通过树突接受输入信号并汇总，而神经元对于各个输入刺激的响应强度并不相同，所以我们给各个输入设置了相应权重来模拟这个现象。之后，将处理的信息通过轴突传给末梢（终端）。但实际上，只有汇总的信号强度大于一定程度时神经元才会向末梢传递信号，而模拟这个现象的就是「激活函数」。 那偏置b又是模拟什么的？其实它是从数学角度考虑的、方便调整输入加权和的变量值而已。 既然感知机被称为「人工神经元」，那多层感知机岂不就是「人工神经网络」？一点没错，我们现在所说的「神经网络」，基本都是指人工神经网络，而不是真正的、生物的神经网络。而「神经网络」起初就是指多层感知机，只不过现在种类多了，定义也变宽泛了。 结合我们对单个感知机的认识，再看看多层感知机： 但这里的单个感知机（后面用「神经元」来代称）怎么输出了多个值（看标蓝色的那部分）？这种结构图可能会误导某些人，我做个解释，这里的每一条线并不是输出，可以看到它是有箭头的，每条线表示它所指向的那个神经元的一个权重。加上箭头是为了表示数据传递的方向。 不难看出，它就是将多个感知机以层为单位进行了组合，每层都有任意数量（每层的数量可以不同）的感知机，并将一层感知机的输出作为下一层的输入，依次套娃下去。像图中，下一层神经元的权重数量 = 上一层的神经元数量，称为全连接，是神经网络中常见的连接方式，本文也只考虑这种连接方式。 这里的「输入层」其实就是输入的数据（是的，这一层不是神经元），类似之前的x0、x1、x2；「输出层」就是用于输出的神经元所组成的层，有了多个感知机，我们也可以得到多个输出；夹在「输入层」与「输出层」之间的就叫「隐藏层」，因为在实际使用神经网络时，就只是输入一组数值作为「输入层」，再看看「输出层」得到的结果，并不关心中间的运算。 我们常说的「深度学习」里的「深度」指的就是神经网络中「隐藏层」的层数（只不过现在这个词有点被炒作了），当一个神经网络的隐藏层超过3层时，它就是「深度神经网络」。 通过改变神经网络的结构或者调节神经网络的权重和偏置，我们可以用神经网络近似任何的函数、甚至是一些摸不着头脑的规律。 比如影响小明今天玩不玩网游的因素有：今日作业量、心情、本月剩余流量、今天是星期几，但我们并不知道这些因素与小明玩不玩的具体数学关系，只能大概地推断：今天小明作业多，不会玩游戏；又或者今天是星期六，虽然作业还有很多，但他还是会玩游戏……可一旦知道具体数学关系，我们就可以通过计算准确预测小明是否会玩游戏，就像我们知道了牛顿力学公式，就可以根据物体的质量和被射出的力来计算它的运动轨迹一样。 所以我们所关心的、实际所使用的都是这种已经设置好正确权重和偏置的神经网络，像在与GPT聊天时怕「污染数据库」这类事就不用操心了。 要如…

导致Resources文件夹的资源在Android打包后丢失的原因
type: item
date: 2025-11-05T04:42:00+02:00
description: 1）导致Resources文件夹的资源在Android打包后丢失的原因 2）GPU Culled Primitive中的xyz三平面剔除与视锥体剔除有什么区别 3）按照不升级Unity引擎小改动快速适配安卓16KB页面要求操作后还是闪退 这是第451篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q：请问Resources文件夹的资源在Android打包后丢失是什么导致的呢？有resources.load显式调用的。 A：Resources文件夹中的资源在Android打包后丢失，尽管有Resources.Load显式调用，通常并非资源未被打包进APK，而是由以下几种原因导致加载失败或资源无法访问： 1. 路径与大小写问题 Resources.Load的路径是不区分大小写的，但某些Android设备（尤其是定制ROM）的文件系统对路径敏感。如果代码中指定的路径与实际文件夹/文件名的大小写不完全一致，可能在部分设备上加载失败。确保路径字符串与Resources文件夹内的资源命名（包括嵌套文件夹）保持一致。 此外，路径应使用正斜杠“/”，且不包含“.asset”等扩展名。 2. 构建过程中资源被剥离或冲突 同名资源冲突：若项目中存在多个Resources文件夹，并且包含同名但不同内容的资源，Unity在构建时行为不确定，可能导致错误的资源被打包或覆盖。 Addressables或AssetBundle冲突：如果同一资源同时被标记为Addressable或打包进AssetBundle，又存在于Resources文件夹，可能会因构建流程混乱导致资源引用异常。建议避免资源重复管理。 3. 热更新或补丁机制干扰 使用Application Patching或自定义热更方案时，若处理不当可能导致StreamingAssets目录下原始资源被替换或删除。虽然Resources资源通常打包在主APK内，但在某些增量更新逻辑中，如果误操作了内部文件结构，也可能影响资源读取。 4. 安装路径变化（特定厂商手机） 部分国产手机（如华为、荣耀）将应用安装到SD卡时，路径中可能出现特殊字符（如 -），若项目中有自定义资源加载逻辑依赖路径拼接，未正确转义可能导致文件打开失败。虽然Resources.Load本身不受此影响，但如果涉及从外部加载补充资源并动态注册，则需注意。 5. 资源未实际打入包体 虽然Resources文件夹下的资源默认会被打包，但以下情况可能导致例外： 构建过程中出现异常中断，导致资源未完整写入。 使用了条件编译或脚本化构建流程，意外排除了Resources文件夹。 可通过解压APK文件（位于AndroidStudioProject/app/build/outputs/apk/或Unity导出目录），检查assets/bin/Data/resources.assets是否存在且包含预期资源，以确认资源是否成功打包。 排查建议 使用UWA GOT Online报告中的Resources.Load调用详情页，查看该资源的加载次数、耗时及是否返回null。 在真机运行时添加日志，捕获Resources.Load返回结果，确认是否为空。 检查目标设备的存储路径和安装方式，排除厂商ROM特殊行为影响。 清理构建环境，重新执行完整构建流程，避免增量构建残留问题。 综上，最可能的原因是路径问题或构建过程中的资源冲突，建议优先验证资源是否存在以及加载路径准确性。 分享链接： https://www.uwa4d.com/main/uwa-shared.html?shareId=88f1787d-7dc5-4d8a-91c2-09dc8d9c2258 From UWA AI 问答 Q：报告中的GPU Culled Primitive中的XY平面和Z平面剔除，和视锥体剔除是一样的吗？ A：GPU Culled Primitive中的剔除机制与视锥体剔除密切相关，但“XY平面和Z平面剔除”这一表述并不准确，实际并不存在独立的“XY平面”或“Z平面”剔除方式。通常所说的图元剔除主要指视锥体剔除（Frustum Culling），它是一种基于摄像机视锥空间的裁剪技术，判断物体是否位于可视范围内。 在图形渲染流程中，图元（如三角形）经过顶点着色器处理后，会进行一系列裁剪操作。其中，被裁剪掉的图元数量（culled_primitives）反映的是那些经过顶点计算后，最终因不在摄像机视野内而未被光栅化的图元。这部分图元的产生，主要受视锥体剔除机制影响 —— 即只有处于视锥内…

Gears 实测室：第五期・模块化思维助力《永恒灵魂》性能分析
type: item
date: 2025-10-30T08:37:00+02:00
description: 在游戏性能优化的过程中，游戏内各模块在设计与功能上的差异性，决定了其性能优化方向也需各有侧重。因此，模块化的性能分析方法显得至关重要 —— 它指引我们穿透宏观数据的迷雾，直指问题核心，从而制定出极具针对性的优化策略。 本文以《永恒灵魂》为例，展示如何通过Gears对项目模块化的性能进行分析评估。 工具声明 UWA Gears的性能数据采集与评测，旨在展示工具功能并为研发团队提供优化参考。相关数据结论并不构成对游戏品质的整体评价。 测试环境 测试设备：Lenovo Legion Duel（高通骁龙865） 画质配置：高画质 测试关卡：战斗、UI、剧情演出 性能总览 1. 战斗场景性能分析 战斗作为游戏的核心玩法，其性能表现直接影响玩家的操作体验和游戏沉浸感。以这份通过Gears采集的战斗场景连续测试数据为例，我们可以从多个维度深入剖析战斗场景的性能表现。 FPS 战斗过程中FPS稳定，卡顿仅集中出现在战斗场景切换的瞬间。 CPU 战斗过程中CPU耗时平稳，仅在场景切换时出现约1秒左右卡顿峰值，由于配合了加载动画过渡，玩家感知相对有限。 GPU 战斗场景中GPU Clocks在258M/s，GPU带宽约为4.73GB/s，均处于安全水平。 内存 整个测试过程中内存占用保持平稳，没有发现内存泄漏趋势。 工具价值：Gears通过多维度的性能数据采集与分析，准确呈现战斗核心阶段的性能表现。帮助开发团队快速确定战斗场景切换时存在的优化空间，为异步加载和资源预加载策略的制定提供了可靠的数据支撑。 2. UI模块性能分析 UI模块作为玩家接触最频繁的部分，其响应速度直接影响玩家的第一印象和日常体验。Gears的精细化监测能力为UI性能优化提供了有力支持。 这份UI遍历的Gears数据显示，较多UI卡顿耗时达到400ms，个别甚至超过700ms，明显超出玩家的感知阈值。 同时，发现测试过程中内存呈现上涨趋势，部分UI场景进入后内存明显上升但离开后没有相应下降，存在潜在的内存泄漏风险。 工具价值：Gears凭借其精准的性能数据采集能力，识别出UI模块的卡顿问题和内存泄漏趋势，为UI资源生命周期管理和加载逻辑优化提供了明确的改进方向。 3. 剧情演出性能分析 剧情演出的性能压力相对可控，但也需要关注卡顿和帧率波动情况。 通过Gears测试连续播放剧情，确认剧情演出过程中帧率稳定维持在30帧，GPU Clocks保持在较低水平，整体性能表现良好。 工具价值：Gears的全面性能评估帮助团队快速验证了剧情演出模块的性能表现，使得团队能够将优化资源合理分配到其他更需要关注的模块，有效提升了整体优化效率。 Gears对模块化优化的核心价值 通过《永恒灵魂》的完整分析案例，我们可以看到UWA Gears在性能优化流程中带来的核心价值： 精准的场景化瓶颈定位：Gears提供针对不同游戏模块的定制化分析视角，让开发团队能够基于真实数据快速定位各个场景下的性能瓶颈，避免依赖经验猜测导致的优化方向偏差。 数据驱动的优化决策支持：通过CPU、GPU、内存等多维度数据的关联分析，为优化决策提供可靠的数据支撑，确保每一次优化都能带来实质性的体验提升。 无侵入式的全面数据采集：无需修改项目代码即可完成多维度的性能数据采集，大幅降低测试复杂度，特别适合在开发各阶段快速进行性能检查，提升开发效率。 数据说明：本文数据基于《永恒灵魂》公开测试版本，测试环境为实验室可控条件，结果仅反映单台设备在测试场景下的性能表现，仅供游戏研发团队优化参考。 无论您的团队需要优化跨设备流畅度，还是细化场景级性能表现，UWA Gears都能提供“数据驱动”的优化依据，免费使用门槛低，助力轻量游戏在全平台实现“体验均衡”。 若您希望针对自家游戏进行类似性能测试，或了解UWA Gears的更多功能细节，可点击阅读原文获得产品下载链接与使用指南。 更多讨论可以前往UWA社区：https://answer.uwa4d.com；或者联系UWA微信号：17502188376；QQ群：793972859。 相关推荐 《UWA Gears 全攻略：从功能到应用场景，助你高效优化游戏性能》

为什么Android游戏画面在30帧运行时有抖动现象
type: item
date: 2025-10-28T05:10:00+02:00
description: 1）为什么Android游戏画面在30帧运行时有抖动现象 2）团结引擎VS Skinning开启ENABLE_VS_SKINNING_MORE_BONES后，性能反而下降 这是第450篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。 UWA社区主页：community.uwa4d.com UWA QQ群：793972859 From UWA AI 问答 Q1：Android平台下，游戏以30帧运行时，即便整体性能稳定，仍普遍存在画面抖动现象，想探讨一下这可能是由于什么原因造成的？ A：画面抖动（Jitter）是Android平台30帧游戏中常见但易被忽视的问题，即便整体FPS稳定，仍可能因以下原因导致视觉上的不流畅或抖动感： 1. 帧生成时间不均匀（Frame Pacing问题） 这是最核心的原因。即使平均帧率为30FPS，若帧的生成间隔不均匀（如一帧耗时28ms，下一帧耗时38ms），会导致视觉上出现“微卡顿”或“抖动”。Android设备尤其在高刷新率屏幕（如90Hz、120Hz）下，若未正确配置帧同步策略，GPU与显示子系统之间的帧提交节奏失配，极易引发此问题。 解决方案： 确保关闭Optimized Frame Pacing（部分模拟器和低端设备存在兼容性问题，实测可缓解抖动）。 使用Choreographer回调来对齐VSync信号，确保帧更新时机精准。 在Unity中，避免仅依赖Application.targetFrameRate=30，因其在动态刷新率设备上可能导致帧率倍数下降（如从30→15）。 可结合定时重设帧率策略： IEnumerator SetFrameRatePeriodically() { while (true) { yield return new WaitForSeconds(10); Application.targetFrameRate = 31; yield return new WaitForSeconds(0.1f); Application.targetFrameRate = 30; } } 2. GPU与CPU工作负载波动引起帧时间波动 即使平均性能达标，若每帧CPU或GPU耗时波动大（如某些帧CPU耗时接近33ms，其他帧仅15ms），会造成帧间隔不一致，表现为抖动。 排查建议： 使用UWA GOT Online的CPU每帧耗时曲线、>40ms帧数占比指标，分析是否存在高波动性。 检查是否存在偶发性任务（如GC、资源加载、逻辑计算集中爆发），导致单帧骤增。 3. 渲染管线与垂直同步机制冲突 Android设备厂商常自定义显示策略，部分机型在非原生刷新率（如60Hz设备跑30Hz）时，系统VSync调度可能出现偏差，导致帧呈现时间错位。 优化方向： 避免频繁切换目标帧率，保持帧率恒定。 在支持的设备上尝试使用SurfaceFlinger相关调试工具观察实际显示帧时序。 若使用自定义渲染管线，检查后处理、阴影等异步操作是否引入延迟。 4. 输入与渲染不同步 触摸输入更新频率（通常60Hz或更高）与30Hz渲染不同步，可能导致操作反馈延迟感叠加视觉抖动。 改进措施： 尽量将关键UI更新与渲染帧对齐。 对高频输入做插值或预测处理，提升交互平滑度。 综上，画面抖动多源于帧间时间不一致性而非平均帧率不足。建议优先通过UWA性能报告中的Jank均值、>40ms帧数占比及CPU每帧耗时曲线进行量化分析，并针对性优化帧生成节奏与负载均衡。 Q2：有什么解决方案？ A：针对Android平台30帧下画面抖动问题，可采取以下系统性解决方案： 1. 精准控制帧率同步（核心措施） 关闭Optimized Frame Pacing：该功能在部分设备（如MuMu模拟器）存在兼容性问题，易导致帧提交延迟。在Player Settings中禁用此选项可显著改善抖动。 使用Choreographer对齐VSync：通过Android原生API确保每帧更新与系统刷新信号同步，避免因调度偏差导致的帧间隔不均。 周期性重设目标帧率：应对动态刷新率设备（如120Hz降为60Hz时30帧变15帧），可定时重置targetFrameRate以强制系统重新计算： IEnumerator SetFrameRate() { while (true) { yield return new WaitForSeconds(10); Application.targetFrameRate = 31; yield return new WaitForSeconds(0.1f); Application.targetFrameRate = 30; } } 2. 优化…

UWA GPM 2.0 核心功能全景指南｜重塑游戏性能主动管控能力
type: item
date: 2025-10-27T04:22:00+02:00
description: UWA GPM 2.0是一款专为已上线或测试阶段的游戏项目打造的高效性能监测平台。它不仅能深入捕捉宏观性能数据，更创新采用几乎性能无损的截帧技术，在不影响玩家体验的前提下，助力开发者全面掌握玩家端运行关键细节，从多维度优化游戏性能，实现从“玩家投诉后救火”到“问题发生前预警”的核心转变。 作为游戏团队的性能护航利器，以下内容将全景呈现GPM 2.0的核心功能模块，帮助新老用户快速定位需求、解锁高效性能优化方案。 一、核心监控与分析 宏观性能实时监控：分钟级监控游戏FPS、内存、崩溃、卡顿等核心指标，支持版本、场景、硬件分档等多维度数据聚合与对比分析。 实时数据追踪：聚焦最近30分钟活跃设备数、崩溃率等关键数据，统计同期问题类型，呈现24小时问题趋势及当日TOP崩溃问题，实现动态预警。 数据总览可视化：汇总活跃设备数、设备崩溃率、FPS均值、温度均值、PSS均值五项核心指标，提供趋势图及多维度Top5排名，支持版本/机型/场景维度快速查阅。 ▍阅读详情 如何高效预警和定位玩家端的性能问题｜UWA GPM 2.0 新品发布 从 “被动救火” 到 “主动掌控”：GPM 2.0 如何重塑游戏性能竞争力？ 玩家端性能数据 一手掌握｜GPM 2.0案例精讲 二、异常筛查与排查 崩溃分析（免费）：多维度筛选崩溃问题，追溯玩家完整会话，整合崩溃堆栈、设备信息等核心数据，支持符号表解析，精准定位崩溃根源。 ANR分析（免费）：统计ANR异常影响范围，追溯会话详情，提供出错堆栈及解析功能，高效解决无响应问题。 ▍阅读详情 崩溃现场全回溯｜「崩溃上报分析」上线，终结“无法复现”的噩梦 无限接近真相｜GPM 2.0 功能上新 崩溃上报功能全面升级｜全场景覆盖+免费开放，让崩溃排查不再卡壳 异常场景筛查：自定义异常指标阈值，自动收集异常场景深度数据，生成包含截图、性能曲线的详细报告，直观呈现异常发生过程。 异常用户筛查：针对单个玩家/设备专项监控异常场景，支持疑似刷机用户识别及重点用户异常数据采集，精准响应核心用户诉求。 异常Session筛查：完整呈现玩家游戏全过程，从全局视角观察、定位特定性能问题，打通“指标-场景-用户”的排查链路。 ▍阅读详情 多维数据与实时截帧完美结合 如果闪退是因为内存崩了｜GPM 2.0 实操之Session篇 从内存占用、功耗、玩家行为、设备信息等多个维度提供实时的数据分析 大R流失、问题难复现？「指标 - Session直连」功能，让异常定位效率翻倍！ 三、数据对比与统计 多维度对比分析：支持版本、场景、机型三类核心维度对比，生成可视化图表及可导出的数据表格，直观呈现性能差异。 性能统计：按日/周维度展示各版本在线情况、异常次数、性能指标排行及机型数据统计，全面掌握版本性能迭代趋势。 运营数据展示：提供累计安装、新增玩家、次留/7留、DAU等12项核心运营指标，关联性能数据辅助运营决策，实现性能与运营联动优化。 版本/场景性能分析：聚合版本或场景维度的性能数据，快速定位异常版本及具体问题场景，支持数据导出供深度分析。 四、硬件相关能力 硬件性能分析：以散点图 + 表格形式呈现不同SoC/GPU/机型的性能分布，辅助针对性调整画质与特效策略。 硬件信息统计：分类聚合玩家设备厂商、机型、GPU型号等信息，提供趋势图、占比分布及数据导出功能，为技术规划提供数据支撑。 智能设备分档：基于UWA性能分级系统自动对设备分级，同时支持自定义分档策略，适配不同游戏的画质优化需求。 ▍阅读详情 硬件性能一目了然｜GPM 2.0 驱动优化与投放决策 海外市场设备适配性优化实战｜GPM 2.0案例精讲 五、告警与配置管理 自定义告警系统：支持灵活设置监控指标、阈值等触发规则，通过邮件/Webhook 推送告警通知，全程追踪告警事件生命周期，实现问题及时响应。 ▍阅读详情 GPM 2.0 告警功能：游戏性能的智能守护者 按游戏类型定制性能监控策略｜GPM 2.0「告警」功能实战指南 灵活阈值设定：支持全局及场景级分别配置FPS、内存等异常阈值，自定义异常报告采集模式、截图间隔等参数，适配不同项目的监控需求。 版本与符号表管理：对游戏版本进行分类标记及匹配规则设置，支持符号表上传/下载以解析崩溃堆栈，提升问题排查效率。 六、产品核心优势 低开销高稳定性：SDK操作全在子线程执行，不影响游戏主线程运行，保障玩家体验。 深度瓶颈分析：精准采集底层函数耗时、堆栈信息等核心数据，直击性能瓶颈根源。 ▍阅读详情 全新发布「卡顿帧堆栈」功能，精准高效定位游戏玩家端性能 深入解析「卡顿帧堆栈」 | 技术细节与常见问题 解锁「卡顿帧堆栈」｜代码示例与实战分析 如何精准打点解决卡牌、SLG、开放大世界、放置类游戏卡顿难题 玩家行为分析：几乎无损性能的截帧方案，辅…