关于androidleakcanary的信息

本篇文章给大家谈谈androidleakcanary，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、如何在编译android源码中引入leakcanary
• 2、android内存优化
• 3、如何在Android Studio中使用LeakCanary检测内存泄露
• 4、Android Studio 导入LeakCanary文件进行分析
• 5、Android-LeakCanary原理解析

如何在编译android源码中引入leakcanary

步骤：

1 在橘扒搭build.gradle 文件的 dependencies里面加上：

compile 'com.squareup.leakcanary:leakcanary-android:1.5'

2 在应用的最先执行的类圆拿里面比如Application类里面（自定义一此启个继承Application），在onCreate（）生命周期方法加上：

LeakCanary.install(this);

完事~

[img]

android内存优化

Android内存优化实践

1.内存模型与分布

我们知道android应用大多是使用java语言进行开发的，这就需要我们了解java的内存模型，此外在android中的应用都是基于Dalvik 虚拟机或者ART虚拟机，那么对这些虚拟机的内存分布也应该有所了解。

上图是常见的java虚拟机的内存分布图：

方法区：主要存储虚拟机加载的类信息，常量，静态变量，及时编译器编译后的代码等数据。内存优化时这一部分主要考虑是不是加载了很多不必要的第三方库。这部分的内存减少主要是常量池的回收和类的卸载（类卸载条件：无引用，类加载器可卸载）

堆：几乎所有的对象都在这个区域产生，该区域属于线程共享的区域，所以写代码时更要注意多线程安全。这个内存区域的大小变化主要是对象的创建和回收，比如：如果短时间内有大量的对象创建和回收，可能会造成内存抖动，如果对象创建之后一直回收不掉，则会导致内存泄漏，严重的内存泄漏会导致频繁的gc，从而是界面卡顿。

虚拟机栈：这个区域描述的是java方法执行的内存模型，我们常说的方法栈的入栈就是将方法的栈帧存储到虚拟机栈，这个区域是线程私有的，其生命周期就是线程的生命周期。也就昌凯是说每个线程都会有，默认一个线程的线程栈大小是1M，这不包括在方法中产生的其他对象的大小。这一块我们能控制的就是线程的数量，特别是程序中没有使用线程池或者使用的多个第三方库都带有线程池的情况。

本地方法栈：同虚拟机栈的作用非常类似，是为虚拟机执行native方法服务的，所以需要注意的地方也和虚拟机栈一样，特别是使用了第三方so的情况

程序计数器：当前线程执行的虚拟机字节码的行号记录器，占用的内存较小，可以不考虑

2.内存限制

android是基于Linux系统的，android中的进程分为两种：

1.native进程：采用C/C++实现，不包含dalvik实例的linux进程，/system/bin/目录下面的程序文件运行后都是以native进程形式存在的

2.java进程：实例化了dalvik虚拟机实例的linux进程，进程的入口main函数为java函数。dalvik虚拟机实例的宿主进程是fork()系统调用创建的linux进程，所以每一个android上的java进程实际上就是一个linux进程，只是进程中多了一个dalvik虚拟机实例

我们知道，操作系统对进程的内存是有限制的，而且操作系统对dalvik虚拟机自身的堆内存大小也是有限制的。可以通过如下命令查看限制大小：

adb shell getprop | grep dalvik.vm.heapgrowthlimit

可以在Androidmanifest文件中application节点加入android:largeHeap=“true”来增加其dalvik虚拟机中堆的大小

我们常说的堆大小其实是包涵两部分的，一是java的堆，而是native的堆，java堆中主要是一下java对象，由 C/C++申请的内存空间则在native堆中，也有一些对象需要结合native和java堆共同完成，比如bitmap，bitmap分为bitmap对象和其中存储的像素值，对象分配在java堆，而存储的像素值旅迅茄则根据版本不同存储的位置也不同，api 11 - api 25是存储在java堆中的，其他版本是存储在native堆中的；

3.内存泄漏

常见的内存泄漏：

1.静态引用（自身代码和第三方代码）

2.集合内引用

3.Handler消息未清除

4.非静态的内部类中持有外部内的应用

5.匿名内部类/非静态内部类和异步线程

检查的方式：

我这里使用的是leakcanary，一般简单的内存泄漏可以直接在leakcanary中查到引用链路，不能查看的我是使用MAT来分析的当前内存信息；

上图中各项详细的指标的意义可以在这里查到，这里主要占比比较大的几个区域：

allocated：表示app内分配的java的对象数，从当前数值可以看出程序内可能存在过多创建对象的情况，比如string对象

Native：从 C 或 C++ 代码分配的对拆察象内存，频繁进出相关页面发现native堆的大小并没有减小，说明存在c/c++层的内存泄漏

Code：您的应用用于处理代码和资源（如 dex 字节码、已优化或已编译的 dex 码、.so 库和字体）的内存。这个区域能优化的就是移除不需要的so库，懒加载使用so库，移除无用代码（import，方法和类）

4.优化实践

了解了android中的内存分布和泄漏相关，接下来就是结合自身业务进行内存优化了，如下：

1.先解决程序中内存占用较大的业务模块中的内存泄漏，不熟悉MAT的使用的可以看看这个

2.移除程序中多余的代码和引用，这里使用默认的lint检测再配合shrinkResources来删除无效资源

3.优化图片，保证图片放置在合理的文件夹，根据View大小加载合适的图片大小，根据手机状态配置bitmap和回收策略

4.优化对象创建，比如string，使用对象池等

如何在Android Studio中使用LeakCanary检测内存泄露

如何查看内存泄露

主要有2种方法

借助工具，查看。

借助adb 命令来查看。

【主要原理含亮】

借助工具来查看泄露的原因。

详细实现方式

【工具查看】

常用工具有很多例如：

1.功能强脊老晌大PC端检测工具，如MemoryAnalyzer运行在PC端抓取Android手机中的dump文件进行深度分析。

2.小而优的Android端检测工具，如LeakCanary随App一起安装会在Android手机桌面安装的内存泄露检测App

详细的介绍百度里面非常多这边不做过多的介绍。

3.还有一种樱锋，要求不高的可以通过android studio查看内存变化等

Android Studio 导入LeakCanary文件进行分析

Android Studio打开profile崩溃解决方案

Android Studio 使用Profile官方指南

LeakCanary检测内存泄露案例让明分析

前面我们说道使用LeakCanary进行了初步的内存分析。接下来我们说一下，如何通过Android Studio自带的Proflie进行深度分析

1.首先，需要把手机里面的leak收集到坦灶告的hprof文件进行导入。

导入方式如下：

路径是：

Physical#手机#Actions#文件夹#storage#sdcard0#Download#leakcanary-xxx(包名)#选中需要导出的文件#Save as#对应保存的路径

2.从电脑导入对应需要分析的hprof文件

路径是：

Profiler#SESSIONS#+#load from file

3.如辩搜何分析，如图

主要看Depth深度，如果大于0。那么我们就需要谨慎分析处理可能存在的引用关系

Android-LeakCanary原理解析

在分析LeakCanary原理之前，首卖困先需要了解ReferenceQueue在LeakCanary的作用。

WeakReference在创建时，如果指定一个ReferenceQueue对象，在垃圾回收检测到被引用的对象的可达性更改后，垃圾回收器会将已注册的引用对象添加到ReferenceQueue对象中，等待ReferenceQueue处理。但是如果当GC过后引用对象仍然不被加入ReferenceQueue中，就可能存在内存泄露问题。这里ReferenceQueue对象中，存的其实就是WeakReference对象，而不是WeakReference中引用的要被回收的对象。即GC过后，WeakReference引用的对象被回收了，那么WeakReference引用的对象就是null，那么该WeakReference对象就会被加入到ReferenceQueue队列中。

所以我们可以通过监听 Activity.onDestroy() 回调之后，通过弱引用（WeakReference）对象、ReferenceQueue和 GC来观测Activity引用的内存泄露情况，如果发现了未被回收的Activity对象，在找到该Activity对象是否被其他对象所引用，如果被其他对象引用，就进行 heap dump生成完整的内存引用链（最短引用链），并通过notification等方式展示出来。

LeakCanary2.+的启动，与LeakCanary1.+的不同，1.+版本的启动，需要在Application的onCreate中手动调用LeakCanary.install方法进行启动；而2.+版本的启动则不需要，而是依赖ContentProvider，因为ContentProvider会在Application之前被加载，所以ContentProvider的onCreate方法会在Application的onCreate方法之前被调用，所以在ContentProvider的onCreate方法中完成初始化工作。

在源码中leakcanary-leaksentry中有一个LeakSentryInstaller，LeakSentryInstaller其实就是ContentProvider的一个子类，在其onCreate方法中就会调用InternalLeakSentry.install(application)进行初始化工作。

然后在AndroidManifest.xml中注册该ContentProvider。在这里注册，那么打包项目时，会将每个库和library中的AndroidManifest.xml合并到最终的app的androidManifest中。

LeakCanary的初始化是在InternalLeakSentry的install方法，即在ContentProvider的onCreate中调用。

这里的listener是LeakSentryListener接口，而实现LeakSentryListener接口的类，其实就是InternalLeakCanary，InternalLeakCanary是在leakcanary-android-core下的，InternalLeakCanary是单例模式的，采用的是kotlin单例，即用object关键字修饰类。

这里使用的RefWatcher对象，是在InternalLeakSentry中进行初始化郑档的，然后在调用ActivityDestroyWatcher和FragmentDestroyWatcher的install方法的时候，传入。

在监测Activity和Fragment的生命周期进行内存回收以及是否泄露的过程，就是调用RefWatcher.watch方法进行，该方法是使用Synchronized修饰的同步方法。RefWatcher.watch的方法，一般是在Activity和Fragment生命周期执行到onDestroy的时候调用。根据生命周期监听触发回调，然后调用RefWatcher.watch方法。

VisibilityTracker其实中丛念就是在InternalLeakCanary.onLeakSentryInstalled方法中通过调用application.registerVisibilityListener方法的时候，添加的Application.ActivityLifecycleCallbacks，这里采用适配器模式，使用适配器模式的目的，其实就是不需要重写所有方法，只在VisibilityTracker中重写需要使用的方法。

VisibilityTracker的目的其实就是监听Activity的生命周期变化，即是否是执行到了onStart和onStop，如果是onStop的时候，则做内存泄露监测工作。

VisibilityTracker与ActivityDestroyWatcher有点区别，ActivityDestroyWatcher是最终Activity执行onDestroy的时候进行内存泄露分析

本方法是在InternalLeakCanary.onLeakSentryInstalled给application添加生命周期回调的时候，根据onStart和onStop生命周期的变化来进行Heap Dump（heap dump文件(.hprof)）

当生命周期执行到onStop的时候，会向该Application的扩展函数registerVisibilityListener的参数listener这个高阶函数传入boolean参数为false

看InternalLeakCanary#onLeakSentryInstalled方法中对application添加的生命周期监听，这是调用了application的扩展函数，该扩展函数是在VisibilityTracker中定义的。

其实registerVisibilityListener方法内部调用的就是application的registerActivityLifecycleCallbacks方法，传入的是Application.ActivityLifecycleCallbacks对象，这里传入的是VisibilityTracker，其实VisibilityTracker就是Application.ActivityLifecycleCallbacks的子类实现。

HeapDumpTrigger.onApplicationVisibilityChanged方法的调用，就是根据上述传给VisibilityTracker的listener函数来回调调用的，listener接收的是false的时候，就会调用scheduleRetainedInstanceCheck，接收的是false的时候是生命周期执行到onStop的时候。

这里的delayMillis默认是5s，因为该参数接收的是LeakSentry.config.watchDurationMillis，这个值初始默认值是5s。

关于androidleakcanary和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。