对于开发人员来说，设计模式有时候就是一道坎，但是设计模式又非常有用，过了这道坎，它可以让你水平提高一个档次。而在android开发中，必要的了解一些设计模式又是必须的，因为设计模式在Android源码中，可以说是无处不在。对于想系统的学习设计模式的同学，这里推荐一本书，《大话设计模式》。

Android常用设计模式系列：

适配器模式

适配器模式是非常常见的设计模式之一，写个笔记，记录一下我的学习过程和心得。

首先了解一些适配器模式的定义。

将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

斋看定义，也是有点难理解的，还是要结合一个列子来进行讲，有助于我们更好的理解。

生活中的手机充电器就是一个适配器的例子，手机一般都是在5V的电压下进行充电，但是外部的电压都是220V，那怎么办，这就需要充电器去适配了，将220V的电压转换为5V。

根据适配器模式的定义，我们知道有三个角色参与了其中的工作：

Adapter(适配器接口):即目标角色，定义把其他类转换为何种接口，也就是我们期望的接口。

Adaptee(被适配角色):即源角色，一般是已存在的类，需要适配新的接口。

ConcreteAdapter(具体适配器):实现适配器接口，把源角色接口转换为目标角色期望的接口。

那么，我们就开始实现吧

1. 创建适配器接口

现在我们需要定义一个220V转换成5V的接口：

interface Adapter {//适配器类

int convert_5v();//装换成5V

}

2. 创建被适配角色

被适配角色，一般是已存在的类，需要适配新的接口。生活中的220V电源无处不在：

public class Electric {// 电源

public int output_220v() {//输出220V

return 220;

}

}

3. 创建具体适配器

我们需要一个具体适配器，这个适配器就是变压器，能够将220V转为5V输出：

public class PhoneAdapter implements Adapter {//手机适配器类

private Electric mElectric;//适配器持有源目标对象

public PhoneAdapter(Electric electric) {//通过构造方法传入对象

mElectric = electric;

}

@Override

public int convert_5v() {

System.out.println("适配器开始工作：");

System.out.println("输入电压：" + mElectric.output_220v());

System.out.println("输出电压：" + 5);

return 5;

}

}

4. 客户端测试：

public void test() {

Electric electric = new Electric();

System.out.println("默认电压：" + electric.output_220v());

Adapter phoneAdapter = new PhoneAdapter(electric);//传递一个对象给适配器

System.out.println("适配转换后的电压：" + phoneAdapter.convert_5v());

}

输出结果：

默认电压：220

适配器开始工作：

输入电压：220

输出电压：5

适配转换后的电压：5

OK，这样就完成了一个适配器模式的实现。

这里实现的例子只是适配器模式其中的一种，其实适配器模式分为

对象适配器模式

类适配器模式

这里我们讲的是对象适配器的实现，类适配器的原理差不多的，只是类适配器模式没什么优势，用得比较少，这里就不做详细讲解了。

接下来把他们做一下对比：

类适配器采用了继承的方式来实现;而对象适配器是通过传递对象来实现，这是一种组合的方式。

类适配器由于采用了继承，可以重写父类的方法;对象适配器则不能修改对象本身的方法等。

适配器通过继承都获得了父类的方法，客户端使用时都会把这些方法暴露出去，增加了一定的使用成本;对象适配器则不会。

类适配器只能适配他的父类，这个父类的其他子类都不能适配到;而对象适配器可以适配不同的对象，只要这个对象的类型是同样的。

类适配器不需要额外的引用;对象适配器需要额外的引用来保存对象。

广泛应用

适配器模式在android中的应用非常广，最常见的ListView、GridView、RecyclerView等的Adapter。而，我们经常使用的ListView就是一个典范。

在使用ListView时，每一项的布局和数据都不一样，但是最后输出都可以看作是一个View，这就对应了上面的适配器模式应用场景的第三条：需要一个统一的输出接口，而输入端的接口不可预知。下面我们来看看ListView中的适配器模式。

首先我们来看看一般我们的Adapter类的结构

class Adapter extends BaseAdapter {

private List mDatas;

public Adapter(List datas) {

mDatas = datas;

}

@Override

public int getCount() {

return mDatas.size();

}

@Override

public long getItemId(int position) { return position; }

@Override

public Object getItem(int position) { return mDatas.get(position);}

@Override

public View getView(int position, View convertView, ViewGroup parent) {

if (convertView == null) {

//初始化View

}

//初始化数据

return convertView;

}

}

可以看出Adapter里面的接口主要是getCount()返回子View的数量，以及getView()返回我们填充好数据的View，ListView则通过这些接口来执行具体的布局、缓存等工作。下面我们来简单看看ListView的实现。

首先这些getCount()等接口都在一个接口类Adapter里

public interface Adapter {

//省略其他的接口

int getCount();

Object getItem(int position);

long getItemId(int position);

View getView(int position, View convertView, ViewGroup parent);

//省略其他的接口

}

中间加了一个过渡的接口ListAdapter

public interface ListAdapter extends Adapter {

//接口省略

}

我们在编写我们自己的Adapter时都会继承一个BaseAdapter，我们来看看BaseAdapter

public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {

//BaseAdapter里面实现了ListAdapter的接口以及部分Adapter中的接口

//而像getCount()以及getView()这些接口则需要我们自己去实现

}

ListView的父类AbsListView中有ListAdapter接口，通过这个接口来调用getCount()等方法获取View的数量等

public abstract class AbsListView extends AdapterView implements TextWatcher,

ViewTreeObserver.OnGlobalLayoutListener, Filter.FilterListener,

ViewTreeObserver.OnTouchModeChangeListener,

RemoteViewsAdapter.RemoteAdapterConnectionCallback {

/**

* The adapter containing the data to be displayed by this view

*/

ListAdapter mAdapter;

@Override

protected void onAttachedToWindow() {

super.onAttachedToWindow();

final ViewTreeObserver treeObserver = getViewTreeObserver();

treeObserver.addOnTouchModeChangeListener(this);

if (mTextFilterEnabled && mPopup != null && !mGlobalLayoutListenerAddedFilter) {

treeObserver.addOnGlobalLayoutListener(this);

}

if (mAdapter != null && mDataSetObserver == null) {

mDataSetObserver = new AdapterDataSetObserver();

mAdapter.registerDataSetObserver(mDataSetObserver);

// Data may have changed while we were detached. Refresh.

mDataChanged = true;

mOldItemCount = mItemCount;

//通过getCount()获取View元素的个数

mItemCount = mAdapter.getCount();

}

}

}

从上面我们可以看出，AbsListView是一个抽象类，它里面封装了一些固定的逻辑，如Adapter模式的应用逻辑、布局的复用逻辑和布局子元素逻辑等。而具体的实现则是在子类ListView中。下面我们来看看ListView中是怎么处理每一个子元素View的。

@Override

protected void layoutChildren() {

//省略其他代码

case LAYOUT_FORCE_BOTTOM:

sel = fillUp(mItemCount - 1, childrenBottom);

adjustViewsUpOrDown();

break;

case LAYOUT_FORCE_TOP:

mFirstPosition = 0;

sel = fillFromTop(childrenTop);

adjustViewsUpOrDown();

break;

//省略其他代码

}

在ListView中会覆写AbsListView中的layoutChildren()函数，在layoutChildren()中会根据不同的情况进行布局，比如从上到下或者是从下往上。下面我们看看具体的布局方法fillUp方法。

private View fillUp(int pos, int nextBottom) {

//省略其他代码

while (nextBottom > end && pos >= 0) {

// is this the selected item?

boolean selected = pos == mSelectedPosition;

View child = makeAndAddView(pos, nextBottom, false, mListPadding.left, selected);

nextBottom = child.getTop() - mDividerHeight;

if (selected) {

selectedView = child;

}

pos--;

}

mFirstPosition = pos + 1;

setVisibleRangeHint(mFirstPosition, mFirstPosition + getChildCount() - 1);

return selectedView;

}

这里我们看到fillUp方法里面又会通过makeAndAddView()方法来获取View，下面我们来看看makeAndAddView()方法的实现

private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,

boolean selected) {

if (!mDataChanged) {

// Try to use an existing view for this position.

final View activeView = mRecycler.getActiveView(position);

if (activeView != null) {

// Found it. We're reusing an existing child, so it just needs

// to be positioned like a scrap view.

setupChild(activeView, position, y, flow, childrenLeft, selected, true);

return activeView;

}

}

// Make a new view for this position, or convert an unused view if

// possible.

final View child = obtainView(position, mIsScrap);

// This needs to be positioned and measured.

setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);

return child;

}

不知道大家看到这里想到了什么？

makeAndAddView()方法里面就出现了缓存机制了，这是提升ListView加载效率的关键方法。我们看到，在获取子View时会先从缓存里面找，也就是会从mRecycler中找，mRecycler是AbsListView中的一个用于缓存的RecycleBin类，来，我们看看缓存的实现

class RecycleBin {

private View[] mActiveViews = new View[0];

/**

* Get the view corresponding to the specified position. The view will be removed from

* mActiveViews if it is found.

*

* @param position The position to look up in mActiveViews

* @return The view if it is found, null otherwise

*/

View getActiveView(int position) {

int index = position - mFirstActivePosition;

final View[] activeViews = mActiveViews;

if (index >=0 && index < activeViews.length) {

final View match = activeViews[index];

activeViews[index] = null;

return match;

}

return null;

}

}

由上可见，缓存的View保存在一个View数组里面，然后我们来看看如果没有找到缓存的View，ListView是怎么获取子View的，也就是上面的obtainView()方法。需要注意的是obtainView()方法是在AbsListView里面。

View obtainView(int position, boolean[] outMetadata) {

//省略其他代码

final View scrapView = mRecycler.getScrapView(position);

final View child = mAdapter.getView(position, scrapView, this);

if (scrapView != null) {

if (child != scrapView) {

// Failed to re-bind the data, return scrap to the heap.

mRecycler.addScrapView(scrapView, position);

} else if (child.isTemporarilyDetached()) {

outMetadata[0] = true;

// Finish the temporary detach started in addScrapView().

child.dispatchFinishTemporaryDetach();

}

}

//省略其他代码

return child;

}

可以看到没有缓存的View直接就是从我们编写的Adapter的getView()方法里面获取。

以上我们简单看了ListView中适配器模式的应用，从中我们可以看出ListView通过引入Adapter适配器类把那些多变的布局和数据交给用户处理，然后通过适配器中的接口获取需要的数据来完成自己的功能，从而达到了很好的灵活性。这里面最重要的接口莫过于getView()接口了，该接口返回一个View对象，而千变万化的UI视图都是View的子类，通过这样一种处理就将子View的变化隔离了，保证了AbsListView类族的高度可定制化

总结

总结一下适配器模式的优缺点

优点：

将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无需修改原有结构。

增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而言是透明的，而且提高了适配者的复用性，同一适配者类可以在多个不同的系统中复用。

灵活性和扩展性都非常好，通过使用配置文件，可以很方便的更换适配器，也可以在不修改原有代码的基础上 增加新的适配器，完全符合开闭原则。

缺点：

一次最多只能适配一个适配者类，不能同时适配多个适配者。

适配者类不能为最终类，在C#中不能为sealed类

目标抽象类只能为接口，不能为类，其使用有一定的局限性。

过多的使用适配器会让系统显得过于凌乱。如果不是很有必要，可以不适用适配器而是直接对系统进行重构

适用场景

系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容

想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的一些类一起工作

需要一个统一的输出接口，而输入端的接口不可预知