java.lang.OutOfMemoryError异常解决方法

摘要：另外再写了一个的抽象方法，该方法在里面调用。去除中相关设置，改在程序中设置背景图放在方法中尽量不使用静态的图片和全局性的图片在时注意，防止得不到及时的释放。等等，还需要进一步地研究

java.lang.OutOfMemoryError简称OOM内存溢出，这是一种很常见的导致的程序崩溃的问题，但也是很容易被开发者忽视的一个问题，因为它不像java.lang.NullPointerException这样的错误，程序一运行就能被发现，它不是每次运行或每台手机都出现，有时可能要等到项目上线，后台产生了大量数据之后才能被发现。
最近做了一个新闻类的项目，和商城类的项目相比，由于涉及更多的图片和视频，很明显数据量要大得多，所以更容易产生OOM的问题。如何解决这个异常呢，首先我们来看看它是怎么产生的。

常见原因有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小；

对应的Log显示的错误提示如下：
1.tomcat:java.lang.OutOfMemoryError: PermGen space
2.tomcat:java.lang.OutOfMemoryError: Java heap space
3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError
4.resin:java.lang.OutOfMemoryError
5.java:java.lang.OutOfMemoryError

1.避免循环产生过多重复的对象实体

个人觉得对于这个问题开发程序时应该是可以避免的，即使写程序时没有考虑到，发现是这个原因造成的，应该也是很容易解决的；
例如,对复杂的listview进行合理设计与编码,注意重用Adapter里面的convertView，以及holder机制的运用

2.自定义内存大小和优化Dalvik虚拟机的堆内存

在Android2.2之前，有这样一个类dalvik.system.VMRuntime，它提供的setTargetHeapUtilization()方法可以增强程序堆内存的处理效率，代码如下：

//在程序onCreate时就可以调用即可

private final static floatTARGET_HEAP_UTILIZATION = 0.75f;  
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 

还有setMinimumHeapSize()方法可以自定义应用需要多大的内存，强行设置最小内存大小,
//设置最小heap内存为6MB大小

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ; 
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); 

但是上面说了这种方法只适用于Android2.2以下，否则编译是通不过的，既然取消了这个方法，肯定有能够代替这个方法，且比这个方法更完美的解决方案，这就是下面我要重点说的几种方法；

3.Fragment的懒加载

现在大多数程序一个Activity里面可能会以viewpager（或其他容器）与多个Fragment来组合使用，而如果每个fragment都需要去加载数据，或从本地加载，或从网络加载，那么在这个activity刚创建的时候就变成需要初始化大量资源。那么，能不能做到当切换到这个fragment的时候，它才去初始化呢？

答案就在Fragment里的setUserVisibleHint这个方法里,该方法用于告诉系统，这个Fragment的UI是否是可见的。所以我们只需要继承Fragment并重写该方法，即可实现在fragment可见时才进行数据加载操作，即Fragment的懒加载。

代码如下：

    public abstract class LazyFragment extends Fragment {  
        protected boolean isVisible;
    @Override  
    public void setUserVisibleHint(boolean isVisibleToUser) {  
        super.setUserVisibleHint(isVisibleToUser);  
        if(getUserVisibleHint()) {  
            isVisible = true;  
            onVisible();  
        } else {  
            isVisible = false;  
            onInvisible();  
        }  
    }  
  
    protected void onVisible(){  
        lazyLoad();  
    }  
  
    protected abstract void lazyLoad();  
  
    protected void onInvisible(){}  
}

在LazyFragment，我增加了三个方法，一个是onVisiable，即fragment被设置为可见时调用，一个是onInvisible，即fragment被设置为不可见时调用。另外再写了一个lazyLoad的抽象方法，该方法在onVisible里面调用。

你可能会想，为什么不在getUserVisibleHint里面就直接调用呢？我这么写是为了代码的复用。因为在fragment中，我们还需要创建视图（onCreateView()方法），可能还需要在它不可见时就进行其他小量的初始化操作（比如初始化需要通过AIDL调用的远程服务）等。

而setUserVisibleHint是在onCreateView之前调用的，那么在视图未初始化的时候，在lazyLoad当中就使用的话，就会有空指针的异常。而把lazyLoad抽离成一个方法，那么它的子类就可以这样做：

public class OpenResultFragment extends LazyFragment{  
    // 标志位，标志已经初始化完成。  
    private boolean isPrepared;  
  
    @Override  
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {  
        Log.d(LOG_TAG, "onCreateView");  
        View view = inflater.inflate(R.layout.fragment_open_result, container, false);  
        //XXX初始化view的各控件  
    isPrepared = true;  
        lazyLoad();  
        return view;  
    }  
  
    @Override  
    protected void lazyLoad() {  
        if(!isPrepared || !isVisible) {  
            return;  
        }  
        //填充各控件的数据  
    }  
  
}  

在上面的类当中，我们增加了一个标志位isPrepared，用于标志是否初始化完成。然后在我们所需要的初始化操作完成之后调用，如上面的例子当中，在初始化view之后，设置 isPrepared为true，同时调用lazyLoad()方法。而在lazyLoad()当中，判断isPrepared和isVisible只要有一个不为true就不往下执行。也就是仅当初始化完成，并且可见的时候才继续加载，这样的避免了未初始化完成就使用而带来的问题。

4.利用BitmapFactory.Options限制图片的大小

有时加载数据量并不是很大时也会产生OOM异常，一般是由于加载图片造成的，Bitmap加载图片最终都是通过java层的createBitmap来完成的，需要消耗大量内存,我们可以利用BitmapFactory.Options限制图片的大小，降低图片质量，减少图片所占内存

InputStream is = this.getResources().openRawResource(R.drawable.pic1); 
BitmapFactory.Options options=new BitmapFactory.Options(); 
options.inJustDecodeBounds = false; 
options.inSampleSize = 10;   //width，hight设为原来的十分一 
Bitmap btp =BitmapFactory.decodeStream(is,null,options); 
 

5.及时对图片进行recyle()操作

if(!bmp.isRecycle() ){ 
         bmp.recycle()   //回收图片所占的内存 
         system.gc()  //提醒系统及时回收 
} 

以上是OOM的常见的几种产生原因和解决方案，还有很多方法，例如，
还有看看页面布局当中有没有大的图片，比如背景图之类的。去除xml中相关设置，改在程序中设置背景图（放在onCreate()方法中）；
尽量不使用静态的图片和全局性的图片；
在Activity destory时注意，bg.setCallback(null); 防止Activity得不到及时的释放。
等等，还需要进一步地研究