ListView多种类型优化:
对于ListView 的优化,网上已经被讲解过很多,ListView的优化一般优化如下几点:
(1)Item View重用优化(防内存溢出)(2)View查找优化(减少执行时间)
(3)滑动优化,在滑动的时候加载图片数据等(防滑动卡顿)
以上基本上是对应单ItemView进行的优化,对于多种ItemView的优化一般使用BaseAdapter给
提供的两个方法
getItemViewType ():返回View类型,默认返回0
getViewTypeCount (): 返回有多少种类型的itemView,默认返回1
只有一种类型item view的话,是不需要重写这两个方法的。
如果有多个的时候,就需要重写这个方法了,并且返回的必须满足一下要求:
(1) getItemViewType()返回值必须大于等于0,并且小于类型的个数。为什么是这个范围,是因为
在ListView里有一个数据,用来缓存已经使用过的Item View,详细信息自己看源码
(2) getViewTypeCount()这个方法的返回值就是你可能遇到的Item view类型的最大个数,ListView会根据这个返回值
去创建缓存数组
如果有两种View类型的话,直接在Adapter里面重写getView()方法就可以了,根据 getItemViewType()返回值创建相应的View既可。
但是,如果有六个,七个怎么办?那么Adapter的getView()方法得写多少代码,到时候维护起来会多么麻烦,自己看自己写的还好,
如果换做别人呢?非常非常的痛苦.....
我在做我们的app的时候,就遇到了这样的问题,订单列表,每种订单所对应的Item View会有很大的区别,操作起来极为不方便,如有小的
改动都会耽误很长时间。新增类型也不好处理。
我针对遇到的问题进行了一个点点的优化,可以能不是最优秀的,但是至少能解决以上问题,如果您能有更好的方式,也欢迎交流。
设计:
使用提供者的设计方式提供每种Item View,不同的ItemView会有不同的提供者,提供者需要实现一个接口:
private List<IItemBean> mList = new ArrayList<IItemBean>();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
createData();
mListView = (ListView) findViewById(R.id.my_listview);
//不同之处在于多了一个provider集合,提供所有期望显示类型的provider class
//getView的实现在provider中实现,和在adapter中用法一样
List<Class<? extends IViewProvider>> providers = new ArrayList<Class<? extends IViewProvider>>();
providers.add(FlightOrderViewProvider.class);
providers.add(SticketOrderViewProvider.class);
MiltilViewListAdapter adpater = new MiltilViewListAdapter(getApplication(), mList, providers);
mListView.setAdapter(adpater);
}[/mw_shl_code
Java内存管理机制
在C++ 语言中,如果需要动态分配一块内存,程序员需要负责这块内存的整个生命周期。从申请分配、到使用、再到最后的释放。这样的过程非常灵活,但是却十分繁琐,程序员很容易由于疏忽而忘记释放内存,从而导致内存的泄露。 Java 语言对内存管理做了自己的优化,这就是垃圾回收机制。 Java 的几乎所有内存对象都是在堆内存上分配(基本数据类型除外),然后由 GC ( garbage collection)负责自动回收不再使用的内存。
上面是Java 内存管理机制的基本情况。但是如果仅仅理解到这里,我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑,既然 Java 的垃圾回收机制能够自动的回收内存,怎么还会出现内存泄漏的情况呢?这个问题,我们需要知道 GC 在什么时候回收内存对象,什么样的内存对象会被 GC 认为是“不再使用”的。
Java中对内存对象的访问,使用的是引用的方式。在 Java 代码中我们维护一个内存对象的引用变量,通过这个引用变量的值,我们可以访问到对应的内存地址中的内存对象空间。在 Java 程序中,这个引用变量本身既可以存放堆内存中,又可以放在代码栈的内存中(与基本数据类型相同)。 GC 线程会从代码栈中的引用变量开始跟踪,从而判定哪些内存是正在使用的。如果 GC 线程通过这种方式,无法跟踪到某一块堆内存,那么 GC 就认为这块内存将不再使用了(因为代码中已经无法访问这块内存了)。
通过这种有向图的内存管理方式,当一个内存对象失去了所有的引用之后,GC 就可以将其回收。反过来说,如果这个对象还存在引用,那么它将不会被 GC 回收,哪怕是 Java 虚拟机抛出 OutOfMemoryError 。
- Vector v = new Vector( 10 );
- for ( int i = 1 ;i < 100 ; i ++ ){
- Object o = new Object();
- v.add(o);
- o = null ;
- }
在这个例子中,代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环中,我们不断的生成新的对象,然后将其添加到 Vector 对象中,之后将 o 引用置空。问题是当 o 引用被置空后,如果发生 GC ,我们创建的 Object 对象是否能够被 GC 回收呢?答案是否定的。因为, GC 在跟踪代码栈中的引用时,会发现 v 引用,而继续往下跟踪,就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管 o 引用已经被置空,但是 Object 对象仍然存在其他的引用,是可以被访问到的,所以 GC 无法将其释放掉。如果在此循环之后, Object 对象对程序已经没有任何作用,那么我们就认为此 Java 程序发生了内存泄漏。
尽管对于C/C++ 中的内存泄露情况来说, Java 内存泄露导致的破坏性小,除了少数情况会出现程序崩溃的情况外,大多数情况下程序仍然能正常运行。但是,在移动设备对于内存和 CPU都有较严格的限制的情况下, Java 的内存溢出会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差,严重的也会引起抛出 OutOfMemoryError ,导致程序崩溃。
一般情况下内存泄漏的避免
在不涉及复杂数据结构的一般情况下,Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。我们有时也将其称为“对象游离”。
例如:
- public class FileSearch{
- private byte [] content;
- private File mFile;
- public FileSearch(File file){
- mFile = file;
- }
- public boolean hasString(String str){
- int size = getFileSize(mFile);
- content = new byte [size];
- loadFile(mFile, content);
- String s = new String(content);
- return s.contains(str);
- }
- }
在这段代码中,FileSearch 类中有一个函数 hasString ,用来判断文档中是否含有指定的字符串。流程是先将mFile 加载到内存中,然后进行判断。但是,这里的问题是,将 content 声明为了实例变量,而不是本地变量。于是,在此函数返回之后,内存中仍然存在整个文件的数据。而很明显,这些数据我们后续是不再需要的,这就造成了内存的无故浪费。
要避免这种情况下的内存泄露,要求我们以C/C++ 的内存管理思维来管理自己分配的内存。第一,是在声明对象引用之前,明确内存对象的有效作用域。在一个函数内有效的内存对象,应该声明为 local 变量,与类实例生命周期相同的要声明为实例变量……以此类推。第二,在内存对象不再需要时,记得手动将其引用置空。
复杂数据结构中的内存泄露问题
在实际的项目中,我们经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时,由于数据结构过于复杂,或者我们存在一些特殊的需求(例如,在内存允许的情况下,尽可能多的缓存信息来提高程序的运行速度等情况),我们很难对数据结构中数据的生命周期作出明确的界定。这个时候,我们可以使用Java 中一种特殊的机制来达到防止内存泄露的目的。
之前我们介绍过,Java 的 GC 机制是建立在跟踪内存的引用机制上的。而在此之前,我们所使用的引用都只是定义一个“ Object o; ”这样形式的。事实上,这只是 Java 引用机制中的一种默认情况,除此之外,还有其他的一些引用方式。通过使用这些特殊的引用机制,配合 GC 机制,就可以达到一些我们需要的效果。
Java中的几种引用方式
Java中有几种不同的引用方式,它们分别是:强引用、软引用、弱引用和虚引用。下面,我们首先详细地了解下这几种引用方式的意义。
强引用
在此之前我们介绍的内容中所使用的引用 都是强引用,这是使用最普遍的引用。如果一个对象具有强引用,那就类似于必不可少的生活用品,垃圾回收器绝不会回收它。当内存空 间不足,Java 虚拟机宁愿抛出 OutOfMemoryError 错误,使程序异常终止,也不会靠随意回收具有强引用的对象来解决内存不足问题。
软引用(SoftReference )
SoftReference 类的一个典型用途就是用于内存敏感的高速缓存。 SoftReference 的原理是:在保持对对象的引用时保证在 JVM 报告内存不足情况之前将清除所有的软引用。关键之处在于,垃圾收集器在运行时可能会(也可能不会)释放软可及对象。对象是否被释放取决于垃圾收集器的算法 以及垃圾收集器运行时可用的内存数量。
弱引用(WeakReference )
WeakReference 类的一个典型用途就是规范化映射( canonicalized mapping )。另外,对于那些生存期相对较长而且重新创建的开销也不高的对象来说,弱引用也比较有用。关键之处在于,垃圾收集器运行时如果碰到了弱可及对象,将释放 WeakReference 引用的对象。然而,请注意,垃圾收集器可能要运行多次才能找到并释放弱可及对象。
虚引用(PhantomReference )
PhantomReference 类只能用于跟踪对被引用对象即将进行的收集。同样,它还能用于执行 pre-mortem 清除操作。 PhantomReference 必须与 ReferenceQueue 类一起使用。需要 ReferenceQueue 是因为它能够充当通知机制。当垃圾收集器确定了某个对象是虚可及对象时, PhantomReference 对象就被放在它的 ReferenceQueue 上。将 PhantomReference 对象放在 ReferenceQueue 上也就是一个通知,表明 PhantomReference 对象引用的对象已经结束,可供收集了。这使您能够刚好在对象占用的内存被回收之前采取行动。 Reference与 ReferenceQueue 的配合使用。
GC、 Reference 与 ReferenceQueue 的交互
3、软引用和弱引用在添加到 ReferenceQueue 的时候,其指向真实内存的引用已经被置为空了,相关的内存也已经被释放掉了。而虚引用在添加到 ReferenceQueue 的时候,内存还没有释放,仍然可以对其进行访问。
- String str = new String( " hello " ); // ①
- ReferenceQueue < String > rq = new ReferenceQueue < String > (); // ②
- WeakReference < String > wf = new WeakReference < String > (str, rq); // ③
- str = null ; // ④取消"hello"对象的强引用
- String str1 = wf.get(); // ⑤假如"hello"对象没有被回收,str1引用"hello"对象
- // 假如"hello"对象没有被回收,rq.poll()返回null
- Reference <? extends String > ref = rq.poll(); // ⑥
在以上代码中,注意⑤⑥两处地方。假如“hello ”对象没有被回收 wf.get() 将返回“ hello ”字符串对象, rq.poll() 返回 null ;而加入“ hello ”对象已经被回收了,那么 wf.get() 返回 null , rq.poll() 返回 Reference 对象,但是此 Reference 对象中已经没有 str 对象的引用了 ( PhantomReference 则与WeakReference 、 SoftReference 不同 )。
引用机制与复杂数据结构的联合应用
了解了GC 机制、引用机制,并配合上 ReferenceQueue ,我们就可以实现一些防止内存溢出的复杂数据类型。
例如,SoftReference 具有构建 Cache 系统的特质,因此我们可以结合哈希表实现一个简单的缓存系统。这样既能保证能够尽可能多的缓存信息,又可以保证 Java 虚拟机不会因为内存泄露而抛出 OutOfMemoryError 。这种缓存机制特别适合于内存对象生命周期长,且生成内存对象的耗时比较长的情况,例如缓存列表封面图片等。对于一些生命周期较长,但是生成内存对象开销不大的情况,使用WeakReference 能够达到更好的内存管理的效果。
附SoftHashmap 的源码一份,相信看过之后,大家会对 Reference 机制的应用有更深入的理解。
原文地址: http://henryyang.iteye.com/blog/1188328
- package com. *** .widget;
- // : SoftHashMap.java
- import java.util. * ;
- import java.lang.ref. * ;
- import android.util.Log;
- public class SoftHashMap extends AbstractMap {
- /** The internal HashMap that will hold the SoftReference. */
- private final Map hash = new HashMap();
- /** The number of "hard" references to hold internally. */
- private final int HARD_SIZE;
- /** The FIFO list of hard references, order of last access. */
- private final LinkedList hardCache = new LinkedList();
- /** Reference queue for cleared SoftReference objects. */
- private ReferenceQueue queue = new ReferenceQueue();
- // Strong Reference number
- public SoftHashMap() { this ( 100 ); }
- public SoftHashMap( int hardSize) { HARD_SIZE = hardSize; }
- public Object get(Object key) {
- Object result = null ;
- // We get the SoftReference represented by that key
- SoftReference soft_ref = (SoftReference)hash.get(key);
- if (soft_ref != null ) {
- // From the SoftReference we get the value, which can be
- // null if it was not in the map, or it was removed in
- // the processQueue() method defined below
- result = soft_ref.get();
- if (result == null ) {
- // If the value has been garbage collected, remove the
- // entry from the HashMap.
- hash.remove(key);
- } else {
- // We now add this object to the beginning of the hard
- // reference queue. One reference can occur more than
- // once, because lookups of the FIFO queue are slow, so
- // we don't want to search through it each time to remove
- // duplicates.
- // keep recent use object in memory
- hardCache.addFirst(result);
- if (hardCache.size() > HARD_SIZE) {
- // Remove the last entry if list longer than HARD_SIZE
- hardCache.removeLast();
- }
- }
- }
- return result;
- }
- /** We define our own subclass of SoftReference which contains
- not only the value but also the key to make it easier to find
- the entry in the HashMap after it's been garbage collected. */
- private static class SoftValue extends SoftReference {
- private final Object key; // always make data member final
- /** Did you know that an outer class can access private data
- members and methods of an inner class? I didn't know that!
- I thought it was only the inner class who could access the
- outer class's private information. An outer class can also
- access private members of an inner class inside its inner
- class. */
- private SoftValue(Object k, Object key, ReferenceQueue q) {
- super (k, q);
- this .key = key;
- }
- }
- /** Here we go through the ReferenceQueue and remove garbage
- collected SoftValue objects from the HashMap by looking them
- up using the SoftValue.key data member. */
- public void processQueue() {
- SoftValue sv;
- while ((sv = (SoftValue)queue.poll()) != null ) {
- if (sv.get() == null ) {
- Log.e( " processQueue " , " null " );
- } else {
- Log.e( " processQueue " , " Not null " );
- }
- hash.remove(sv.key); // we can access private data!
- Log.e( " SoftHashMap " , " release " + sv.key);
- }
- }
- /** Here we put the key, value pair into the HashMap using
- a SoftValue object. */
- public Object put(Object key, Object value) {
- processQueue(); // throw out garbage collected values first
- Log.e( " SoftHashMap " , " put into " + key);
- return hash.put(key, new SoftValue(value, key, queue));
- }
- public Object remove(Object key) {
- processQueue(); // throw out garbage collected values first
- return hash.remove(key);
- }
- public void clear() {
- hardCache.clear();
- processQueue(); // throw out garbage collected values
- hash.clear();
- }
- public int size() {
- processQueue(); // throw out garbage collected values first
- return hash.size();
- }
- public Set entrySet() {
- // no, no, you may NOT do that!!! GRRR
- throw new UnsupportedOperationException();
- }
- }
什么是内存泄露?
Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任何引用所指向,则该对象会在被GC发现的时候被回收;另外,如果一组对象中只包含互相的引用,而没有来自它们外部的引用(例如有两个对象A和B互相持有引用,但没有任何外部对象持有指向A或B的引用),这仍然属于不可到达,同样会被GC回收。
Android中使用Handler造成内存泄露的原因
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
上面是一段简单的Handler的使用。当使用内部类(包括匿名类)来创建Handler的时候,Handler对象会隐式地持有一个外部类对象(通常是一个Activity)的引用(不然你怎么可能通过Handler来操作Activity中的View?)。而Handler通常会伴随着一个耗时的后台线程(例如从网络拉取图片)一起出现,这个后台线程在任务执行完毕(例如图片下载完毕)之后,通过消息机制通知Handler,然后Handler把图片更新到界面。然而,如果用户在网络请求过程中关闭了Activity,正常情况下,Activity不再被使用,它就有可能在GC检查时被回收掉,但由于这时线程尚未执行完,而该线程持有Handler的引用(不然它怎么发消息给Handler?),这个Handler又持有Activity的引用,就导致该Activity无法被回收(即内存泄露),直到网络请求结束(例如图片下载完毕)。另外,如果你执行了Handler的postDelayed()方法,该方法会将你的Handler装入一个Message,并把这条Message推到MessageQueue中,那么在你设定的delay到达之前,会有一条MessageQueue -> Message -> Handler -> Activity的链,导致你的Activity被持有引用而无法被回收。
内存泄露的危害
只有一个,那就是虚拟机占用内存过高,导致OOM(内存溢出),程序出错。对于Android应用来说,就是你的用户打开一个Activity,使用完之后关闭它,内存泄露;又打开,又关闭,又泄露;几次之后,程序占用内存超过系统限制,FC。
使用Handler导致内存泄露的解决方法
方法一:通过程序逻辑来进行保护。
1.在关闭Activity的时候停掉你的后台线程。线程停掉了,就相当于切断了Handler和外部连接的线,Activity自然会在合适的时候被回收。
2.如果你的Handler是被delay的Message持有了引用,那么使用相应的Handler的removeCallbacks()方法,把消息对象从消息队列移除就行了。
方法二:将Handler声明为静态类。
静态类不持有外部类的对象,所以你的Activity可以随意被回收。代码如下:
static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
但其实没这么简单。使用了以上代码之后,你会发现,由于Handler不再持有外部类对象的引用,导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用(WeakReference):
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}
将代码改为以上形式之后,就算完成了。
延伸:什么是WeakReference?
WeakReference弱引用,与强引用(即我们常说的引用)相对,它的特点是,GC在回收时会忽略掉弱引用,即就算有弱引用指向某对象,但只要该对象没有被强引用指向(实际上多数时候还要求没有软引用,但此处软引用的概念可以忽略),该对象就会在被GC检查到时回收掉。对于上面的代码,用户在关闭Activity之后,就算后台线程还没结束,但由于仅有一条来自Handler的弱引用指向Activity,所以GC仍然会在检查的时候把Activity回收掉。这样,内存泄露的问题就不会出现了。
相关阅读:
Android内存泄漏就这样产生了 http://www.linuxidc.com/Linux/2012-02/52952.htm
如何避免Android内存泄漏 http://www.linuxidc.com/Linux/2012-02/52951.htm
Android内存管理的原理--进程管理 http://www.linuxidc.com/Linux/2011-09/43556.htm
更多Android相关信息见Android 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=11