zoukankan      html  css  js  c++  java
  • android内存优化发展——使用软引用

      整个Android开发者一定是遇到了内存溢出这个头疼的问题,一旦这个问题。很难直接决定我们的应用程序是哪里出了问题,为了找到问题的解决方案,必须累积发行通过一些内存分析工具高速定位和强大的体验,现在详细那里能力。

      具有此功能基于手机开发,低内存消耗的原则。以及我近期遇到的内存堆积(偶尔溢出)问题,总结一下这次解决问题的经验。

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

      定位到问题的所在后,先用前面的广播方式替换掉之前的那种方案,这样就攻克了问题的一半了,那本地图片怎样处理呢?就上网查看了一些文章。看到很多大神都说到了软引用这个东东。于是就研究了下软引用怎样使用。

    发现这软引用的确是个好东西。的确能够优化整个应用对内存的消耗。

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

      假设一个对象仅仅具有软引用,那么假设内存假设够用的话,GC就不会回收它,假设内存不足了,就会优先回收仅仅有软引用的对象内存,而保证不会内存溢出。

    基于软引用的这个特性。我们能够使用软引用来实现内存敏感区的快速缓存。因此为了防止内存溢出的发生,在处理一些占用内存较大且声明周期较长的对象的时候,我们能够尽量使用软引用,比如: Context及其子类对象。Drawable及其子类对象,Bitmap位图对象等,在创建这些类的对象的时候。尽量将其声明为软引用。

      软引用对象声明: SoftReference<Class> instance;

      以下两个样例是我在项目中实际使用的代码。大家能够看下。

              

    //这个样例是用来处理生命周期较长的大对象
     
    /**********************************************************
     * @文件名:ActivityManager.java
     * @创建时间:2014年11月6日 上午11:38:23
     * @文件描写叙述:Activity管理类
     * @改动历史:2014年11月6日创建初始版本号
     **********************************************************/
    public class ActivityManager
    {
    	private static ActivityManager manager = null;
    	private static HashMap<String, SoftReference<Activity>> activityMap;
    
    	// 静态语句块,在类载入的时候一起运行
    	static
    	{
    		manager = new ActivityManager();
    		activityMap = new HashMap<String, SoftReference<Activity>>();
    	}
    
    	private ActivityManager()
    	{
    
    	}
    
    	public static ActivityManager getInstance()
    	{
    		return manager;
    	}
    
    	public void put(Activity act)
    	{
    		activityMap.put(act.toString(), new SoftReference<Activity>(act));
    	}
    
    	public void remove(Activity act)
    	{
    		activityMap.remove(act.toString());
    	}
    
    	public void finishAllActivity()
    	{
    		Set<String> set = activityMap.keySet();
    		Iterator<String> iter = set.iterator();
    		while (iter.hasNext())
    		{
    			String actName = iter.next();
    			Activity currentAct = activityMap.get(actName).get();
    			if (currentAct != null)
    			{
    				currentAct.finish();
    				currentAct = null;
    			}
    		}
    		activityMap.clear();
    		activityMap = null;
    	}
    }

    //这个样例是用来处理位图等内存敏感对象演示样例
    public class BitmapManager
    {
    
    	private static BitmapManager bitmapManager = null;
    	private static HashMap<String, SoftReference<Bitmap>> imageCache = null;
    
    	static
    	{
    		bitmapManager = new BitmapManager();
    		imageCache = new HashMap<String, SoftReference<Bitmap>>();
    	}
    
    	private BitmapManager()
    	{
    
    	}
    
    	public static BitmapManager getInstance()
    	{
    		return bitmapManager;
    	}
    
    	public static void saveBitmapToCache(String path)
    	{
    		Bitmap bitmap = BitmapFactory.decodeFile(path);
    		// 加入该对象软引用对象到Map中使其缓存
    		imageCache.put(path, new SoftReference<Bitmap>(bitmap));
    		// 使用完后手动将位图对象置null
    		bitmap = null;
    	}
    
    	public static Bitmap queryBitmapByPath(String path)
    	{
    		// 取出软软引用
    		SoftReference<Bitmap> softBitmap = imageCache.get(path);
    		// 使用时必须推断软引用是否回收,被回收返回空
    		if (softBitmap == null)
    		{
    			return null;
    		}
    		Bitmap bitmap = softBitmap.get();
    
    		return bitmap;
    	}
    
    }
     总结一下:当我们开发应用程序,最好是刚开始认识到要考虑到可能发生的帐户问题,这些细节提前做处理好工作,将杜绝从根发生此类问题,而当问题发生在许多其他的能源处理将再次花费。



     

      

  • 相关阅读:
    红黑树
    二叉搜索树
    散列表
    基本数据结构
    顺序统计量
    RabbitMQ一些实用方法
    (转)elasticsearch连接不到head插件解决方案
    (转)如何优雅的使用rabbit mq
    (转)elasticsearch6.0版本安装head插件
    Rabbit MQ一些参数解释
  • 原文地址:https://www.cnblogs.com/hrhguanli/p/5038509.html
Copyright © 2011-2022 走看看