ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

《HarmonyOS 7 ArkGraphics 3D 空间设计开发实战》07:复杂3D场景的帧率、内存与资源性能优化【鸿蒙心迹】

《HarmonyOS 7 ArkGraphics 3D 空间设计开发实战》07:复杂3D场景的帧率、内存与资源性能优化【鸿蒙心迹】 家具加到50个以后为什么转视角开始卡了前言前面六篇SpaceRoom 从空房间做到了能选家具、能转视角。房间里放个十来件家具跑起来很流畅。然后我放了 50 件家具进去问题来了转视角的时候开始掉帧拖一下卡一下内存也涨了不少。第一反应是手机性能不够吧然后我打印了一下帧率发现还真不是 GPU 跑不动而是很多地方做了不必要的工作。这一篇就讲3D 场景卡顿不能只盯着 GPU。节点数量、纹理大小、重复材质、不可见对象、每帧的逻辑更新这些都会影响性能。先把性能数据测出来才知道该优化哪里。一、先测数据卡顿到底卡在哪很多人做性能优化上来就模型减面、纹理压缩结果做完发现帧率还是上不去。因为你都不知道瓶颈在哪优化就是瞎猜。先建一个性能监控把关键指标打出来exportclassScenePerformanceMonitor{privateframeCount:number0;privatelastTime:number0;privatefps:number0;// 统计数据privatestats{nodeCount:0,// 节点总数meshCount:0,// Mesh数量materialCount:0,// 材质数量textureCount:0,// 纹理数量memoryMB:0,// 内存占用initTimeMs:0,// 场景初始化耗时frameTimeMs:0// 每帧耗时};/** * 每帧调用统计FPS */onFrame():void{this.frameCount;constnowDate.now();if(now-this.lastTime1000){this.fpsthis.frameCount;this.frameCount0;this.lastTimenow;console.info(PerfMonitor: FPS${this.fps}, nodes${this.stats.nodeCount}, meshes${this.stats.meshCount});}}/** * 收集场景统计 */collectStats(scene:scene.Scene):void{// 递归统计节点数this.stats.nodeCountthis.countNodes(scene.getRoot());console.info(PerfMonitor: stats collected,this.stats);}privatecountNodes(node:scene.Node):number{letcount1;constchildrennode.getChildren();for(constchildofchildren){countthis.countNodes(child);}returncount;}}先把数据打出来才能知道问题在哪。常见的问题有指标正常范围异常表现FPS50~60低于30就明显卡节点数几百个以内上千个就要注意纹理内存几十MB超过100MB就吃紧每帧耗时16ms以内超过33ms就是30帧二、最常见的优化不可见对象不渲染第一个最容易做的优化相机看不到的物体就不要渲染了。比如房间里有个柜子柜子门是关着的柜子里面的东西相机根本看不到。但如果柜子里面的模型也在渲染就是浪费。更常见的情况用户视角转到另一边左边的家具完全在视野外面但还是每帧都在算。这个叫视锥体裁剪Frustum Culling相机视野是个锥形锥形外面的物体直接跳过渲染。ArkGraphics 3D 应该会自动做这个但我们自己也可以加一层离相机太远的小物体直接不渲染。exportclassVisibilityManager{privatecameraPos:{x:number,y:number,z:number}{x:0,y:1.6,z:5};/** * 每帧更新可见性 */updateVisibility(nodes:scene.Node[]):void{for(constnodeofnodes){constposnode.position;// 算一下离相机多远constdxpos.x-this.cameraPos.x;constdypos.y-this.cameraPos.y;constdzpos.z-this.cameraPos.z;constdistMath.sqrt(dx*dxdy*dydz*dz);// 超过30米的小物体直接隐藏if(dist30){if(node.visible){node.visiblefalse;}}else{if(!node.visible){node.visibletrue;}}}}}这个优化很简单但效果明显。尤其是大场景里远处的小物体全部跳过渲染帧率马上就上来了。三、重复材质和纹理别每个家具都来一份第二个常见问题10把椅子每把椅子都加载了一份纹理。其实椅子都是一样的纹理只需要一份所有椅子共享。这个和之前说的 Resource 缓存是一个道理但材质和纹理也要做缓存exportclassMaterialCache{privatematerialMap:Mapstring,scene.MaterialnewMap();/** * 获取共享材质 */getMaterial(texturePath:string):scene.Material|null{// 已经有了直接返回if(this.materialMap.has(texturePath)){returnthis.materialMap.get(texturePath)!;}// 没有就创建constmaterial...// 创建材质加载纹理this.materialMap.set(texturePath,material);returnmaterial;}}10把椅子共享一份布料纹理纹理内存直接省了 90%。这个优化在家具多的时候效果特别明显。四、别每帧都更新不需要变的东西第三个问题每帧都在做不必要的逻辑更新。比如家具的位置从来没变过但每帧都在重新算它的世界坐标UI 状态从来没变过但每帧都在刷新动画已经停了但每帧还在检查。这些看起来都是小事但每帧省一点加起来就是帧率提升。一个原则只有真的会变的东西才每帧更新。东西什么时候更新相机位置手势操作的时候更新不是每帧家具位置用户拖动的时候更新选中高亮选中状态变化的时候更新可见性相机移动的时候更新不是每帧很多人写代码习惯了 onFrame() 里什么都做结果就是每帧跑一大堆没用的逻辑。五、几个最容易踩的性能坑把这一篇遇到的坑总结一下坑现象解决办法上来就减面压缩纹理做了半天帧率没提升先测数据找到瓶颈再优化所有物体都渲染视野外的物体也在算视锥体裁剪远处的隐藏每个家具一份纹理纹理内存爆了相同材质纹理共享缓存每帧都跑所有逻辑CPU占用高帧率上不去只在状态变化的时候更新退出页面不释放资源退出再进内存越来越大页面销毁时释放所有资源只看FPS不看内存帧率还行但App被系统杀了内存和帧率都要监控3D 性能优化不是玄学是先测数据、再找瓶颈、然后针对性优化。不要上来就瞎优化。总结第七篇的核心就一句话卡顿不能只怪 GPU先测数据再优化。先建性能监控把 FPS、节点数、内存都打出来相机看不到的物体直接隐藏不渲染相同的材质和纹理所有家具共享不要每个都来一份只有真的会变的东西才每帧更新退出页面记得释放资源不然内存越积越多SpaceRoom 现在家具多了也能流畅跑了。最后一篇做工程收尾加动画、管生命周期把整个项目整理成一个可维护的工程。
返回列表