UI耗時(shí)函數(shù)
1.1 Canvas.SendWillRenderCanvases
這個(gè)函數(shù)是由于自身UI的更新，產(chǎn)生的耗時(shí)
1. 這里更新的是vertex 屬性，比如 color、tangent、position、uv，修改recttransform的position、scale，rotation并不會(huì)導(dǎo)致頂點(diǎn)屬性改變，因?yàn)轫旤c(diǎn)的position是根據(jù)pivot的偏移決定的，而改變其size、pivot、anchor，則會(huì)修改UI的transform屬性，從而引發(fā)重建，還包括替換圖片，更新文本等
2. 優(yōu)化建議：隔幀更新
1.2 Canvas.BuildBatch & EmitWorldScreenspaceCameraGeometry?
?網(wǎng)格重建包含了UI更新，比如recttransform位置的改變，雖然沒有UI更新，但有網(wǎng)格重建
1. Canvas.BuildBatch:UI元素改變導(dǎo)致需要重新build mesh 時(shí)，主線程調(diào)用該函數(shù)發(fā)起網(wǎng)格合并。
2. 合并的過程在子線程中實(shí)現(xiàn)，如果網(wǎng)格過于復(fù)雜，出現(xiàn)了主線程的等待，則耗時(shí)會(huì)被統(tǒng)計(jì)到
EmitWorldScreenspaceCameraGeometry這個(gè)函數(shù)里面
3. unity 會(huì)把同一個(gè)canvas下的所有UI合并成一個(gè)mesh，根據(jù)層級(jí)的不同，分成多個(gè)submesh，所以盡可能合批，減少submesh，減少drawcall
4. 優(yōu)化建議：增加合批、動(dòng)靜分離
1.3 SyncTransform
對(duì)于UI元素調(diào)用SetActive（false改成true）會(huì)導(dǎo)致：
該Canvas下所有的同級(jí)UI元素觸發(fā)SyncTransform，從而導(dǎo)致較高的耗時(shí)。
?
該Canvas的父Canvas下的同級(jí)UI元素觸發(fā)SyncTransform
該UI元素同級(jí)的canvas下的UI元素不會(huì)觸發(fā)SyncTransform
一句話：同級(jí)及父級(jí)下的UI元素，除了canvas 都會(huì)SyncTransform
優(yōu)化建議：通過設(shè)置local scale=0/1來實(shí)現(xiàn)相同的效果
1.4 EventSystem.Update
EventSystem組件主要負(fù)責(zé)處理輸入、射線投射以及發(fā)送事件、UI的創(chuàng)建會(huì)自動(dòng)創(chuàng)建相關(guān)組件處理UI點(diǎn)擊事件。raycast target 不用就關(guān)閉它
DrawCall優(yōu)化
2.1 合并圖集
盡量整合并制作圖集，從而使得不同U元素的材質(zhì)圖集一致。圖集中的按鈕、圖標(biāo)等需要使用圖片的比較小的UI元素，完全可以整合并制作圖集。當(dāng)它們密集地同時(shí)出現(xiàn)時(shí)，就有效降低了DrawCall
2.2 重疊打斷合批
在同一Canvas下、材質(zhì)和圖集一致的前提下，要避免重疊時(shí)的層級(jí)穿插。簡(jiǎn)單概括就是，應(yīng)使得符合合批條件的UI元素的“層級(jí)深度”相同;
這里的重疊，是UI元素重疊，而不是Recttransform 的重疊
2.3 Z！= 0
當(dāng)UI元素的Z！=0時(shí)，也會(huì)產(chǎn)生合批被打斷的情況
加載卸載api
1.1 Shader 耗時(shí)
Shader的解析和編譯耗時(shí)一般是指，在Shader資源被加載進(jìn)內(nèi)存后觸發(fā)的Shader.Parse()和Shader.CreateGPUProgram兩種API的耗時(shí)
shader在進(jìn)入一個(gè)場(chǎng)景的時(shí)候，是把該場(chǎng)景的shader一次性全部加載進(jìn)來，可以通過shader變體集來優(yōu)化
如果一個(gè)shader 重復(fù)打進(jìn)ab包內(nèi)，當(dāng)每個(gè)ab包被加載的時(shí)候，就會(huì)產(chǎn)生一種耗時(shí)
1.2 Resources.UnloadUnusedAssets
Resources.UnloadUnusedAssets為Unity遍歷所有資源的(gameobject、mono對(duì)象)引用情況并卸載Unused對(duì)象的API，一般在場(chǎng)景切換時(shí)由Unity自動(dòng)觸發(fā)或由開發(fā)者手動(dòng)調(diào)用。耗時(shí)主要體現(xiàn)在遍歷上
優(yōu)化方法：
1. 減少material和粒子數(shù)量，這樣會(huì)減少mono對(duì)象的數(shù)量
2. 使用assetbundle.unload、resources.unloadasset 先卸載一部分資源
resources.unloadassets:只能用于卸載resource.load的單個(gè)資源，比如材質(zhì)球，紋理，等不能用來卸載gameobject、assetbundle、component，因?yàn)樗鼈兪菑?fù)雜的資源。
3. 如果不切換場(chǎng)景，嘗試在每5-10分鐘調(diào)用一次該方法，釋放內(nèi)存
1.3 異步加載優(yōu)先級(jí)
異步加載是很多項(xiàng)目中場(chǎng)景切換時(shí)加載資源的做法，但往往受Application.backgroundLoadingPriority這一API的默認(rèn)設(shè)置限制而效率低下
異步方法：
Scenemanager.LoadSceneSync、Scenemanager.UnLoadSceneSync
Assetbundle.LoadAssetSync、Resources.LoadAssetSync
異步加載優(yōu)先級(jí)Application.backgroundLoadingPriority:限制主線程的集成時(shí)間，單幀內(nèi)最長(zhǎng)可用異步操作時(shí)間，unity 中默認(rèn)設(shè)置為BelowNormal，異步加載是在后臺(tái)加載線程中進(jìn)行數(shù)據(jù)讀取和反序列化，然后在主線程中對(duì)其調(diào)用，調(diào)用的方式，取決于加載的資源類型，比如Texture 、Meshes 是上傳到GPU對(duì)其繪制，?audio clips 準(zhǔn)備 playing.
- ThreadPriority.Low - 2ms
- ThreadPriority.BelowNormal - 4ms
- ThreadPriority.Normal - 10ms
- ThreadPriority.High - 50ms
體現(xiàn)到profiler中的函數(shù)為Application.IntegrateAssetslnBackground的耗時(shí)
優(yōu)化方向：
異步加載時(shí)處于戰(zhàn)斗場(chǎng)景:設(shè)置調(diào)高會(huì)增加主線程耗時(shí),可能影響性能
異步加載時(shí)處于加載界面:建議設(shè)置調(diào)高,盡量縮短加載時(shí)間
1.4 加載和卸載AssetBundle
加載assetbundle的方法：
Load From Memory:
Load From File：
Load From Stream：
DownLoadHandlerAssetBundle：
壓縮格式：
BuildAssetBundleOptions.None:使用LZMA算法壓縮
BuildAssetBundleOptions.ChunkBasedCompression:使用LZ4算法壓縮
LZMA:stream-based,只支持順序讀取,加載需要將整個(gè)包解壓
LZ4:chunk-based,支持隨機(jī)讀取,加載速度快
?文章來源：http://www.zghlxwxcb.cn/news/detail-623459.html
1.5?實(shí)例化和銷毀對(duì)象
頻繁大量的實(shí)例化和單次實(shí)例化過長(zhǎng)都是可能困擾開發(fā)者的性能問題，而緩存池、分幀加載等策略和技巧可能獲得良好的優(yōu)化效果。文章來源地址http://www.zghlxwxcb.cn/news/detail-623459.html
到了這里，關(guān)于Unity 性能優(yōu)化四：UI耗時(shí)函數(shù)、資源加載、卸載API的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
