系列文章请扫关注公众号！
Android Display Graphics系列文章-汇总
本文主要包括部分：
1、dma-buf问题初步判定方法
2、SF/HWC dma-buf debug
3、SF/HWC与对比机内存使用对比问题
本文主要分析SurfaceFlinger、Hardware composer内存使用问题，及dma-buf的debug技巧。
Overview
dma-buf是一个多进程间的buffer共享的机制， 本节主要介绍针对display部分相关的dma-buf如何做初步的分析
在Android中Buffer需要在多个进程间传递使用的Module有很多， 但用量比较明显，无法回避的主要都在MM相关module中， 其中显示Graphic图形使用的Buffer是最为频繁的， Buffer会在APP / sytemserver / Surface / GPU / SurfaceFlinger / hwcomposer / kernel display DRM driver 等module间进行传递使用， 所以Graphic的相关Module是最容易被Call到需要来厘清dma-buf使用情况的
1、 dma-buf问题初步判定方法
怎样判定当前的内存问题是dma-buf相关的问题呢？
在meminfo中的 EGL mtrack 部分就是代表 dma buf的用量， 如果这部分用量异常则需要厘清dma buf的使用情况
dma-buf使用异常会与哪些问题相关？
1，内存分配不出引发的异常 ： 各种exception, 图像卡死等现象，伴有低内存的， 经过内存owner分析以后无其他内存异常的
2, 内存占用异常 ： 主要指在一些预期不会使用很多内存的场景， 出现较大的dma-buf占用
3, buffer相关fd异常 ： 目前对于fd主要会报异常的就是fdsan， 或者有些exception发生前突然出现fd error等
发生异常时如何进一步查看dma-buf的使用信息呢？
1， 有发生exception， 且能获取到db的情况：
Hang : SYS_DMA_HEAP_RAW
SWT/Other: DMABUF_HEAP_INFO / ION_DMABUF_SYSTEM_INFO
OOM/KE/JE****：SYS_KERNEL_LOG****(search keyword: "dma_heap: mtk_debug")
2, 没有发生exception或没有db的情况：
此种情况一般基本要求是device保有内存使用异常的现场未恢复， 进阶要求是有找到一些复现操作路径，并且可以观察到EGL mtrack部分随着使用在持续增长且不会自动减少
制作adb脚本去循环cat meminfo， 并持续比较和观察EGL mtrack部分， 可以设定增长到一定Size即主动去kill -11 [SurfaceFlinger Pid] 来产生NE, 以固定到问题现场并提取到db
如果不方便触发和提取到db，可以通过以下cmd去cat到当前一些dmabuf的info出来
adb shell cat /proc/dma_heap/all_heaps > all_dma_heaps.txt 此文件为MTK平台独有，在MTK平台debug时推荐优先查看
adb shell /system/bin/dma_buf_dump > dmabuf_dump.txt 此文件会按进程分开列出每个进程的dma buf持有情况
adb shell dmabuf_dump -a > dmabuf_dump_a.txt 该文件为Android默认节点， 其列表形式比较容易查看Fd ref/ Map ref count持有情况
adb shell dmabuf_dump -b > dmabuf_dump_b.txt 该文件为Android默认节点， 主要时按per buffer进行统计汇总
2、 SF/HWC dma-buf debug
SF/HWC作为图形系统的传递中枢， Buffer的使用异常通常都会有surfaceflinger和composer的中间持有， 这也是此类问题为什么会常常需要SF/HWC owner参与梳理的原因
SF/HWC的梳理step by step:
1, 首先通过all_dma_heaps可以观察整体状况
此处dump首先会列出dma buffer的主要user, 我们主要关注surfaceflinger和composer的使用量是否有异常
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| PID PSS(KB) RSS(KB) 3236 25272 47712 2935 103267 127272 1443 37533 108432 1225 4 4 984 102401 371176 906 232617 330476 893 48 48 -----EGL memtrack data end --sum: userspace_pss:501143 KB rss:985120 KB --sum: kernel rss: 3136 KB pid table: pid:3236 name:droid.launcher3 pid:2935 name:ndroid.systemui pid:1443 name:system_server pid:1225 name:binder:1225_2 pid:984 name:surfaceflinger pid:906 name:composer@3.2-se pid:893 name:binder:893_2 |
同步观察dump中列出的top 10用量的buffer, 注意这里把 buffer name 都有打印出来, 因为Buffer最终通过BufferQueue分配使用，所以其使用进程肯定会经过surfaceflinger和composer， 此处可以进一步分辨是否有哪个名字的buffer使用量过多， 需要进一步去分析关注
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| dmabuf alloc total:(361/504280KB), top 10 user: debug name sum of size(KB) count of heap G:ColorFade#2(BLAST Consumer)2 79772 37 G:VRI[NotificationShade]#13(BLA 79772 13 G:VRI[GalleryActivity]#4(BLAST 77840 37 G:SurfaceView[com.android.galle 73500 37 FramebufferSurface 63552 37 G:screenshot 44880 12 G:ColorFade#3(BLAST Consumer)3 31444 35 G:VRI[]#14(BLAST Consumer)14 29092 10 G:Wallpaper#0(BLAST Consumer)0 11316 9 G:VRI[NavigationBar0]#1(BLAST C 4368 64 |
2， 去具体查看有嫌疑的Buffer的使用情况
3， 进一步debug ref count不归 0 的原因
( i ) SF/APP
（ii）HWC
（iii）kernel
3、 SF/HWC与对比机内存使用对比问题
SF部分主要差异就是在Buffer数量上，主要分为两点：.......
Composer进程的差异： ........
=========================================================================
============================完整文章见公众号===============================
=========================================================================