【Unity开发】性能优化——记录一个关于材质（Material）设置的坑

原理解析

之前一直发现set pass（draw call）非常高，batches完全没有办法合并，后来才知道原来是材质变成了Instance，虽然我是经过自己的猜测得出只要访问了Renderer.material，就会克隆（Instantiate）一个材质并返回。还写了代码去验证，后来我才发现我是傻了，直接看文档不就行了，于是去看稳定，文档里面就写明白了。虽然我觉得这样设计挺蛋疼的，我觉得应该返回null，如果用户想访问sharedMaterial，自己去访问就好了，这种设计很容易让人踩坑。而且如果我要自己控制材质，也会自己克隆一个。不过这也是双刃剑吧，对于小白来说，也是自动的才是最好的，而且大部分时候不会成为性能瓶颈。

性能优化

明白了原理实际上就很好操作了，比如敌人被攻击后变色或闪烁，通常是靠设置材质的shader属性完成的，那么最好就是创建一个设置好的效果，然后去设置给renderer。

最早的版本是直接spriteRenderer.material.SetFloat("_FlashAmount", _FlashAmount);这样在对象不多的时候其实完全没问题，很简单。但是对象多的时候或者同事大量操作的时候有可能会产生卡顿。

另外需要注意的是，当你设置了材质material之后，共享材质sharedMaterial也会跟着改变，所以要在一开始进行获取

写在最后

实际上本次是一次失败的优化，因为最终我发现我自己的框架性能的瓶颈不在这里，而是物理引擎，本次变成了一次失败的优化。所以优化性能的时候，首先去看看性能瓶颈在哪里，否则浪费了很多时间，实际上在做无用功！