Performance

1）设置Application.targetFrameRate没有起作用的起因2）Unity如何监听程序退出，包含被后盾kill3）升高Mesh LOD是否会升高片元函数的执行次数4）TMP SubMeshUI呈现的起因 这是第304篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） PerformanceQ：在代码里设置了Application.targetFrameRate并没有起作用，请问是什么起因？ A1：题主能够检查一下引擎设置中VSync设置是否开启。如下图，能够调成Don't Sync再试试。 经测试，VSync敞开时，Application.targetFrameRate的锁帧成果失常失效；VSync开启时，理论帧率总是会达到设施反对的最大帧率，从而使Application.targetFrameRate的锁帧生效。 举例而言，在小米10上进行测试，开启VSync后，只管在代码中设置Application.targetFrameRate=60，但理论帧率会达到90，从而使得我的项目的GPU压力高于预期。 感激Faust@UWA问答社区提供了答复 A2：挪动平台会跟手机无关，不会超过最大的刷新率。看下官网文档:https://docs.unity.cn/cn/2021...感激zerolj@UWA问答社区提供了答复 AndroidQ：如果实现了MonoBehaviour.OnApplicationQuit这个办法，在PC或者编辑器下用能够监听到，然而我发现，公布Android时这个函数不会被监听到。 应用Application.Quit办法退出能够监听到，然而如果间接被后盾杀死，那么就无奈监听到。 想请问有没有别的办法，能在各种状况下（强制退出或后盾kill等）监听到程序退出？ A：将我的项目导出成Android我的项目，此时导出的我的项目目录unityLibrary\src\main\java\com\unity3d\player下有一份UnityPlayerActivity.Java文件，外面的代码是在管制UnityPlayer的生命周期。 Android生命周期： 依据以上周期，游戏失常退出会调用Quit，零碎杀过程则不会触发Quit。 所以可能倡议思考一些别的方法。比方onSaveInstanceState()和onRestoreInstanceState()这两个事件，以及通过编写Servise辅助检测Uniy我的项目的活动状态。 如果你想编写安卓间接交互Unity的代码，也能够像这样写：mUnityPlayer.UnitySendMessage(“receiveObj”, “UnityMethod”, “This is args.”); 感激Isle@UWA问答社区提供了答复 RenderingQ：镜头固定，如果模型应用Mesh LOD请问除了升高顶点函数执行次数，还会升高片元函数次数？ 或者影响片元函数的执行次数跟哪些因素无关？ A1：那就只能降屏幕分辨率或者进行深度剔除，AlphaTest等提前剔除的伎俩。感激欧月松@UWA问答社区提供了答复 A2：补充楼上，次要是看Primitive光栅化之后的占屏幕像素数量（这个受到渲染分辨率的影响）。当然还要思考暗藏面打消，Early-Z等防止Fragment计算的因素。感激Xuan@UWA问答社区提供了答复 TextMeshProQ：当初在应用Unity 2019.4.34f1版本和TextMeshPro 2.1.6版本开发性能，在我的项目中有两个字体，Font_Main和Font_Main_Fallback。 如果在Font_Main设置了Fallback Font Assets，创立的TextMeshPro文本组件下会有一个子节点TMP SubMeshUI [Font_Test_1 Material + KaiTiJianCu Atlas]，而且还无奈删除，删除后会再次主动呈现；如果不设置Fallback Font Assets，那么就能够把子节点TMP SubMeshUI [Font_Test_1 Material + KaiTiJianCu Atlas]删除，请问这个有什么作用？会对性能有影响吗？ A：如果主字体中没有对应的Unicode的文字时，就会应用Fallback的字体显示。感激萧小俊@UWA问答社区提供了答复 封面图来源于网络 明天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题兴许都只是冰山一角，咱们早已在UWA问答网站上筹备了更多的技术话题等你一起来摸索和分享。欢送酷爱提高的你退出，兴许你的办法恰能解他人的当务之急；而他山之“石”，也能攻你之“玉”。 官网：www.uwa4d.com官网技术博客：blog.uwa4d.com官网问答社区：answer.uwa4d.comUWA学堂：edu.uwa4d.com官网技术QQ群：793972859（原群已满员）

1）如何定位游戏发热问题2）Unity获取指定脚本的援用对象3）如何晓得打包时的一个Shader有多少变体4）如何优化Font.CacheFontForText频繁造成的耗时峰值 这是第300篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） PerformanceQ：目前我的项目的发热问题很头疼，2D游戏，基于TileMap、SpriteRenderer和UGUI的渲染，敞开了垂直同步，TargetFrameRate设置为60。Android和iOS上发热都很重大，而且在比拟好的机型（比方iPhone 12这种），发热景象甚至更显著。 跟大部分状况不同，发热并没有怎么影响帧率，在大部分机型上，帧率都不是问题，连iPhone 8机型，都能60帧跑满。 在Unity Profile和Xcode都进行过性能剖析，CPU最显著的热点函数就是Spine的骨骼动画更新计算。然而到一个没有骨骼动画的场景，发热景象稍好点，但还是比预期的要烫不少（场景中除了高空和一些动态贴图，根本就没有多少货色）。 另一个比拟广泛的发热点是网络测试，在某场景敞开网络后，发热仍然重大。甚至启动游戏，停留在登录界面一会儿，发热景象都比别的游戏更显著。 猜想是否因为每帧的顶点数量过多造成的，在游戏中Unity的Status面板，顶点数量Verts达到了40KB，三角形Tris也有简直20KB。看起来很多，但我不太分明以后支流游戏这个数值的级别大略是多少。而且，顶点和三角形的数量很难解释登录界面仍然容易发热，毕竟登录界面这些数值不可能很高。 本人也做了很多测试了，切实搞不清楚问题到底在哪儿，Unity是还有什么特地须要优化的，针对发热的点吗？ A1：能够用Xcode抓帧看看带宽，Load Store Action是否正当。感激littlesome@UWA问答社区提供了答复 A2：以下是我的倡议： iPhone 8上跑满60帧，证实CPU、GPU都没有达到瓶颈，耗费在较为正当的范畴。举荐在Unity Profiler看一下CPU端的耗费，以及查看一下DrawCall数量。举荐应用FrameDebugger，看一下是否有冗余的物体或者后处理在渲染，尤其是你说的启动界面有发热。如果低级谬误都排查过了，那么倡议看一下是否用了原生的插件。渲染的分辨率是否调整过了，RenderScale的值和FrameDebugger能够查出来分辨率。感激张振东@UWA问答社区提供了答复 A3：对于发热的问题，通常要从几个角度排查：CPU压力（耗时）、GPU压力（耗时和带宽，能够思考升高分辨率看看发热问题是否会有改善）和IO等几个角度。从题主的问题上看，耗时应该是没问题，都能跑满帧（当然60帧自身就是对发热影响比拟大的一点，能够看看限度30帧会不会发热有降落），所以要看看一些隐形的货色是否有问题。比方带宽，能够用Snapdragon在高通手机上跑一跑。如果带宽较高，看看纹理的一些设置是否正当，比方是否压缩、是否开启Mipmap，这两项通常都是须要设置成开启的。还能够查看是否有不必要的BlitCopy操作，在URP我的项目中比拟容易呈现Copy Color和Copy Depth节约。对于IO，须要看看是否存在子线程外面有频繁IO的景象。感激Xuan@UWA问答社区提供了回 ScriptQ：Unity获取指定脚本的援用对象：一个GameObject上挂载了一个Script，这个Script援用了很多资源。如何只取得这个Script援用的资源呢？AssetDatabase是会获取所有的援用，然而并没有做辨别。 A1：有Guid能够应用以下代码加载：var assetPath = AssetDatabase.GUIDToAssetPath(guid);var texture2D = AssetDatabase.LoadAssetAtPath(assetPath);感激萧小俊@UWA问答社区提供了答复 A2：通过SerializedObject拿到了所有的ObjectReference，而后AssetDatabase.GetAssetPath获取对应门路： var assetObj = AssetDatabase.LoadAssetAtPath<Object>(path);if (assetObj != null){ GameObject gameObj = assetObj as GameObject; if (gameObj != null) { MeshRendererTextureStreamingData streamingOBJ = gameObj.GetComponent<“taget component”>(); if (streamingOBJ != null) { SerializedObject so = new SerializedObject(streamingOBJ); SerializedProperty it = so.GetIterator(); bool first = true; while (it.Next(true)) { if (it.propertyType == SerializedPropertyType.ObjectReference && it.objectReferenceValue!=null) { // Debug.LogError(it.objectReferenceValue); var depPath = AssetDatabase.GetAssetPath(it.objectReferenceValue); streamingAssets.Add(depPath); } } } }}感激题主null@UWA问答社区提供了答复 ...

在一个网络编程性能优化我的项目中，利用perf trace进行性能剖析。背景：一个过程负责解决socket音讯，在须要解决音讯数量达到32k条100+字节的音讯量时，耗时大略须要25分钟指标：定位耗时的热区环境：linux 假如1：用户态耗时多，过程耗时多是耗费在算法计算上？该过程只进行简略的音讯解决，不波及过多数据结构和算法，排除该可能性。 假如2：零碎态耗时多，过程耗时多是耗费在零碎调用上？因为音讯量大，进行了32k*n 数量级的零碎调用，假如有可能成立。 在这里，抉择应用linux的perf工具进行统计分析：perf trace -p $PID -s 由上图可见，在解决一条音讯的过程中，大抵流程波及到与socket相干的 poll->recvfrom->sendto，同时还有与文件IO相干的零碎调用。解决32k条音讯，波及到的零碎调用数量在数量级上合乎预期。 指标统计分析： fsync(), 该零碎调用用时最多，耗费了大略15分钟。该零碎调用用于同步写入磁盘，调用后会阻塞，直至期待内核缓冲区数据写入磁盘后，内核才会返回。定位到该零碎调用位于过程的日志模块。针对该零碎调用改善：业务数据日志，升高其日志等级，在运行过程时通过日志等级开发将对应的等级敞开，缩小日志输入；同时在日志模块中删除fsync()调用，该类日志不须要实时同步至磁盘。 从新执行雷同的测试，过程总用时大概50s。从本次检测到的零碎调用指标来看，解决了fsync()带来了极大的晋升空间。 在这个实际中，能够看到perf trace的一个用途：统计肯定工夫内的零碎调用的次数以及其耗时散布。 思考1：perf trace统计的零碎调用，各列中的工夫是零碎工夫还是时钟工夫？集体认为是时钟工夫，因为只管是零碎调用，内核态也会处于一种阻塞状态，该状态不耗费CPU资源。例如过程调用fsync()，陷入内核态，DMA把零碎缓冲区的数据同步至磁盘，此过程过程睡眠，没有占用CPU资源，同步至磁盘实现后，DMA会中断，CPU进行响应解决，此时fsync()调用完结，返回用户态。

问题谋求 MySQL 的性能时，总据说要调整自旋锁的参数: innodb_spin_wait_delay 和 innodb_sync_spin_loops，是真的么？ 试验首先咱们要晓得自旋锁的长处：自旋锁要上锁时，如果须要期待其余线程开释锁，那么： 在期待锁的过程中会先线程会先自旋一段时间 自旋阶段，线程不会放弃 CPU自旋过后： 如果能够获取锁了，那么响应会比拟快（自旋没产生上下文切换）如果还须要期待锁，再用更高老本的形式进行锁期待innodb_spin_wait_delay 参数决定了自旋阶段的长度。当初咱们试着调整 innodb_spin_wait_delay 参数，来测试一下： 先宽油起一个数据库，此处疏忽步骤 建个表，放点数据： 配置好 performance_schema： 检查一下相干参数： 清理 performance_schema 的统计值： 来点压力： 查问一下锁期待老本最高的锁： 能够看到锁期待老本最高的是 lock_mutex，是爱护 MySQL 锁零碎的锁 上面咱们来调整一下 innodb_spin_wait_delay，让自旋的工夫变长： 重做一次压力（记得先清理统计数据），查看统计数据： 能够看到 lock_mutex 的均匀等待时间从 751267 减少到了 1399041。咱们让自旋阶段减少了 10 倍，锁期待的工夫也会随之增大。 目前的试验看上去自旋阶段越短越好，那么自旋阶段是不是就没有意义了？当然不会。 大家能够将 innodb_spin_wait_delay 设置为 1，再进行测试，随着自旋阶段的缩小，锁期待的工夫也会随之增大（大部分锁都应用了高老本的形式来进行期待）。 那么如何抉择自旋的参数呢？咱们倡议“不出问题不瞎调”。 在之前的统计数据中，工夫的单位是：cycle，依据以下换算表，锁的均匀工夫是 1399041 cycle，大略也就 0.5ms（1399041 / 2385353233 = 0.00058 s），占 SQL 的整体工夫很低，能够不必瞎调。 一个驰名的 CPU 问题自旋阶段，MySQL 会调用 CPU 的 PAUSE 指令，既能占用了 CPU，同时 PAUSE 指令（比起其余占用 CPU 的指令）也比拟节能。 ...

1）MMORPG手游正当的性能参数2）应用ScriptableBuildPipeline打包的疑难3）如何获取到Animation批改材质球色彩后的色彩值4）嵌套预设AssetBundle打包的疑难5）LWRP渲染下，Profiler中函数开销高 这是第219篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。 UWA 问答社区：answer.uwa4d.comUWA QQ群2：793972859（原群已满员） PerformanceQ：想求教一下大家，一款MMORPG游戏上线时的性能参数是如何制订的？有没有可参考的性能参数能够领导一下？ A1：制订指标要依据多方维度来综合思考，包含产品定位、团队程度、老本估算和工夫估算等等，很难一概而论，以下是咱们针对新我的项目立项要指定美术指标时一贯的做法，能够参考： 拿对标美术体现的竞品来看他们各项性能指标如何，用RenderDoc或者NSight可能失去比拟精确的数据，也能够抽出他们资源来做下一步操作。制作成果Demo，尝试技术上还原竞品的成果，这时尽量做到体现上和性能上都能还原。有了成果Demo后，根本指标曾经有了，不过还是得本人团队从美术到技术再到策动残缺地把流程跑通，而且可能还要对体现的要求进行进步以晋升产品竞争力，这时候尽可能依据上线工夫推断适合的指标机型，略微超前地指定渲染能力指标。感激邓永健@UWA问答社区提供了答复 A2：能够参考UWA的蓝皮书《Unity手游性能蓝皮书》。感激jessica@UWA问答社区提供了答复 BuildQ：我应用ScriptableBuildPipeline打包AssetBundle比原始Build Pipeline慢，有人应用ScriptableBuildPipeline打包取得更快的打包速度了吗？想弄清楚是我本人某些做法不对，还是自身ScriptableBuildPipeline就是打包更慢。 通过测试失去以下数据：全量打包 增量打包（资源无变动）原生 560s 7sSBP 610s 480s A：测试的数据（AssetBundle的数量大略在3200个左右， 统计耗时：ms） 所以集体感觉SBP + CacheServer， 可能在肯定水平上晋升打包速度。 感激杨宇杰@UWA问答社区提供了答复 RenderingQ：如果用Animation动静更新_Color后，材质球上的_Color色彩获取不到，GetColor获取到的色彩始终是Animation运行前的色彩，求教怎么获取动画更新后材质球的色彩？ 复现步骤：1. 新建材质球A，轻易应用Shader带Color属性的，（我这里应用Shader: Legacy Shaders/Diffuse），_Color默认红色；2. 新建物体Cube，将材质球A拖到Cube上；3. 创立Animation，批改Cube上A的_Color色彩，给蓝色或者非红色；4. 创立一个脚本在Update中打印_Color的色彩（mat.GetColor("_Color")）；5. 运行后色彩值应用时初始值红色，不是动画Animation批改后的色彩。 A1：实测应用MaterialPropertyBlock是能够获取到的。代码如下： void Start() { render = GetComponent<MeshRenderer>(); mpb = new MaterialPropertyBlock(); } void Update() { render.GetPropertyBlock(mpb); Color color= mpb.GetColor("_Color"); ; Debug.Log(color); } 感激Xuan@UWA问答社区提供了答复 A2：最初发现是美术在Animation里把_Color指定一个固定值，没有勾选刷新，所以始终不对。感激题主王@UWA问答社区提供了答复 AssetBundleQ：嵌套预设AssetBundle打包存在两份资源冗余，目前解决办法有预设b的材质球和Mesh独自打成AssetBundle，然而这样会导致AssetBundle打得太散。求问有什么解决办法？ 目前解决办法如下：1. 空工程，预设b带了贴图tex_b和tex_c.应用嵌套预设把b嵌套在预设a外面（Unity版本2018.4.24）。2. 预设a和b都独自打成AssetBundle。3. 打包AssetBundle后，应用AssetStudio后查看预设a的AssetBundle，蕴含了预设b的贴图和Mesh。 A：设计使然：在运行时不存在预制体的概念。预制体在构建过程中是被 “烘焙”好的，因而每个预制体（无论嵌套与否）都是残缺且彼此独立的。https://issuetracker.unity3d.com/issues/nestedprefabs-when-building-assetbundles-with-nested-prefab-assets-are-duplicated-in-parent-prefab-assetbundle 能够将子预制体依赖的资源显式地与子预制体打包在一起（如果能辨别出哪个是子预制体）。 ...