android内存优化总结

根据我个人的项目经历，和平时钻研借鉴资料等；对于android中的内存优化，我个人总结了以下一些经验方法：

内存优化可以从处理图片入手：

图片显示

我们需要根据需求去加载图片的大小。

例如在列表中仅用于预览时加载缩略图。

只有当用户点击具体条目想看详细信息的时候，这时另启动一个fragment／activity／对话框等等，去显示整个图片。

图片像素

Android中图片有四种属性，分别是：
       ALPHA_8：每个像素占用1byte内存 
       ARGB_4444：每个像素占用2byte内存 
       ARGB_8888：每个像素占用4byte内存 （默认）
       RGB_565：每个像素占用2byte内存 

 

Android默认的颜色模式为ARGB_8888，这个颜色模式色彩最细腻，显示质量最高。但同样的，占用的内存也最大。 所以在对图片效果不是特别高的情况下使用RGB_565（565没有透明度属性）

 

BitmapFactory.Options opt = new BitmapFactory.Options();   opt.inPreferredConfig = Bitmap.Config.RGB_565; // 图像以RGB_565读取

 图片大小边界压缩

直接使用ImageView显示bitmap会占用较多资源，特别是图片较大的时候，可能导致崩溃。 
使用BitmapFactory.Options设置inSampleSize, 这样做可以减少对系统资源的要求。 
属性值inSampleSize表示缩略图大小为原始图片大小的几分之一，即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片大小就为原始大小的1/4。 

图片OOM的原理：

假设一张图片的宽高为2600 * 1800 像素，每个像素是ARGB_8888,则其直接拉进内  存，占用的内存大小为：

2600 * 1800 * 4byte = 18720000byte = 17.8M

 

      若展示此图片的ImageView大小仅为260 * 180px，则加载这么大的图片是没什么意义的，经计算，压缩比为10（2600 / 260），即inSampleSize = 10；

经过边界压缩后，图片的大小为：

260 * 180 * 4byte = 0.18M

图片压缩范例代码：

BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; // 设置inJustDecodeBounds为true后，decodeFile并不分配空间 Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/test.jpg", options); //此时返回bitmap为空, 但加载到了原始图片的长度和宽度    options.inJustDecodeBounds = false; // 这里一定要将其设置回false，因为之前我们将其设置成了true    // 计算缩放比 （仅以计算高度缩放举例） int be = (int)(options.outHeight / iv.getHeight()); if (be <= 0) {        be = 1; } options.inSampleSize = be; // 设置压缩比 //重新读入图片，注意这次要把options.inJustDecodeBounds 设为 false bitmap=BitmapFactory.decodeFile("/sdcard/test.jpg",options);  iv.setImageBitmap(bitmap); // 设置图片到ImageView

图片回收

使用Bitmap过后，就需要及时的调用Bitmap.recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。

下面是释放Bitmap的示例代码片段：

// 先判断是否已经回收  if(bitmap != null && !bitmap.isRecycled()){      // 回收并且置为null  bitmap.recycle();      bitmap = null;  }  System.gc();

捕获异常

经过上面这些优化后还会存在报OOM的风险，所以下面需要一道最后的关卡——捕获OOM异常：

Bitmap bitmap = null; try {      // 实例化Bitmap      bitmap = BitmapFactory.decodeFile(path);  } catch (OutOfMemoryError e) {      // 捕获OutOfMemoryError，避免直接崩溃  }  if (bitmap == null) {     // 如果实例化失败 返回默认的Bitmap对象      return defaultBitmapMap;  }

使用LruCache进行内存管理

这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。

在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。

我们应该考虑到底应该为缓存分配多大的空间，一般建议为可用内存最大值的1/8左右：

// 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。 // LruCache通过构造函数传入缓存值，以KB为单位。 int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);   LruCache mBitmapCache = new LruCache(maxMemory);

常见图片加载框架

Univeral-Image-Loader

l  多线程下载图片，图片可以来源于网络，文件系统，项目文件夹assets中以及drawable中等

l  支持随意的配置ImageLoader，例如线程池，图片下载器，内存缓存策略，硬盘缓存策略，图片显示选项以及其他的一些配置

l  支持图片的内存缓存，文件系统缓存或者SD卡缓存

l  支持图片下载过程的监听

l  根据控件(ImageView)的大小对Bitmap进行裁剪，减少Bitmap占用过多的内存

l  较好的控制图片的加载过程，例如暂停图片加载，重新开始加载图片，一般使用在ListView,GridView中，滑动过程中暂停加载图片，停止滑动的时候去加载图片

l  提供在较慢的网络下对图片进行加载

Picasso

l  使用ListView，GridView的时候，自动检测Adapter的重用，取消下载，使用缓存

l  将图像进行变换，以更好的适应布局控件等，减小内存开销

l  进行图形变换，也可以写自己的变换类，但是必须实现Transformation接口

l  支持设置加载之前的图片，和加载失败后的图片

l  支持加载资源文件的图片

l  支持加载sdcard中的图片文件

Fresco

FaceBook出品

Fresco综合了之前图片加载库的优点的基础上利用本地代码做了性能上的优化

Google推荐的图片加载库Glide，有兴趣的可以自己去githup上找demo学习。

ListView优化：

1.利用ListView自身的缓存机制，他会缓存条目中的一个条目item，当listview第一屏显示完成之后，就会出现一个缓存条目，其实就是BaseAdapter里面的public View getView(int position, View convertView, ViewGroup parent)。

2.减少findViewById()的次数，findViewById是一个相对比较耗性能的操作，因为这个操作每次都需要到布局中去查找文件。把item里面的控件封装成一个javaBean，当item条目被加载的时候就去找到对应的控件。

3.利用时间去换取时间，比如开机优化，把一些重要的程序先启动了，启动完系统之后再启动其他程序。

4.利用空间去换取时间，把要获取的数据先加载到内存里面，再处理数据的时候，直接从内存中获取。

   例如：减少数据库的频繁打开和关闭和减少查询的次数。

（前两点都是利用ListView的自身优化机制优化【缓存优化】）

UI Review（视图检查）

减少视图层级

减少视图层级可以有效的减少内存消耗，因为视图是一个树形结构，每次刷新和渲染都会遍历一次。

ViewStub标签

此标签可以使UI在特殊情况下，直观效果类似于设置View的不可见性，但是其更大的意义在于被这个标签所包裹的Views在默认状态下不会占用任何内存空间。

 

include标签

可以通过这个标签直接加载外部的xml到当前结构中，是复用UI资源的常用标签。

 

merge标签

它在优化UI结构时起到很重要的作用。目的是通过删减多余或者额外的层级，从而优化整个Android Layout的结构。

 

 

 

使用ThreadPool而不是每次new Thread

 

减少不必要的全局变量

尽量避免static成员变量引用资源耗费过多的实例,比如Context。

因为Context的引用超过它本身的生命周期，会导致Context泄漏。所以尽量使用Application这种Context类型。 

你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。 

 

Cursor（游标）回收

Cursor是Android查询数据后得到的一个管理数据集合的类，在使用结束以后。应该保证Cursor占用的内存被及时的释放掉，而不是等待GC来处理。并且Android明显是倾向于编程者手动的将Cursor close掉，因为在源代码中我们发现，如果等到垃圾回收器来回收时，会给用户以错误提示。

 

Receiver（接收器）回收

调用registerReceiver()后未调用unregisterReceiver(). 

当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver，一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册 
也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现，通常我们可以重写Activity的onDestory()方法，在onDestory里进行unregisterReceiver操作

 

Stream/File（流/文件）回收

主要针对各种流，文件资源等等如：

InputStream/OutputStream，SQLiteOpenHelper，SQLiteDatabase，Cursor，文件，I/O，Bitmap图片等操作等都应该记得显示关闭。

 

 

避免创建不必要的对象

最常见的例子就是当你要频繁操作一个字符串时，使用StringBuffer代替String。

还比如：使用int数组而不是Integer数组。

避免创建短命的临时对象，减少对象的创建就能减少垃圾收集，进而减少对用户体验的影响。

避免内部Getters/Setters

在Android中，虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践，在公共接口中使用Getters和Setters是有道理的，但在一个字段经常被访问的类中宜采用直接访问。

for循环

访问成员变量比访问本地变量慢得多，如下面一段代码：

for(int i =0; i < this.mCount; i++)  {}  

永远不要在for的第二个条件中调用任何方法，如下面一段代码：

for(int i =0; i < this.getCount(); i++) {}  

对上面两个例子最好改为：

int count = this.mCount; / int count = this.getCount();  

for(int i =0; i < count; i++)  {}