内存拆解

Android 内存拆解

一、Graphic内存拆解：

1. Native Heap/EGL mtrack

参考文档

https://wiki.n.miui.com/pages/viewpage.action?pageId=696470793

https://xiaomi.f.mioffice.cn/wiki/wikk4VpCKVtvrgu5M40VEokEvKb

Native Heap需要关注的是Pss Total + Swap Dirty

Swap 内存后，整体占用的内存大小并没有改变，Pss Total和Swap Dirty都是pss占用，内核内存回收时会把部分内存交换到swap分区，所以要合起来计算

TOTAL是根据内核数据给出的计算结果，Pss、SwapPss等都是内核数据，并且不是Pss Total各部分的简单求和。

Native Heap各调用栈的占用内存情况可利用以下工具。Native Heap Insight

https://xiaomi.f.mioffice.cn/wiki/wikk4Bho9oivelenmWesvWyJqkx

https://xiaomi.f.mioffice.cn/docx/doxk4Zc07cIVFYtDwJdUAzm1ZOg

EGL mtrack

egl mtrack统计的值不准确，需要看kgsl egl_image。

cache模式不同会出现egl mtrack统计出来的结果不同，cache模式是gpu私有库里面确定的，因为是writecombine模式，所以meminfo的统计值 与 kgsl中egl_image的值有出入，这都是正常的。

Kgsl egl_image

kgsl文件：

egl_image这个值我们可以理解为是应用申请的Buffer大小，和imported gralloc有一定的关系，imported gralloc 是指graphicbuffer的多少。

但并不是所有的graphicbuffer都会映射到****GPU 作为egl_image , 所以egl_image的size与imported gralloc 不一致。

具体哪些graphicbuffer映射到gpu是由surfaceflinger和renderengine决定的，主要是由以下两个接口确定创建和销毁eglCreateImageKHR、eglDestroyImageKHR。

1. 1 配置好环境

准备好可以复现的环境

2. dump meminfo信息

2. 命令抓SurfaceFlinger信息

adb shell dumpsys SurfaceFlinger > sflog.txt

3. 过滤关键字

Imported gralloc buffers:

4.提取需要查的进程的buffer分配情况

比如这里智能助理申请了4个buffer ,尺寸和内存占用如下

buffer名称	w/h	内存
VRI[personalassistant]#26(BLAST Consumer)26, id:1734	w/h:1080x2400	size:10276.00KiB
VRI[personalassistant]#26(BLAST Consumer)26, id:1736	w/h:1080x2400	size:10276.00KiB
VRI[personalassistant]#26(BLAST Consumer)26, id:1737	w/h:1080x2400	size:10276.00KiB
VRI[personalassistant]#26(BLAST Consumer)26, id:1735	w/h:1080x2400	size:10276.00KiB

adb shell dumpsys SurfaceFlinger 命令dump信息中 Imported gralloc buffers:各项详细解读下都是什么作用

ChatGPT

The adb shell dumpsys SurfaceFlinger command provides detailed information about the current state of the SurfaceFlinger service, which is responsible for compositing window buffers to the display on Android devices. The Imported gralloc buffers: section specifically gives information about the graphic buffers that have been imported into SurfaceFlinger. Each item in this section has a specific meaning and purpose related to how graphic buffers are managed and utilized in the system.

Here’s a detailed explanation of the various fields that might appear under Imported gralloc buffers::

1. handle:
   • Description: This represents the native handle of the gralloc buffer. It’s a unique identifier used by the system to refer to this particular buffer.
2. width, height:
   • Description: These specify the dimensions of the buffer in pixels.
3. format:
   • Description: This indicates the pixel format of the buffer, such as RGBA_8888, RGBX_8888, etc. The format determines how the pixels are laid out in memory.
4. usage:
   • Description: This field lists the usage flags associated with the buffer. Usage flags define how the buffer will be used (e.g., for rendering, texturing, etc.). Common flags include GRALLOC_USAGE_HW_RENDER, GRALLOC_USAGE_HW_TEXTURE, and GRALLOC_USAGE_SW_READ_OFTEN.
5. stride:
   • Description: The stride is the number of pixels between the start of one row of the buffer and the start of the next row. It’s used to calculate memory offsets for accessing buffer content.
6. imported_at:
   • Description: This indicates the timestamp or the sequence when the buffer was imported into SurfaceFlinger.
7. name:
   • Description: The name of the buffer, which can be used for identifying it in logs and debugging. It might include details such as which process or application owns the buffer.
8. owner:
   • Description: This shows the owner of the buffer, typically the process or service that created or currently holds the buffer.

Here is an example of what this section might look like and how to interpret each item:

yaml复制代码解释Imported gralloc buffers:
  buffer handle 0xb4000070097892b0
  width: 1080
  height: 2400
  format: 1 (HAL_PIXEL_FORMAT_RGBA_8888)
  usage: 0x933 (GRALLOC_USAGE_HW_RENDER | GRALLOC_USAGE_HW_TEXTURE | GRALLOC_USAGE_SW_READ_OFTEN)
  stride: 1088
  imported_at: 654321
  name: "com.example.app/com.example.app.MainActivity"
  owner: 1000

• buffer handle: 0xb4000070097892b0 is the native handle for this buffer.
• width: 1080 pixels is the width of the buffer.
• height: 2400 pixels is the height of the buffer.
• format: 1 corresponds to HAL_PIXEL_FORMAT_RGBA_8888, meaning the buffer uses 32-bit color with 8 bits for each RGBA channel.
• usage: 0x933 indicates a combination of usage flags, which in this case includes hardware rendering, hardware texturing, and frequent software reads.
• stride: 1088 pixels is the distance in pixels from the start of one row to the start of the next.
• imported_at: 654321 is the timestamp or sequence number indicating when the buffer was imported.
• name: "com.example.app/com.example.app.MainActivity" is the name of the buffer, usually indicating the owning application or activity.
• owner: 1000 typically represents the UID (user identifier) of the owner of the buffer, which can be mapped to a particular process or application.

Understanding these details can help in diagnosing graphical issues, performance problems, or other anomalies related to buffer management on an Android device.

按照上面的顾虑帮我解析一行+ name

personalassistant

#18(BLAST Consumer)18, id:865, size:10276.00KiB, w/h:1080x2400, usage: 0x10000900, req fmt:1, fourcc/mod:875708993/0, dataspace: 0x88a0000, compressed: true planes: R/G/B/A: w/h:1080x2400, stride:4352 bytes, size:10522624

ChatGPT

Sure, let’s break down and analyze the provided line in detail:

yaml复制代码name:VRI[personalassistant]#18(BLAST Consumer)18, id:865, size:10276.00KiB, w/h:1080x2400, usage: 0x10000900, req fmt:1, fourcc/mod:875708993/0, dataspace: 0x88a0000, compressed: true
    planes: R/G/B/A:    w/h:1080x2400, stride:4352 bytes, size:10522624

Breakdown and Analysis

1. name: VRI[personalassistant]#18(BLAST Consumer)18

   • Description

     : This is the name of the buffer. It includes:

     • VRI: Likely a prefix or an identifier related to the buffer.
     • [personalassistant]: Possibly the owner or related to the application or service using the buffer.
     • #18: An identifier or index for the buffer.
     • (BLAST Consumer): Indicates that this buffer is consumed by BLAST (Buffer Layered Allocation STream) or a similar mechanism.
     • 18: Another identifier, possibly related to the buffer’s lifecycle or instance.

2. id: 865

   • Description: This is the unique identifier for the buffer. It helps in tracking and managing the buffer within the system.

3. size: 10276.00KiB

   • Description: The size of the buffer in kibibytes (KiB). This represents the amount of memory allocated for this buffer, which is 10276 KiB.

4. w/h: 1080x2400

   • Description: The width and height of the buffer in pixels. Here, the buffer is 1080 pixels wide and 2400 pixels high.

5. usage: 0x10000900

   • Description: This hexadecimal value represents the usage flags for the buffer. These flags define how the buffer will be used. For instance, 0x10000900 can be decoded based on the Gralloc usage flags (e.g., hardware rendering, hardware texturing, etc.).

6. req fmt: 1

   • Description: The requested format for the buffer, which is 1. This usually corresponds to HAL_PIXEL_FORMAT_RGBA_8888, meaning the buffer uses 32-bit color with 8 bits for each RGBA channel.

7. fourcc/mod: 875708993/0

   • Description

     :

     • fourcc (Four Character Code): 875708993 corresponds to a specific pixel format. The FourCC code is used to identify video data formats.
     • mod: Modifier, often used to indicate additional properties or transformations applied to the buffer. In this case, it is 0, meaning no modifier.

8. dataspace: 0x88a0000

   • Description: This value indicates the dataspace, which describes the color space and profile of the buffer. For instance, 0x88a0000 can specify a particular color profile, such as sRGB, Display P3, etc.

9. compressed: true

   • Description: Indicates that the buffer is compressed, which helps in reducing the memory footprint and potentially improving performance.

10. planes: R/G/B/A: w/h: 1080x2400, stride: 4352 bytes, size: 10522624

    • Description

      :

      • planes: Indicates the color planes for the buffer. Here, R (Red), G (Green), B (Blue), and A (Alpha) are likely packed into a single plane.
      • w/h: 1080x2400: The width and height of the plane in pixels.
      • stride: 4352 bytes: The number of bytes between the start of one row of pixels and the start of the next row. This is used to calculate the memory offsets for accessing pixel data.
      • size: 10522624: The total size of the plane in bytes, which is 10522624 bytes (approximately 10.52 MiB).

Summary

• Buffer Name: VRI[personalassistant]#18(BLAST Consumer)18

• Buffer ID: 865

• Buffer Size: 10276.00 KiB

• Dimensions: 1080x2400 pixels

• Usage Flags: 0x10000900

• Requested Format: 1 (HAL_PIXEL_FORMAT_RGBA_8888)

• FourCC Code: 875708993

• Modifier: 0

• Dataspace: 0x88a0000

• Compression: true

• Color Planes

  :

  • Width/Height: 1080x2400
  • Stride: 4352 bytes
  • Total Size: 10522624 bytes

Understanding these details helps in diagnosing and optimizing the performance of graphic buffers within the system.

这里的size和w/h存在什么关系呢，怎么换算的

The relationship between the size of the buffer (size), the dimensions of the buffer (w/h), and the stride involves understanding how the buffer’s memory layout is managed. The size of the buffer is determined by its width, height, pixel format, and stride. Let’s break down the calculation:

1. Dimensions (w/h):
   • The width (w) and height (h) are the dimensions of the buffer in pixels.
2. Stride:
   • The stride is the number of bytes between the start of one row of pixels and the start of the next row. It can be greater than the width of the buffer multiplied by the number of bytes per pixel to ensure proper alignment in memory.
3. Pixel Format:
   • The pixel format determines how many bytes are used to represent each pixel. For HAL_PIXEL_FORMAT_RGBA_8888, each pixel is 4 bytes (32 bits).

Calculation

The total size of the buffer in bytes can be calculated using the formula:

Total Size=Stride×HeightTotal Size=Stride×Height

Let’s use the provided example to illustrate this calculation:

• Width (w): 1080 pixels
• Height (h): 2400 pixels
• Stride: 4352 bytes
• Pixel Format: HAL_PIXEL_FORMAT_RGBA_8888 (4 bytes per pixel)

The size provided in the example is 10276.00 KiB, which is equivalent to 10276.00 * 1024 = 10518528 bytes.

Step-by-Step Calculation:

1. Total Size Calculation: Total Size=Stride×HeightTotal Size=Stride×Height Total Size=4352 bytes×2400 pixelsTotal Size=4352bytes×2400pixels Total Size=10444800 bytesTotal Size=10444800bytes
2. Verify Size: The size calculated using the stride and height is 10444800 bytes, which differs from the provided 10518528 bytes. This discrepancy could be due to additional metadata or padding added to the buffer, which is not uncommon in buffer management.

Additional Notes

• Pixel Format and Size Calculation: The size in bytes can be calculated directly from the width, height, and bytes per pixel if no stride or padding is involved: Size=Width×Height×Bytes Per PixelSize=Width×Height×Bytes Per Pixel Size=1080 pixels×2400 pixels×4 bytes/pixelSize=1080pixels×2400pixels×4bytes/pixel Size=10368000 bytesSize=10368000bytes
• Stride and Alignment: The stride is often larger than the width multiplied by bytes per pixel to align rows of pixels in memory, which can improve performance and comply with hardware requirements.

Summary

• The size of the buffer is related to its width, height, and stride.
• The stride determines the actual memory layout, often including padding for alignment.
• The provided size (10518528 bytes) includes both the pixel data and possibly additional metadata or padding.
• The calculated size using stride and height (10444800 bytes) is close but slightly less, suggesting some extra space might be allocated for alignment or other purposes.

文档参考

https://blog.csdn.net/tkwxty/article/details/121209801