导语
在Android的性能优化中,内存优化是必不可少的点,而内存优化最重要的一点就是解决内存泄漏的问题,在Android的内存泄漏分析工具也不少,比如PC端的有:AndroidStudio自带的Android Profiler、MAT等工具;手机端也有,就是我们今天要介绍的LeakCanary
LeakCanary简介
LeakCanary是Square公司为Android开发者提供的一个自动检测内存泄漏的工具,
LeakCanary本质上是一个基于MAT进行Android应用程序内存泄漏自动化检测的的开源工具,我们可以通过集成LeakCanary提供的jar包到自己的工程中,一旦检测到内存泄漏,LeakCanary就好dump Memory信息,并通过另一个进程分析内存泄漏的信息并展示出来,随时发现和定位内存泄漏问题,而不用每次在开发流程中都抽出专人来进行内存泄漏问题检测,极大地方便了Android应用程序的开发。
LeakCanary显示内存泄漏的页面:
LeakCanary优点:
1、针对Android Activity组件完全自动化的内存泄漏检查。
2、可定制一些行为(dump文件和leaktrace对象的数量、自定义例外、分析结果的自定义处理等)。
3、集成到自己工程并使用的成本很低。
4、友好的界面展示和通知。
LeakCanary工作机制:
引用LeakCanary中文使用说明,它的基本工作机制如下:
1、RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。
2、然后在后台线程检查引用是否被清除,如果没有,调用GC。
3、如果引用还是未被清除,把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。
4、在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析这个文件。
5、得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference,定位内存泄露。
6、HeapAnalyzer 计算 到 GC roots 的最短强引用路径,并确定是否是泄露。如果是的话,建立导致泄露的引用链。
7、引用链传递到 APP 进程中的 DisplayLeakService, 并以通知的形式展示出来。
LeakCanary的Android Studio集成
一、 在build.gradle中添加LeakCanary的依赖包,截止目前leakcanary的最新版本是1.6.1:
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.6.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.1'
}
在开发中一般同时集成debug和release版本,其中:
- com.squareup.leakcanary:leakcanary-android:1.6.1 是debug版本,在你的app编译的是debug版本,加载的是该jar包,一旦出现内存泄漏会在通知栏中通知开发者产生了内存泄漏;
- com.squareup.leakcanary:leakcanary-android-no-op:1.6.1 是release版本,如果你的app编译的是release版本时,加载的是该jar包,no-op是指No Operation Performed,代表不会做任何操作,不会干扰正式用户的使用;
二、 在我们自定义Application的onCreate方法中注册LeakCanary
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
}
- 解释一下为什么要先判断
LeakCanary.isInAnalyzerProcess(this)
在注册之前先判断LeakCanary是否已经运行在手机上,比如你同时有多个APP集成了LeakCanary,其他app已经运行了LeakCanary则不需要重新install
我们看一下isInAnalyzerProcess
方法的源码:
从源码中可以看到真正调用的是/** * Whether the current process is the process running the {@link HeapAnalyzerService}, which is * a different process than the normal app process. */ public static boolean isInAnalyzerProcess(Context context) { Boolean isInAnalyzerProcess = LeakCanaryInternals.isInAnalyzerProcess; // This only needs to be computed once per process. if (isInAnalyzerProcess == null) { isInAnalyzerProcess = isInServiceProcess(context, HeapAnalyzerService.class); LeakCanaryInternals.isInAnalyzerProcess = isInAnalyzerProcess; } return isInAnalyzerProcess; }
isInServiceProcess
方法,在来看下isInServiceProcess
的源码:
我们可以看到public static boolean isInServiceProcess(Context context, Class<? extends Service> serviceClass) { PackageManager packageManager = context.getPackageManager(); PackageInfo packageInfo; try { packageInfo = packageManager.getPackageInfo(context.getPackageName(), GET_SERVICES); } catch (Exception e) { CanaryLog.d(e, "Could not get package info for %s", context.getPackageName()); return false; } String mainProcess = packageInfo.applicationInfo.processName; ComponentName component = new ComponentName(context, serviceClass); ServiceInfo serviceInfo; try { serviceInfo = packageManager.getServiceInfo(component, 0); } catch (PackageManager.NameNotFoundException ignored) { // Service is disabled. return false; } if (serviceInfo.processName.equals(mainProcess)) { CanaryLog.d("Did not expect service %s to run in main process %s", serviceClass, mainProcess); // Technically we are in the service process, but we're not in the service dedicated process. return false; } int myPid = android.os.Process.myPid(); ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE); ActivityManager.RunningAppProcessInfo myProcess = null; List<ActivityManager.RunningAppProcessInfo> runningProcesses; try { runningProcesses = activityManager.getRunningAppProcesses(); } catch (SecurityException exception) { // https://github.com/square/leakcanary/issues/948 CanaryLog.d("Could not get running app processes %d", exception); return false; } if (runningProcesses != null) { for (ActivityManager.RunningAppProcessInfo process : runningProcesses) { if (process.pid == myPid) { myProcess = process; break; } } } if (myProcess == null) { CanaryLog.d("Could not find running process for %d", myPid); return false; } return myProcess.processName.equals(serviceInfo.processName); }
ComponentName component = new ComponentName(context, serviceClass);
而这个serviceClass
参数是isInAnalyzerProcess
方法中调用的HeapAnalyzerService
,HeapAnalyzerService
正是用来分析内存泄漏的单独进程,说以说LeakCanary在同一个手机只需要执行一次install
就可以了,当然执行多次也是可以的; - 回到正题,正常情况下
Application
调用LeakCanary.install(this)
后就可以正常监听该app程序的内存泄漏;
LeakCanary监听指定对象的内存泄漏
如果想让LeakCanary监听指定对象的内存泄漏,我们就需要使用到RefWatcher
的watch
功能,使用方式如下:
- 在
Application
的onCreate
中调用install
方法,并获取RefWatcher
对象:private static RefWatcher sRefWatcher; @Override public void onCreate() { super.onCreate(); sRefWatcher = LeakCanary.install(this); } public static RefWatcher getRefWatcher() { return sRefWatcher; }
注意:因为这时候需要获取sRefWatcher对象,所以sRefWatcher = LeakCanary.install(this)一定需要执行,不需要判断LeakCanary.isInAnalyzerProcess(this)
- 为了方便演示使用LeakCanary获取和解决内存泄漏的问题,我们先写一个内存泄漏的场景,我们知道最常见的内存泄漏是单列模式使用
Activity
的Context
场景,所以我们也用单列模式来演示:public class Singleton { private static Singleton singleton; private Context context; private Singleton(Context context) { this.context = context; } public static Singleton newInstance(Context context) { if (singleton == null) { synchronized (Singleton.class) { if (singleton == null){//双重检查锁定 singleton = new Singleton(context); } } } return singleton; } }
- 在需要监听的对象中调用
RefWatcher
的watch
方法进行监听,比如我想监听一个Activity
,我们可以在该Acitivity
中onCreate
方法中添加DemoApp.getRefWatcher().watch(this);
:@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); DemoApp.getRefWatcher().watch(this); setContentView(R.layout.activity_second); Singleton singleton = Singleton.newInstance(this); }
LeakCanary内存泄漏展示页面
同时上面的步骤,当我们在运行app程序的时候,出现内存泄漏后,过一小段时间后就会在通知栏中通知出现内存泄漏的情况:
同时会在桌面上生成一个Leaks的图标,这个就是展示内存泄漏列表的,内存泄漏列表页面如下:
这是一个内存泄漏的列表,我们可以通过点击进入查看泄漏的内容
还可以通过点击右边的“+”号查看更详细的信息,内容太长就不截图了,内部有详细介绍调用的流程;
内存泄漏解决
上面的演示列子我们使用的是单列模式来产生内存泄漏,我们当然知道怎样正确的解决这个内存泄漏,
就是Singleton singleton = Singleton.newInstance(this)
的调用传入Contxt
时使用ApplicationContext
;
这里总结一下产生内存泄漏的常见场景和常用的解决方案
- 常见的内存泄漏场景:
1、单例设计模式造成的内存泄漏
2、非静态内部类创建的静态实例造成的内存泄漏
3、Handler造成的内存泄漏
4、线程造成的内存泄漏
5、资源未关闭造成的内存泄漏 - 常见的解决方案(思路)
1、尽量使用Application的Context而不是Activity的漏
2、使用弱引用或者软引用漏
3、手动设置null,解除引用关系漏
4、将内部类设置为static,不隐式持有外部的实例漏
5、注册与反注册成对出现,在对象合适的生命周期进行反注册操作。漏
6、如果没有修改的权限,比如系统或者第三方SDK,可以使用反射进行解决持有关系
7、在使用完BraodcastReceiver,ContentObserver,File,Cursor,Stream,Bitmap等资源时,一定要在Activity中的OnDestry中及时的关闭、注销或者释放内存,
由于篇幅过长这里就不对此展开介绍。
参考链接:
https://github.com/square/leakcanary
https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/