原理解析

之前一直發(fā)現(xiàn)set pass（draw call）非常高，batches完全沒有辦法合并，后來才知道原來是材質(zhì)變成了Instance，雖然我是經(jīng)過自己的猜測得出只要訪問了Renderer.material，就會克?。↖nstantiate）一個材質(zhì)并返回。還寫了代碼去驗證，后來我才發(fā)現(xiàn)我是傻了，直接看文檔不就行了，于是去看穩(wěn)定，文檔里面就寫明白了。雖然我覺得這樣設(shè)計挺蛋疼的，我覺得應(yīng)該返回null，如果用戶想訪問sharedMaterial，自己去訪問就好了，這種設(shè)計很容易讓人踩坑。而且如果我要自己控制材質(zhì)，也會自己克隆一個。不過這也是雙刃劍吧，對于小白來說，也是自動的才是最好的，而且大部分時候不會成為性能瓶頸。

性能優(yōu)化

明白了原理實際上就很好操作了，比如敵人被攻擊后變色或閃爍，通常是靠設(shè)置材質(zhì)的shader屬性完成的，那么最好就是創(chuàng)建一個設(shè)置好的效果，然后去設(shè)置給renderer。

最早的版本是直接spriteRenderer.material.SetFloat("_FlashAmount", _FlashAmount);這樣在對象不多的時候其實完全沒問題，很簡單。但是對象多的時候或者同事大量操作的時候有可能會產(chǎn)生卡頓。

另外需要注意的是，當(dāng)你設(shè)置了材質(zhì)material之后，共享材質(zhì)sharedMaterial也會跟著改變，所以要在一開始進行獲取

寫在最后

實際上本次是一次失敗的優(yōu)化，因為最終我發(fā)現(xiàn)我自己的框架性能的瓶頸不在這里，而是物理引擎，本次變成了一次失敗的優(yōu)化。所以優(yōu)化性能的時候，首先去看看性能瓶頸在哪里，否則浪費了很多時間，實際上在做無用功！