這兩周在開發(fā)的彈幕引擎遇到了一些性能問題：
1.同一時(shí)刻創(chuàng)建大量子彈會(huì)造成卡屏，跑起來就是一頓一頓的，原因是new一個(gè)對(duì)象很耗CPU。
2.draw call 和 batch 的問題。
第一個(gè)問題可以使用OT自帶的對(duì)象池功能解決：
1）初始化對(duì)象池 PreFabricate(string objectPrototype, int numberOfInstances)
objectPrototype 對(duì)象必須放在OT prefab的子對(duì)象Prototypes下。
2）要銷毀對(duì)象時(shí)，必須調(diào)用 OT.DestroyObject(xxx），不然對(duì)象無法回收到pool中。
3）當(dāng)要?jiǎng)?chuàng)建新的對(duì)象時(shí)調(diào)用OT.CreateObject(objectPrototype ) ，剛好對(duì)象池里有可以使用的閑置對(duì)象時(shí)，OT就會(huì)自動(dòng)服用該對(duì)象。但是要注意一個(gè)問題，被復(fù)用的對(duì)象已經(jīng)被初始化過一次并運(yùn)行過了，可能有一些參數(shù)必須重置，這個(gè)操作OT不可能幫你完成，因?yàn)镺T不知道哪些參數(shù)需要重置。但OT在 CreateObject 方法內(nèi)有一行代碼：
g.SendMessage("StartUp",null,SendMessageOptions.DontRequireReceiver);
意味著OT在給你一個(gè)對(duì)象之前，讓這個(gè)對(duì)象執(zhí)行了這個(gè)StartUp函數(shù)，所以可以在對(duì)象的各個(gè)component里重寫這個(gè)函數(shù)，必做必要的重置操作。
除了使用OT自帶的對(duì)象池，還可以使用另外一個(gè)插件：PoolManager2，不過這個(gè)插件蠻貴的也不提供使用版，有米的就入手一個(gè)試試吧。
第二個(gè)問題是關(guān)于對(duì)象材質(zhì)的問題。
我在一個(gè)彈幕demo中想讓N個(gè)彈幕tween到一個(gè)顏色，通過改變OTSprite的tintcolor，結(jié)果發(fā)現(xiàn)幀率掉得很厲害：
1）彈幕剛生成的時(shí)候，Draw Calls只有3次，全部子彈都被batch到一起。
2）第二個(gè)操作是改變各個(gè)彈幕OTAnimatingSprite的幀圖片，發(fā)現(xiàn)幀率等沒有變化，性能瓶頸不是在切換動(dòng)畫幀上。
3）開始隨機(jī)tween每一個(gè)子彈的tintcolor，發(fā)現(xiàn)DrawCall暴增，batched數(shù)剩0，幀率掉出翔來了。。
很顯然，改變tintcolor會(huì)導(dǎo)致不能batch，每一個(gè)彈幕自己跑了一次渲染管線，超低效。
下一個(gè)操作是把所有子彈tween回同一個(gè)顏色，發(fā)現(xiàn)參數(shù)都恢復(fù)了，包括幀率。所以這個(gè)tintcolor的改變應(yīng)該不是給每一個(gè)子彈生成了新的材質(zhì)（Copy On Write寫復(fù)制這種機(jī)制)，只是同一次shader不能有不同的外部參數(shù)。
這個(gè)恢復(fù)機(jī)制反應(yīng)出Unity和OT還是很智能的。
這個(gè)問題好像沒有什么解決方法，最好的辦法就是不要像我這樣子搞=。=
做移動(dòng)平臺(tái)游戲，性能相當(dāng)重要，這種華麗的效果還是放棄吧。
雖然做了對(duì)象池優(yōu)化，但是幀率還是蠻低，以后加上游戲邏輯、碰撞檢測(cè)、游戲場(chǎng)景、特效、GUI后，幀率又會(huì)降低，
所以性能革命這路子還長(zhǎng)呀。