6.1 内存机制及使用优化

Posted 2020-08-19 qkeyar

6.1.1  Android的内存机制

　　android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的.

　　那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个对象不再被引用，可以被GC回收。

　　当系统内存不足时，系统将激活内存回收过程。为了不因内存回收影响用户体验（如杀死当前的活动进程），Android 基于进程中运行的组件及其状态规定了默认的五个回收优先级，这几种优先级的回收顺序是 ：

Empty process、Background process、Service process、Visible process、Foreground process

　　当 Android 应用程序退出时，并不清理其所占用的内存，Linux 内核进程也相应的继续存在，所谓“退出但不关闭”。从而使得用户调用程序时能够在第一时间得到响应。

6.1.2  Android的内存溢出

1. 内存泄露导致

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

常见的内存泄漏还有：

1) 万恶的static

  　static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。

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

•     第一、应该尽量避免static成员变量引用资源耗费过多的实例，比如Context；
•     第二、Context尽量使用Application Context，它的生命周期比较长，引用它不会出现内存泄露的问题；
•     第三、使用WeakReference代替强引用。比如可以使用WeakReference mContextRef。

2) 线程惹的祸

　　线程产生内存泄露的主要原因在于线程生命周期的不可控。

　　我们来考虑下面一段代码：

public class MyActivity extends Activity {           
　　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函数是一个很费时的操作，当调用finish的时候Activity 会销毁掉吗？

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

解决方案： 将线程的内部类，改为静态内部类。 如果需要引用Acitivity，使用弱引用。

【附】内存泄漏调试：内存监测工具 DDMS --> Heap；内存分析工具 MAT(Memory Analyzer Tool)

2. 占用内存较多的对象

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

1) 万恶之源BitMap

　　可以说出现OutOfMemory问题的绝大多数人，都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了，特别是分辨率大的图片，如果要显示多张那问题就更显著了。

　　解决方案：

　　第一、及时的销毁。

虽然，系统能够确认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); 

BitmapFactory这个类提供了多个解析方法用于创建Bitmap对象，比如：

• • SD卡中的图片可以使用decodeFile方法，
  • 网络上的图片可以使用decodeStream方法，
  • 资源文件中的图片可以使用decodeResource方法。

这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。

　　为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。

 　　虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。现在图片的大小已经知道了，我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。通过设置BitmapFactory.Options中inSampleSize的值就可以实现。

　　比如我们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存，压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型，即每个像素点占用4个字节)。

　　使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析一次图片。然后将BitmapFactory.Options连同期望的宽度和高度一起传递到到calculateInSampleSize方法中，就可以得到合适的inSampleSize值了。之后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就可以得到压缩后的图片了。

　　第三、巧妙的运用软引用（SoftRefrence）

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

　　第四、异步加载和缓存 ，如使用第三方加载库。

 2) 行踪诡异的Cursor

Cursor是Android查询数据后得到的一个管理数据集合的类，正常情况下，如果查询得到的数据量较小时不会有内存问题，而且虚拟机能够保证Cusor最终会被释放掉。

然而如果Cursor的数据量特表大，特别是如果里面有Blob信息时，应该保证Cursor占用的内存被及时的释放掉，而不是等待GC来处理。并且Android明显是倾向于编程者手动的将Cursor close掉而且android数据库中对Cursor资源的是又限制个数的，如果不及时close掉，会导致别的地方无法获得

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

  　　以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法： getView( )

 　　AdapterView 在使用View会有一个循环的View队列的，把不显示的View重新投入使用，所以在convertView不为空的时候，不要直接创建新的View。