成人aa视频在线观看_色婷婷精品久久二区二区蜜臂av _国产一区二区三区在线观看免费 _韩日欧美一区二区三区_午夜成人免费视频_欧美综合久久久_国产精品国产三级国产普通话99 _福利一区二区在线观看_奇米精品一区二区三区在线观看_91精品国产综合久久福利_免费精品视频在线_狠狠色丁香久久婷婷综合_中_色一区在线观看_91福利国产成人精品照片_在线观看www91_日韩高清在线一区

Unity消息系統

Unity有個消息系統，該系統用來實現游戲運行時腳本內部方法的調用。這是個非常簡單和容易理解的概念，特別對新用戶來說。只需定義一個Update方法，便可以每幀調用該方法中的內容。

一個經驗豐富的開發者肯定會對此產生疑問：
1.不清楚這個方法究竟是如何被調用的。
2.不清楚當一個場景中有多個對象時，這些方法是如何調用順序。
3.這種代碼風格不是十分智能。
UPDATE是怎么被調用的Unity并沒有使用System.Reflection進行方法的定位。
取而代之的是，首先給定類型的MonoBehaviour通過底層腳本進行檢查，判斷腳本運行過程中（無論是Mono或IL2CPP）是否有方法被定義，同時其中內容有沒有被緩存。如果檢查到特定的方法，便將其添加到一個合適的列表中。例如，當一個腳本中定義了Update方法后，這個腳本便被添加至一個需要每幀更新的腳本列表中。
在游戲過程中，Unity只需要重復執行所有列表中的方法既可。所以，你的Update方法究竟是public還是private并不重要。UPDATE方法們的執行順序是什么執行順序由腳本執行順序設置（Script Execution Order Settings）（菜單：Edit > Project Settings > Script Execution Order）決定。要手動設置1000個腳本的執行順序不是什么好主意，但是要微調某些特定腳本的執行順序還是可以的。當然，未來我們將會提供更加方便的方式來指定執行順序，比如在代碼中使用一個特性（Attribute）。無法使用INTELLISENSE在Unity中，我們使用某類IDE編譯C#腳本，這些IDE大多無法識別這些特定方法應該在何處被調用。因此常會導致警告以及玳瑁導航困難。
一些開發者用一個叫BaseMonoBehaviour或差不多名字的抽象類擴展MonoBehaviour，然后在他們的項目中的每個腳本里都擴展這個類。他們在其中寫了一些有用的功能以及一堆虛的特殊方法：這個結構可以使你在代碼中使用MonoBehaviour時更有邏輯性，但存在一個小缺點。我打賭你已經發現了……
你所有的MonoBehaviour都會儲存在Unity的內部更新列表里，你所有的腳本都會在每幀里調用所有這些基本上什么也沒用的方法！
有人可能會問為什么會有人關心一個空方法？因為這些從C++到托管C#的調用有成本上的開銷。讓我們來看看成本為何。調用10000個UPDATE我為這篇文章在Github上創建了一個示例項目，大家可以前往以下鏈接下載：
https://github.com/valyard/Unity-Updates
它有兩個場景，可以通過點擊設備或在編輯器中按任意鍵互相切換：
(1) 在第一個場景中，使用下面這樣的代碼創建了10000個MonoBehaviour：(2) 在第二個場景中，創建了另外10000個MonoBehaviour。不過，不同的是，這個代碼中并不是只調用Update，而是像下面這樣，加入了一個由Manager腳本在每幀都調用一次的自定義UpdateMe方法。測試項目在兩臺iOS設備上被編譯為Mono以及IL2CPP，發布設置中都設為非開發模式。它們的運行時間記錄如下：
1.在第一次Update調用時設置一個Stopwatch (在Script Execution Order中配置)
2.在LateUpdate時停止Stopwatch
3.將獲得的計時時間均攤到幾分鐘上

Unity版本: 5.2.2f1
iOS版本: 9.0

Mono哇！好多時間！測試肯定哪里出了問題！
實際上，我只是忘了把Script Call Optimization 設為Fast but no exceptions，但是現在我們能看到這種設置對性能的影響了……至于IL2CPP不必太在意。
Mono (fast but no exceptions)OK，這樣好多了，讓我們切換到IL2CPP。
IL2CPP這里我們發現兩件事情：
1.這個優化對于IL2CPP同樣有用
2.IL2CPP仍有改進空間，而且在寫這篇文章的同時Scripting 與IL2CPP團隊正在努力提高性能。比如，最新的Scripting分支內包含的優化可以讓測試運行快35%。

我接下來就會介紹Unity在幕后做了些什么，但是現在讓我們修改下Manager代碼，將它提速5倍！接口調用，虛調用以及數組訪問結果告訴我們，如果你想在每幀里都循環迭代擁有10000個元素的列表，那應該使用數組而不是List，因為這樣生成的C++代碼會更簡單，而數組訪問就是要快很多的。
在下一個測試中，我把List<ManagedUpdateBehavior> 改為了ManagedUpdateBehavior[]。這看起來好多了！解救之道！我們發現了從C++調用C#函數較慢，不過讓我們再研究下當調用所有這些對象的Update方法時，Unity實際上做了些什么。最簡單的方法就是使用Apple Instruments的Time Profiler。
注意這不是Mono與IL2CPP 的對比測試 — 討論的大多數內容對Mono iOS構建同樣適用。
我在iPhone6上用Time Profiler啟動了測試項目，記錄了幾分鐘的數據，然后選擇了一分鐘檢視一次。從這行代碼開始的所有東西我們都很感興趣：
void BaseBehaviourManager::CommonUpdate<BehaviourManager>()

如果你以前沒有使用過Instruments，右邊是按照執行時間排序的函數，以及它們調用的其他函數。最左邊的列是以毫秒為單位的CPU時間，以及這些函數及其調用的函數所占的CPU時間百分比。左邊第二列是函數自己的執行時間。注意，在這個實驗中Unity并沒有將CPU使用完，所以我們能看到在60秒間隔內有10秒的CPU時間花在了我們的Update上。顯然，我們關心的是那些執行時間最長的函數。
用瘋狂的Photoshop技術，將一些區域做了顏色區分，以便你能明白到底發生了什么。
UpdateBehavior.Update()
在中間你能看到我們的Update方法，以及IL2CPP是如何調用它的 ——UpdateBehavior_Update_m18。但是Unity在那之前還做了很多其他事。
循環迭代所有的Behaviour
Unity循環迭代所有的Behaviour并執行更新。特殊的迭代類SafeIterator確保了即使移除了列表中的下一項，整個循環也不會中斷。僅僅是循環迭代所有已注冊的Behaviour就用了9979ms中的1517ms。
檢測調用是否有效
下一步，Unity做了一堆檢測，確保調用的方法是屬于某個已激活已初始化且Start方法已調用過的GameObject的。你肯定不希望在Update里銷毀一個GameObject時讓游戲崩潰，對吧？這些檢測花去了整個9979ms中的另外2188ms。
準備調用方法
Unity創建了一個ScriptingInvocationNoArgs實例 (代表了一個從原生到托管的調用)以及ScriptingArguments，然后命令IL2CPP虛擬機調用方法（scripting_method_invoke函數）。這一步消耗了整個9979ms中的2061ms。
調用方法
scripting_method_invoke函數檢測傳入的參數是否有效（900ms），然后調用IL2CPP 虛擬機的Runtime::Invoke方法 (1520ms)。開始時，Runtime::Invoke檢測方法是否存在 (1018ms)。而后，它調用一個生成的RuntimeInvoker函數獲取方法簽名（283ms）。接著再依次調用我們的Update函數，根據Time Profiler，這一步花了42ms。
一個漂亮的彩色表格。托管的更新現在讓那個我們在Manager測試上使用下Time Profiler。你在屏幕截圖上可以看到，還是同樣的一些方法（有些方法因為執行時間少于1ms，甚至都沒出現），但是大部分的執行時間實際上都花在了UpdateMe函數上（或者說花在了IL2CPP調用ManagedUpdateBehavior_UpdateMe_m14上）。另外，IL2CPP還插入了一個null檢測，確保我們循環迭代的數組不會為null。
下面這個圖片使用了相同的顏色。所以，你現在怎么看，我們應該忽略那小小的方法調用嗎？有關測試的幾句話老實說，這個測試并不是完全公平的。Unity為了防止你的游戲出錯或崩潰，做了很多了不起的事：這個GameObject是否已激活？它是否在Update循環中被銷毀了？對象上是否存在Update方法？怎么處理在這個Update循環中創建的MonoBehaviour？——我的Manager腳本沒有處理這其中任何一項，僅僅是循環迭代了一堆的對象，調用它們的Update而已。
在真實世界中，Manager腳本可能會更加復雜，執行得更慢。但是，我是個開發者——我知道我的代碼要做什么，我架構我的Manger類時，知道可能的行為是什么，什么不會出現在我的游戲中。而不幸的是，Unity并不知道這些。你應該怎么做？當然這完全視你的項目而定，但實戰中碰到一個游戲在單一場景中使用大量需要在每幀都執行一些代碼的GameObject的情況并不少見。通常這看起來都是些不起眼的小代碼，似乎不會影響到任何東西，但當其數量非常巨大時，調用幾千個Update方法的開銷將變得顯著。這個時候再去修改游戲架構，重構這些對象為Manager樣式，可能已經為時已晚。
你現在有數據了，在你開始下一個項目時考慮下吧。