對(duì)于開發(fā)人員來說，設(shè)計(jì)模式有時(shí)候就是一道坎，但是設(shè)計(jì)模式又非常有用，過了這道坎，它可以讓你水平提高一個(gè)檔次。而在android開發(fā)中，必要的了解一些設(shè)計(jì)模式又是必須的，因?yàn)樵O(shè)計(jì)模式在Android源碼中，可以說是無處不在。對(duì)于想系統(tǒng)的學(xué)習(xí)設(shè)計(jì)模式的同學(xué)，這里推薦一本書，《大話設(shè)計(jì)模式》。
Android常用設(shè)計(jì)模式系列：
面向?qū)ο蟮幕A(chǔ)特征
面向?qū)ο蟮脑O(shè)計(jì)原則
單例模式
模板模式
適配器模式
工廠模式
代理模式
原型模式
策略模式
Build模式
觀察者模式
裝飾者模式
中介模式
門面模式
適配器模式
適配器模式是非常常見的設(shè)計(jì)模式之一，寫個(gè)筆記，記錄一下我的學(xué)習(xí)過程和心得。
首先了解一些適配器模式的定義。
將一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個(gè)類能夠在一起工作。
齋看定義，也是有點(diǎn)難理解的，還是要結(jié)合一個(gè)列子來進(jìn)行講，有助于我們更好的理解。
生活中的手機(jī)充電器就是一個(gè)適配器的例子，手機(jī)一般都是在5V的電壓下進(jìn)行充電，但是外部的電壓都是220V，那怎么辦，這就需要充電器去適配了，將220V的電壓轉(zhuǎn)換為5V。
根據(jù)適配器模式的定義，我們知道有三個(gè)角色參與了其中的工作：
- Adapter(適配器接口):即目標(biāo)角色，定義把其他類轉(zhuǎn)換為何種接口，也就是我們期望的接口。
- Adaptee(被適配角色):即源角色，一般是已存在的類，需要適配新的接口。
- ConcreteAdapter(具體適配器):實(shí)現(xiàn)適配器接口，把源角色接口轉(zhuǎn)換為目標(biāo)角色期望的接口。
那么，我們就開始實(shí)現(xiàn)吧
1. 創(chuàng)建適配器接口
現(xiàn)在我們需要定義一個(gè)220V轉(zhuǎn)換成5V的接口：
interface Adapter {//適配器類
int convert_5v();//裝換成5V
}
2. 創(chuàng)建被適配角色
被適配角色，一般是已存在的類，需要適配新的接口。生活中的220V電源無處不在：
public class Electric {// 電源
public int output_220v() {//輸出220V
return 220;
}
}
3. 創(chuàng)建具體適配器
我們需要一個(gè)具體適配器，這個(gè)適配器就是變壓器，能夠?qū)?20V轉(zhuǎn)為5V輸出：
public class PhoneAdapter implements Adapter {//手機(jī)適配器類
private Electric mElectric;//適配器持有源目標(biāo)對(duì)象
public PhoneAdapter(Electric electric) {//通過構(gòu)造方法傳入對(duì)象
mElectric = electric;
}
@Override
public int convert_5v() {
System.out.println("適配器開始工作：");
System.out.println("輸入電壓：" + mElectric.output_220v());
System.out.println("輸出電壓：" + 5);
return 5;
}
}
4. 客戶端測(cè)試：
public void test() {
Electric electric = new Electric();
System.out.println("默認(rèn)電壓：" + electric.output_220v());
Adapter phoneAdapter = new PhoneAdapter(electric);//傳遞一個(gè)對(duì)象給適配器
System.out.println("適配轉(zhuǎn)換后的電壓：" + phoneAdapter.convert_5v());
}
輸出結(jié)果：
默認(rèn)電壓：220
適配器開始工作：
輸入電壓：220
輸出電壓：5
適配轉(zhuǎn)換后的電壓：5
OK，這樣就完成了一個(gè)適配器模式的實(shí)現(xiàn)。
這里實(shí)現(xiàn)的例子只是適配器模式其中的一種，其實(shí)適配器模式分為
對(duì)象適配器模式
類適配器模式
這里我們講的是對(duì)象適配器的實(shí)現(xiàn)，類適配器的原理差不多的，只是類適配器模式?jīng)]什么優(yōu)勢(shì)，用得比較少，這里就不做詳細(xì)講解了。
接下來把他們做一下對(duì)比：
- 類適配器采用了繼承的方式來實(shí)現(xiàn);而對(duì)象適配器是通過傳遞對(duì)象來實(shí)現(xiàn)，這是一種組合的方式。
- 類適配器由于采用了繼承，可以重寫父類的方法;對(duì)象適配器則不能修改對(duì)象本身的方法等。
- 適配器通過繼承都獲得了父類的方法，客戶端使用時(shí)都會(huì)把這些方法暴露出去，增加了一定的使用成本;對(duì)象適配器則不會(huì)。
- 類適配器只能適配他的父類，這個(gè)父類的其他子類都不能適配到;而對(duì)象適配器可以適配不同的對(duì)象，只要這個(gè)對(duì)象的類型是同樣的。
- 類適配器不需要額外的引用;對(duì)象適配器需要額外的引用來保存對(duì)象。
廣泛應(yīng)用
適配器模式在android中的應(yīng)用非常廣，最常見的ListView、GridView、RecyclerView等的Adapter。而，我們經(jīng)常使用的ListView就是一個(gè)典范。
在使用ListView時(shí)，每一項(xiàng)的布局和數(shù)據(jù)都不一樣，但是最后輸出都可以看作是一個(gè)View，這就對(duì)應(yīng)了上面的適配器模式應(yīng)用場(chǎng)景的第三條：需要一個(gè)統(tǒng)一的輸出接口，而輸入端的接口不可預(yù)知。下面我們來看看ListView中的適配器模式。
首先我們來看看一般我們的Adapter類的結(jié)構(gòu)
class Adapter extends BaseAdapter {
private List<String> mDatas;
public Adapter(List<String> 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
}
//初始化數(shù)據(jù)
return convertView;
}
}
可以看出Adapter里面的接口主要是getCount()返回子View的數(shù)量，以及getView()返回我們填充好數(shù)據(jù)的View，ListView則通過這些接口來執(zhí)行具體的布局、緩存等工作。下面我們來簡(jiǎn)單看看ListView的實(shí)現(xiàn)。
首先這些getCount()等接口都在一個(gè)接口類Adapter里
public interface Adapter {
//省略其他的接口
int getCount();
Object getItem(int position);
long getItemId(int position);
View getView(int position, View convertView, ViewGroup parent);
//省略其他的接口
}
中間加了一個(gè)過渡的接口ListAdapter
public interface ListAdapter extends Adapter {
//接口省略
}
我們?cè)诰帉懳覀冏约旱腁dapter時(shí)都會(huì)繼承一個(gè)BaseAdapter，我們來看看BaseAdapter
public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
//BaseAdapter里面實(shí)現(xiàn)了ListAdapter的接口以及部分Adapter中的接口
//而像getCount()以及getView()這些接口則需要我們自己去實(shí)現(xiàn)
}
ListView的父類AbsListView中有ListAdapter接口，通過這個(gè)接口來調(diào)用getCount()等方法獲取View的數(shù)量等
public abstract class AbsListView extends AdapterView<ListAdapter> 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元素的個(gè)數(shù)
mItemCount = mAdapter.getCount();
}
}
}
從上面我們可以看出，AbsListView是一個(gè)抽象類，它里面封裝了一些固定的邏輯，如Adapter模式的應(yīng)用邏輯、布局的復(fù)用邏輯和布局子元素邏輯等。而具體的實(shí)現(xiàn)則是在子類ListView中。下面我們來看看ListView中是怎么處理每一個(gè)子元素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中會(huì)覆寫AbsListView中的layoutChildren()函數(shù)，在layoutChildren()中會(huì)根據(jù)不同的情況進(jìn)行布局，比如從上到下或者是從下往上。下面我們看看具體的布局方法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方法里面又會(huì)通過makeAndAddView()方法來獲取View，下面我們來看看makeAndAddView()方法的實(shí)現(xiàn)
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()方法里面就出現(xiàn)了緩存機(jī)制了，這是提升ListView加載效率的關(guān)鍵方法。我們看到，在獲取子View時(shí)會(huì)先從緩存里面找，也就是會(huì)從mRecycler中找，mRecycler是AbsListView中的一個(gè)用于緩存的RecycleBin類，來，我們看看緩存的實(shí)現(xiàn)
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保存在一個(gè)View數(shù)組里面，然后我們來看看如果沒有找到緩存的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;
}
可以看到?jīng)]有緩存的View直接就是從我們編寫的Adapter的getView()方法里面獲取。
以上我們簡(jiǎn)單看了ListView中適配器模式的應(yīng)用，從中我們可以看出ListView通過引入Adapter適配器類把那些多變的布局和數(shù)據(jù)交給用戶處理，然后通過適配器中的接口獲取需要的數(shù)據(jù)來完成自己的功能，從而達(dá)到了很好的靈活性。這里面最重要的接口莫過于getView()接口了，該接口返回一個(gè)View對(duì)象，而千變?nèi)f化的UI視圖都是View的子類，通過這樣一種處理就將子View的變化隔離了，保證了AbsListView類族的高度可定制化
總結(jié)
總結(jié)一下適配器模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
- 將目標(biāo)類和適配者類解耦，通過引入一個(gè)適配器類來重用現(xiàn)有的適配者類，無需修改原有結(jié)構(gòu)。
- 增加了類的透明性和復(fù)用性，將具體的業(yè)務(wù)實(shí)現(xiàn)過程封裝在適配者類中，對(duì)于客戶端類而言是透明的，而且提高了適配者的復(fù)用性，同一適配者類可以在多個(gè)不同的系統(tǒng)中復(fù)用。
- 靈活性和擴(kuò)展性都非常好，通過使用配置文件，可以很方便的更換適配器，也可以在不修改原有代碼的基礎(chǔ)上 增加新的適配器，完全符合開閉原則。
缺點(diǎn)：
- 一次最多只能適配一個(gè)適配者類，不能同時(shí)適配多個(gè)適配者。
- 適配者類不能為最終類，在C#中不能為sealed類
- 目標(biāo)抽象類只能為接口，不能為類，其使用有一定的局限性。
- 過多的使用適配器會(huì)讓系統(tǒng)顯得過于凌亂。如果不是很有必要，可以不適用適配器而是直接對(duì)系統(tǒng)進(jìn)行重構(gòu)
適用場(chǎng)景
- 系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要，即接口不兼容
- 想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的一些類一起工作
- 需要一個(gè)統(tǒng)一的輸出接口，而輸入端的接口不可預(yù)知
