Instruments如何看Mono內存分配

時間 2021-02-15

標籤 html 數組網絡 app 編輯器 ide 工具測試優化網站欄目 HTML 简体版

原文原文鏈接

1）Instruments如何看Mono內存分配
2）關於Addressable v1.11.2的疑問
3）展開UV2時致使Mesh頂點數增長
4）提高Unity編輯器中代碼的編譯速度
5）Renderdoc調試的疑問html

這是第217篇UWA技術知識分享的推送。今天咱們繼續爲你們精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。數組

UWA 問答社區：answer.uwa4d.com
UWA QQ羣2：793972859（原羣已滿員）網絡

Memory

Q：例如在分配了一個10MB數組，對應在Unity Profiler中會看到開闢了至少10MB大小的Mono內存。app

那麼在Instruments中，如何查看分配的內存信息呢？Allocations中的信息是此進程中分配的全部內存信息嗎，嘗試分配過100MB內存，Allocations中的統計沒有任何增加。編輯器

A：我這邊也作了測試：

建立了100MB大小的int數組，Size實際應該是400MB。ide

而後到Profile觀察：工具

能夠看到ManagedHeap正確分配了這400MB的空間。測試

而後打包iOS後到Xcode運行，運行前首先把Run這個Scheme的Malloc Stack勾上。優化

RUN之後點選Memory並導出Memory Graph來觀察：網站

因爲應用程序的內存都是在VirtualMemory空間分配的，所以查看VM Regions的VM_ALLOCATE部分。

能夠發現128X3+16恰好400MB的分配。

調用堆棧也很好肯定：

正是咱們的測試代碼。

而後咱們來看Instruments。首先是Allocations部分，有一點要注意，該欄的下部有一些選項：

注意最後一個選項，若是選擇第一個：

All Heap & Anonymous VM，All Heap對應App實際分配的物理空間，不包含VM，Anonymous VM的官方解釋是：

interesting VM regions such as graphics- and Core Data-related. Hides mapped files, dylibs, and some large reserved VM regions。

所以一些比較大的預留分配空間是不會顯示的。

將這個選項切換爲All VM Regions，就能看到分配的400M了：

而且右邊詳情頁面也正確顯示了調用堆棧：

另外，咱們還能夠從VM Tracker來觀察。打開VMTracker的Snapshots：

就能看到這400MB的詳細分配信息：

能夠發現，Virutal Size略大於400MB，由於程序其餘部分也要申請一些內存。而這400MB又分別保存在Resident和Swapped內，其中Resident部分又基本等於Dirty Size，說明這部分大小的空間被標記了Dirty是不能被交換出去的，剩下240MB左右空間是Clean空間，能夠暫時被交換出去以保證有足夠的物理空間能使用。這也是由於咱們只是申請了這部分空間，並無進行具體的賦值初始化和使用。

那若是賦值使用了呢？修改代碼測試

運行Instruments後再觀察：

能夠清楚的發現這400MB都在Dirty Size內。這種狀況真正會給該App和iOS之內存壓力。

推薦閱讀：
《寫給Unity開發者的iOS內存調試指南》

《Understanding iOS Memory (WiP)》

感謝黃程@UWA問答社區提供了回答

Addressable

Q：關於Addressable v1.11.2開始編輯器在「Fast Mode」模式下運行會獲取SubAsset失敗的問題。

A：今天將項目使用Addressables系統從1.8.4升級到1.14.2。忽然發現AssetReference指向的資源進行實例化老是報Key無效的錯誤。調查後發現從1.11.2開始，爲了給FastMode進一步加速，官方修改了流程。

以前版本即便是Fast Mode下，也是要進行一次Build，而且Play時讀取Build出來的Catalog，Catalog會序列化全部的AssetEntry和SubAsset，生成ResourceLocationMap對象而後進行檢索。咱們使用了很多AssetReference來指向SubAsset使用。這時使用沒有問題。

1.11.2版本開始，Fast Mode直接提供編輯器環境下AddressableAssetSettings對象的GUID而非Catalog文件路徑，所以Play後初始化時則會啓用FastMode專用的初始化操做FastModeInitializationOperation，這時生成的不是ResourceLocationMap，而是AddressableAssetSettingsLocator，這個Locator只是遍歷了編輯器Group窗口對應可見的Group內的AssetEntry，而AssetEntry內部的SubAsset則不會被遍歷到，所以若是遊戲中用到SubAsset，就會報Key無效的錯誤。

官方Changelog：
Refactored Play Mode Script for "Use Asset Database" to pull data directly from the settings. This reduces the time needed to enter play mode.
建議：

暫時只使用v1.8.4版本（經項目長期使用，相對較爲穩定）

不建議使用1.9.2到1.11.2期間版本，還有其餘bug

升級到最新的狀況下，使用Simulate Groups模式進行開發

等待官方後續改進

感謝題主黃程@UWA問答社區提供了回答

Rendering

Q：在Unity中自動展開UV2（Generate Lightmap UVs），會形成個別物體的Mesh中頂點個數增長。

我自動展開的一個地面，頂點數從134變成136，若是不展開UV2，是沒有問題的。請問，有什麼辦法能夠在展開UV2時，不增長頂點個數嗎？

在導入FBX模型時，沒有勾選優化Mesh和其餘影響頂點的一些選項。

A：由於有時候2個面片對應到Lightmap上2個不連續區域，而這兩個面片上的頂點可能共享，所以須要拆開成2個頂點，其餘數據一致，可是UV2不一樣。屬於正常現象。
想要不增長，除非美術手動設置UV2並導出，即使如此，若是模型在一些面是包圍閉合的，也很難保證頂點不重複。其實這個時候是頂點在Maya等工具內已經作了增長後導出。Unity內可能看不出變化。

感謝黃程@UWA問答社區提供了回答

Build

Q：有沒有什麼辦法能夠提高Unity編輯器中代碼的編譯速度？咱們如今每修改一次代碼，等待的編譯時間都將近半分鐘。

A1：對於大型項目來講，這確實是你們常常遇到的狀況。通常來講，Unity Editor會按照腳本的依賴關係編譯代碼，其主要分爲如下四個步驟：

編譯Standard Assets、Pro Standard Assets和Plugins文件夾中的Runtime Script；

編譯以上三個文件夾中Editor文件夾下的Script；

編譯項目中全部剩餘的Runtime Script（Editor文件夾之外Script）；

編譯剩餘Script（即Editor文件夾中Script）。

知道了Unity編輯器的腳本編譯特性後，咱們則建議研發團隊能夠將一些長時間不須要改動的腳本代碼（好比各類插件代碼）放入到Standard Assets、Pro Standard Assets或Plugins文件夾中，這樣這些代碼只須要編譯一次，後續的時間就都能節省下來。

有朋友作過測試，在他們的項目中通過上面的改動，原來項目每次的編譯時間從23s降低到7s。想一想看，這將節省你和你的團隊多少時間！

推薦插件：Mad Compile Time Optimizer
推薦閱讀：《優化Unity項目編譯速度》