Android常用内存泄漏学习

java gc概念：
在大部分虚拟机（包括Android的ART）中，Java都采用了“可达性分析”算法来进行内存回收，原理是：会有几个引用作为root节点，对于任意对象来说，如果从root层层遍历，如果找不到对于他的引用链，那么这个对象就被标记为无用，就会在gc时被销毁。
何为泄漏
内存泄漏，即部分对象虽然已经不再使用，但是因为有root持有引用，所以并没有被销毁，所占用的内存一直没有被释放。一次两次发生影响不大。如果频繁发生，那么可用内存会渐渐不足，最终在某一次请求内存时发现内存不足而发生oom。这里要明确一个概念，只有强引用会发生内存泄漏，而weak等引用因为其特殊机制，所以影响不大。
什么会泄露

泄露影响比较大的就是一些大对象，常见的比如某些资源，bitmap，以及activity。
static

static这个关键字使一个变量变为只和这个类相关的类变量，和实例无关。他的生命周期是很长的，贯穿于app的启动到关闭。因此只要用一个static引用一个大对象，就可以泄漏了！举个例子：

static Activity activity;

这是最简单粗暴的持有一个activity的引用，这样这个activity退出之后对象并没有被销毁。

static View view;

一个View初始化时会用到context，我们在自定义View，重写构造方法时就知道这个了。因此如果一个View也像这样被持有，那个context也不会被释放。
innerClass

内部类有个特性，是他会持有一个外部类的引用。如果内部类的实例一直存活，那么外部类activity的实例也就一直在。比如持有一个static的内部类引用：

static LeakInnerClass context;class LeakInnerClass {    Context context;}

或者以前我们用asynctask时喜欢搞一个匿名内部类执行异步任务，那当我们activity退出后这个异步任务还在执行的话，就会泄露了。
还有自己开个匿名线程：

还有在使用handler时，如果用了匿名handler，那么这个handler会带着activity的引用藏到消息队列中。消息没有被处理，就会造成内存泄漏。类似的，还有timertask等。

register
我们平时会用到很多第三方库，比如ButterKnife EventBus RxJava等等，有的时候要获取系统服务，getSystemService。在使用的时候，都有一个先registerd或者bind的操作，而且在创建的时候会把activity的引用传过去。如果在activity结束时没有unregister或者unbind，就会造成内存泄漏。
如何检测泄漏

最简单的方法自然就是使用leakcanary了。只要给自己的项目加上这个工具，在发生泄漏的时候很快就会有提示。具体使用方法看这地方。

重点是如何解决内存泄漏问题！
很简单，泄漏是因为持有了activity引用导致无法被销毁，那么只有两个选择：及时取消引用，或者让这个引用多待一会，但是该gc的时候就销毁。
根据这个思路：

• 我们在代码中能不用static变量持有contxt就不用，非要用就用weak引用。
• 对于内部类，尽量用静态内部类，这样就不会持有外部类引用。如果需要外部类引用做一些事，就手动赋给一个weak引用。
• 对于匿名内部类，不要图简单方便，实在不行就乖乖的写成外部类。
• 异步操作，尽量用可以方便管理的，比如rxJava，而不是用老古董AsyncTask了。非要用也最好加一个终止条件，在退出Activity时就该结束了。
• 在用rx时，可以在subscribe()的时候获取到Subscripeion，在不用的时候手动unSubscribe()，或者直接bind()到Activity的生命周期上，比如使用RxActivity管理。
• 在使用handler时，记得在activity的onDestroy()中加上remove()
• 在获取到某些资源时，使用完记得释放
• 在用到一些大对象比如Bitmap啊什么的，要记得回收
• 最后，在使用各种第三方库或者系统服务的时候还要记得有注册或绑定就要有解除注册、解绑定。