1.介紹
Chromium對記憶體的消耗一直以來都為人诟病，着手進行記憶體優化我們首先需要了解chromium的記憶體使用政策以及目前政策下記憶體的消耗情況，公欲善其事，必先利其器，首先介紹一下chromium自帶的systrace工具包含的一個記憶體列印插件。從chromium 48版本開始，trace工具加入了MemoryInfra插件，通過trace抓取的log可以過濾包含heap的使用情況以及記憶體的狀态變化，使用chrome://trace 或chrome://inspect?tracing（android）進行開關控制；
1.1 Request& Purpose
Request：網頁浏覽器引擎chromium 記憶體優化及分析工具的指導。
Purpose：參照此文檔能夠快速找到定位chromium記憶體的方法，并對chromium記憶體的形态及管理模型有初步的認識。
2. chromium 記憶體分析工具Memory-infra
2.1 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”
2.2 memory-infra 記憶體視圖概覽
抓取的記憶體資料是某一時間段内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
這塊區域是顯示的某一時刻下記憶體分布的詳細資料，點選
或者
可以将某一時刻記憶體狀态的詳細資訊列印在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頁面的緩存資料
2.3 memory-infra 子系統記憶體解析
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系統内配置設定的記憶體；