开发定位APP遇内存泄漏问题，LeakCanary检测到两处泄漏点

结合你给出的LeakCanary检测结果，这两个泄漏点都是定位/传感器场景下的典型问题，咱们一步步来排查和修复：

一、先处理MainActivity$26.this$0（匿名LocationListener）的泄漏 #

这个泄漏的核心原因是匿名内部类默认持有外部MainActivity的强引用，当Activity销毁后，如果LocationManager还在后台持有这个Listener的引用，就会导致整个Activity实例无法被GC回收，进而引发内存泄漏。

修复方法：

• 替换匿名内部类为静态内部类+弱引用：把你的匿名LocationListener改成静态内部类，用WeakReference来持有MainActivity的引用，这样当Activity被销毁时，GC可以正常回收它，不会因为Listener的引用而卡住。
  示例代码：

  // 在MainActivity内部定义静态内部类
  private static class AppLocationListener implements LocationListener {
      private final WeakReference<MainActivity> activityRef;
  
      public AppLocationListener(MainActivity activity) {
          this.activityRef = new WeakReference<>(activity);
      }
  
      @Override
      public void onLocationChanged(Location location) {
          MainActivity activity = activityRef.get();
          if (activity != null && !activity.isFinishing()) {
              // 在这里处理位置更新逻辑，比如更新UI或存储数据
          }
      }
  
      // 实现LocationListener的其他方法（onStatusChanged、onProviderEnabled等），同样先判断activity是否有效
  }
  

• 必须显式移除定位监听：在MainActivity的onDestroy()方法中，一定要调用LocationManager.removeUpdates()来移除Listener，哪怕你觉得定位已经停止了——系统的LocationManager可能还会在后台持有这个引用。
  示例代码：

  private LocationManager locationManager;
  private AppLocationListener locationListener;
  
  @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
  
      locationManager = (LocationManager) getSystemService(LOCATION_SERVICE);
      locationListener = new AppLocationListener(this);
      // 注册定位监听（根据你的需求选择Provider和参数）
      locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationListener);
  }
  
  @Override
  protected void onDestroy() {
      super.onDestroy();
      // 移除监听，释放引用
      if (locationManager != null && locationListener != null) {
          locationManager.removeUpdates(locationListener);
      }
      // 置空引用，帮助GC回收
      locationManager = null;
      locationListener = null;
  }
  

二、处理SystemSensorManager$SensorEventQueue.mListener的泄漏 #

这个泄漏通常和传感器注册未取消有关，可能的情况：

• 你的应用直接注册了传感器（比如加速度计、陀螺仪，用来辅助定位），但在Activity销毁时没取消注册；
• 系统LocationManager在某些定位模式下会自动关联传感器，如果定位监听没正确移除，传感器的引用也会被遗留。

修复方法：

• 检查并取消传感器注册：如果你的代码里有直接调用SensorManager.registerListener()的地方，一定要在onDestroy()中调用SensorManager.unregisterListener()取消注册；
• 确保定位监听完全移除：按照上面的方法正确移除LocationListener后，系统关联的传感器引用通常会被自动释放。如果还是存在泄漏，可以检查是否使用了第三方定位SDK，确认SDK的资源清理逻辑是否完善。

三、进一步排查的工具技巧 #

• 深挖LeakCanary的泄漏链：LeakCanary会展示完整的引用链，你可以看看是哪个对象最终持有了泄漏的实例——比如是不是某个单例、后台服务或者系统组件没释放引用；
• 使用Android Studio Profiler：捕获内存快照（Memory Snapshot），搜索MainActivity的实例，查看它的引用路径，能更直观地找到泄漏的根源。

额外注意点 #

如果你使用的是Google Play服务的FusedLocationProviderClient而不是原生LocationManager，也要确保在onDestroy()中调用removeLocationUpdates()来取消回调或PendingIntent的注册，避免类似的泄漏问题。

内容的提问来源于stack exchange，提问作者Edon Freiner