modbus調試團結

曾幾何時，有一個統一的游戲程序員叫做Lancelot。 我會說，這是一個非常熱情的人。 他還不知道，但是最終他將面對Unity垃圾回收最黑暗的一面。

蘭斯洛特一直在尋找更大的

更大的標題需要處理。 因此，他努力工作，以獲得在游戲行業的巨大機會。

他知道這并不容易。

游戲行業中的這些位置過去是，現在仍然是為少數游戲程序員保留的。 而且他不確定自己是否會達到標準。

但是他堅持并繼續提高他的編程技巧。

蘭斯洛特開始從事小型游戲。 他想，也許在某個時候，他會得到他尋找的巨大機會。

幾年過去了，直到他獲得了等待的機會。 他被要求將大型VR游戲移植到移動平臺上。 像蘭斯洛特一樣興奮，他不停地想知道自己是否

足以勝任這項任務。 這令人生畏，但他接受了挑戰。 他知道自己只能從中成長。

蘭斯洛特最大的擔憂是需要大幅提高游戲性能。 實際上，這是雙重挑戰。 他必須

在功能相對不那么強大的平臺 上將性能提高20％ 。

經過幾個月的不間斷工作，他終于設法對游戲進行了足夠的優化，以達到堅實的性能基準。

但是，一個意外的問題迫在眉睫……

統一的分析器向他顯示，每隔幾秒鐘便有相當大的幀速率下降。 這讓他感到擔心，因為那將不允許他發布游戲。 游戲發布處于危險之中。 那使他完全不舒服。

根據他以前的經驗，蘭斯洛特很快就懷疑

垃圾收集器 。 畢竟，他知道在游戲中過多分配臨時內存可能會導致這些性能峰值。 就像每個人廚房中的垃圾桶一樣，當垃圾量達到其容量的80％時，就該清理它了。

因此，他花了幾天的時間來解決煩人的內存分配問題。 他執行了他能想到的所有類型的優化。 對象池，數據緩存，數據結構優化...

這些天的花費優化使他在性能旅程中遙遙領先。 蘭斯洛特（Lancelot）為自己的工作感到自豪，但是直到他看到垃圾收集器每15秒仍在運行時，他的擔憂才會增加。

在這些性能下降的情況下在VR中玩游戲會使人顯得蒼白。

“那怎么可能發生？” 他想知道。

經過更多的耐心和挖掘，Lancelot發現了他之前從未見過的第二個內存分配來源。 那些發生在

第三方圖書館 。

他看了一下，很快就意識到自己處于有史以來最糟糕的位置：該庫是封閉源代碼。 不僅如此，他還嘗試使用Unity的

增量垃圾收集器，但他負擔不起性能價格。

Lancelot的選項已用完。

他感到絕望，但設法保持鎮定。 畢竟他一直處在更糟糕的情況下。

他可以

對庫進行反向工程 ，然后自己進行內存分配優化。 問題是許可證不允許這種事情。 而且他還太年輕，無法入獄。

他考慮的第二個選擇是

在堆上預分配大量內存。 他知道，當堆使用率達到一定百分比時，團結會觸發垃圾回收過程。 因此，增加堆應該給他更多的時間來進行垃圾回收。

可悲的是，這還不夠。

慢慢地，他感覺好像無法控制局勢。 很難，但再次，他

堅持不懈 。

所以蘭斯洛特想出了一個

瘋狂的主意 。 如果他完全禁用垃圾收集怎么辦？ 那有可能嗎？ 他覺得自己的想法有多危險。 他不想增加游戲崩潰的可能性。 上一次他檢查時，對球員來說那并不好玩。 也許時代確實發生了變化，但總比后悔好。

最重要的是，他擔心推遲游戲的發布。 他不想讓他的球員在圣誕節錯過這個冠軍。 他記得在這些假期里玩EverQuest有多少樂??趣。 他不會從球員身上奪走這些。

達到這一點，他除了禁用垃圾收集器外別無選擇。

他進入研究模式，發現他確實可以

手動禁用垃圾收集 。 他進行了數十次實驗，以查看游戲在不耗盡內存的情況下能保持多長時間。 他做了各種各樣的測試來強調系統。 單擊各處，四處走動，在不同的應用程序之間切換。 數字開始出現在他的電子表格中：25分鐘，28分鐘，30分鐘...他還指出堆使用率隨時間增加的方式，以確保他永遠不會超過安全預算。

有了這些數字，蘭斯洛特建立了一個慷慨的

保證金并準備了原型。 他將在加載屏幕期間和每隔幾分鐘手動運行垃圾收集。

他又有了希望。

他彬彬有禮地要求qa進行數十遍游戲。

記憶總是在預算之內。 沒有崩潰。 沒有副作用。

漫長的旅程將他帶到了他能夠

運送游戲。

你猜怎么著？ 在圣誕節期間，數百名玩家現在正在享受它。

一開始，他對這種解決方案不滿意。 這是一個冒險的舉動，他知道。 但是他設法做到了。

蘭斯洛特學會了適應

不舒服 。 他學會了更加務實 。 因為有時候必須要有程序員。

故事有什么響嗎？ 如果是這樣，您的直覺可能是正確的。

那個程序員就是我。

在您需要的時候，這是管理垃圾收集器的方式：

public?class?GarbageCollectionManager?:?MonoBehaviour {[SerializeField]?private?float?maxTimeBetweenGarbageCollections?=?60f;private?float?_timeSinceLastGarbageCollection;private?void?Start(){ #if?!UNITY_EDITORGarbageCollector.GCMode?=?GarbageCollector.Mode.Disabled; #endif//?You?might?want?to?run?this?during?loading?times,?screen?fades?and?such.//?Events.OnScreenFade?+=?CollectGarbage;}private?void?Update(){_timeSinceLastGarbageCollection?+=?Time.unscaledDeltaTime;if?(_timeSinceLastGarbageCollection?>?maxTimeBetweenGarbageCollections){CollectGarbage();}}private?void?CollectGarbage(){_timeSinceLastGarbageCollection?=?0f;Debug.Log("Collecting?garbage");?//?talking?about?garbage...? #if?!UNITY_EDITOR//?Not?supported?on?the?editorcGarbageCollector.GCMode?=?GarbageCollector.Mode.Enabled;GC.Collect();GarbageCollector.GCMode?=?GarbageCollector.Mode.Disabled; #endif} }?該代碼段向您展示了如何禁用自動垃圾收集。 它每分鐘以及可能在屏幕轉換（淡入黑色）期間手動運行GC過程。

請注意其可能的副作用：

-崩潰：如果您的游戲不夠安全，將耗盡內存。 更糟糕的是，當您在應用程序之間切換時，操作系統可能會殺死您的游戲

-更長的垃圾收集時間：增加堆將使以后的垃圾收集速度變慢

如果您需要產生大量的垃圾，這是一個簡單有效的方法：

public?class?GenerousGarbageCreator?:?MonoBehaviour {[SerializeField]?private?int?garbageCreationRate?=?1024;private?static?int[]?_garbage;void?Update(){_garbage?=?new?int[garbageCreationRate];} }?這樣一來，您將看到內存使用率增加。 不斷增長的堆使用情況突出顯示為“單”。 幸運的是，我們每3秒運行一次手動垃圾收集器。

有關更常規的內存優化，您可能對Unity可尋址對象感興趣（請參閱我的博客）。 使用可尋址對象，您可以減少總的內存使用量，從而可以減少觸發垃圾回收的頻率。 反過來，這將減少您的播放器會遇到的性能峰值。

魯本

翻譯自: https://bytes.com/topic/c-sharp/insights/973685-unity-breaking-rules-garbage-collection

modbus調試團結

總結

以上是生活随笔為你收集整理的modbus调试团结_团结：打破垃圾收集规则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。