关于Android内存泄露问题

最近在做项目的时候遇到一个常见的问题就是Activity中Context导致的内存泄露、折腾死人了、最终找到一些方法可以具体定位到问题关键从而能让你能根据问题入手,好过自己在那里盲目找问题，找到了问题才能更好解决问题,废话不多说。。。。
注：本文是看了其它大神的博客然后拿过来加上自己的一些经验的

首先我们先借助LeakCanary这个库检测出项目内存溢出的某个位置它会定位到某个Activity里，相信也有很多人知道这个的(具体想了解的到这里看 里面有原作者翻译的中文说明 http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/)
1、在 build.gradle 中加入引用，不同的编译使用不同的引用：
dependencies {
debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3’
releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3’
}
2、在 Application 中：
publicclassExampleApplicationextendsApplication{@OverridepublicvoidonCreate(){super.onCreate();LeakCanary.install(this);}}

然而通过上面的并不能让我们知道这个Activity里面的什么对象导致的内存无法释放所以我们还需要借助 Android Studio性能专项测试之Heap Snapshot工具
(原文出自 http://blog.csdn.net/itfootball/article/details/48786275)

获取Java堆内存详细信息，可以分析出内存泄漏的问题

C区域
的某对象引用树对象，在这里面能看出其没谁引用了，比如在内存泄漏中，可以看出来它被谁引用，比如上图，引用树的第一行，可以看出来，该对象被Object[12]对象引用，索引值为1，那我们展开后，可以看到，该Object[12]是一个ArrayList.

通过LeakCanary找到Activity的泄露位置然后通过Studio本身的性能测试工具就可以通过观看堆里面的哪些对象没释放进而通过这对象想解决办法了

而Studio性能工具里面的 Java堆：Shallow Size和Retained Size的解释如下(出自http://blog.csdn.net/kingzone_2008/article/details/9083327 )：

Shallow size就是对象本身占用内存的大小，不包含其引用的对象。常规对象（非数组）的Shallow size有其成员变量的数量和类型决定。数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定。Shallow size of a set of objects represents the sum of shallow sizes of all objects in the set.在32位系统上，对象头占用8字节，int占用4字节，不管成员变量（对象或数组）是否引用了其他对象（实例）或者赋值为null它始终占用4字节。故此，对于String对象实例来说，它有三个int成员（3*4=12字节）、一个char[]成员（1*4=4字节）以及一个对象头（8字节），总共3*4 +1*4+8=24字节。根据这一原则，对String a=”rosen jiang”来说，实例a的shallow size也是24字节。（注意：上述String是jdk1.5的，代码如下：）

[java] view plaincopy在CODE上查看代码片派生到我的代码片
public final class String
implements java.io.Serializable, Comparable, CharSequence
{
/* The value is used for character storage. /
private final char value[];

/** The offset is the first index of the storage that is used. */  
private final int offset;  

/** The count is the number of characters in the String. */  
private final int count;  

/** Cache the hash code for the string */  
private int hash; // Default to 0  

jdk1.7的String实现已经变了。）
Retained size是该对象自己的shallow size，加上从该对象能直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。为了更好的理解retained size，不妨看个例子。

把内存中的对象看成下图中的节点，并且对象和对象之间互相引用。这里有一个特殊的节点GC Roots，这就是reference chain的起点。

从obj1入手，上图中蓝色节点代表仅仅只有通过obj1才能直接或间接访问的对象。因为可以通过GC Roots访问，所以左图的obj3不是蓝色节点；而在右图却是蓝色，因为它已经被包含在retained集合内。

所以对于左图，obj1的retained size是obj1、obj2、obj4的shallow size总和；右图的retained size是obj1、obj2、obj3、obj4的shallow size总和。
对于obj2，它的retained size是：在左图中，是obj2和obj4的shallow size的和；在右图中，是obj2、obj3和obj4的shallow size的和。

总之，retained size是一个整体度量，有助于理解内存结构和对象图中的依赖关系并找到根节点。

英文原文：Shallow and retained sizes

参考：

http://www.blogjava.net/rosen/archive/2010/05/21/321575.html

http://kenwublog.com/understand-shallow-and-retained-size-in-hprofling

因为Context导致的问题并且经常用到，所以Context的用法以及注意的也放在着了
注：从几位大神里拿来的、也希望能帮到大家
1、Context完全解析，Context的各种细节
注明出处：http://blog.csdn.net/guolin_blog/article/details/47028975

Context类型
我们知道，Android应用都是使用Java语言来编写的，那么大家可以思考一下，一个Android程序和一个Java程序，他们最大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，我们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

下面我们来看一下Context的继承结构：

Context的继承结构还是稍微有点复杂的，可以看到，直系子类有两个，一个是ContextWrapper，一个是ContextImpl。那么从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。

那么在这里我们至少看到了几个所比较熟悉的面孔，Activity、Service、还有Application。由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。

那么Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等等等都需要用到Context。由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

Context数量
那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型我们就已经可以得出答案了。Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写：

[plain] view plaincopy
Context数量 = Activity数量 + Service数量 + 1
上面的1代表着Application的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。

Application Context的设计
基本上每一个应用程序都会有一个自己的Application，并让它继承自系统的Application类，然后在自己的Application类中去封装一些通用的操作。其实这并不是Google所推荐的一种做法，因为这样我们只是把Application当成了一个通用工具类来使用的，而实际上使用一个简单的单例类也可以实现同样的功能。但是根据我的观察，有太多的项目都是这样使用Application的。当然这种做法也并没有什么副作用，只是说明还是有不少人对于Application理解的还有些欠缺。那么这里我们先来对Application的设计进行分析，讲一些大家所不知道的细节，然后再看一下平时使用Application的问题。

首先新建一个MyApplication并让它继承自Application，然后在AndroidManifest.xml文件中对MyApplication进行指定，如下所示：

[html] view plaincopy