一次OOM引起的优化

本文主要是介绍一次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();}}