android开发内存优化之软引用

所有Android的开发者一定都遇到过内存溢出这个头疼的问题,一旦出现这个问题,很难直接确定我们的应用是那里出了问题,要想定位问题的原因,必须通过一些内存分析工具和强大的经验积累才能快速的定位到问题具体出现在那里。

  基于移动开发具有的这个特性,本着尽量减少内存消耗的原则,以及我最近遇到的内存堆积(偶尔溢出)问题,总结一下这次解决这个问题的经验。

  问题源头:开始App功能没那么多的时候,是没有注意到这个问题的,后来功能越强越多,图片也越来越多的时候,用ADT自带的 Allocation Tracker查看了一下内存分配,明显有许多无用的data object,而没有释放掉,开始以为是universalImageLoader的问题,以为这个开源工程对图片的加载有问题,后来把图片全去掉再看内 存分配时还是有无用的data object,花了两天时间后发现是,是自己本地的一些bitmap没有回收,一直缓存在内存中,另一个原因就是前面文章提到的,为了实现退出功能,使用 了一个全局的ArrayList去存储所有新启动的Activity,导致Activity这种大对象无法释放,有这两个问题内存不堆积才有问题。

  定位到问题的所在后,先用前面的广播方式替换掉之前的那种方案,这样就解决了问题的一半了,那本地图片如何处理呢?就上网查看了一些文章,看到 许多大神都说到了软引用这个东东,于是就研究了下软引用如何使用。发现这软引用的确是个好东西。的确可以优化整个应用对内存的消耗。

  从JDK1.2开始,java将对象分成了四种级别,以达到程序对对象生财周期的灵活控制,这四个级别由强到弱是:强引用,软引用,弱引用,虚 引用。强引用就不多说了,就是我们平时直接new出来的一个对象,不做任何的修饰,就是强引用。虚引用暂未使用过也就没做过深入了解,弱引用的使用方式基 本和软引用是一样的,所以就重点看了一下应用程序如何使用软引用。

  如果一个对象只具有软引用,那么如果内存如果够用的话,GC就不会回收它,如果内存不足了,就会优先回收只有软引用的对象内存,而保证不会内存 溢出。基于软引用的这个特性,我们可以使用软引用来实现内存敏感区的高速缓存,因此为了防止内存溢出的发生,在处理一些占用内存较大且声明周期较长的对象 的时候,我们可以尽量使用软引用,例如: Context及其子类对象,Drawable及其子类对象,Bitmap位图对象等,在创建这些类的对象的时 候,尽量将其声明为软引用。

  软引用对象声明: SoftReference instance;

  下面两个例子是我在项目中实际使用的代码,大家可以看下。

代码片段一:

 1 //这个例子是用来处理生命周期较长的大对象
 2  
 3 /**********************************************************
 4  * @文件名称:ActivityManager.java
 5  * @创建时间:2014年11月6日 上午11:38:23
 6  * @文件描述:Activity管理类
 7  * @修改历史:2014年11月6日创建初始版本
 8  **********************************************************/
 9 public class ActivityManager
10 {
11     private static ActivityManager manager = null;
12     private static HashMap activityMap;
13 
14     // 静态语句块,在类加载的时候一起执行
15     static
16     {
17         manager = new ActivityManager();
18         activityMap = new HashMap();
19     }
20 
21     private ActivityManager()
22     {
23 
24     }
25 
26     public static ActivityManager getInstance()
27     {
28         return manager;
29     }
30 
31     public void put(Activity act)
32     {
33         activityMap.put(act.toString(), new SoftReference(act));
34     }
35 
36     public void remove(Activity act)
37     {
38         activityMap.remove(act.toString());
39     }
40 
41     public void finishAllActivity()
42     {
43         Set set = activityMap.keySet();
44         Iterator iter = set.iterator();
45         while (iter.hasNext())
46         {
47             String actName = iter.next();
48             Activity currentAct = activityMap.get(actName).get();
49             if (currentAct != null)
50             {
51                 currentAct.finish();
52                 currentAct = null;
53             }
54         }
55         activityMap.clear();
56         activityMap = null;
57     }
58 }

代码片段二:

 1 //这个例子是用来处理位图等内存敏感对象示例
 2 public class BitmapManager
 3 {
 4 
 5     private static BitmapManager bitmapManager = null;
 6     private static HashMap> imageCache = null;
 7 
 8     static
 9     {
10         bitmapManager = new BitmapManager();
11         imageCache = new HashMap>();
12     }
13 
14     private BitmapManager()
15     {
16 
17     }
18 
19     public static BitmapManager getInstance()
20     {
21         return bitmapManager;
22     }
23 
24     public static void saveBitmapToCache(String path)
25     {
26         Bitmap bitmap = BitmapFactory.decodeFile(path);
27         // 添加该对象软引用对象到Map中使其缓存
28         imageCache.put(path, new SoftReference(bitmap));
29         // 使用完后手动将位图对象置null
30         bitmap = null;
31     }
32 
33     public static Bitmap queryBitmapByPath(String path)
34     {
35         // 取出软软引用
36         SoftReference softBitmap = imageCache.get(path);
37         // 使用时必须判断软引用是否回收,被回收返回空
38         if (softBitmap == null)
39         {
40             return null;
41         }
42         Bitmap bitmap = softBitmap.get();
43 
44         return bitmap;
45     }
46 
47 }

总结:在我们开发应用程序时,最好是刚开始实现时就考虑到可能发生的问题,提前就做好这些细节性的处理,就会从根上杜绝这类问题的发生,而当问题发生了再去处理就会花费更多的精力。

 

posted @ 2015-04-10 21:17  perfect亮  阅读(387)  评论(0编辑  收藏  举报