轉載請注明出處：https://www.cnblogs.com/zzcperf/articles/11615655.html
上一篇文章列舉了不同版本Android OS內存泄漏的檢測操作（傳送門），這一篇說一下Android Native內存泄漏檢測的原理。
之前所說的內存泄漏檢測，主要借助了Android 原生的libc_malloc_debug.so，這一種檢測方法分為以下三步：
記錄內存分配的調用棧 -> 輸出當前進程尚未釋放的內存對應的申請調用棧 -> 找出內存泄漏的調用棧。
其實是圍繞記錄內存分配的調用棧這個主題。
- 記錄內存分配的調用棧
為了輸出尚未釋放內存的調用棧，內存分配時需要記錄當時的調用棧，釋放內存時，也要刪除相應內存申請時調用棧的信息。
內存泄漏的代碼往往重復執行而沒有釋放，所以才導致嚴重的內存占用問題。
這些內存申請都有相同的調用棧，所以libc_malloc_debug.so以調用棧為Key，使用哈希表保存尚未釋放的內存申請記錄。
每次申請內存時，會額外一個頭部指針，並在哈希表中記錄本次的內存申請，最后將頭部指針指向哈希表中的記錄。
-> PointerData::AddBacktrace(size_t num_frames)
每次釋放內存時，就根據頭部指針，消去哈希表中對應的記錄。
-> PointerData::RemoveBacktrace(size_t hash_index)
提取哈希表的記錄，就是進程當前尚未釋放的內存記錄
-> PointerData::GetInfo(uint8_t** info, size_t* overall_size, size_t* info_size, size_t* total_memory, size_t* backtrace_size)
- 輸出當前進程尚未釋放的內存對應的申請調用棧
Android N OS之后，Google有native_heapdump_viewer.py腳本，已經不需要我們自己寫代碼來解析獲得的哈希表內容了
- 找出內存泄漏的調用棧
native_heapdump_viewer.py生成的HTML文件，是樹狀結構。樹的每一個節點代表一個棧幀，葉子節點就是申請內存的地方。
通過對比重新20次和40次的HTML文件，找上升最快的調用棧，就基本上是內存泄漏的地方。