Android内存泄露检测工具---LeakCanary的前世今生

Posted 2023-02-26 逆水当行舟

原创地址：http://blog.csdn.net/zivensonice/article/details/51639763

曾经检测内存泄露的方式

让我们来看看在没有LeakCanary之前，我们怎么来检测内存泄露
1. Bug收集
通过Bugly、友盟这样的统计平台，统计Bug，了解OutOfMemaryError的情况。
2. 重现问题
对Bug进行筛选，归类，排除干扰项。然后为了重现问题，有时候你必须找到出现问题的机型，因为有些问题只会在特定的设备上才会出现。为了找到特定的机型，可能会想尽一切办法，去买、去借、去求人（14年的时候，上家公司专门派了一个商务去广州找了一家租赁手机的公司，借了50台手机回来，600块钱一天）。然后，为了重现问题，一遍一遍的尝试，去还原当时OutOfMemaryError出现的原因，用最原始、最粗暴的方式。
3. Dump导出hprof文件
使用Eclipse ADT的DDMS，观察Heap，然后点击手动GC按钮(Cause GC)，观察内存增长情况，导出hprof文件。
主要观测的两项数据：
3-1. Heap Size的大小，当资源增加到堆空余空间不够的时候，系统会增加堆空间的大小，但是超过可分配的最大值（比如手机给App分配的最大堆空间为128M）就会发生OutOfMemaryError,这个时候进程就会被杀死。这个最大堆空间，不同手机会有不同的值，跟手机内存大小和厂商定制过后的系统存在关联。
3-2. Allocated堆中已分配的大小，这是应用程序实际占用的大小，资源回收后，这项数据会变小。
查看操作前后的堆数据，看是否存在内存泄露，比如反复打开、关闭一个页面，看看堆空间是否会一直增大。

4. 然后使用MAT内存分析工具打开，反复查看找到那些原本应该被回收掉的对象。
5. 计算这个对象到GC roots的最短强引用路径。
6. 确定那个路径中那个引用不该有，然后修复问题。

很麻烦，不是吗。现在有一个类库可以直接解决这个问题

LeakCanary

使用方式

使用androidStudio，在Module.app的build.gradle中引入

 dependencies 
   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'
   testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'
 

然后在Application中重写onCreate()方法

public class ExampleApplication extends Application 
  @Override public void onCreate() 
    super.onCreate();
    LeakCanary.install(this);
  

在Activity中写一些导致内存泄露的代码，当发生内存泄露了，会在通知栏弹出消息，点击跳转到泄露页面

LeakCanary 可以做到非常简单方便、低侵入性地捕获内存泄漏代码，甚至很多时候你可以捕捉到 Android 系统组件的内存泄漏代码，最关键是不用再进行（捕获错误+Bug归档+场景重现+Dump+Mat分析） 这一系列复杂操作，6得不行。

原理分析

如果我们自己实现

首先，设想如果让我们自己来实现一个LeakCanary，我们怎么来实现。
按照前面说的曾经检测内存的方式，我想，大概需要以下几个步骤：
1. 检测一个对象，查看他是否被回收了。
2. 如果没有被回收，使用DDMS的dump导出.hprof文件，确定是否内存泄露，如果泄露了导出最短引用路径
3. 把最短引用路径封装到一个对象中，用Intent发送给Notification，然后点击跳转到展示页，页面展示

检测对象，是否被回收

我们来看看，LeakCanary是不是按照这种方式实现的。除了刚才说的只需要在Application中的onCreate方法注册LeakCanary.install(this);这种方式。 查看源码，使用官方给的Demo示例代码中，我们发现有一个RefWatcher对象，也可以用来监测，看看它是如何使用的。
MainActivity.class

    @Override
    protected void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        RefWatcher refWatcher = LeakCanary.androidWatcher(getApplicationContext(),
                new ServiceHeapDumpListener(getApplicationContext(), DisplayLeakService.class),
                AndroidExcludedRefs.createAppDefaults().build());
        refWatcher.watch(this);
  

就是把MainActivity作为一个对象监测起来，查看refWatcher.watch(this)的实现

  public void watch(Object watchedReference) 
    watch(watchedReference, "");
  

  /**
   * Watches the provided references and checks if it can be GCed. This method is non blocking,
   * the check is done on the @link Executor this @link RefWatcher has been constructed with.
   *
   * @param referenceName An logical identifier for the watched object.
   */
  public void watch(Object watchedReference, String referenceName) 
    Preconditions.checkNotNull(watchedReference, "watchedReference");
    Preconditions.checkNotNull(referenceName, "referenceName");
    if (debuggerControl.isDebuggerAttached()) 
      return;
    
    final long watchStartNanoTime = System.nanoTime();
    String key = UUID.randomUUID().toString();
    retainedKeys.add(key);
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue);

    watchExecutor.execute(new Runnable() 
      @Override public void run() 
        ensureGone(reference, watchStartNanoTime);
      
    );
  

可以总结出他的实现步骤如下：
1. 先检查监测对象是否为空，为空抛出异常
2. 如果是在调试Debugger过程中允许内存泄露出现，不再监测。因为这个时候监测的对象是不准确的，而且会干扰我们调试代码。
3. 给监测对象生成UUID唯一标识符，存入Set集合，方便查找。
4. 然后定义了一个KeyedWeakReference，查看下KeyedWeakReference是个什么玩意

public final class KeyedWeakReference extends WeakReference<Object> 
  public final String key;
  public final String name;

  KeyedWeakReference(Object referent, String key, String name,
      ReferenceQueue<Object> referenceQueue) 
    super(Preconditions.checkNotNull(referent, "referent"), Preconditions.checkNotNull(referenceQueue, "referenceQueue"));
    this.key = Preconditions.checkNotNull(key, "key");
    this.name = Preconditions.checkNotNull(name, "name");
  

原来KeyedWeakReference就是对WeakReference进行了一些加工，是一种装饰设计模式，其实就是弱引用的衍生类。配合前面的Set retainedKeys使用，retainedKeys代表的是没有被GC回收的对象，referenceQueue中的弱引用代表的是被GC了的对象，通过这两个结构就可以明确知道一个对象是不是被回收了。（ 一个对象在referenceQueue可以找到当时在retainedKeys中找不到，那么肯定被回收了，没有内存泄漏一说）
5. 接着看上面的执行过程，然后通过线程池开启了一个异步任务方法ensureGone。watchExecutor看看这个实体的类实现—AndroidWatchExecutor，查看源码

public final class AndroidWatchExecutor implements Executor 

  static final String LEAK_CANARY_THREAD_NAME = "LeakCanary-Heap-Dump";
  private static final int DELAY_MILLIS = 5000;

  private final Handler mainHandler;
  private final Handler backgroundHandler;

  public AndroidWatchExecutor() 
    mainHandler = new Handler(Looper.getMainLooper());
    HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME);
    handlerThread.start();
    backgroundHandler = new Handler(handlerThread.getLooper());
  

  @Override public void execute(final Runnable command) 
    if (isOnMainThread()) 
      executeDelayedAfterIdleUnsafe(command);
     else 
      mainHandler.post(new Runnable() 
        @Override public void run() 
          executeDelayedAfterIdleUnsafe(command);
        
      );
    
  

  private boolean isOnMainThread() 
    return Looper.getMainLooper().getThread() == Thread.currentThread();
  

  private void executeDelayedAfterIdleUnsafe(final Runnable runnable) 
    // This needs to be called from the main thread.
    Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() 
      @Override public boolean queueIdle() 
        backgroundHandler.postDelayed(runnable, DELAY_MILLIS);
        return false;
      
    );
  

做得事情就是，通过主线程的mainHandler转发到后台backgroundHandler执行任务，后台线程延迟DELAY_MILLIS这么多时间执行
6. 具体执行的任务在ensureGone()方法里面

  void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) 
    long gcStartNanoTime = System.nanoTime();
    //记录观测对象的时间
    long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
    //清除在queue中的弱引用 保留retainedKeys中剩下的对象
    removeWeaklyReachableReferences();
    //如果剩下的对象中不包含引用对象，说明已被回收，返回||调试中,返回
    if (gone(reference) || debuggerControl.isDebuggerAttached()) 
      return;
    
    //请求执行GC
    gcTrigger.runGc();
    //再次清理一次对象
    removeWeaklyReachableReferences();
    if (!gone(reference)) 
      long startDumpHeap = System.nanoTime();
      //记录下GC执行时间
      long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
      //Dump导出hprof文件
      File heapDumpFile = heapDumper.dumpHeap();

      if (heapDumpFile == null) 
        // Could not dump the heap, abort.
        return;
      
      //记录下Dump和文件导出用的时间
      long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
      //分析hprof文件
      heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs));
    
  

  private boolean gone(KeyedWeakReference reference) 
    return !retainedKeys.contains(reference.key);
  

  private void removeWeaklyReachableReferences() 
    // WeakReferences are enqueued as soon as the object to which they point to becomes weakly
    // reachable. This is before finalization or garbage collection has actually happened.
    KeyedWeakReference ref;
    while ((ref = (KeyedWeakReference) queue.poll()) != null) 
      retainedKeys.remove(ref.key);
    
  

这里我们思考两个问题：
1. retainedKeys和queue怎么关联起来的？这里的removeWeaklyReachableReferences方法就实现了我们说的 retainedKeys代表的是没有被GC回收的对象，queue中的弱引用代表的是被GC了的对象，之间的关联， 一个对象在queue可以找到当时在retainedKeys中找不到，那么肯定被回收了。gone()返回true说明对象已被回收，不需要观测了。
2. 为什么执行removeWeaklyReachableReferences()两次？为了保证效率，如果对象被回收，没必要再通知GC执行，Dump操作等等一系列繁琐步骤，况且GC是一个线程优先级极低的线程，就算你通知了，她也不一定会执行，基于这一点，我们分析的观测对象的时机就显得尤为重要了，在对象被回收的时候召唤观测。

何时执行观测对象

我们观测的是一个Activity，Activity这样的组件都存在生命周期，在他生命周期结束的时，观测他如果还存活的话 就肯定就存在内存泄露了，进一步推论，Activity的生命周期结束就关联到它的onDestory()方法，也就是只要重写这个方法就可以了。

    @Override
    protected void onDestroy() 
        super.onDestroy();
        refWatcher.watch(this);
    

在MainActivity中加上这行代码就好了，但是我们显然不想每个Activity都这样干，都是同样的代码为啥要重复着写，当然解决办法呼之欲出：

  private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new Application.ActivityLifecycleCallbacks() 
        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) 
        

        @Override public void onActivityStarted(Activity activity) 
        

        @Override public void onActivityResumed(Activity activity) 
        

        @Override public void onActivityPaused(Activity activity) 
        

        @Override public void onActivityStopped(Activity activity) 
        

        @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) 
        

        @Override public void onActivityDestroyed(Activity activity) 
          ActivityRefWatcher.this.onActivityDestroyed(activity);
        
      ;
    void onActivityDestroyed(Activity activity) 
        refWatcher.watch(activity);
    

LeakCanary源码是这样做的，通过ActivityLifecycleCallbacks转发，然后在install()中使用这个接口，这就实现了我们只需要调用LeakCanary.install(this);这句代码在Application中就可以实现监测

public final class LeakCanary 
    public static RefWatcher install(Application application) 
        return install(application, DisplayLeakService.class, AndroidExcludedRefs.createAppDefaults().build());
    

    public static RefWatcher install(Application application, Class<? extends AbstractAnalysisResultService> listenerServiceClass, ExcludedRefs excludedRefs) 
        if(isInAnalyzerProcess(application)) 
            return RefWatcher.DISABLED;
         else 
            enableDisplayLeakActivity(application);
            ServiceHeapDumpListener heapDumpListener = new ServiceHeapDumpListener(application, listenerServiceClass);
            RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);
            ActivityRefWatcher.installOnIcsPlus(application, refWatcher);
            return refWatcher;
        
    

不需要在每个Activity方法的结束再多写几行onDestroy()代码，但是这个方法有个缺点，看注释

  // If you need to support Android < ICS, override onDestroy() in your base activity.

        //ICS
        October 2011: Android 4.0.
        public static final int ICE_CREAM_SANDWICH = 14;

如果是SDK 14 Android 4.0以下的系统，不具备这个接口，也就是还是的通过刚才那种方式重写onDestory()方法。而且只实现了ActivityRefWatcher.installOnIcsPlus(application, refWatcher);对Activity进行监测，如果是服务或者广播还需要我们自己实现

分析hprof文件

接着分析，查看文件解析类发现他是个转发工具类

public final class ServiceHeapDumpListener implements HeapDump.Listener 
  ...
  @Override public void analyze(HeapDump heapDump) 
      Preconditions.checkNotNull(heapDump, "heapDump");
     //转发给HeapAnalyzerService
    HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
  

通过IntentService运行在另一个进程中执行分析任务

public final class HeapAnalyzerService extends IntentService 

  private static final String LISTENER_CLASS_EXTRA = "listener_class_extra";
  private static final String HEAPDUMP_EXTRA = "heapdump_extra";

  public static void runAnalysis(Context context, HeapDump heapDump,
      Class<? extends AbstractAnalysisResultService> listenerServiceClass) 
    Intent intent = new Intent(context, HeapAnalyzerService.class);
    intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName());
    intent.putExtra(HEAPDUMP_EXTRA, heapDump);
    context.startService(intent);
  

  @Override protected void onHandleIntent(Intent intent) 
    String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA);
    HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA);

    ExcludedRefs androidExcludedDefault = createAndroidDefaults().build();
    HeapAnalyzer heapAnalyzer = new HeapAnalyzer(androidExcludedDefault, heapDump.excludedRefs);
    //获取分析结果
    AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey);
    AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
  

查看heapAnalyzer.checkForLeak代码

public AnalysisResult checkForLeak(File heapDumpFile, String referenceKey) 
    long analysisStartNanoTime = System.nanoTime();

    if (!heapDumpFile.exists()) 
      Exception exception = new IllegalArgumentException("File does not exist: " + heapDumpFile);
      return AnalysisResult.failure(exception, since(analysisStartNanoTime));
    

    ISnapshot snapshot = null;
    try 
      // 加载hprof文件
      snapshot = openSnapshot(heapDumpFile);
      //找到泄露对象
      IObject leakingRef = findLeakingReference(referenceKey, snapshot);

      // False alarm, weak reference was cleared in between key check and heap dump.
      if (leakingRef == null) 
        return AnalysisResult.noLeak(since(analysisStartNanoTime));
      

      String className = leakingRef.getClazz().getName();
      // 最短引用路径
      AnalysisResult result =
          findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, className, true);
      //如果没找到  尝试排除系统进程干扰的情况下找出最短引用路径
      if (!result.leakFound) 
        result = findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, className, false);
      

      return result;
     catch (SnapshotException e) 
      return AnalysisResult.failure(e, since(analysisStartNanoTime));
     finally 
      cleanup(heapDumpFile, snapshot);
    
  

到这里，我们就找到了泄露对象的最短引用路径，剩下的工作就是发送消息给通知，然后点击通知栏跳转到我们另一个App打开绘制出路径即可。

补充—排除干扰项

但是我们在找出最短引用路径的时候，有这样一段代码，他是干什么的呢

 // 最短引用路径
      AnalysisResult result =
          findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, className, true);
      //如果没找到  尝试排除系统进程干扰的情况下找出最短引用路径
      if (!result.leakFound) 
        result = findLeakTrace(analysisStartNanoTime, snapshot, leakingRef, className, false);

查看findLeakTrace()

  private AnalysisResult findLeakTrace(long analysisStartNanoTime, ISnapshot snapshot,
      IObject leakingRef, String className, boolean excludingKnownLeaks) throws SnapshotException 

    ExcludedRefs excludedRefs = excludingKnownLeaks ? this.excludedRefs : baseExcludedRefs;

    PathsFromGCRootsTree gcRootsTree = shortestPathToGcRoots(snapshot, leakingRef, excludedRefs);

    // False alarm, no strong reference path to GC Roots.
    if (gcRootsTree == null) 
      return AnalysisResult.noLeak(since(analysisStartNanoTime));
    

    LeakTrace leakTrace = buildLeakTrace(snapshot, gcRootsTree, excludedRefs);

    return AnalysisResult.leakDetected(!excludingKnownLeaks, className, leakTrace, since(analysisStartNanoTime));
  

唯一的不同是excludingKnownLeaks 从字面意思也很好理解，是否排除已知内存泄露

其实是这样的，在我们系统中本身就存在一些内存泄露的情况，这是上层App工程师无能为力的。但是如果是厂商或者做Android Framework层的工程师可能需要关心这个，于是做成一个参数配置的方式，让我们灵活选择岂不妙哉。当然，默认是会排除系统自带泄露情况的，不然打开App，弹出一堆莫名其妙的内存泄露，我们还无能为力，着实让人惶恐，而且我们还可以自己配置。
通过ExcludedRefs这个类

public final class ExcludedRefs implements Serializable 

  public final Map<String, Set<String>> excludeFieldMap;
  public final Map<String, Set<String>> excludeStaticFieldMap;
  public final Set<String> excludedThreads;

  private ExcludedRefs(Map<String, Set<String>> excludeFieldMap,
      Map<String, Set<String>> excludeStaticFieldMap, Set<String> excludedThreads) 
    // Copy + unmodifiable.
    this.excludeFieldMap = unmodifiableMap(new LinkedHashMap<String, Set<String>>(excludeFieldMap));
    this.excludeStaticFieldMap = unmodifiableMap(new LinkedHashMap<String, Set<String>>(excludeStaticFieldMap));
    this.excludedThreads = unmodifiableSet(new LinkedHashSet<String>(excludedThreads));
  

  public static final class Builder 
    private final Map<String, Set<String>> excludeFieldMap = new LinkedHashMap<String, Set<String>>();
    private final Map<String, Set<String>> excludeStaticFieldMap = new LinkedHashMap<String, Set<String>>();
    private final Set<String> excludedThreads = new LinkedHashSet<String>();

    public Builder instanceField(String className, String fieldName) 
        Preconditions.checkNotNull(className, "className");
      Preconditions.checkNotNull(fieldName, "fieldName");
      Set<String> excludedFields = excludeFieldMap.get(className);
      if (excludedFields == null) 
        excludedFields = new LinkedHashSet<String>();
        excludeFieldMap.put(className, excludedFields);
      
      excludedFields.add(fieldName);
      return this;
    

    public Builder staticField(String className, String fieldName) 
        Preconditions.checkNotNull(className, "className");
        Preconditions.checkNotNull(fieldName, "fieldName");
      Set<String> excludedFields = excludeStaticFieldMap.get(className);
      if (excludedFields == null) 
        excludedFields = new LinkedHashSet<String>();
        excludeStaticFieldMap.put(className, excludedFields);
      
      excludedFields.add(fieldName);
      return this;
    

    public Builder thread(String threadName) 
        Preconditions.checkNotNull(threadName, "threadName");
      excludedThreads.add(threadName);
      return this;
    

    public ExcludedRefs build() 
      return new ExcludedRefs(excludeFieldMap, excludeStaticFieldMap, excludedThreads);
    
  

参考源码的使用方法，如下
排除staticField干扰

排除thread干扰

排除Field干扰