Bitmap 内存优化

Posted 2020-08-04 马骝

android在加载大背景图或者大量图片时，经常导致内存溢出（Out of Memory  Error），本文根据我处理这些问题的经历及其它开发者的经验，整理解决方案如下（部分代码及文字出处无法考证）：
 方案一、读取图片时注意方法的调用，适当压缩  尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。 因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的  source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。

         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);

如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常。

 

   /**

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

     *  @param context

     *  @param resId

     *  @return

      */

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

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

         opt.inPreferredConfig =  Bitmap.Config.RGB_565;

         opt.inPurgeable = true;

         opt.inInputShareable = true;

         //  获取资源图片

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

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

         }

另 外，decodeStream直接拿图片来读取字节码，  不会根据机器的各种分辨率来自动适应，使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源，  否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。
方案二、在适当的时候及时回收图片占用的内存  通常Activity或者Fragment在onStop/onDestroy时候就可以释放图片资源：  

 if(imageView !=  null &&  imageView.getDrawable() != null){     

      Bitmap oldBitmap =  ((BitmapDrawable) imageView.getDrawable()).getBitmap();    

       imageView.setImageDrawable(null);    

      if(oldBitmap !=  null){    

            oldBitmap.recycle();     

            oldBitmap =  null;   

      }    

 }   

 //  Other code.

 System.gc();

在释放资源时，需要注意释放的Bitmap或者相关的Drawable是否有被其它类引用。如果正常的调用，可以通过Bitmap.isRecycled()方 法来判断是否有被标记回收；而如果是被UI线程的界面相关代码使用，就需要特别小心避免回收有可能被使用的资源，不然有可能抛出系统异常： E/AndroidRuntime: java.lang.IllegalArgumentException: Cannot draw recycled  bitmaps 并且该异常无法有效捕捉并处理。
方案三、不必要的时候避免图片的完整加载 只需要知道图片大小的情形下，可以不完整加载图片到内存。 在使用BitmapFactory压缩图片的时候，BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，可以在不分配空间状态下计算出图片的大小。示例：   

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

 //  设置inJustDecodeBounds为false     

 opts.inJustDecodeBounds = false;    

 //  使用decodeFile方法得到图片的宽和高    

 BitmapFactory.decodeFile(path,  opts);    

 //  打印出图片的宽和高

 Log.d("example", opts.outWidth + "," + opts.outHeight);

（ps:原理其实就是通过图片的头部信息读取图片的基本信息）
方案四、优化Dalvik虚拟机的堆内存分配  堆 （HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，通常有一个分配机制来控制它的大小。比如初始的HEAP是4M大， 当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减 它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。 Heap  Utilization是堆的利用率。当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。使用  dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。  

 private final static float  TARGET_HEAP_UTILIZATION = 0.75f;    

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

 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);

方案五、自定义堆（Heap）内存大小  对 于一些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大小。

但是上面方法还是存在问题，函数setMinimumHeapSize其实只是改变了堆的下限值，它可以防止过于频繁的堆内存分配，当设置最小堆内存大小超过上限值（Max Heap  Size）时仍然采用堆的上限值，对于内存不足没什么作用。  
在默认情况下android进程的内存占用量为16M，因为Bitmap他除了java中持有数据外，底层C++的  skia图形库还会持有一个SKBitmap对象，因此一般图片占用内存推荐大小应该不超过8M。这个可以调整，编译源代码时可以设置参数。

参考资料：http://www.tuicool.com/articles/yemM7zf

方案六：在Manifest.xml文件里面的<application  里面添加Android:largeHeap="true"

简单粗暴。这种方法允许应用需要耗费手机很多的内存空间，但却是最快捷的解决办法

 

 

这篇文章是我很久以前写的，感觉写得太官方了，于是我下定决心想要改得更加贴近大家的思维，于是我将把改版后的推荐给大家。
1、内存泄漏：

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

2、内存溢出：

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

3、两者的区别：

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

4、四种不同类型的引用：

引用名称	Strong Reference(强引用)	Soft Reference (软引用)	Weak Reference (弱引用)	Phantom Reference (虚引用)
引用特点	通常我们编写的代码都是Strong Ref，于此对应的是强可达性，只有去掉强可达，对象才被回收。	对应软可达性，只要有足够的内存，就一直保持对象，直到发现内存吃紧且没有Strong Ref时才回收对象。一般可用来实现缓存，	比Soft Ref更弱，当发现不存在Strong Ref时，立刻回收对象而不必等到内存吃紧的时候	根本不会在内存中保持任何对象，你只能使用Phantom Ref本身。一般用于在进入finalize()方法后进行特殊的清理过程
引用方式		通过java.lang.ref. SoftReference类实现	通过java.lang.ref.WeakReference和java.util.WeakHashMap类实现	通过java.lang.ref.PhantomReference实现

 

 

5、持有Context引用造成的泄漏。

在Android应用程序中，很多操作都用到了Context对象，但是大多数都是用来加载和访问资源的。
这就是为什么所有的显示控件都需要一个Context对象作为构造方法的参数。
在Android应用程序中通常可以使用两种Context对象：Activity和Application。
当类或方法需要Context对象的时候常见的作法是使用第一个作为Context参数。
但这就意味着View对象对整个activity保持引用，因此也就保持对activity内的所有东西的引用，
也就是整个View结构和它所有的资源都无法被及时的回收，而且对activity的长期引用是比较隐蔽的。

当屏幕方向改变时，Android系统默认作法是会销毁当前的Activity，然后创建一个新的Activity，这个新的Activity会显示刚才的状态。
在这样做的过程中，Android系统会重新加载UI用到的资源。
现在假设的应用程序中有一个比较大的bitmap类型的图片，每次旋转时都重新加载图片所用的时间较多。
为了提高屏幕旋转时Activity的创建速度，最简单的方法是用静态变量的方法。

这样的代码执行起来是快速的，但同时是错误的：这样写会一直保持着对Activity的引用。
当一个Drawable对象附属于一个View时，这个View就相当于drawable对象的一个回调（引用）。
在上面的代码片段中，就意味着drawable和TextView存在着引用的关系，
而TextView自己持有了对Activity（Context对象）的引用，这个Activity又引用了相当多的东西。

有两种简单的方法可以避免由引用context对象造成的内存泄露。
首先第一个方法是避免context对象超出它的作用范围。
上面的例子展示了静态引用的情况，但是在类的内部，隐式的引用外部的类同样的危险。
第二种方法是，使用Application对象。这个context对象会随着应用程序的存在而存在，而不依赖于activity的生命周期。
如果你打算对context对象保持一个长期的引用，请记住这个application对象。
通过调用Context.getApplicationContext() 或者 Activity.getApplication().方法，你可以很容易的得到这个对象。
如果在activity中使用静态的类时如果需要引用activity,应该采用WeakReference弱引用来引用Activity。

总结一下避免Context泄漏应该注意的问题： 尽量使用Application这种Context类型， 

注意对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字，Context里如果有线程，一定要在onDestroy()里及时停掉。 

为了防止内存泄露，我们应该注意以下几点：
（1）不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的.
（2）对于生命周期长的对象，可以使用application context。
（3）避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。

6、线程之间通过Handler通信引起的内存泄漏

Android中线程之间进行通信时最常用的作法是通过接收消息的目标线程所持有Handler对象来创建Message对象，然后再向目标线程发送该Message。
在目标线程中Handler在执行handleMessage()时会根据相应Message来执行相应不同功能。
另外一种作法是通过Handler对象向目标线程直接发送Runnable对象来执行该Runnable对象中不同的功能代码。
在通过Handler进行通信时如果不注意，也很有可能引起内存泄漏。

在sendMessage完成之后显示的将msg成员变量置为null，并且在退出整个应用程序之前，将handler置为null。

7、将变量的作用域设置为最小

最小化作用域意味着对垃圾收集器更快的可见。让我们举一个例子。
我们有一个变量定义在方法级,当方法执行完毕后,也就是说,控制跳出方法后,则该变 量将不会被引用。
这也就意味着它已经可以被垃圾回收。但是如果该变量是类级的,这时垃圾回收器就需要等待直到对该类的所有的引用都被移除后才能进行垃圾回收。
优化属性的作用域是必须的。同样这也是封装原则。最小化作用域降低了通过包访问变量并减少了耦合。

8、构造Adapter时，没有使用缓存的convertView。

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

由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，
即浪费时间，也造 成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。

9、Bitmap的回收和置空。
Bitmap 对象不在使用时调用 recycle()释放内存，有时我们会手工的操作 Bitmap 对象,
如果一个Bitmap 对象比较占内存, Bitmap对象在不使用时，我们应该先调用recycle()释放内存，然后才它设置为null。
虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。
但是我它应该还是能大大的加速Bitmap的主要内存的释放。

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

资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。
它们的 缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。
如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。
因为有些资源 性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），
如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。
因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.
在我们的程序退出时一定要确保我们的资源性对象已经关闭。

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

11、各种注册没取消。

这种情况造成的内存泄露这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些Android程序可能引用我们的Anroid程序的对象（比如注册机制）。
即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收
。比如 假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，
则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。
对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。
如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。
虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

12、集合容器对象没清理造成的内存泄露。

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，
并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。

13、static关键字的滥用。

当类的成员变量声明成static后，它是属于类的而不是属于对象的，
如果我们将很大的资源对象（Bitmap，context等）声明成static，那么这些资源不会随着对象的回收而回收，
会一直存在，所以在使用static关键字定义成员变量的时候要慎重。

14、WebView对象没有销毁。

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。

15、GridView的滥用。

GridView和ListView的实现方式不太一样。GridView的View不是即时创建的，而是全部保存在内存中的。
比如一个GridView有100项，虽然我们只能看到10项，但是其实整个100项都是在内存中的。
所以在应用程序退出之前，要讲gridView和adapter全部置为null。