内存溢出和泄漏

内存泄漏，指申请的内存不会被回收了;          内存溢出，指系统内存不够用了
一.Android加载大图片内存溢出的问题总结

尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，

因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。因此，先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，
decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。

如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常。另外，decodeStream直接拿的图片来读取字节码了， 不会根据机器的各种分辨率来自动适应，使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源，否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。

另外，以下方式也大有帮助：

1. InputStream is = this.getResources().openRawResource(R.drawable.pic);

BitmapFactory.Options options=new BitmapFactory.Options();

options.inJustDecodeBounds = false;

options.inSampleSize = 10; //width，hight设为原来的十分一

Bitmap btp =BitmapFactory.decodeStream(is,null,options);

2. if(!bmp.isRecycle() ){

bmp.recycle() //回收图片所占的内存

system.gc() //提醒系统及时回收

}

//以最省内存的方式读取本地资源的图片

public static Bitmap readBitMap(Context context, int resId) {

      BitmapFactory.Options opt = new BitmapFactory.Options();

      opt.inPreferredConfig = Bitmap.Config.RGB_565;
      opt.inPurgeable = true;//设为true表示当系统要内存的时候，可以回收它

//如果图片当有需要可以被回收的话，这个opt.inInputShareable=true;可以让bitmap共享他人的数据

//获取资源图片

InputStream is = context.getResources().openRawResource(resId);

        return BitmapFactory.decodeStream(is,null,opt);

 }

Android内存溢出的解决办法

昨天在模拟器上给gallery放入图片的时候，出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常，图像大小超过了RAM内存。

模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。

由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：

//解决加载图片 内存溢出的问题

//Options 只保存图片尺寸大小，不保存图片到内存

BitmapFactory.Options opts = new BitmapFactory.Options();

//缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰

opts.inSampleSize = 4;

Bitmap bmp = null;

bmp = BitmapFactory.decodeResource(getResources(), mImageIdsposition ,opts);

...

//回收

bmp.recycle();

通过上面的方式解决了，但是这并不是最完美的解决方式。（等比例缩放）
优化Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体 原理我们可以参考开源工程，这里我们仅说下使用方法: 

private final static float TARGET_HEAP_UTILIZATION = 0.75f; 

在程序onCreate时就可以调用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆内存也可自己定义大小

对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说 RAM对 性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理

bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法

android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget

主要是加上这段：

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;

 eg1：(通过Uri取图片)

private ImageView preview;

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一

Bitmap bitmap = BitmapFactory.decodeStream(cr

.openInputStream(uri), null, options);

preview.setImageBitmap(bitmap);

以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。

eg2:（通过路径去图片）

private ImageView preview;

private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一

Bitmap b = BitmapFactory.decodeFile(fileName, options);

preview.setImageBitmap(b);

filePath.setText(fileName);

还可以用到优化Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);

Android堆内存也可自己定义大小

对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

Java代码：

1. private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

3. VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
4. //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理

二.由于我们程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。

保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。

万恶的static

 static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。

public class ClassName {  

     private static Context mContext;  

     //省略  

}  

以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。

private static Drawable sBackground;  

 @Override  

 protected void onCreate(Bundle state) {  

   super.onCreate(state);  

     

   TextView label = new TextView(this);  

   label.setText("Leaks are bad");  

     

   if (sBackground == null) {  

     sBackground = getDrawable(R.drawable.large_bitmap);  

   }  

   label.setBackgroundDrawable(sBackground);  

     

   setContentView(label);  

 }  

    sBackground, 是 一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable与View连接之后，Drawable就将View设 置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：

    Drawable->TextView->Context

    所以，最终该Context也没有得到释放，发生了内存泄露。

    如何才能有效的避免这种引用的发生呢？

    第一，应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。

    第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。

    第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;

    该部分的详细内容也可以参考Android文档中Article部分。

四、都是线程惹的祸

    线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。

public class MyActivity extends Activity {  

    @Override  

    public void onCreate(Bundle savedInstanceState) {  

        super.onCreate(savedInstanceState);  

        setContentView(R.layout.main);  

        new MyThread().start();  

    }  

  

    private class MyThread extends Thread{  

        @Override  

        public void run() {  

            super.run();  

            //do somthing  

        }  

    }  

}  

    这段代码很平常也很 简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一 般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。

    由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。

    有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内 存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应 用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。

    这种线程导致的内存泄露问题应该如何解决呢？

    第一、将线程的内部类，改为静态内部类。

    第二、在线程内部采用弱引用保存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;  

        }  

    }  

    @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  

    }  

}