chromium内存分析工具MemoryInfra

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系统内分配的内存；