一般游戲的性能指標(biāo)有:幀率西设、穩(wěn)定性、流暢性答朋、加載時間(loading)贷揽、內(nèi)存占用(這一項在移動設(shè)備上比較重要，有很多閃退原因就是由此造成的)绿映、安裝包大小擒滑、網(wǎng)絡(luò)延遲腐晾、耗電量等。
程序:代碼優(yōu)化
美術(shù):資源優(yōu)化
策劃:合理和設(shè)計方案以避免性能開銷
性能優(yōu)化主要從以下幾個方面展開: CPU丐一、GPU藻糖、內(nèi)存

一、CPU

CPU的性能開銷主要來自于以下兩個方面:
1.引擎模塊自身的性能開銷:渲染(Draw Call)库车、動畫巨柒、物理引擎、UI模塊柠衍、粒子系統(tǒng)洋满、資源加載、GC(Garbage Collection)珍坊。
2.游戲自身代碼的性能開銷:代碼結(jié)構(gòu)牺勾、循環(huán)、數(shù)據(jù)結(jié)構(gòu)等阵漏。

渲染:

1.降低Draw Call
CPU每次在準(zhǔn)備數(shù)據(jù)(頂點位置驻民、法線、顏色履怯、坐標(biāo)紋理等)并通知GPU渲染的過程稱為一次Draw Call回还，其實就是CPU對底層圖形程序接口的調(diào)用。
Draw Call的消耗來源:如果每次Draw Call只提交少量的數(shù)據(jù)將導(dǎo)致CPU瓶頸叹洲，CPU無法將GPU填滿柠硕。Draw Call對GPU的耗費在于硬件一直等待CPU提交數(shù)據(jù)，而無法得到有效利用运提。GPU大量的時間耗費在不斷切換狀態(tài)和正確性檢測上蝗柔。
降低Draw Call有以下幾種方法：
①減少所渲染物體的材質(zhì)種類 → 通過把紋理打包成圖集來盡量減少材質(zhì)的使用。
②通過Draw Call Batching來減少其數(shù)量 → 靜態(tài)批處理和動態(tài)批處理糙捺。
批處理的思想:在每次調(diào)用Draw Call時盡可能多地處理多個物體(多個物體最好一起渲染诫咱，將批處理之前需要很多次調(diào)用的物體合并，之后只需要調(diào)用一次底層圖形的接口就行)洪灯，減少每一幀需要的Draw Call數(shù)目坎缭。
靜態(tài)批處理的優(yōu)點:自由度高，限制很少签钩。
靜態(tài)批處理的缺點:可能會占用更多的內(nèi)存(額外的內(nèi)存開銷來存儲合并后的幾何數(shù)據(jù))掏呼，而經(jīng)過靜態(tài)批處理后的所有物體都不可以再移動了(即使在腳本中嘗試改變物體的位置也是無效的)。
靜態(tài)批處理的時間點:⑴在游戲?qū)С龅臅r候铅檩，在player setting中勾選static batching憎夷，這樣導(dǎo)出包的時候就進行批處理，包體較大昧旨。⑵在游戲場景中勾選物體的static選項拾给，在加載該場景的時候祥得，會進行一次靜態(tài)批處理的合并，這樣導(dǎo)出來的包不大蒋得，但是在加載的時候會使得內(nèi)存變大级及。
動態(tài)批處理的優(yōu)點:Unity自動完成，實現(xiàn)方便额衙，經(jīng)過批處理的物體仍然可以移動饮焦，這是由于在處理每一幀時Unity都會重新合并一次網(wǎng)格。
動態(tài)批處理的缺點:限制有很多窍侧，可能一不小心就破壞了這種機制县踢，導(dǎo)致Unity無法批處理一些使用了相同材質(zhì)的物體。
③盡量少使用反光伟件、陰影等硼啤，因為這樣會使得物體多次渲染。
2.簡化資源
3.LOD
Levels Of Detail是一種優(yōu)化游戲效率的常用方法斧账，它是根據(jù)物體在游戲畫面中所占視圖的百分比來調(diào)用不同復(fù)雜度的模型的丙曙，其缺點在于會占用大量內(nèi)存，使用這個技術(shù)一般是在解決運行時流暢度的問題其骄，以空間交換時間。
4.剔除Culling

UI模塊:

1.動靜分離
2.預(yù)加載扯旷、常駐拯爽、即時釋放
3.圖集
4.內(nèi)存池
5.Active/Deactive
6.UISprite、Texture
7.不移動钧忽、不可見UI不更新
8.對于不交互的UI元素毯炮，關(guān)閉Raycast Target
9.資源預(yù)加載
10.shader預(yù)加載

在使用UGUI的過程中，有以下幾點可能會成為影響游戲性能的原因:
⑴圖集整理不規(guī)范
在UI界面設(shè)計的時候要考慮到重用性耸黑，比如一些公用的UI資源或使用頻率較高的資源可列為公共資源桃煎，放在若干張大圖集當(dāng)中(1~3張)作為重用圖集，在游戲開始時進行加載大刊，必要的情況考慮常駐內(nèi)存使用为迈；對于一些特殊的、使用情況不多的UI缺菌，可對其按照使用功能劃分為功能圖集葫辐，在特定的時間進行加載；對于一些同時使用到重用圖集與功能圖集的UI伴郁，在功能圖集的“留白”部分較多的情況下耿战，可以考慮將部分在重用圖集中出現(xiàn)的元素單獨提取出來，合并到功能圖集中焊傅，從而做到讓UI只依賴功能圖集剂陡，這樣可以省去部分加載重用圖集的資源消耗(可接受的冗余換取性能)狈涮。
UGUI自動打包圖集時，有時候同一個Tag會自己打出多個Group圖集鸭栖，導(dǎo)致Draw Call增加歌馍，產(chǎn)生Group的主要原因有兩種:
①紋理的格式不同
②紋理量太大，一個Group放不進
⑵UI的層級深度
有相同材質(zhì)和紋理的UI元素是可以Batch的纤泵，可以Batch的UI(注意UI的層級)上下疊在一起不會影響性能骆姐，但是不能Batch的UI元素疊在一起就會增加Draw Call。要注意UI元素之間的層疊關(guān)系捏题，有一些UI會有透明的部分玻褪，在設(shè)計和開發(fā)的過程中可能會在透明的部分上面疊加了其他的UI元素，這樣就有可能造成Draw Call的增加公荧，比如排列带射、列表、背包等情況循狰。
有些情況可以考慮人為增加層級從而減少Draw Call窟社，比如一個Text的層級為0，另一個可以Batch的Text疊在了圖片A上绪钥，層級為1灿里，那此時有兩個Text因為層級不同會安排2個Draw Call，但如果在第一個Text下放一張透明圖片(可以和圖片A進行Batch)程腹，那兩個Text的層級就一致了匣吊，Draw Call就可以減少一個。
⑶圖文交叉
Image和Text組件寸潦，當(dāng)Text疊在Image上面(比如Button)色鸳，然后Text上又疊了一張圖片，就會至少多2個Draw Call见转，這種情況可以考慮將字體直接印在下面的圖片上命雀。
⑷Mask
應(yīng)避免使用Mask，其實Mask組件功能有時候可以變通斩箫，比如設(shè)計一個邊框吏砂，讓這個邊框疊在最上面，底下的UI移動時校焦，就會被這個邊框給遮住赊抖，Mask以內(nèi)的和Mask以外的UI無法Batch
如果需要使用Mask，需要評估一下Mask會帶來的性能消耗寨典，如果Mask內(nèi)的UI是動態(tài)生成的話氛雪，需要注意UI之間是否有重疊 → 可能某些透明部分存在重疊，需要細(xì)致觀察耸成。
⑸Raycast Target屬性
用不上的UI盡量關(guān)閉這個屬性
⑹Alpha = 0
在某些情況下可能會使用到將Canva Group組件中的Alpha設(shè)置為0來隱藏UI报亩，雖然不會增加draw call浴鸿，但在引擎處理的時候?qū)嶋H上還是畫了一個透明度為0的面片，這種隱藏方法依然會觸發(fā)GPU渲染弦追。

加載模塊

主要出現(xiàn)于場景切換處岳链，且CPU占用峰值均較高 → 前一場景的場景卸載和下一場景的場景加載。
⑴場景卸載
調(diào)用SceneManger.LoadScene時劲件，引擎即會對上一場景進行處理
其主要開銷如下:
--Destroy
引擎在切換場景時會收集未標(biāo)識成"DontDestroyOnload"的GameObject掸哑，然后進行Destroy。同時零远，代碼中的OnDestroy被觸發(fā)執(zhí)行苗分，這里的性能開銷主要取決于OnDestroy回調(diào)函數(shù)中的代碼邏輯。
--Resource.UnloadUnusedAssets
一般情況下牵辣，場景切換過程中摔癣，該API會被調(diào)用兩次，一次為引擎在切換場景時自動調(diào)用纬向，另一次則為用戶手動調(diào)用(一般出現(xiàn)在場景加載后择浊，用戶調(diào)用他拉確保上一場景中的資源被卸載干凈)，其耗時開銷主要取決于場景中Asset和Object的數(shù)量逾条，數(shù)量越多琢岩、耗時越長。
⑵場景加載
--資源加載(90%以上)
其加載效率主要取決于資源的加載方式(R.L和AB加載)师脂、加載量(紋理粘捎、網(wǎng)格、材質(zhì)等資源數(shù)據(jù)的大小)和資源的格式(紋理格式危彩、音頻格式等)。
--Instantiate實例化
①資源加載泳桦，在Instantiate實例化時汤徽，引擎底層會查看其相關(guān)的資源是否已經(jīng)被加載，如果沒有灸撰，則會先加載其相關(guān)資源谒府，再進行實例化 → Instantiate耗時的根本原因。
②除此之外浮毯，Instantiate實例化的性能開銷還體現(xiàn)在腳本代碼的序列化(當(dāng)GameObject上Component數(shù)目比較多時完疫，其Instantiate實例化性能會受到影響)和構(gòu)造函數(shù)的執(zhí)行上。(Awake和Start函數(shù)中的代碼邏輯债蓝，其產(chǎn)生的開銷也會被計算在Instantiate實例化內(nèi))
資源加載是加載模塊中最為耗時的部分壳鹤，其CPU開銷在Unity中主要體現(xiàn)在Loading.UpdatePreloading和Loading.ReadObject

Loading.UpdatePreloading
Loading.UpdatePreloading這一項僅在調(diào)用類似LoadLevel(Async)的接口處出現(xiàn)，主要負(fù)責(zé)卸載當(dāng)前場景的資源并且加載下一場景中的相關(guān)資源和序列化信息等饰迹。下一場景中芳誓，自身所擁有的GameObject和資源越多余舶，其加載開銷越大。(在很多項目中锹淌，存在另外一種加載方式匿值，及場景為空場景，絕大部分資源和GameObject都是通過OnLevelwasloaded回調(diào)函數(shù)進行加載赂摆、實例化和拼合的挟憔，對于這種情況，Loading.UpdatePreloading的開銷會很小)

Loading.ReadObject
Loading.ReadObject這一項記錄的則是資源加載時的真正資源讀取性能開銷烟号，基本上引擎的主流資源(紋理绊谭、資源、網(wǎng)絡(luò)資源褥符、動畫片段等)讀取均是通過該項來進行體現(xiàn)的龙誊。可以說這一項很大程度上決定了項目場景的切換效率喷楣。
另外趟大，在使用Resources.UnloadUnusedAssets()時有可能造成一定的卡頓，盡量不要主動使用铣焊，在切換場景時會自動調(diào)用該API逊朽。

從點擊應(yīng)用到出現(xiàn)游戲畫面，加載時間受哪些方面的影響曲伊？
①Resource文件夾中的資源數(shù)量叽讳。在游戲啟動時，Unity引起會為Resource文件夾下的資源建立一個查找樹來存放與其對應(yīng)的索引坟募，便于后續(xù)資源的加載岛蚤。一般來說，Resource文件夾下資源數(shù)量越多懈糯，其構(gòu)建時間越長涤妒，應(yīng)用啟動也就越慢。
②首場景的資源加載和相關(guān)代碼的初始化工作赚哗。如果首場景的資源量越多她紫，其腳本初始化的任務(wù)越繁重，則應(yīng)用的啟動時間也會越慢屿储。

物理:

1.少用或不用mesh colider(網(wǎng)格碰撞器)
太復(fù)雜贿讹，網(wǎng)格碰撞器利用一個網(wǎng)格資源并在其上構(gòu)建碰撞器。對于復(fù)雜網(wǎng)狀模型上的碰撞檢測够掠，它要比應(yīng)用原型碰撞器精確的多民褂。
2.設(shè)置一個合適的Fixed Timestep
Fixed Timestep和物理計算有關(guān)，若計算的頻率太高，增加CPU的開銷
3.優(yōu)化物理算法

GC(Garbage Collection)

GC:主要作用在于從已用內(nèi)存中找出那些不再使用的內(nèi)存助赞，并進行釋放
GC是Mono運行時的機制买羞，而非Unity3D游戲引擎的機制，故GC不是用來處理引擎的Assets的內(nèi)存釋放的雹食。
什么東西會被分配到托管堆上? → 引用類型(類的實例畜普、字符串、數(shù)組等)
而值類型是分配到堆棧上而非堆上群叶。
所以GC的優(yōu)化其實就相當(dāng)于是代碼的優(yōu)化吃挑。
下列兩種情況會觸發(fā)GC:
⑴當(dāng)空閑內(nèi)存不足時會觸發(fā)GC。(PS:GC釋放的內(nèi)存只會留給Mono使用街立，并不會交還給舶衬，因此Mono堆內(nèi)存是只增不減的)
⑵在代碼中通過調(diào)用GC.Collect()手動進行GC，但是GC本身是比較耗時的操作赎离，而且由于GC會暫停那些需要Mono內(nèi)存分配的線程(C#代碼創(chuàng)建的線程和主線程)逛犹，因此無論是否在主線程中調(diào)用，GC都會導(dǎo)致游戲一定程度的卡頓梁剔，需要謹(jǐn)慎處理虽画。
Mono內(nèi)存泄漏:對象不再使用卻沒有被GC回收的情況 → 會導(dǎo)致空閑內(nèi)存減少，GC頻繁荣病，Mono堆不斷擴充码撰，最終導(dǎo)致游戲占用的內(nèi)存升高。
※游戲中大部分Mono內(nèi)存泄漏的情況都是由于靜態(tài)對象的引用而引起的个盆，因此對于靜態(tài)對象盡量少用脖岛，對于不再使用的靜態(tài)對象將其引用設(shè)置為null，使其可以即使被GC回收颊亮。
GC使用注意點:
⑴字符串連接的處理柴梆。因為將兩個字符串連接的過程，其實是生成一個新的字符串的過程终惑。而作為引用類型的字符串轩性，其空間是在堆上分配的，被棄置的舊的字符串的空間會被GC當(dāng)做垃圾回收狠鸳。
⑵盡量不用使用foreach，foreach循環(huán)將會在每一次迭代中創(chuàng)建一個enumerator對象悯嗓，這時候GC會對enumerator對象進行回收處理件舵，消耗資源。
⑶不要直接訪問gameobject的tag屬性脯厨。比如if (MyGameObject.tag == “Player”)最好換成if (MyGameObject.CompareTag (“Player”))铅祸。因為訪問物體的tag屬性會在堆上額外的分配空間。
⑷使用對象池 → 實現(xiàn)空間的復(fù)用
⑸最好不用LINQ的命令，因為它們會分配臨時的空間临梗，同樣也是GC收集的目標(biāo)涡扼。
⑹盡量減少代碼堆內(nèi)存分配，應(yīng)避免頻繁創(chuàng)建和開辟空間盟庞，防止頻繁觸發(fā)GC吃沪，同時在Loading或者對性能不敏感的時候主動GC。

二什猖、GPU

GPU的性能瓶頸主要存在于以下幾個方面:
1.Fill Rate(填充率)票彪，是指顯卡每幀或者說每秒能夠渲染的像素數(shù)。在每幀的繪制中不狮，如果一個像素被反復(fù)繪制(overdraw)的次數(shù)越多降铸，那么它占用的資源也必然越多。目前在移動設(shè)備上摇零，F(xiàn)illRate的壓力主要來自半透明物體推掸。因為多數(shù)情況下，半透明物體需要開啟Alpha Blend并且關(guān)閉ZTest和ZWrite(shader中的渲染隊列)驻仅，同時如果我們繪制像alpha = 0這種實際上不會產(chǎn)生效果的顏色上去谅畅，也會有Blend操作，這是一種極大的浪費雾家。
2.像素的復(fù)雜度铃彰，比如動態(tài)陰影、光照芯咧、復(fù)雜的shader等牙捉。
3.幾何體的復(fù)雜度(頂點數(shù)量)。
4.GPU的顯存帶寬敬飒。

降低填充率
在開發(fā)過程中應(yīng)注意避免overdraw和盡量降低overdraw邪铲，降低overdraw有以下幾種方法:
⑴盡量減少alpha = 0的資源的使用，因為這種資源也會參與繪制无拗，占用一定的GPU带到。
⑵制作圖集的時候，盡量使小圖排布緊湊英染，盡量圖集中大面積留白揽惹，理由同上。
⑶避免無用對象及組件的過度使用(比如新手教學(xué)部分用了很多“不可見”的Image作為交互響應(yīng)的控件四康；但這些東西雖然畫上去沒有效果搪搏，依然占用了顯卡資源，特別是有很多大塊的區(qū)域)闪金，這種情況下可以實現(xiàn)一個只在邏輯上響應(yīng)Raycast但是不參與繪制的組件即可疯溺。
具體可參考以下文章:https://blog.uwa4d.com/archives/fillrate.html
⑷通過修改渲染隊列也能降低overdraw论颅。
⑸注意UI文本的空白區(qū)域引起的overdraw。UI文本字形是作為獨立的面片(quad)進行渲染的囱嫩，每個字符都是一個面片恃疯。這些面片通常含有大量的空白區(qū)域圍繞著字體，空白區(qū)域的大小取決于字形的形狀墨闲，在放置文本時很容易就會忽略(破壞其他UI的批處理今妄，所以對字體盡可能預(yù)留一定的空間。
⑹Image Sliced模式(九宮格拉伸)损俭，情況允許下取消勾選Fill Center(中心鏤空蛙奖，以其他UI元素覆蓋)，可以減少overdraw杆兵。

減少頂點數(shù)量
⑴保持材質(zhì)的數(shù)目盡可能少雁仲，使Unity容易批處理 → 盡可能減少模型中三角形的數(shù)目，盡可能重用頂點琐脏。(“軟邊”→減少頂點數(shù)目攒砖，并且可以使得渲染效果更加平滑。)
⑵使用紋理圖集(一張大貼圖里面包含了很多子貼圖)來代替一系列單獨的小貼圖日裙。它們可以更快地被加載吹艇，具有很少的狀態(tài)轉(zhuǎn)換，而且對批處理更友好昂拂。
⑶如果使用了紋理圖集和共享材質(zhì)受神，如果使用了紋理圖集和共享材質(zhì)，使用Renderer.sharedMaterial 來代替Renderer.material格侯。
⑷使用光照紋理(LightMap)而非實時燈光鼻听。(LightMap是一種很常見的優(yōu)化策略，它主要用于場景中整體的光照效果联四。這種技術(shù)主要是提前把場景中的光照信息存儲在一張光照紋理中撑碴，然后在運行時刻只需要根據(jù)紋理采樣得到光照信息即可。)
⑸使用LOD朝墩，好處就是對那些離得遠(yuǎn)醉拓，看不清的物體的細(xì)節(jié)可以忽略。(但如果沒有調(diào)整好距離的話可能會造成模型的突變收苏，使用時需要注意)
⑹遮擋剔除(Occlusion culling)亿卤，這里需要注意的是，合并方式也會影響Culling鹿霸，例如把整個游戲所有的樹都合并成一個DC排吴，DC是下降了，但是只要有一棵樹在攝像機里杜跷，所有合并的樹模型都會被渲染，增大了渲染帶寬和負(fù)載，需要權(quán)衡使用葛闷。
⑺使用mobile版的shader憋槐。因為簡單。

優(yōu)化顯存帶寬
壓縮圖片淑趾，減小顯存帶寬的壓力阳仔。
顯存帶寬的瓶頸:
①尺寸很大且未壓縮的紋理。(理解為一個通道扣泊，太大難過去)
②分辨率過高的framebuffer
優(yōu)化方法:
⑴設(shè)置格式壓縮
Android → ETC1
IOS → PVRTC
但對于透明紋理近范，ETC1不支持，而PVRTC則可能會有較大失真延蟹，因此更推薦使用RGBA16(要注意“色階問題”评矩，即色彩過渡不均勻，應(yīng)避免大量的過渡色使用)阱飘，RGBA32比較占內(nèi)存斥杜，不推薦使用。
另外沥匈，針對Android上帶alpha通道的圖片蔗喂，還有一種比較常見的做法:即把alpha通道獨立出來作為另外一張紋理，從而將RGB部分和alpha部分分別采用ETC1來壓縮高帖，但渲染時就需要自定義的shader來處理缰儿。
⑵Mipmap
Mipmap中每一個層級的小圖都是主圖的一個特定比例的縮小細(xì)節(jié)的復(fù)制品。因為存了主圖和它的那些縮小的復(fù)制品散址，所以內(nèi)存占用會比之前大乖阵。但是為何又優(yōu)化了顯存帶寬呢？因為可以根據(jù)實際情況爪飘，選擇適合的小圖來渲染义起。所以，雖然會消耗一些內(nèi)存(大概增加30%)师崎，但是為了圖片渲染的質(zhì)量（比壓縮要好）默终，這種方式也是推薦的。(一般UI沒有必要開啟Mipmap)

三犁罩、內(nèi)存

Unity內(nèi)存占用主要來自一下三個方面:
1.資源內(nèi)存占用
2.引擎模塊自身內(nèi)存占用
3.托管堆內(nèi)存占用齐蔽，高頻率地New Class/Container/Array等，注意盡量不要在Update等高頻函數(shù)中開辟新內(nèi)存床估。
PS:Log輸出也會占用少量內(nèi)存含滴，當(dāng)有大量Log輸出時需要注意。

資源內(nèi)存占用
⑴紋理(Texture)
①盡可能根據(jù)硬件的種類選擇硬件支持的紋理格式
②紋理尺寸越大丐巫，則占用內(nèi)存越大谈况，必要時可以使用九宮格拉伸
③Mipmap勺美，此項開啟后內(nèi)存消耗會增加1/3，UI不開啟碑韵，2D游戲所有圖片不開啟赡茸，3D場景內(nèi)貼圖開啟，角色和特效根據(jù)實際情況開啟
④Read & Write祝闻，此項開啟后內(nèi)存消耗會增大一倍(開啟后可以在運行時進行貼圖合并操作)
⑵網(wǎng)格(Mesh)
Color數(shù)據(jù)占卧、Normal數(shù)據(jù)、Tangent數(shù)據(jù)联喘，面數(shù)越多加載越慢华蜒，LOD
⑶動畫片段(AnimationClip)
①壓縮格式
②數(shù)據(jù)精度(衡量概率曲線會隨著精度的上升增加)
③動畫的類型:Generic OR? Humanoid
⑷音頻片段(AudioClip)
受LoadType和Compression Format影響
首推Mp3
默認(rèn)情況下Load in Background不開啟
非及時音效建議開啟，如bgm
大量頻繁使用的音效不開啟豁遭，如音效資源叭喜，選擇Decompressed On Load來降低CPU的開銷
對于Quality，建議選擇50%(此效果是非線性的)堤框，在某些極端情況下或?qū)σ糍|(zhì)要求不高的情況下可以選擇1%
⑸材質(zhì)(Material)
⑹著色器(Shader)
⑺字體資源(Font)
⑻文本資源(TextAsset)
另外域滥，盡量減少在Hierarchy對資源的直接引用，使用動態(tài)有效的管理方式去管理當(dāng)前場景用到的資源文件蜈抓。

Unity官方給出的一些優(yōu)化建議：
1.PC平臺的話保持場景中顯示的頂點數(shù)少于200K~3M启绰，移動設(shè)備的話少于10W，一切取決于你的目標(biāo)GPU與CPU沟使。
2.如果你用U3D自帶的SHADER委可，在表現(xiàn)不差的情況下選擇Mobile或Unlit目錄下的。它們更高效腊嗡。
3.盡可能共用材質(zhì)着倾。
4.將不需要移動的物體設(shè)為Static，讓引擎可以進行其批處理燕少。
5.盡可能不用燈光卡者。
6.動態(tài)燈光更加不要了。
7.嘗試用壓縮貼圖格式客们，或用16位代替32位崇决。
8.如果不需要別用霧效(fog)
9.嘗試用OcclusionCulling,在房間過道多遮擋物體多的場景非常有用。若不當(dāng)反而會增加負(fù)擔(dān)底挫。
10.用天空盒去“褪去”遠(yuǎn)處的物體恒傻。
11.shader中用貼圖混合的方式去代替多重通道計算。
12.shader中注意float/half/fixed的使用建邓。
13.shader中不要用復(fù)雜的計算pow,sin,cos,tan,log等盈厘。
14.shader中越少Fragment越好。
15.注意是否有多余的動畫腳本官边，模型自動導(dǎo)入到U3D會有動畫腳本沸手，大量的話會嚴(yán)重影響消耗CPU計算外遇。
16.注意碰撞體的碰撞層，不必要的碰撞檢測請舍去契吉。