前几天同事发现一个正在开发的小程序在反复进入退出时,应用的 GPU 内存占用会一直上涨直到触发 OOM,因为小程序使用了内核作为渲染引擎,所以怀疑是内核发生内存泄露,让我帮忙分析看看。
![Snapdragon Profiler](https://i.loli.net/2020/01/10/yp9UQwNhlTamGnW.png?x-oss-process=image/resize,w_1400/format,webp)
Snapdragon Profiler Snapshot Capture
进入小程序后,使用 Snapdragon Profiler Snapshot Capture 抓取了当前帧的 GPU 快照,可以看到一共分配了 4 个 GL Context。
![Texture](https://i.loli.net/2020/01/10/hiIVaNrA6jFkD3b.png?x-oss-process=image/resize,w_1400/format,webp)
查看每个 Context 分配的纹理
点击右上角的 All 可以看到每个 Context 分配的纹理,从分配的纹理内容很快就猜到了其中三个 Context 的分配来源和用途。一个是 Android UI 渲染引擎 HWUI 分配的,一个是我们浏览器内核分配的,还有一个是因为摄像头扫码模块分配。而第四个 Context 分配了大量的纹理,但是不知道是哪个模块分配的。
退出小程序后在应用的主界面再抓一帧 Snapshot,可以发现内核分配的 Context 已经释放了绝大部分的纹理(只保留一些内部作为 placeholder 使用),而第四个 Context 没有释放纹理。再进入小程序后再抓一次 Snapshot,发现该 Context 重复分配了同样的纹理,从而可以确定是这个 Context 发生了泄漏。把这个 Context 分配的纹理截图发给同事,很快就确认了是应用的一个 Native 组件自己分配的 GL Context 发生了泄漏。
一些 takeaway:
- Chromium 内核本身只会分配一个物理 GL Context,WebGL,Canvas,合成器,光栅化器都是共用同一个 Context(一般是通过 Command Buffer 进行多路复用);
- 超级 App 通常整合了多个不同组件,这些组件有可能使用了不同的渲染引擎,有自己的 GL Context 和纹理缓存池,如果发生 GPU 内存泄漏使用一些底层的 Profiler 工具外部工具进行对应用进行全面分析更容易找出问题;
- 因为嵌入式 View 和混合渲染的使用,网页可能内嵌了其它 Native 组件,这些组件可能有自己的 GL Context;
关于 Snapdragon Profiler 使用过程碰到的常见问题的 Q&A:
- Snapdragon Profiler 支持 Windows/Mac/Linux,但是因为是使用 .Net 开发,在 Linux 下要安装 Mono 框架,安装和使用比较麻烦,建议使用 Mac 或者 Windows;
- 理论上现在使用高通芯片的手机都支持,如果不行可以使用 Pixel 系列;
- 云真机这种 adb 通过网络映射的链接,Snapshot 会无法获取数据,需要使用数据线链接实机;Chromium 内核本身只会分配一个物理 GL Context,WebGL,Canvas,合成器,光栅化器都是共用同一个 GL Context