|前端如何快速上手 Web 3D 游戏的开发( 七 )

上述两项其实都是针对跑酷项目本身做的一些特定优化，其他项目未必能够完全照搬，我们的尘沫大神针对业务方面的性能优化做了比较通用全面的总结，这里简单列举一下：
语言

使用枚举：在标记判断if或switch语句中尽量使用number型枚举,避免使用字符串作为判断标记，字符串作为判断标记性能损耗较大
使用Number做Object的Key：Object作为Map使用时尽量不要使用string作为Key,而是倾向使用Number作为Key ，其中Number的范围越小性能越高，通常小于65535性能较优
使用“.”访问对象属性：避免使用[''string'']访问对象的属性和方法，会导致JIT优化失效，应使用“.”访问属性
尽量使用for循环遍历：帧级调用尽量使用for循环进行遍历操作提升性能,相对于语法糖循环更纯粹,需要提前缓存长度n进行循环判断，减少纹理寻址性能损耗

逻辑

多用对象池机制：由于JS本身机制和原理，需要避免在帧循环中new对象,避免GC卡顿,在业务开发中的模型抽象强烈建议使用对象池机制做对象管理
善用实例或静态全局变量：除了对象池机制避免GC外，还需要利用实例或静态全局变量减少GC损耗，比如一些用于中转数学计算的临时变量可使用静态全局变量缓存，另外一些可逐实例的类变量可缓存为实例全局变量，减少使用时的频繁new操作带来的开销和GC 。
慎用事件：在大型项目中慎用事件,事件本身的灵活性是一把双刃剑，在解耦的同时也带来了逻辑可读性低等困难，尤其在多人协作开发的项目中，所以在业务系统中该解耦的模块用事件，不需要的地方需要用明确的设计调用逻辑解决,切记不要因为设计的懒惰把项目搞乱

资源优化

模型合并优化：美术需将不可独立移动的模型尽可能合并减少渲染批次，同时注意不要合并场景范围跨度过大的模型导致模型无法裁剪的问题
材质优化：尽可能合并材质，材质作为三维引擎的合并根基，一切引擎级渲染批次的合并前提都是使用相同材质，所以要保持材质对象尽可能的少材质模型选择需要根据美术风格尽量精简，比如直接把光照合并在漫反射贴图的的卡通风格模型可以直接选择unlit材质，而无需使用复杂的PBR材质模型
贴图优化：贴图尺寸不可能盲目追求质量使用超大尺寸，需要评估实际项目贴图光栅化后的实际显示像素来使用接近的贴图尺寸，否则使用过大尺寸不仅得不到效果手机还浪费显存。除此之外还可使用纹理压缩优化显存
像素填充率优化：尽量减少全屏渲染的绘制,比如UI或遮罩使用类似全屏但大部分透明的图片绘制会带来大幅的GPU渲染负担在移动端等高DPI的设备中可适当降低DPI配置，减少GPU负担

玩法系统优化

碰撞系统优化：善用主动碰撞和被动碰撞概念,减少主动碰撞器可以大幅减少碰撞检测的循环遍历次数善用碰撞组概念，将物体划分所属碰撞组和可与之发生碰撞的组作为过滤器，根据业务规则划分可以减少不必要的碰撞检测循环
跑酷弯道优化：可尝试利用顶点着色器模拟弯道跑酷效果，减少CPU端相关跑酷弯道逻辑的计算负担，降低美术制作复杂度

Oasis 3D V2.x To V3.x
随着 Oasis 3D 服务的业务数量越来越多、业务负责度越来越大，也暴露出不少问题，为此，我们对现有引擎进行了大重构，也就是V3.x版本，此版本主要目标是：更快、更方便、更高效。
这里先简单介绍几个重构模块，希望让大家有个初步体感。
资源管理模块
资源管理模块我们从底层实现进行了大重构，主要目的是简化开发者的使用，下面是v2.x版本和v3.x版本加载一个带有骨骼动画的模型示例，对比可以看出v3.x版本的api是特别精简的，除了api的简化外，功能上我们还提供了下载重试、重试间隔、下载超时、下载进度、取消下载等。