在Android的性能优化中，内存优化是必不可少的点，而内存优化最重要的一点就是解决内存泄漏的问题，在Android的内存泄漏分析工具也不少，比如PC端的有：AndroidStudio自带的Android Profiler、MAT等工具；手机端也有，就是我们今天要介绍的LeakCanary
LeakCanary简介
LeakCanary是Square公司为Android开发者提供的一个自动检测内存泄漏的工具，
LeakCanary本质上是一个基于MAT进行Android应用程序内存泄漏自动化检测的的开源工具，我们可以通过集成LeakCanary提供的jar包到自己的工程中，一旦检测到内存泄漏，LeakCanary就好dump Memory信息，并通过另一个进程分析内存泄漏的信息并展示出来，随时发现和定位内存泄漏问题，而不用每次在开发流程中都抽出专人来进行内存泄漏问题检测，极大地方便了Android应用程序的开发。
LeakCanary显示内存泄漏的页面：
image
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程序的时候，出现内存泄漏后，过一小段时间后就会在通知栏中通知出现内存泄漏的情况：
image
同时会在桌面上生成一个Leaks的图标，这个就是展示内存泄漏列表的，内存泄漏列表页面如下：
image
这是一个内存泄漏的列表，我们可以通过点击进入查看泄漏的内容
image
还可以通过点击右边的“+”号查看更详细的信息，内容太长就不截图了，内部有详细介绍调用的流程；
内存泄漏解决
上面的演示列子我们使用的是单列模式来产生内存泄漏，我们当然知道怎样正确的解决这个内存泄漏，
就是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中及时的关闭、注销或者释放内存，
由于篇幅过长这里就不对此展开介绍。
参考链接：
网友评论