【转】android 开发如何做内存优化

转两个不错的总结

http://www.cnblogs.com/kingOfPointer/archive/2012/12/21/2828018.html

http://blog.chinaunix.net/uid-26930580-id-3844811.html

http://blog.csdn.net/xieqibao/article/details/6707519

 

 

内存泄漏的原因：

不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。其实如果我们一个程序 中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的 java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所 有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄露就比较糟糕了，它的内存 泄露是系统级，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。
　 　Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序 都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。 Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视 为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会 引起系统重启）。

 

分两种：

1、内存泄漏：

当出现对Activity、View或drawable等类的对象长期持有无用的引用，就会造成被引用的对象无法在GC时回收，而是长期占用堆空间，此时就会发生内存泄漏。
简单来说，就是保留下来却永远不再使用的对象引用。

2、内存溢出：

如果应用程序在消耗光了所有的可用堆空间(16M到48M），那么再试图在堆上分配新对象时就会引起OOM(Out Of Memory Error)异常，此时应用程序就会崩溃退出。

两者的区别：

简单的说，就是内存溢出是占用内存太大，超过了其可以承受的范围；
内存泄漏是回收不及时甚至是没有被回收，而在推空间中产生的许多无用的引用。
于是过多的内存泄漏就会导致内存溢出，从而迫使程序崩溃退出。

 

一、引用没释放造成的内存泄露

1.1注册没取消造成的内存泄露

这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些 Android程序可能引用我们的Anroid程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的 Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收。

例如:我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些 信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到 TelephonyManager服务中。

对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面 消失的时候LockScreen对象就会被释放掉。如果在释放LockScreen对象的时候忘记取消我们之前注册的 PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的 LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

1.2集合中对象没清理造成的内存泄露

 我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。

二、资源对象没关闭造成的内存泄露

资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时 候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为 null,而不关闭它们，往往会造成内存泄露。

因为有些资源性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

 

三、一些不良代码成内存压力

有些代码并不造成内存泄露，但是它们，或是对没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存，对内存的回收和分配造成很大影响的，容易迫使虚拟机不得不给该应用进程分配更多的内存，造成不必要的内存开支。

 

3.1  Bitmap没调用recycle()
Bitmap对象在不使用时,我们应该先调用recycle()释放内存，然后才它设置为null.虽然recycle()从源码上看，调用它应该能立 即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。但是我它应该还是能大大的加速Bitmap的主要内存的释放。

3.2  构造Adapter时，没有使用缓存的 convertView

以构造ListView的BaseAdapter为例，在BaseAdapter中提共了方法：
public View getView(int position, View convertView, ViewGroup parent)来向ListView提供每一个item所需要的view对象。

初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。

 

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

public class ClassName {  

      private static Context mContext;  

      // 。。。
}

 

 以上的代码是很危险的，如果将Activity赋值到么mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。
我们举Android官方文档中的一个例子：【TODO 找到网址】

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也没有得到释放，发生了内存泄露。

 

如果你打算保存一个长时间的对象， 并且其需要一个 Context，记得使用Application对象。你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。
    最近遇到一种情况引起了Context泄漏，就是在Activity销毁时，里面有其他线程没有停。
    总结一下避免Context泄漏应该注意的问题：
    1.使用Application这种Context类型。
    2.注意对Context的引用不要超过它本身的生命周期。
    3.慎重的使用“static”关键字。
    4.Context里如果有线程，一定要在onDestroy()里及时停掉。

    5.使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;

 

五 线程问题

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

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也不会被销毁，因此就出现了内存泄露的问题。

 

解决：

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

在线程内部采用弱引用保存Context引用。

 

 public class ThreadAvoidActivity extends Activity {  
            public void onCreate(Bundle savedInstanceState) {  
                super.onCreate(savedInstanceState);  
                setContentView(R.layout.activity_main);  
                new MyThread(this).start();  
            }  
          
            private void dosomthing() {  
          
            }  
          
            private static class MyThread extends Thread {  
                WeakReference<ThreadAvoidActivity> mThreadActivityRef;  
          
                public MyThread(ThreadAvoidActivity activity) {  
                    mThreadActivityRef = new WeakReference<ThreadAvoidActivity>(  
                            activity);  
                }  
          
                @Override  
                public void run() {  
                    super.run();  
                    if (mThreadActivityRef == null)  
                        return;  
                    if (mThreadActivityRef.get() != null)  
                        mThreadActivityRef.get().dosomthing();  
                    // dosomthing  
                }  
            }  
        }  

 

 

上面的两个步骤其实是切换两个对象的双向强引用链接

1. 静态内部类：切断Activity 对于 MyThread的强引用。
2. 弱引用： 切断MyThread对于Activity 的强引用。

六 超级大胖子Bitmap

可以说出现OutOfMemory问题的绝大多数人，都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了，它是一个“超级大胖子”，特别是分辨率大的图片，如果要显示多张那问题就更显著了。
如何解决Bitmap带给我们的内存问题？

 

及时的销毁bitmap- recycle

虽然，系统能够确认Bitmap分配的内存最终会被销毁，但是由于它占用的内存过多，所以很可能会超过java堆的限制。因此，在用完Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释 放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。

 

设置一定的采样率

有时候，我们要显示的区域很小，没有必要将整个图片都加载出来，而只需要记载一个缩小过的图片，这时候可以设置一定的采样率，那么就可以大大减小占用的内存。如下面的代码：

 

private ImageView preview;


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


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

Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);


preview.setImageBitmap(bitmap);

 

 巧妙的运用软引用（SoftRefrence）

有些时候，我们使用Bitmap后没有保留对它的引用，因此就无法调用Recycle函数。这时候巧妙的运用软引用，可以使Bitmap在内存快不足时得到有效的释放。如下例：