一次OOM引起的优化

一次OOM引发的优化

最近在自己研究一个应用，功能简单，所以就想在ui上面下些功夫。

关于界面的想法：

页面A对某一类型的数据项进行增删改，存入数据库中。页面B对数据库中现存的数据项放入自定义View中进行显示（一条数据和一个view是对应的），从而实现一种类似Metro风格的布局。

实施

自定义View不是很难，算是初学，所以在数据适配显示、尺寸计算方面耽误了一些时间。
原来的想法是扩展一个LinearLayout类，可以对List的数据进行适配、显示。奈何自定义ViewGroup方面的知识还有待学习，所以只好写一个继承了BaseAdapter的Adapter了。
实现原理用xml表示大体是这样的，只不过在Adapter中是用代码实现的…

<LinearLayout 根结点，方向为垂直>
    <LinearLayout 一级结点，方向为水平>
        <MyView>
        <MyView>
        <MyView>
    </LinearLayout>

    <LinearLayout 一级结点，方向为水平>
        <MyView>
        <MyView>
    </LinearLayout>
    ...
</LinearLayout>

起初就感觉这样效率会很低…毕竟嵌套了这么多层的layout。

OOM

果不其然，意料之中，进入这个页面，卡，刷新显示自定义view的布局足足用了三秒钟..由于显示Metro风格布局是在一个Fragment中，切换到其他Fragment再切换回来的时候，由于又重新读取数据、适配、刷新ui一次，很干脆的程序崩溃，看了一下log，是OOM。

尝试1：

把数据的读取、适配都放到了子线程中进行，在ui线程中只做刷新。

结果在进入那个Fragment时，ui方面不太卡了，但是对于OOM来说没有明显的效果。说明OOM的原因是自定义View的重复刷新

尝试2：

在刷新线程和负责刷新ui的Handler类中添加了一个标识变量，用于监控数据源是否发生了改变，如果数据源中有数据改动，则下次进入该Fragment中就需要取数据、适配、刷新view；否则维持原样。

结果Fragment之间的来回切换没有问题了，但是从其他的Activity跳回到主Activity（就是盛放Fragment的Activity）中的那个特定Fragment中时，OOM…而且数据源变化，重新刷新view之后，也同样的OOM…说明之前几次占用的内存空间并没有因为失去了引用而被GC清理掉…于是多次刷新的结果就是用光了内存。

尝试3：

睡梦中突然想到，能不能在主Activity中就把数据读取、适配、刷新自定义View的操作执行了，直接把view传递给Fragment直接显示呢？这样在从其他的activity返回主activity、并显示特定的Fragment时，Fragment的onCreateView方法就不需要重复刷新自定义view了，毕竟这个方法的返回值就是一个view嘛。

然而结果并没有什么卵用…原因是Fragment的构造函数要么是缺省的，要么参数只能是Bundle类型的，但是Bundle类型的参数传不了View对象…

尝试4：

既然奇葩的招都用了也没有效果，那只能研究一下如何减少自定义view在绘制过程中对内存的占用了…
1. 想法1，缩减图片的大小。在自定义view中需要一个大小为100*100的png图片，缩小一下图片的大小应该会有作用。
2. 想法2，前天晚上记得看了一篇博客(Android性能优化典范（二）)[http://android.jobbole.com/80938/]里面讲到了一些东西…下面节选一些用到的地方

“通常来说，对于不透明的View，显示它只需要渲染一次即可，可是如果这个View设置了alpha值，会至少需要渲染两次。原因是包含alpha的view需要事先知道混合View的下一层元素是什么，然后再结合上层的View进行Blend混色处理。”

“避免在onDraw()方法里面执行导致内存分配的操作,onDraw()方法是执行在UI线程的，在UI线程尽量避免做任何可能影响到性能的操作。虽然分配内存的操作并不需要花费太多系统资源，但是这并不意味着是免费无代价的。设备有一定的刷新频率，导致View的onDraw方法会被频繁的调用，如果onDraw方法效率低下，在频繁刷新累积的效应下，效率低的问题会被扩大，然后会对性能有严重的影响。如果在onDraw里面执行内存分配的操作，会容易导致内存抖动，GC频繁被触发，虽然GC后来被改进为执行在另外一个后台线程(GC操作在2.3以前是同步的，之后是并发)，可是频繁的GC的操作还是会影响到CPU，影响到电量的消耗。”

“尽量减少PNG图片的大小是Android里面很重要的一条规范。相比起JPEG，PNG能够提供更加清晰无损的图片，但是PNG格式的图片会更大，占用更多的磁盘空间。到底是使用PNG还是JPEG，需要设计师仔细衡量，对于那些使用JPEG就可以达到视觉效果的，可以考虑采用JPEG即可。”

“Re-using Bitmaps”

于是我就做了下面的改动：

由于背景颜色不需要透明度，所以我将原来的ARGB格式改成了RGB格式。
之前看过一篇Bitmap缓存的方法，用的是软引用，上网找了一下进行下学习。下面是代码

package com.mmrx.health.util;

import android.content.Context;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;

import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
import java.util.Hashtable;

/**
 * Created by mmrx on 2015/5/7.
 */
public class BitmapCache {

    static private BitmapCache cache;
    /** 用于cache内容的存储 */
    private Hashtable<Integer,MySoftRef> hashRefs;
    /** 垃圾Reference的队列（所引用的对象已经被回收，则将该引用存入队列中） */
    private ReferenceQueue<Bitmap> q;
    /**
     * 继承SoftReference，使得每一个实例都具有可识别的标识。
     */
    private class MySoftRef extends SoftReference<Bitmap>{
        private Integer _key = 0;

        public MySoftRef(Bitmap bmp,ReferenceQueue<Bitmap> q,int key){
            super(bmp,q);
            _key = key;
        }
    }
    //私有构造函数
    private BitmapCache(){
        hashRefs = new Hashtable<Integer,MySoftRef>();
        q = new ReferenceQueue<Bitmap>();
    }

    /**
     * 取得缓存器实例
     * */
    public static BitmapCache getInstance(){
        if(cache == null)
            cache = new BitmapCache();
        return cache;
    }

    /**
     * 以软引用的方式对一个Bitmap对象的实例进行引用并保存该引用
     */
    private void addCacheBitmap(Bitmap bmp,Integer key){
        //清除垃圾引用
        cleanCache();
        MySoftRef ref = new MySoftRef(bmp,q,key);
        hashRefs.put(key,ref);
    }
    /**
     * 依据所指定的drawable下的图片资源ID号（可以根据自己的需要从网络或本地path下获取）
     * 重新获取相应Bitmap对象的实例
     */
    public Bitmap getBitmap(int resid,Context context){
        Bitmap bmp = null;
        //缓存中是否有该bitmap实例的软引用，如果有，则从软引用中取得
        if(hashRefs.containsKey(resid)){
            MySoftRef ref = (MySoftRef)hashRefs.get(resid);
            bmp = (Bitmap)ref.get();
        }
        //如果没有软引用，或者从软引用中得到的实例是null，重新构建一个实例，
        //并保存这个新建实例的软引用
        if(bmp == null){
            bmp = BitmapFactory.decodeStream(context.getResources().openRawResource(resid));
            this.addCacheBitmap(bmp,resid);
        }
        return bmp;
    }

    private void cleanCache(){
        MySoftRef ref = null;
        while ( (ref=(MySoftRef)q.poll())!=null )
            hashRefs.remove(ref._key);
    }

    /**
     * 清除Cache内的全部内容
     */
    public void clearCache(){
        cleanCache();
        hashRefs.clear();
        System.gc();
        System.runFinalization();
    }
 }

上面两招用了之后，就好使了~自定义的view刷新腰不酸了腿不疼了，赶紧把刚到的键帽给换上~~

总结

一切困难都是纸老虎（如果你找到了正确的解决方法）…OOM果然大多都是由Bitmap引起的！

一次OOM唤起的优化