一.介绍
Android机器中，内存使用问题一直是个十分重要，引人注目的问题，当我们代码编写不当，或者逻辑没处理好，就会导致机器运行缓慢，有时候甚至死机。
对于程序员来说，这很致命，所以要去理解内存的使用，去避免内存的泄露，不断优化内存，而当出现内存泄露导致的问题，我们能够分析log,并且会用工具MAT。
二.什么场景会导致内存泄露
内存泄露其实就是占用内存的对象使用后没有被回收。在这种现象下，当java程序运行一段时间，占用的内存越来越大，导致该进程的内存占用达到Android为进程分配的内存使用上限，程序就死了。
- ListView、GridView等在使用适配器时，没有使用ConvertView缓存
- Bitmap使用后没有释放
- Context泄露。Context的引用超过了本身的生命周期。比如一个长时间在跑的异步任务或者长时间的对象，拥有着Activity(Context类型)的引用，这时Activity被销毁了，但是内存依然存在，Context无法被回收。所以这种情况下， 可以使用getApplicationContext比较好,或者弱引用Context
- 数据库游标或者文件流缓存等使用后未关闭
- 线程使用不当。在线程中的run函数处理着耗时的工作，当设备横竖屏切换，重新创建Activity，由于run函数未处理完，导致引用的Activity也不会被销毁。再说AsyncTask,由于运行机制ThreadPoolExcutor，生命周期更加不可控，更容易出现问题了（具体解决方法，可看下面讲解）。
- Rxjava订阅与反订阅
- BraodcastReceiver等在生命周期结束后一定要记得unregidter
三.内存优化注意点
1.图片优化
在Android中显示Bitmap图片，会造成一定的内存消耗，甚至会导致OOM异常爆发，所以对于图片的显示，要做一定的处理。
- 大图片显示要进行压缩才能加载。一张图片，不要认为表面的小而不以为然，比如一张150kb的图片，当读到内存时，若该图片像素为20481024，使用属性为ARGB_8888(默认)，也就是一个像素4byte,那么总内存就是42048*1024byte,8M多。可见，大图片压缩加载的必要性。具体压缩详细方法可见 Android高效加载大图，防止OOM,以及多图解决方案
- 多图显示时要活用内存缓存技术。在一个ListView（或GridView）中，不断加载图片，不可能一直把图片都到内存中，因为内存是有上限值的，也要为其他操作分配内存。所以当在可见区域里，要将移除屏幕的部分内存进行回收处理。可若移除的部分在下个操作中又要马上使用，这时若被移除回收，性能效率马上就下去了，所以可以使用LRUCache缓存技术。具体可见以上那篇博文。
- ListView中的快速滑动加载图片，在不影响使用体验的情况下，应判断滑动状态进行加载操作。在快速滑动时，由于滑动过程中加载的资源是不会被使用的，反而影响了用户所要查看资源的加载，所以在快速滑动（SCROLL_STATE_TOUCH_SCROLL）列表时，就不再去获取加载资源了，在静止（SCROLL_STATE_IDLE）以及触摸屏幕(SCROLL_STATE_TOUCH_SCROLL)时才去加载,我们需要注册一个滚动监听器OnScrollListener 。
- 由于图片占用内存的缘故，所以一些内置资源的图片可以经过tinyPng处理，再放到app里加载。通常的压缩率可以达到50%以上，意思是150kb的图片处理后至少能减少到75kb以下，而且不失真。降低了内存的占用，同时达到APK瘦身的效果。TinyPng入口地址
2.线程、异步任务优化
因为线程、异步任务等生命周期的不可控性，成为了内存泄露的另一个源头。平常中，因为对它的频繁使用，所以，我们应慎重对待它。
- 在Activity结束时，应及时销毁所创建的线程。不然，当线程持有该所在Activity的引用时，实际上以为退出去的Activity，其实由于线程未完成，所引用的老Activity是不会被销毁的，就出现了内存泄露，所以可使用Thread.interrupt()中断线程，虽然并不是真正意义上的中断！具体详细可见 Thread的中断机制（interrupt），这个机制到底做了些什么呢？原来Thread.interrupt()方法不会中断一个正在运行的线程。这一方法实际上完成的是，设置线程的中断标示位，在线程受到阻塞的地方（如调用sleep、wait、join等地方）抛出一个异常InterruptedException，并且中断状态也将被清除，这样线程就得以退出阻塞的状态。
-
AsyncTask异步任务的生命周期不可控性。一定得注意一件事，因为以前很喜欢在Activity中创建AsyncTask作为内部类，完成一些耗时且Ui交互的操作，十分方便，但是其实这个是具有很大风险的，因为很容易出现内存泄露。异步任务内部是以ThreadPoolExcutor作为实现机制的，这样出来的线程对象生命周期是不确定的！！
解决方案：在线程内部采用弱引用保存Context引用。即如下代码所示：
public abstract class WeakAsyncTask < Params,Progress,Result,WeakTarget >
extends AsyncTask < Params,Progress,Result > {
protected WeakReference < WeakTarget > mTarget;
public WeakAsyncTask(WeakTarget target) {
mTarget = new WeakReference < WeakTarget > (target);
}
/** {@inheritDoc} */
@Override protected final void onPreExecute() {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPreExecute(target);
}
}
/** {@inheritDoc} */
@Override protected final Result doInBackground(Params...params) {
final WeakTarget target = mTarget.get();
if (target != null) {
return this.doInBackground(target, params);
} else {
return null;
}
}
/** {@inheritDoc} */
@Override protected final void onPostExecute(Result result) {
final WeakTarget target = mTarget.get();
if (target != null) {
this.onPostExecute(target, result);
}
}
protected void onPreExecute(WeakTarget target) {
// No default action
}
protected abstract Result doInBackground(WeakTarget target, Params...params);
protected void onPostExecute(WeakTarget target, Result result) {
// No default action
}
}
所以内存优化方面，还有很多方面需要补足，还需努力。
四.内存分析
不管是对内存使用情况的分析，还是排查内存泄露与溢出，我都推荐去好好看看以下大神的文章，相信看过后，会有很大的收获，我就是如此=。=
android 中如何分析内存泄露
Android最佳性能实践(二)——分析内存的使用情况
小小的总结与推荐阅读，希望可以帮助到大家～
Ps:以前博客迁移到简书，如果你觉得文章还可以，麻烦底下点个“喜欢”！
