预防OOM的几点建议 Android开发过程中，在 Activity的生命周期里协调耗时任务可能会很困难，你一不小心就会导致内存泄漏问题。下面是一些小提示，能帮助你预防内存泄漏问题的发生：

http://www.csdn.net/article/2015-09-18/2825737/2

1 Context 与getApplication区别

在写单例时  传入的Context对象要注意，如果传入的是Activity.this，很容易造成内存泄露  一个是当前Activity的实例，一个是项目的Application的实例。

http://www.android-doc.com/html/docs/2017/0410/329.html

2 Activity的泄漏

1 内部类引用导致Activity的泄漏 ，典型的场景是Handler导致的Activity泄漏，如果Handler中有延迟的任务或者是等待执行的任务队列过长，都有可能因为Handler继续执行而导致Activity发生泄漏

2 Activity Context被传递到其他实例中，这可能导致自身被引用而发生泄漏。（比如顶部提到的Context 与getApplication区别引用到的单例）

3 虑尽量使用static类型的内部类，同时使用WeakReference的机制来避免因为互相引用而出现的泄露。

4 考虑使用Application Context而不是Activity Context

 3、合理使用static： 

每一个非静态内部类实例都会持有一个外部类的引用，若该引用是Activity 的引用，那么该Activity在被销毁时将无法被回收。

如果你的静态内部类需要一个相关Activity的引用以确保功能能够正常运行，那么你得确保你在对象中使用的是一个Activity的弱引用，否则你的Activity将会发生意外的内存泄漏。

但是要注意，当此类在全局多处用到时在这样干，因为static声明变量的生命周期其实是和APP的生命周期一样的，有点类似与Application。如果大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。

static的合理使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。

4、谨慎handler在处理异步操作的时候

解决方案，

一是在Activity的onDestroy方法中调handler.removeCallbacksAndMessages(null);取消所有的消息的处理，包括待处理的消息；

二是声明handler的内部类为static。

三 单独封装成类，引入lrucache算法 将Activity软引用起来

4 减小Bitmap对象的内存占用

Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常来说有以下3个措施：

1 inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。

2 decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。

3 采用软引用 lrucache算法

5 间断性内存抖动

     避免在onDraw方法里面执行对象的创建

     StringBuilder

     在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使        用     StringBuilder来替代频繁的“+”。

6 注意监听器的注销 ，Cursor对象是否及时关闭

存在很多需要register与unregister的监听器，

7 WebView的泄漏

Android中的WebView存在很大的兼容性问题，不仅仅是Android系统版本的不同对WebView产生很大的差异，另外不同的厂商出货的ROM里面WebView也存在着很大的差异。更严重的是标准的WebView存在内存泄露的问题

为WebView开启另外一个进程，通过AIDL与主进程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。

8 资源文件需要选择合适的文件夹进行存放

hdpi/xhdpi/xxhdpi等等不同dpi的文件夹下的图片在不同的设备上会经过scale的处理。

例如我们只在hdpi的目录下放置了一张100100的图片，那么根据换算关系，xxhdpi的手机去引用那张图片就会被拉伸到200200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到assets或者nodpi的目录下。

9 、SoftReference/WeakReference/LruCache

如果对内存的开销比较关注的APP，可以考虑使用WeakReference，当GC回收扫过这块内存区域时就会回收；

如果不是那么关注的话，可以使用SoftReference，它会在内存申请不足的情况下自动释放，同样也能解决OOM问题。

同时Android自3.0以后也推出了LruCache类，使用LRU算法就释放内存，一样的能解决OOM，如果兼容3.0一下的版本，请导入v4包。

11 借第三方工具 traceviewleakcanary或 自带ddms  Memory Monitor查看内存中Dalvik Heap的实时变化

内存泄露场景及解决方法；

1 类的静态变量持有大数据对象静态变量长期维持到大数据对象的引用，阻止垃圾回收。

2 非静态内部类存在静态实例非静态内部类会维持一个到外部类实例的引用

3 资源对象未关闭（Cursor，File文件等）

4 andler内存泄漏Handler作为内部类存在于Activity中（常写在activity里，会隐式引用activity对象）比如当Handler对象有Message在排队，则无法释放，进而导致本该释放的Acitivity也没有办法进行回收

5 BitMap隐患

OOM的避免及解决方法

http://www.csdn.net/article/2015-09-18/2825737/4