1307人阅读
Android Base（35）
OpenDeveloper（15）
Mac and DevTools（12）
内存泄漏，memory leak，开发者经常念叨的一个词，稍不留意，就游走在我们的代码中。Andriod开发，内存泄漏的原因有很多，比如activity的context引用，static引用，广播未取消注册，MVP设计时没有detachView，Rx没有取消subscribe订阅，动画处理等。检测的工具也很多。今天总结下，LeakCanary的使用。看这图，Js接口引用activity泄漏了528kb。
一，大话内存泄漏
Java通过垃圾收集器（GC, garbage collection）来自动管理内存。当一个对象不再被使用，就会被自动回收。而“内存泄漏“就是没有成功回收内存的体现。一个对象已经不需要再使用了，但是因为其它的对象持有该对象的引用，导致它的内存不能被回收。“内存泄漏”积累到一定程度，可能导致OOM，所以在写代码的过程中，要注意导致“内存泄漏”的代码写法，提高代码的健壮性。
二，内存泄漏的类型
如果一个对象是可达的有引用的，但实际上它已经没有再使用了，但引用它的对象依然存在，这样的它就是内存泄漏的对象。内存泄漏可分为以下几种类型：
1、静态变量引起的内存泄漏
通常是，一个静态变量，持有对象的应用，对象销毁了，static修饰的变量还在，导致内存无法回收。我之前在BaseActivity中加入实现类到集合中，就造成过内存泄漏。如过静态context一直持有activity的引用，onDestory执行后造成内存泄漏。
public class LeakActivity extends Activity {
private static Context sC
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_leak);
sContext = this;
我遇到的情况，activity当上下文传，js接口引用webview所在的activity，反正不要静态的引用。
2、非静态内部类引起的内存泄漏
如果用android studio开发，写handle发送消息，下面的写法会有黄色警告，因为可能会引发内存泄漏:
private Handler mHandler = new Handler() {
public void handleMessage(Message msg) {
super.handleMessage(msg);
为什么呢？非静态内部类会引用外部类对象（Activity），当它使用了 postDelayed 的时候，如果 Activity 已经 finish 了，而这个 handler 仍然引用着这个 Activity 就会致使内存泄漏，因为这个 handler 会在一段时间内继续被 mainLooper 持有，导致引用仍然存在，在这段时间内，如果内存不够使，可能OOM了。
3、资源未关闭引起的内存泄漏
IO流的操作，切记要close关闭流，文件读写，网络访问等都要及时关闭字节流、字符流；注册了广播要在onDestory方法中销毁。使用了BraodcastReceiver、Cursor、Bitmap等资源时，需要及时释放掉，若没有释放，则会引起内存泄漏。这个比较好理解。
三，内存泄漏检测工具
用Eclipse开发自带的内存检测工具：Heap。
DDMS中的Heap工具用于大致分析是否存在“内存泄漏”，而MAT工具则用于分析“内存泄漏”发生在哪里，MAT工具中,File-&Open Heap Dump，可以打开xxx.hprof文件分析。这个我现在不用。不多说。直接看下面介绍的LeakCanary。
四，LeakCanary，内存泄漏精确检测神器。
要精确地追踪到内存泄漏点，强烈推荐使用Square 公司开源的 LeakCanary开源方案，LeakCanary在Application实现类中一行代码，简单暴力侵入性地捕获内存泄漏代码，甚至捕获Android组件的内存泄漏代码。我发现android动画绘制的时候存在内存泄漏的问题。
1，LeakCanary就像金丝雀监视着你的“煤矿”
不用重复造轮子，直接拿来，android studio开撸步骤：
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'
compile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
public class ExampleApplication extends Application{
@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
Good，好了，LeakCanary这是金丝雀会随着你app的运行，自动安装监测，给你通知。方便你查看那个类出现了内存泄漏，甚至告诉你泄漏了多少M。如图：
2，查看log日志，分析LeakCanary收集的数据
一般通过它的通知界面就很明了了，如果要详细看看过程，看log部分如下：SplashActivity has leaked！
遇到内存泄漏不是什么好事，所以平时写代码，留个心眼，以预防为主。一些通用的解决方案：
1，使用Application的context
需要上下文的时候，如果不是非得activity对象，传入Application的context,因为Application的context的生命周期比Activity长，它是app全局的，相当于static的生命周期。
2，static变量不要引用view实例
3，关闭资源，close，unsubscribe，unregister，null记得吃药。
欢迎交流，Dusan，杜乾，！OpenDeveloper！
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：84741次
积分：1474
积分：1474
排名：千里之外
原创：56篇
评论：22条
公众号：OpenDeveloper
(1)(2)(1)(2)(6)(27)(18)(1)(2)(4)当前位置： >
内存泄漏检测库针对Android和Java。
时间： 11:20 来源：互联网 作者：源码搜藏 浏览：
LeakCanary 内存泄漏检测库针对 Android 和Java。 小不忍则乱大谋。 -本杰明富兰克林 入门 在你 的build.gradle ： dependencies { debugCompile com.squareup.leakcanary:leakcanary-android:1.3.1 // or 1.4-beta1 releaseCompile com.squareup.leakcanary
LeakCanary
内存泄漏检测库针对和Java。
&小不忍则乱大谋。&&-本杰明&富兰克林
在你的build.gradle：
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1' // or 1.4-beta1
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' // or 1.4-beta1
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' // or 1.4-beta1
在您的应用程序类：
public class ExampleApplication extends Application {
@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
你是好去！当你的调试版本检测到活动内存泄漏LeakCanary会自动显示一个通知。
为什么要使用LeakCanary？
很高兴你问！我们写了一篇正是要回答这个问题。
我如何使用它？
使用RefWatcher看，应该是GCed引用：
RefWatcher refWatcher = {...};
// We expect schrodingerCat to be gone soon (or not), let's watch it.
refWatcher.watch(schrodingerCat);
LeakCanary.install（）返回配置的预RefWatcher。它还安装了ActivityRefWatcher如果活动泄漏后，可以自动检测Activity.onDestroy（）被调用。
public class ExampleApplication extends Application {
public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication) context.getApplicationContext();
return application.refW
private RefWatcher refW
@Override public void onCreate() {
super.onCreate();
refWatcher = LeakCanary.install(this);
您可以使用RefWatcher观看的片段泄漏：
public abstract class BaseFragment extends Fragment {
@Override public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(this);
它是如何工作的？
RefWatcher.watch（）创建一个到监视对象。
后来，在后台线程，它会检查是否引用已被清除，如果没有它触发GC。
如果参考仍未清除，它会转储堆到.hprof存储应用程序的文件系统上的文件。
HeapAnalyzerService是在一个单独的进程开始，HeapAnalyzer使用解析堆转储。
HeapAnalyzer发现KeyedWeakReference堆转储由于采用了独特的引用键和定位泄漏参考。
HeapAnalyzer计算最短强参考路径到GC罗茨，以确定是否存在泄漏，然后生成引起泄漏的引用链。
将结果传回给DisplayLeakService在应用过程中，和泄漏通知被示出。
如何复制泄漏痕迹？
你可以看到在logcat的泄漏跟踪：
在com.example.leakcanary：1.0：1 com.example.leakcanary.MainActivity渗漏：
* GC线程ROOT的java.lang.Thread。&Java的地方&（命名为&AsyncTask的＃1&）
*引用com.example.leakcanary.MainActivity $ 3，本$ 0（匿名类扩展android.os.AsyncTask）
*泄漏com.example.leakcanary.MainActivity实例
*参考键：e71f3bf5-d786-4afaecad1d
*设备：Genymotion通用谷歌Nexus 6
*的Android版本：5.1 API：22
*持续时间：观看= 5086ms，GC = 110毫秒，堆转储= 435ms，分析= 2086ms
你也可以分享泄漏跟踪，并从堆转储文件操作栏菜单。
如何解决内存泄漏？
一旦你有泄漏痕迹，找出哪些路径参考不应该存在。然后弄清楚为什么该引用仍然存在。很多时候，这是一个注册的侦听器应该是未注册的，一个close（）方法是不叫的方法，即持有引用外部类匿名类。如果你不能在你的代码中找出问题，请不要提交问题。相反，创建一个（使用leakcanary标签）。
我的泄漏是由Android SDK的实施造成的！
有许多已经在AOSP以及在制造商实现了固定的一段时间内已知的内存泄漏。当这样的泄漏发生时，有一点你可以做一个应用程序开发人员来修复它。出于这个原因，LeakCanary具有已知的Android泄漏的内置列表忽略：。
如果你找到一个新的，请，并按照下列步骤操作：
提供整个泄漏跟踪信息（参考键，设备等）。
阅读该版本的Android的AOSP源代码，并试图弄清楚为什么会发生。您可以通过SDK版本轻松浏览。
检查是否发生在Android的最新版本，并以其他方式使用怪发现，当它被固定的。
如果问题仍然发生，构建一个简单的摄制情况
文件中的问题上与泄漏跟踪和摄制情况
创建LeakCanary公关更新AndroidExcludedRefs.java。可选：如果你发现一个黑客以清除在Android的早期版本的泄漏，随时记录下来。
这是特别重要的Android的新版本。你有机会来帮助发现早期新的内存泄漏，这有利于整个Android社区。
除了微量泄漏
有时漏痕迹是不够的，你需要挖掘与堆转储或。这里是你如何能找到头部转储泄漏实例：
寻找的所有实例com.squareup.leakcanary.KeyedWeakReference
对于这些，看关键领域。
找到KeyedWeakReference具有键字段等于由LeakCanary报告的参考键。
该指涉的领域KeyedWeakReference是你的泄漏对象。
从此，此事是在你的手中。一个良好的开端是看的最短路径的GC根（不含弱引用）。
定制并使用无操作的依赖
该leakcanary-Android的无操作释放依赖构建只包含LeakCanary和RefWatcher类。如果你开始自定义LeakCanary，你需要确保定制只发生在调试版本，因为它可能会引用不存在的类leakcanary-Android的无操作的依赖。
比方说，你的发布版本声明一个ExampleApplication类AndroidManifest.xml中，你的调试版本声明了一个DebugExampleApplication扩展ExampleApplication。
在您的共享资源：
public class ExampleApplication extends Application {
public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication) context.getApplicationContext();
return application.refW
private RefWatcher refW
@Override public void onCreate() {
super.onCreate();
refWatcher = installLeakCanary();
protected RefWatcher installLeakCanary() {
return RefWatcher.DISABLED;
在调试来源：
public class DebugExampleApplication extends ExampleApplication {
protected RefWatcher installLeakCanary() {
RefWatcher refWatcher = ? // Build a customized RefWatcher
return refW
这样一来，你的发布代码将包含不超过存在于两个空类等参考LeakCanary&leakcanary-Android的无操作的依赖。
图标和标签
DisplayLeakActivity自带的默认图标和标签，您可以通过提供改变R.drawable .__ leak_canary_icon和R.string .__ leak_canary_display_activity_label在您的应用程序：
drawable-hdpi/
__leak_canary_icon.png
drawable-mdpi/
__leak_canary_icon.png
drawable-xhdpi/
__leak_canary_icon.png
drawable-xxhdpi/
__leak_canary_icon.png
drawable-xxxhdpi/
__leak_canary_icon.png
&?xml version=&1.0& encoding=&utf-8&?&
&resources&
&string name=&__leak_canary_display_activity_label&&MyLeaks&/string&
&/resources&
存储泄漏的痕迹
DisplayLeakActivity节省多达7堆转储和泄漏的痕迹在app目录。您可以通过提供改变这个数字R.integer .__ leak_canary_max_stored_leaks在您的应用程序：
&?xml version=&1.0& encoding=&utf-8&?&
&resources&
&integer name=&__leak_canary_max_stored_leaks&&20&/integer&
&/resources&
可在1.4-SNAPSHOT。
直到参考被认为提供了内存泄漏，您可以更改延迟R.integer.leak_canary_watch_delay_millis在您的应用程序：
&?xml version=&1.0& encoding=&utf-8&?&
&resources&
&integer name=&leak_canary_watch_delay_millis&&1500&/integer&
&/resources&
默认延迟为5秒。
上传到服务器
您可以更改默认行为泄漏跟踪和堆转储上传到您选择的服务器。
创建您自己的AbstractAnalysisResultService。最简单的方法是延长DisplayLeakService在调试来源：
public class LeakUploadService extends DisplayLeakService {
@Override protected void afterDefaultHandling(HeapDump heapDump, AnalysisResult result, String leakInfo) {
if (!result.leakFound || result.excludedLeak) {
myServer.uploadLeakBlocking(heapDump.heapDumpFile, leakInfo);
建立一个自定义RefWatcher在调试应用程序类：
// ExampleApplication在&自定义定义和使用无操作dependency&
DebugExampleApplication
ExampleApplication {
RefWatcher
installLeakCanary () {
LeakCanary . install(app, LeakUploadService . class, AndroidExcludedRefs . createAppDefaults() . build());
不要忘记在调试注册服务的AndroidManifest.xml：
&?xml version=&1.0& encoding=&utf-8&?&
&manifest xmlns:android=&/apk/res/android&
xmlns:tools=&/tools&
&application android:name=&com.example.DebugExampleApplication&&
&service android:name=&com.example.LeakUploadService& /&
&/application&
&/manifest&
您也可以上传泄漏痕迹，松弛或HipChat，。
忽略具体引用
你可以创建自己的版本ExcludedRefs忽略你知道是造成泄漏，但你仍然想要忽略具体的参考：
// ExampleApplication在&自定义定义和使用无操作
public class DebugExampleApplication extends ExampleApplication {
protected RefWatcher installLeakCanary() {
ExcludedRefs excludedRefs = AndroidExcludedRefs.createAppDefaults()
.instanceField(&com.example.ExampleClass&, &exampleField&)
return LeakCanary.install(this, DisplayLeakService.class, excludedRefs);
不看具体的活动课
ActivityRefWatcher是默认安装和手表的所有活动。您可以自定义安装步骤，使用不同的东西来代替：
// ExampleApplication在&自定义定义和使用无操作
public class DebugExampleApplication extends ExampleApplication {
@Override protected RefWatcher installLeakCanary() {
if (LeakCanary.isInAnalyzerProcess(this)) {
return RefWatcher.DISABLED;
ExcludedRefs excludedRefs = AndroidExcludedRefs.createAppDefaults().build();
LeakCanary.enableDisplayLeakActivity(this);
ServiceHeapDumpListener heapDumpListener = new ServiceHeapDumpListener(this, DisplayLeakService.class);
final RefWatcher refWatcher = LeakCanary.androidWatcher(this, heapDumpListener, excludedRefs);
registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
public void onActivityDestroyed(Activity activity) {
if (activity instanceof ThirdPartyActivity) {
refWatcher.watch(activity);
return refW
开发版快照
如果leakcanary-的Android是不是在Android Studio中的外部库的列表，但leakcanary分析仪和leakcanary观察家在那里：尝试做一个干净的构建。如果它仍然是一个问题，尝试在命令行建设。
错误：包com.squareup.leakcanary不存在：如果你有其他类型的建设比调试和释放，你需要添加一个特定的依赖也为它们（xxxCompile）。
库下载地址/square/leakcanary
LeakCanary：检测所有的内存泄漏！。
扯皮的Dalvik系列：。
上传泄漏的痕迹到。
计算器：。你的位置： >
> 使用新版Android Studio检测内存泄露和性能
内存泄露，是Android开发者最头疼的事。可能一处小小的内存泄露，都可能是毁于千里之堤的蚁穴。
怎么才能检测内存泄露呢？网上教程非常多，不过很多都是使用Eclipse检测的, 其实1.3版本以后的Android Studio 检测内存非常方便, 如果结合上MAT工具,LeakCanary插件,一切就变得so easy了。
熟悉Android Studio界面
工欲善其事,必先利其器。我们接下来先来熟悉下Android Studio的界面
一般分析内存泄露, 首先运行程序,打开日志控制台,有一个标签Memory ,我们可以在这个界面分析当前程序使用的内存情况, 一目了然, 我们再也不需要苦苦的在logcat中寻找内存的日志了。
图中蓝色区域，就是程序使用的内存， 灰色区域就是空闲内存，
当然，Android内存分配机制是对每个应用程序逐步增加, 比如你程序当前使用30M内存, 系统可能会给你分配40M, 当前就有10M空闲, 如果程序使用了50M了,系统会紧接着给当前程序增加一部分,比如达到了80M， 当前你的空闲内存就是30M了。 当然,系统如果不能再给你分配额外的内存,程序自然就会OOM(内存溢出)了。 每个应用程序最高可以申请的内存和手机密切相关，比如我当前使用的华为Mate7,极限大概是200M,算比较高的了, 一般128M 就是极限了, 甚至有的手机只有可怜的16M或者32M，这样的手机相对于内存溢出的概率非常大了。
我们怎么检测内存泄露呢
首先需要明白一个概念, 内存泄露就是指,本应该回收的内存,还驻留在内存中。
一般情况下,高密度的手机,一个页面大概就会消耗20M内存,如果发现退出界面,程序内存迟迟不降低的话,可能就发生了严重的内存泄露。
我们可以反复进入该界面，然后点击dump java heap 这个按钮,然后Android Studio就开始干活了,下面的图就是正在dump
dump成功后会自动打开 hprof文件,文件以Snapshot+时间来命名
通过Android Studio自带的界面,查看内存泄露还不是很智能,我们可以借助第三方工具,常见的工具就是MAT了,下载地址
,这里我们需要下载独立版的MAT. 下图是MAT一开始打开的界面, 这里需要提醒大家的是，MAT并不会准确地告诉我们哪里发生了内存泄漏，而是会提供一大堆的数据和线索，我们需要自己去分析这些数据来去判断到底是不是真的发生了内存泄漏。
接下来我们需要用MAT打开内存分析的文件, 上文给大家介绍了使用Android Studio生成了 hprof文件, 这个文件在呢, 在Android Studio中的Captrues这个目录中,可以找到
注意,这个文件不能直接交给MAT, MAT是不识别的, 我们需要右键点击这个文件,转换成MAT识别的。
然后用MAT打开导出的hprof(File-&Open heap dump) MAT会帮我们分析内存泄露的原因
LeakCanary
上面介绍了MAT检测内存泄露, 再给大家介绍LeakCanary。
项目地址：
LeakCanary会检测应用的内存回收情况，如果发现有垃圾对象没有被回收，就会去分析当前的内存快照，也就是上边MAT用到的.hprof文件，找到对象的引用链，并显示在页面上。这款插件的好处就是,可以在手机端直接查看内存泄露的地方,可以辅助我们检测内存泄露
在build.gradle文件中添加，不同的编译使用不同的引用：
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
在应用的Application onCreate方法中添加LeakCanary.install(this)，如下
public class ExampleApplication extends Application
public void onCreate() {
super.onCreate();
LeakCanary.install(this);
应用运行起来后，LeakCanary会自动去分析当前的内存状态，如果检测到泄漏会发送到通知栏，点击通知栏就可以跳转到具体的泄漏分析页面。
Tips：就目前使用的结果来看，绝大部分泄漏是由于使用单例模式hold住了Activity的引用，比如传入了context或者将Activity作为listener设置了进去，所以在使用单例模式的时候要特别注意，还有在Activity生命周期结束的时候将一些自定义监听器的Activity引用置空。
关于LeakCanary的更多分析可以看项目主页的介绍，还有这里
追踪内存分配
如果我们想了解内存分配更详细的情况,可以使用Allocation Traker来查看内存到底被什么占用了。
用法很简单：
点一下是追踪， 再点一下是停止追踪， 停止追踪后 .alloc文件会自动打开,打开后界面如下:
当你想查看某个方法的源码时,右键选择的方法,点击Jump to source就可以了
查询方法执行的时间
Android Studio 功能越来越强大了, 我们可以借助AS观测各种性能,如下图:
如果我们要观测方法执行的时间,就需要来到CPU界面
点击Start Method Tracking, 一段时间后再点击一次, trace文件被自动打开,
非独占时间: 某函数占用的CPU时间,包含内部调用其它函数的CPU时间。
独占时间: 某函数占用CPU时间,但不含内部调用其它函数所占用的CPU时间。
我们如何判断可能有问题的方法？
通过方法的调用次数和独占时间来查看，通常判断方法是：
如果方法调用次数不多，但每次调用却需要花费很长的时间的函数，可能会有问题。
如果自身占用时间不长，但调用却非常频繁的函数也可能会有问题。
上面给大家介绍了若干使用Android Studio检查程序性能的工具,工具永远是辅助,不要因为工具耽误太长时间。如果有问题，欢迎大家纠正。
转载请注明： &
与本文相关的文章暂没有新消息哦～
Android 内存泄漏工具 ...
视频中使用的开发工具是android studio 我想知道在eclipse中如何导入LeakCanary
LeakCanary默认是as开发的结构。可能你需要修改源代码将项目修改为eclipse格式。然后导入作为library使用就可以
针对你得问题，我觉得，是时候使用Android studio替换eclipse了。谷歌已经不再继续支持eclipse 了。这个库的创造者也是大公司，他们都不对eclipse提供支持。 &如果你实在希望在eclipse中使用 ，那需要折腾折腾。
Android 内存泄漏工具 ...
服务热线:400-678-8266&nbsp&#8250&nbsp&nbsp&#8250&nbsp
LeakCanary:检测所有的内存泄漏
原文： &ava.lang.OutOfMemoryError
&&&&&&&&at&android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
&&&&&&&&at&android.graphics.Bitmap.createBitmap(Bitmap.java:689)
&&&&&&&&at&com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)没人喜欢OutOfMemoryError在Square的注册过程中，我们在bitmap上 。这个bitmap和设备的屏幕大小相当，在创建它的时候，我遇到了相当数量的OOM导致的崩溃。我们试过了几种方法，没有一个解决了我们的问题：使用Bitmap.Config.ALPHA_8（签名是不需要颜色的）捕获OutOfMemoryError，触发垃圾回收然后重试几次（从 获得的启发）我们没有考虑过将bitmap分配在堆内存之外，那个时候 还没出现。我们看待问题的方式是不对的bitmap的大小本身不是什么问题。当内存快要满了的时候，OOM随时随地都可能发生。尤其是在创建大对象的时候更容易发生，比如bitmap。OOM一般代表着更深层次的问题：内存泄漏。什么是内存泄漏?有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。比如，在Activity.onDestroy()被调用之后，view树以及相关的bitmap都应该被垃圾回收。如果一个正在运行的后台线程继续持有这个Activity的引用，那么相关的内存将不会被回收，这最终将导致OutOfMemoryError崩溃。寻找内存泄漏寻找内存泄漏是一个人工操作的过程，在Raizlabs的
系列中描述得很清楚。下面是关键的步骤：通过 , , 或者 了解OOM主动重现问题。你可能需要买或者借或者偷一个遭遇了崩溃的特殊设备（并不是所有的设备上都会发生内存泄漏！）。你还需要找出是什么串在一起导致了内存泄漏。当OOM出现时进行堆转储(dump the heap)().使用MAT或YourKit内存检测工具检测内存的变化，并找出哪个对象应该被垃圾回收;从那个对象到GC roots推断最短的强引用路径;在路径中找出不存在的引用，并修复要是有一个库可以为你做完所有的事情，让你专注于修复内存泄漏的问题，那该有多好。LeakCanary介绍 是一个开源的在debug版本中检测内存泄漏的java库。让我们来看看一个cait的例子：class&Cat&{
class&Box&{
&&Cat&hiddenC
class&Docker&{
&&static&Box&
Box&box&=&new&Box();
Cat&schrodingerCat&=&new&Cat();
box.hiddenCat&=&schrodingerC
Docker.container&=&创建一个RefWatcher实例，然后给它一个对象让它观察：//&We&expect&schrodingerCat&to&be&gone&soon&(or&not),&let's&watch&it.
refWatcher.watch(schrodingerCat);当检测出泄漏的时候，你会自动得到一个漂亮的泄漏线索：*&GC&ROOT&static&Docker.container
*&references&Box.hiddenCat
*&leaks&Cat&instance我们知道你的时间宝贵，因此我们让它非常好设置。只需几行代码，LeakCanary就能自动检测Activity的泄漏：public&class&ExampleApplication&extends&Application&{
&&@Override&public&void&onCreate()&{
&&&&super.onCreate();
&&&&LeakCanary.install(this);
}当内存不足时，会有一个通知和良好的展示界面：结论在启用LeakCanary之后，我们发现和修复了许多内存泄漏的问题。我们甚至发现了一些。结果是非常令人惊奇的，我们现在减少了94%的oom崩溃问题。如果你想终结OOM崩溃，!
上一篇： 这是实现材料设计风格的INSTAGRAM系列文章的总结。如果你已经阅读了前面的文章，可以直接跳过此文。 几个月前我开始了一个实现 设计师Emmanuel Pacamalan发布的一个视频 中绝大多数视觉效果的项目。这个视频演示了谷歌新的设计语言 - 材料设计 。所有的东西
下一篇： 在这个系列中，我将向你解释什么是依赖注入，为什么使用依赖注入以及在Android中如何使用依赖注入框架dagger， dagger是square出品的专门为Android优化设计的依赖注入框架。这篇文章是是我上一篇关于如何在Android项目中使用MVP模式的姊妹篇，读者中一定有人