我们在不知觉中写出致使内存泄漏的代码，但是却不知道怎么解决，石家庄Android培训班列举了一些内存泄露的例子，大家可以参考下，以后在写Android编程代码的时候尽量避免。

静态变量造成内存泄漏

首先，比较简单的一种情况是，静态变量致使内存泄漏，说到静态变量，我们至少得了解其生命周期才能彻底明白。静态变量的生命周期，起始于类的加载，终止于类的释放。对于 Android 而言，程序也是从一个 main 方法进入，开始了主线程的工作，如果一个类在主线程或旁枝中被使用到，它就会被加载，反过来说，假如一个类存在于我们的项目中，但它从未被我们使用过，算是个孤岛，这时它是没有被加载的。一旦被加载，只有等到我们的 Android 应用进程结束它才会被卸载。

于是，当我们在 Activity 中声明一个静态变量引用了Activity 自身，就会造成内存泄漏。

这样的代码会导致当这个Activity 结束的时候，sContext 仍然持有它的引用，致使Activity 无法回收。解决办法就是在这个Activity 的onDestroy 时将sContext 的值置空，或者避免使用静态变量这样的写法。

同样的，如果一个 Activity 的静态field 变量内部获得了当前 Activity 的引用，比如我们经常会把 this 传给 View 之类的对象，这个对象若是静态的，并且没有在 Activity 生命周期结束之前置空的话，也会导致同样的问题。

非静态内部类和匿名内部类造成内存泄漏

也是一个很常见的情景，经常会遇到的Handler问题就是这样一种情况，如果我们在field 声明一个Handler 变量。

由于在 Java 中，非静态内部类(包括匿名内部类，比如这个 Handler 匿名内部类)会引用外部类对象(比如 Activity)，而静态的内部类则不会引用外部类对象。所以这里 Handler 会引用 Activity 对象，当它使用了 postDelayed 的时候，如果 Activity 已经 finish 了，而这个 handler 仍然引用着这个 Activity 就会致使内存泄漏，因为这个 handler 会在一段时间内继续被 main Looper 持有，导致引用仍然存在，在这段时间内，如果内存吃紧至超出，就很危险了。

解决办法就是大家都知道的使用静态内部类加WeakReference。

另外，综合上面两种情况，如果一个变量，既是静态变量，而且是非静态的内部类对象，那么也会造成内存泄漏。

注意，这里我们定义的 Hello 虽然是空的，但它是一个非静态的内部类，所以它必然会持有外部类即 LeakActivity.this 引用，导致 sHello 这个静态变量一直持有这个 Activity，于是结果就和第一个例子一样，Activity 无法被回收。

到这里大家应该可以看出，内存泄漏经常和静态变量有关。和静态变量有关的，还有一种常见情景，就是使用单例模式没有解绑致使内存泄漏，单例模式的对象经常是和我们的应用相同的生命周期，如果我们使用 EventBus 或 Otto 并生成单例，注册了一个 Activity 而没有在页面结束的时候进行解除注册，那么单例会一直持有我们的 Activity，这个 Activity 虽然没有使用了，但会一直占用着内存。

属性动画造成内存泄漏

另外当我们使用属性动画，我们需要调用一些方法将动画停止，特别是无限循环的动画，否则也会造成内存泄漏，好在使用 View 动画并不会出现内存泄漏，估计 View 内部有进行释放和停止。

RxJava 使用不当造成内存泄漏

最后说一说 RxJava 使用不当造成的内存泄漏，RxJava 是一个非常易用且优雅的异步操作库。对于异步的操作，如果没有及时取消订阅，就会造成内存泄漏。

同样是匿名内部类造成的引用没法被释放，使得如果在 Activity 中使用就会导致它无法被回收，即使我们的 Action1 看起来什么也没有做。解决办法就是接收 subscribe 返回的 Subscription 对象，在 Activity onDestroy 的时候将其取消订阅即可。

除了以上这种解决方式之外，还有一种解决方式就是通过 RxJava 的 compose 操作符和 Activity 的生命周期挂钩，我们可以使用一个很方便的第三方库叫做 RxLifecycle 来快捷做到这点，使用起来就像这样。

另外，它还提供了和 View 的便捷绑定，详情可以点击我提供的链接进行了解，这里不多说了。

总结来说，仍然是前面说的内部类或匿名内部类引用了外部类造成了内存泄漏，所以在实际编程过程中，如果涉及此类问题或者线程操作的，应该特别小心，很可能不知不觉中就写出了带内存泄漏的代码了。

前面说了不少内存泄漏的场景和对应的解决办法，但如果我们不知不觉中写出了带有内存泄漏隐患的代码怎么办，面对这个问题，其实到现在，我们是很幸运的，因为有很多相关的检查方式或组件可以选择，比如最简单的：观察 Memory Monitor 内存走势图，可以或多或少知道内存情况，但如果要精确地追踪到内存泄漏点，这里特别推荐伟大的 Square 公司开源的 LeakCanary 方案，LeakCanary 可以做到非常简单方便、低侵入性地捕获内存泄漏代码，甚至很多时候你可以捕捉到 Android 官方组件的内存泄漏代码。

今天讲的东西有点深奥，但是参加石家庄Android培训班的同学们这些也是必须知道的知识哦。