記錄原生配置
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
如果您正在編寫原生程式碼,且擔心記憶體用量,建議您分析應用程式的原生配置,找出是否有可進行最佳化的部分。
為什麼您必須分析應用程式記憶體
Android 提供受管記憶體環境;當 Android 判定應用程式不再使用部分物件時,垃圾收集器就會將未使用的記憶體釋放回堆積中。我們正持續改善 Android 尋找未使用記憶體的運作機制,不過在所有 Android 版本中,系統有時會暫停執行您的程式碼。在多數情況下,這類暫停情形不易察覺。不過,如果應用程式配置記憶體的速度勝過於系統收集記憶體的速度,即使收集器釋出足以滿足配置需求的記憶體,應用程式仍可能會發生延遲情形。這類延遲可能會導致應用程式略過畫格,並讓顯示畫面變慢。
如要進一步瞭解可減少應用程式記憶體用量的程式設計做法,請參閱「管理應用程式的記憶體」。
原生配置總覽
執行「追蹤記憶體用量 (原生配置)」工作時,Android Studio 分析器會在您指定的時間範圍內,追蹤原生程式碼中物件的配置和取消配置情形,並提供下列資訊:
- Allocations:在所選時間範圍內,使用
malloc()
或 new
運算子配置的物件數量。
- Deallocations:在所選時間範圍內,使用
free()
或 delete
運算子取消配置的物件數量。
- Allocations Size:在所選時間範圍內,所有配置的匯總大小 (以位元組為單位)。
- Deallocations Size:在所選時間範圍內,所有已釋放記憶體的匯總大小 (以位元組為單位)。
- Total Count:Allocations 欄中的值減去 Deallocations 欄中的值所得的結果。
- Remaining Size:Allocations Size 欄中的值減去 Deallocations Size 欄中的值所得的結果。

「Visualization」分頁會顯示所選時間範圍內,與呼叫堆疊中原生程式碼相關的所有物件的匯總檢視畫面。它基本上會顯示呼叫堆疊與顯示的例項所需的記憶體總量。第一個資料列會顯示執行緒名稱。根據預設,系統會根據分配大小,將物件從左至右堆疊;使用下拉式選單變更排序。

根據預設,分析器使用的樣本大小為 2048 位元組;意即每配置 2048 位元組的記憶體時,系統就會建立記憶體快照。樣本大小越小,快照擷取頻率就越高,進而產生更準確的記憶體用量資料。樣本大小越大,資料準確度就越低,但消耗的系統資源較少,並且能提升分析作業期間的效能。如要變更取樣大小,請參閱「編輯錄製設定」。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Record native allocations\n\nIf you're writing native code and concerned about its memory usage, it's helpful\nto profile your app's native allocations to discover if there's opportunity to\noptimize.\n\nWhy you should profile your app memory\n--------------------------------------\n\nAndroid provides a [managed memory\nenvironment](/topic/performance/memory-overview)---when Android determines that\nyour app is no longer using some objects, the garbage collector releases the\nunused memory back to the heap. How Android goes about finding unused memory is\nconstantly being improved, but at some point on all Android versions, the system\nmust briefly pause your code. Most of the time, the pauses are imperceivable.\nHowever, if your app allocates memory faster than the system can collect it,\nyour app might be delayed while the collector frees enough memory to satisfy\nyour allocations. The delay could cause your app to skip frames and cause\nvisible slowness.\n\nFor information about programming practices that can reduce your app's memory\nuse, read [Manage your app's memory](/topic/performance/memory).\n\nNative allocations overview\n---------------------------\n\nWhen you run the [**Track Memory Consumption (Native Allocations)**](/studio/profile#start-profiling) task,\nthe Android Studio Profiler tracks allocations and deallocations of objects in\nnative code for the time period that you specify and provides the following\ninformation:\n\n- **Allocations** : A count of objects allocated using `malloc()` or the `new` operator during the selected time period.\n- **Deallocations** : A count of objects deallocated using `free()` or the `delete` operator during the selected time period.\n- **Allocations Size**: The aggregated size in bytes of all allocations during the selected time period.\n- **Deallocations Size**: The aggregated size in bytes of all freed memory during the selected time period.\n- **Total Count** : The value in the **Allocations** column minus the value in the **Deallocations** column.\n- **Remaining Size** : The value in the **Allocations Size** column minus the value in the **Deallocations Size** column.\n\nThe **Visualization** tab shows an aggregated view of all the objects related to\nnative code in the call stack during the time range selected. It essentially\nshows you how much total memory the callstack with the instances shown takes.\nThe first row shows the thread name. By default, the objects are stacked left to\nright based on allocation size; use the drop-down to change the ordering.\n\nBy default, the profiler uses a sample size of 2048 bytes: Every time 2048 bytes\nof memory are allocated, a snapshot of memory is taken. A smaller sample size\nresults in more frequent snapshots, yielding more accurate data about memory\nusage. A larger sample size yields less accurate data, but it consumes fewer\nsystem resources and improves performance while recording. To change the sample\nsize, see [Edit the recording configuration](/studio/profile#edit-recording)."]]