一、Android显存泄漏的核心机制与影响

1.1 显存与Android内存管理的特殊性

Android设备的显存（GPU内存）主要用于存储图形资源（纹理、着色器、帧缓冲区等），其分配与释放由GPU驱动和SurfaceFlinger系统共同管理。与传统堆内存不同，显存的分配通常通过GraphicBuffer或EGLImage等底层接口完成，且受硬件限制更为严格。例如，一块1080p屏幕的帧缓冲区可能占用数MB显存，若频繁泄漏会导致：

• UI卡顿：显存不足时，系统可能强制回收资源，引发帧率骤降。
• OOM崩溃：部分设备对显存超限会直接终止应用。
• 功耗上升：显存泄漏可能伴随GPU持续高负载运行。

1.2 显存泄漏的典型场景

场景1：未释放的Bitmap资源

// 错误示例：Bitmap未回收导致显存泄漏
public class LeakActivity extends Activity {
    private Bitmap mBackground;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mBackground = BitmapFactory.decodeResource(getResources(), R.drawable.large_image);
        // 忘记调用 mBackground.recycle()
    }
}

原理：Bitmap对象在Native层关联显存块，即使Java层对象被回收，若未显式调用recycle()，Native显存不会释放。

场景2：TextureView未正确释放

// 错误示例：TextureView泄漏
public class VideoPlayerActivity extends Activity {
    private TextureView mTextureView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mTextureView = new TextureView(this);
        setContentView(mTextureView);
        // 忘记在onDestroy中移除SurfaceTextureListener
    }
}

原理：TextureView通过SurfaceTexture与GPU交互，若未解除监听或释放SurfaceTexture，关联的显存会持续占用。

场景3：GL线程资源未清理

// 错误示例：OpenGL ES资源泄漏
public class GLRenderer implements GLSurfaceView.Renderer {
    private int mTextureId;
    @Override
    public void onSurfaceCreated(GL10 gl, EGLConfig config) {
        int[] textures = new int[1];
        gl.glGenTextures(1, textures, 0); // 生成纹理
        mTextureId = textures[0];
    }
    @Override
    public void onSurfaceDestroyed(GL10 gl) {
        // 忘记调用 gl.glDeleteTextures(1, new int[]{mTextureId}, 0);
    }
}

原理：OpenGL ES的纹理ID需显式删除，否则GPU会保留对应的显存。

二、显存泄漏的诊断工具与方法

2.1 Android Profiler实战

1. 步骤：
   • 在Android Studio中打开Profiler窗口。
   • 选择Memory标签页，切换至GPU Memory视图（需设备支持）。
   • 监控GraphicBuffer和Texture的分配趋势。
2. 关键指标：
   • 显存总量：对比应用启动前后的显存增量。
   • 泄漏对象类型：识别GraphicBuffer、EGLSurface等高频泄漏对象。

2.2 adb命令深度排查

# 1. 获取当前进程的GPU内存快照
adb shell dumpsys meminfo <package_name> | grep "GPU Memory"
# 2. 强制触发GC并观察显存变化
adb shell am force-stop <package_name>
adb shell am start -n <package_name>/<activity_name>
adb shell dumpsys gfxinfo <package_name>

输出解析：关注Graphics部分的Total PSS和Heap Alloc，若重启后显存未回落，可能存在泄漏。

2.3 第三方工具推荐

• LeakCanary扩展：通过自定义RefWatcher监听GraphicBuffer和Surface对象。
• GAPID（Graphics API Debugger）：捕获GPU调用栈，定位未释放的资源。

三、显存泄漏的优化策略

3.1 显式资源释放

• Bitmap优化：

  @Override
  protected void onDestroy() {
      super.onDestroy();
      if (mBackground != null && !mBackground.isRecycled()) {
          mBackground.recycle();
          mBackground = null;
      }
  }

• OpenGL ES资源清理：

  @Override
  public void onSurfaceDestroyed(GL10 gl) {
      int[] textures = new int[]{mTextureId};
      gl.glDeleteTextures(1, textures, 0);
      mTextureId = 0;
  }

3.2 生命周期管理

• TextureView最佳实践：

  @Override
  protected void onDestroy() {
      super.onDestroy();
      if (mTextureView != null) {
          mTextureView.setSurfaceTextureListener(null);
          mTextureView = null;
      }
  }

• 避免静态引用：严禁将Bitmap或Surface设为静态变量。

3.3 架构层优化

• 资源池化：复用Bitmap和Texture对象，减少频繁分配。

  public class BitmapPool {
      private static final int MAX_POOL_SIZE = 5;
      private LruCache<String, Bitmap> mPool = new LruCache<>(MAX_POOL_SIZE);
      public Bitmap getBitmap(Resources res, int id) {
          String key = "res_" + id;
          Bitmap bitmap = mPool.get(key);
          if (bitmap == null) {
              bitmap = BitmapFactory.decodeResource(res, id);
          }
          return bitmap;
      }
      public void recycleBitmap(Bitmap bitmap) {
          if (bitmap != null && !bitmap.isRecycled()) {
              bitmap.recycle();
          }
      }
  }

• 异步加载：使用Glide或Coil等库自动管理显存。

四、实战案例：修复某视频应用的显存泄漏

4.1 问题复现

• 现象：连续播放3个视频后，应用崩溃并报错EGL_BAD_ALLOC。
• 诊断：通过GAPID发现每次播放均生成新的EGLSurface，但未释放旧对象。

4.2 修复方案

1. 代码修改：

   public class VideoPlayer {
       private EGLSurface mEglSurface;
       public void release() {
           if (mEglSurface != EGLSurface.EGL_NO_SURFACE) {
               EGL14.eglDestroySurface(mEglDisplay, mEglSurface);
               mEglSurface = EGLSurface.EGL_NO_SURFACE;
           }
       }
   }

2. 效果验证：修复后连续播放10个视频，显存占用稳定在200MB以内（原泄漏时达500MB+）。

五、总结与建议

1. 预防优于修复：在开发阶段集成显存监控工具（如自定义LeakCanary规则）。
2. 兼容性测试：在低端设备（如显存1GB以下）上重点测试。
3. 文档化流程：制定《Android显存管理规范》，明确资源释放责任人。

通过系统化的诊断与优化，可显著降低Android应用的显存泄漏风险，提升用户体验与稳定性。