OOM主要有两种原因导致：
1. 加载大图片；
2. 内存泄漏；
一、加载大图片
在Android应用中加载Bitmap的操作是需要特别小心处理的，因为Bitmap会消耗很多内存。比如，Galaxy Nexus的照相机能够拍摄2592x1936 pixels (5 MB)的图片。 如果bitmap的图像配置是使用ARGB_8888 (从Android 2.3开始的默认配置) ，那么加载这张照片到内存大约需要19MB(2592*1936*4 bytes) 的空间，从而迅速消耗掉该应用的剩余内存空间。
对于分辨率比我们手机屏幕的分辨率高得多的图片，我们应该加载一个缩小版本的图片，从而避免超出程序的内存限制。下面我们就来看一看，如何对一张大图片进行适当的压缩，让它能够以最佳大小显示的同时，还能防止OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。如下代码所示：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;为了避免java.lang.OutOfMemory 的异常，我们需要在真正解析图片之前检查它的尺寸（除非你能确定这个数据源提供了准确无误的图片且不会导致占用过多的内存）。
通过上面的步骤我们已经获取到了图片的尺寸，这些数据可以用来帮助我们决定应该加载整个图片到内存中还是加载一个缩小的版本。有下面一些因素需要考虑：
- 预估一下加载整张图片所需占用的内存。
- 为了加载这一张图片你所愿意提供多少内存。
- 用于展示这张图片的控件的实际大小。
- 当前设备的屏幕尺寸和分辨率。
例如，如果把一个大小为1024x768像素的图片显示到大小为128x96像素的ImageView上，就没有必要把整张原图都加载到内存中。
那我们怎样才能对图片进行压缩呢？通过设置BitmapFactory.Options中inSampleSize的值就可以实现。比如我们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存，压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型，即每个像素点占用4个字节)。下面的方法可以根据传入的宽和高，计算出合适的inSampleSize值：
public static int calculateInSampleSize(
BitmapFactory.Options options, int reqWidth, int reqHeight) {
// Raw height and width of image
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
final int halfHeight = height / 2;
final int halfWidth = width / 2;
// Calculate the largest inSampleSize value that is a power of 2 and keeps both
// height and width larger than the requested height and width.
while ((halfHeight / inSampleSize) > reqHeight
&& (halfWidth / inSampleSize) > reqWidth) {
inSampleSize *= 2;
}
}
return inSampleSize;
}注意: inSampleSize的取值应该总是为2的指数，比如1、2、4、8、16，等等。如果外界传递给系统的inSampleSize不为2的指数，那么系统会向下取整并选择一个最接近2的指数来代替，比如3，系统会选择2来代替，但是这个结论并非在所有的Android版本上都能成立。
使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析一次图片。然后将BitmapFactory.Options连同期望的宽度和高度一起传递到到calculateInSampleSize方法中，就可以得到合适的inSampleSize值了。之后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就可以得到压缩后的图片了。
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
// First decode with inJustDecodeBounds=true to check dimensions
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// Calculate inSampleSize
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
下面的代码非常简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展示。
mImageView.setImageBitmap(decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));当然我们也可以通过替换合适的BitmapFactory.decode* 方法来实现一个类似的方法，从其他的数据源解析Bitmap。
二、内存泄漏（Memory leak）
1. Service导致内存泄漏：Service执行完没有停止操作或者停止失败就会导致内存泄漏，针对这种情况官方推荐使用IntentService，IntentService的最大特点就是后台任务执行结束后会自动停止。
2. 使用依赖注入框架导致内存泄漏：依赖注入框架虽然简化了复杂的编码操作，但为了要搜寻代码中的注解，通常都需要经历较长的初始化过程，并且还可能将一些你用不到的对象也一并加载到内存当中。这些用不到的对象会一直占用着内存空间，可能要过很久之后才会得到释放。
3. 静态对象导致内存泄漏：静态变量的生命周期和类是息息相关的，它们分配在方法区上，垃圾回收一般不会回收这一块的内存。所以我们在代码中用到静态对象，在不用的时候如果不赋null值消除对象的引用的话，那么这些对象是很难被垃圾回收的。如果这些对象一多或者比较大的话，程序出现OOM的概率就比较大了。因为静态变量而出现内存泄漏是很常见的。
4. Context导致内存泄漏： android 中很多地方都要用到context,连基本的Activty 和 Service都是从Context派生出来的，我们利用Context主要用来加载资源或者初始化组件，在Activity中有些地方需要用到Context的时候，我们经常会把context给传递过去了，将context传递出去就有可能延长了context的生命周期，最终导致了内存泄漏。例如 我们将activty context对象传递给一个后台线程去执行某些操作，如果在这个过程中因为屏幕旋转而导致activity重建，那么原先的activity对象不会被回收，因为它还被后台线程引用着，如果这个activity消耗了比较多的内存，那么新建activity或者后续操作可能因为旧的activity没有被回收而导致内存泄漏。所以，遇到需要用到context的时候，我们要合理选择不同的context，对于android应用来说还有一个单例的Application Context对象，该对象生命周期和应用的生命周期是绑定的。选择context应该考虑到它的生命周期，如果使用该context的组件的生命周期超过该context对象，那么我们就要考虑是否可以用application context。如果真的需要用到该context对象，可以考虑用弱引用来WeakReference来避免内存泄漏。
5. 非静态内部类导致的内存泄漏：非静态的内部类会持有外部类的一个引用，所以和前面context说到的一样，如果该内部类生命周期超过外部类的生命周期，就可能引起内存泄露了，如AsyncTask和Handler。因为在Activity中我们可能会用到匿名内部类，所以要小心管理其生命周期。 如果明确生命周期较外部类长的话，那么应该使用静态内部类。
6.Drawable对象的回调隐含的内存泄漏：当我们为某一个view设置背景的时候，view会在drawable对象上注册一个回调，所以drawable对象就拥有了该view的引用了，进而对整个context都有了间接的引用了，如果该drawable对象没有管理好，例如设置为静态，那么就会导致内存泄漏。
7.监听器注册没注销造成内存泄漏：在Android程序里面存在很多需要register与unregister的监听器，我们需要确保在合适的时候及时unregister那些监听器。自己手动add的listener，需要记得及时remove这个listener。
8.资源对象没关闭造成内存泄漏：资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。因为有些资源性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。 因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。
9.单例对象中不合理的持有造成内存泄漏：虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。
10. 集合容器中的对象泄漏：当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。
Set<Person> set = new HashSet<Person>();
Person p1 = new Person("唐僧","pwd1",25);
set.add(p1);
p1.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变
set.remove(p1); //此时remove不掉，造成内存泄漏 11. Webview导致内存泄漏：Android中的WebView存在很大的兼容性问题，不仅仅是Android系统版本的不同对WebView产生很大的差异，另外不同的厂商出货的ROM里面WebView也存在着很大的差异。更严重的是标准的WebView存在内存泄露的问题，看这里WebView causes memory leak - leaks the parent Activity。所以通常根治这个问题的办法是为WebView开启另外一个进程，通过AIDL与主进程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
12. 属性动画导致内存泄露：从Android3.0开始，Google提供了属性动画，属性动画中有一类无限循环的动画，如果在Activity中播放此类动画且没有在onDestroy中去停止动画，那么动画就会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候Activity的View会被动画持有，而View又持有了Activity，最终Activity无法释放。解决方法是在Activity的onDestroy中调用animator.cancle()来停止动画。