chromium記憶體分析工具MemoryInfra
1.介紹
Chromium對記憶體的消耗一直以來都為人詬病，著手進行記憶體優化我們首先需要了解chromium的記憶體使用策略以及當前策略下記憶體的消耗情況，公欲善其事，必先利其器，首先介紹一下chromium自帶的systrace工具包含的一個記憶體列印外掛。從chromium 48版本開始，trace工具加入了MemoryInfra外掛，通過trace抓取的log可以過濾包含heap的使用情況以及記憶體的狀態變化，使用chrome://trace 或chrome://inspect?tracing（android）進行開關控制；
Request：網頁瀏覽器引擎chromium 記憶體優化及分析工具的指導。
Purpose：參照此文件能夠快速找到定位chromium記憶體的方法，並對chromium記憶體的形態及管理模型有初步的認識。
2. chromium 記憶體分析工具Memory-infra
A、 啟動chrome並開啟—enable-heap-profiling.的開關（待求證）這個是用來列印chromium的呼叫棧.
B、 開始抓取memoryinfra的log.準備工作：為了保證抓取資料的精確度.最好保證是第一次開啟chromium。並關閉多餘的tab頁，只保留需要列印的物件頁面即可，記憶體資訊收集完成後可以通過呈現的檢視展現dump的細節，例如點選紫色的M圖示即可以顯示記憶體分配的函式呼叫關係。
C、使用devtool工具將android手機裝置連線到PC，手機root。
D、 進入chrome://inspect?tracing(除錯桌面版進入chrome://tracing),進入trace；
E、 點選左上角的“record”，進入打點過濾設定項；
F、 選擇的類別必須包含“memory-infra”,然後點選“record”，記錄完成之後點選“stop”
抓取的記憶體資料是某一時間段內chromium的記憶體狀態，系統自動每隔一段時間對記憶體進行一次打點拍照，記錄下當前時刻記憶體的詳細使用情況，包括總記憶體吃進/各個子系統記憶體佔用，以及相關的資料呼叫棧等等...
抓取到的資料以圖例化呈現，大體區分為2塊區域：timeline view 以及analysis view。
2.2.1 timeline view
Timeline View展示了記憶體隨時間推進的變化曲線，同樣也是按照程序和子系統的類別進行劃分的，也就是左側標識的2個不同行：Memoryper process( 每個程序的記憶體資料)和Memoryper component （每個子系統的記憶體資料）詳細提供內容包括：
a.按程序顯示總的記憶體消耗
b.按子模組顯示子系統總的記憶體消耗
c.各個子系統各自的記憶體消耗
2.2.2 Analysis View
這塊區域是顯示的某一時刻下記憶體分佈的詳細資料，點選
從左邊的overview可以看到，展示的記憶體分佈是以程序區分的，每個程序的詳細資料又分為藍色字型部分和黑色字型部分，展示的列表種類：
藍色的列：顯示的各程序實際使用的記憶體大小
1）Total Resident: 各程序總記憶體消耗
2）Peak Total Resident: 各程序對記憶體消耗的峰值
3）PSS: 實際使用的實體記憶體（比例分配共享庫佔用的記憶體）
4）Private Dirty:私有dirty記憶體
5）Swapped: 交換區域的記憶體
黑色的列：顯示各個子系統實際佔用的記憶體大小
1）Blink GC: Oilpan（Blink objects的垃圾回收系統）子系統的記憶體消耗
2）CC: compositor 合成層
3）Discardable:diacarde memory 區域的大小
4）Font Caches: 字型快取
5）GPU 和 GPU Memory Buffer: GPU程序的記憶體消耗.
6）Malloc: 通過呼叫malloc或者是非blink 的object new 出來的空間
7）PartitionAlloc: blink的記憶體管理器分配的記憶體
8）Skia: skia的記憶體大小
9）SQLite: 資料庫相關
10）V8: V8 js引擎的記憶體分配
11）Web Cache: web頁面的快取資料
Used memory:頁面顯示所需要的實際分配的記憶體大小；目前還只能統計到記憶體實際使用的大小，還無法統計到是誰或者哪個子系統分配了這些記憶體；
Allocated memory:需要的虛擬記憶體的大小，該值反映出系統潛在的記憶體需求，不一定是實際的使用記憶體；如：有可能建立了一個2M skia buffer，但實際使用可能只有16k。因此對系統的硬性要求是16k而不是2M.
點選藍色字型的資料，可以檢視這段事件內各個時刻詳細的記憶體分佈資料：
點選黑色字型的子系統列，可以檢視該子系統記憶體狀態的分佈
2.3.1 Blink_gc（Oilpan）
針對Blink物件的記憶體垃圾處理系統，Blink本身包含對個執行緒，包括主執行緒，HTML解析執行緒，資料庫執行緒等等，這些執行緒會包含一些跨執行緒的指標，Oilpan主要工作就是遍歷這些執行緒的物件，記錄正常使用的物件並清除沒用的物件。
2.3.2 CC
cc子系統的記憶體主要是ResourceProvider使用的資源所分配的記憶體，所有資源所分配的記憶體都會羅列在cc/resource_memory 下，而這些資源子集被稱為tile memory,並且在cc/tile_memory下記錄，對於即出現在cc/resource_memory下又出現在 cc/tile_memory的資源所佔被記憶體會被統計到cc/tile_memory下。
2.3.3 Discaedable
cache 資源被標記為Discardable memory。
2.3.4 Gpu
記錄CC繪製資源時所使用的GPU路徑而產生的記憶體份額。這個記憶體並不是GPU的記憶體，它只是在渲染過程中所用到的共享記憶體部分。例如：GL command buffer， image upload paths/用來向GPU傳送資料的Transfer Buffer。
2.3.5 Java_heap
Java 層啟動時候heap分配的空間
2.3.6 Malloc
通過malloc獲得的記憶體空間。
2.3.7 Partition_alloc
PartitionAlloc本身是一個記憶體分配管理模組，是為保證blink系統最佳效能和資料安全而單獨設計的模組。blink內的物件的全部分佈在PartitionAlloc或Oilpan。
2.3.8 Skia
skia系統所用到的資源所分配的記憶體；
2.3.9 V8 引擎
V8系統內分配的記憶體；
