在上一期《場景檢測：霧效、Canvas和碰撞體》中，我們依託本地資源檢測中和場景檢測相關的規則，把涉及到的知識點跟大家進行了簡單的講解。這些看似細小的知識點，很容易在大家的開發和學習過程中被疏忽，而長期的問題積累最終都會反映到項目的性能表現上。爲此，我們將這些規則列出，並且以一個個知識點的形式向大家逐一解讀。
本期，我們將繼續聚焦場景相關的檢測規則：“掛載多個AudioListener的物體”、“檢測場景物件與Prefab的連接是否正常”和“掛載RigidBody的靜態物體”，我們將力圖以淺顯易懂的表達，讓職場萌新或優化萌新能夠深入理解。
1、掛載多個AudioListener的物體
這裏涉及到的其實是Unity的音頻播放的相關知識。這裏我們來簡單講一下AudioSource組件和AudioListener組件。
AudioSource組件，主要是用於音頻的播放。它可以對音頻進行諸如播放情況、音量、混合以及播放速度等多種設定。形象點講這就是Unity場景中的DJ化身。
Audio Listener一般用於音頻的收聽。Audio Listener就是我們在場景中的“耳朵”，沒有它的話，我們是聽不到場景中任何聲音的。AudioListener組件沒有屬性設置界面，它只服務於“收聽音頻”這麼一件事，是一個“存在即合理”的組件。
Audio Listener一般都掛載在攝像機上，而且這也比較符合邏輯：隨着鏡頭視野的移動，我們能動態接收到相關範圍內的音頻訊息的變化。Unity官方文檔中提到：每個場景只能有1個Audio Listener來合適地工作。這是因爲：在同一時刻，即使有多個物體上有多個Audio Listener，也只能有1個起作用。我們不排除由於特殊需求，在不同位置的不同物體上都掛載Audio Listener，或在不同時刻啓用不同的Audio Listener來實現3D音效的情況。但是一般情況下，在同一個物體上掛載多個Audio Listener大概率是沒有意義的。因此，本條規則檢測出的即爲場景中同一個GameObject上掛有多個Audio Listener的情況。
開發團隊可以對本條規則排查出的物體進行檢查，以規範場景中對Audio Listener這一組件的使用。
2、檢測場景物件與Prefab的連接是否正常
Prefab，即預製體，這是Unity中最常見的資源類型。在Unity場景裏，我們經常會涉及到大量相同或者相似對象的使用與管理。比如批量修改資源屬性設置，以及修改屬性時不改動相關的資源的單獨設置，對Unity而言，Prefab就非常適合處理這些情況。最常見的例子就是MMORPG遊戲中的刷怪點。
當我們修改原始Prefab資源時，所有由它而來的Prefab實例都會同步修改並應用對應的設置，而且不會改動具體實例的特殊化設定。比如修改Prefab資源裏的野狼，把皮膚顏色由棕色換成銀白，那麼所有野狼刷怪點的狼都會變成銀白色，但精英刷怪點的野狼身上的火焰特效會繼續存在。
而當派生的Prefab實例與原始Prefab的連接處於中斷狀態的話，這種對原始Prefab資源的修改就無法同步到這些出問題的實例上。比如一羣銀白雪狼裏卻有幾隻灰狼突兀地夾雜在刷怪點裏，那麼整個場景的和諧感都會被破壞掉。
本條規則將GameObject與Prefab的Missing或Disconnected兩種狀態都視爲“連接不正常”，典型的Missing出現在GameObject對應的Prefab被刪除的情況下，而Disconnect會由項目對Unity版本的升級等原因造成。當遇到類似情況時，我們建議研發團隊要麼將GameObject與Prefab之間的關係徹底解除（Unpack），要麼將兩者之間的連接關係重新恢復，以規範項目的開發。
3、掛載RigidBody的靜態物體
在上一篇《場景檢測：霧效、Canvas和碰撞體》中，我們簡單介紹了碰撞體的概念，而在項目的實際開發中，Collider和RigidBody往往是配合使用的。
如果說碰撞體組件使得場景中相關物體去遵守“物理法則”，那麼RigidBody組件則賦予了相關物體對應的“物理屬性”。
我們可以在RigidBody組件上爲物體設置各種屬性，例如質量、阻力、重力生效與否、運動學規律生效與否等多種基於現實物理規律模擬的屬性設定。
在真實世界裏，物理規律對萬事萬物都有影響；但在Unity項目場景中，出於場景實際需求和項目性能限制，很多場景元素其實不需要擁有物理屬性，就比如作爲不可動的地形元素石頭、樹木等，加了重力，摩擦力等屬性不僅不會提升場景的擬真效果，反而會造成不必要的性能消耗。對於這類不需要具備運動屬性的物體，我們可以勾選“Static”，Unity Editor會對靜態物體的某些信息進行預計算（如靜態合批）。
如果開啓了Static的GameObject上掛載了RigidBody組件，那麼不但會造成不必要的物理開銷，還會產生一些意外的運動效果。所以當本條規則檢測出這些帶有RigidBody的Static物體後，開發團隊進行進一步的檢查和判斷，然後就可以果斷刪除相關靜態物體的RigidBody組件，以降低不必要的計算開銷。
希望以上這些知識點能在實際的開發過程中爲大家帶來幫助。需要說明的是，每一項檢測規則的閾值都可以由開發團隊依據自身項目的實際需求去設置合適的閾值範圍，這也是本地資源檢測的一大特點。同時，也歡迎大家來使用UWA推出的本地資源檢測服務，可幫助大家儘早對項目建立科學的美術規範。
萬行代碼屹立不倒，全靠基礎掌握得好！
相關推薦
性能黑榜相關閱讀
《那些年給性能埋過的坑，你跳了嗎？》
《那些年給性能埋過的坑，你跳了嗎？（第二彈）》
《掌握了這些規則，你已經戰勝了80%的對手！》