建造者模式

建造者模式最明顯的標誌就是Build類，而在Android中最常用的就是Dialog的構建，Notification的構建也是標準的建造者模式。

建造者模式很好理解，如果一個類的構造需要很多引數，而且這些引數並不都是必須的，那麼這種情況下就比較適合Builder。

比如構建一個AlertDialog，標題、內容、取消按鈕、確定按鈕、中立按鈕，你可能只需要單獨設定幾個屬性即可；另外在我的OkHttpPlus專案中，構造一個Http請求也是這樣的，有可能你只需要設定URL，有可能需要新增請求引數、Http Header等，這個時候建造者模式也是比較合適的。

單例模式

單例在Android

開發中經常用到，但是表現形式可能不太一樣。

以ActivityManager等系統服務來說，是通過靜態程式碼塊的形式實現單例，在首次載入類檔案時，生成單例物件，然後儲存在Cache中，之後的使用都是直接從Cache中獲取。

classContextImplextendsContext {

    static {

        registerService(ACTIVITY_SERVICE, new ServiceFetcher() {

                
 
public Object createService(ContextImpl ctx) {

                    returnnew ActivityManager(ctx.getOuterContext(),       ctx.mMainThread.getHandler());

                }});
 

    }

}

當然，還有更加明顯的例子，比如AccessibilityManager內部自己也保證了單例，使用getInstance獲取單例物件。

 publicstatic AccessibilityManager getInstance(Context context) {

        synchronized (sInstanceSync) {

            if (sInstance == null) {

               ......

                IBinder iBinder = ServiceManager.getService(Context.ACCESSIBILITY_SERVICE);

                IAccessibilityManager service = iBinder == null

                        ? null : IAccessibilityManager.Stub.asInterface(iBinder);

                sInstance = new AccessibilityManager(context, service, userId);

            }

        }

        return sInstance;

    }

除此之外，還有一些偽單例，比如Application，預設情況下在一個程序中只存在一個例項，但是Application不能算是單例，因為它的構造方法未私有，你可以生成多個Application例項，但是沒有用，你沒有通過attach()繫結相關資訊，沒有上下文環境。

publicApplication() {

        super(null);

    }

單例的使用場景也很簡單，就是一個App只需要存在一個類例項的情況，或者是類的初始化操作比較耗費資源的情況。在很多開源框架中，我們只需要一個物件即可完成工作，比如各種網路框架和圖片載入庫。

除此之外，因為單例的實現方式很多，比如懶漢式、餓漢式、靜態內部類、雙重鎖檢查、列舉等方式，所以要清楚每種實現方式的主要特點和使用場景。

原型模式

原型模式在開發中使用的並不多，但是在原始碼中卻有所體現。

書中以Intent介紹了原型模式，是通過實現Cloneable介面來做的

publicclassIntentimplementsParcelable, Cloneable {

    @Override

        public Object clone() {

         returnnew Intent(this);

        }

    }

其實這樣來看的話，原型模式也比較好理解，就是你想更快的獲取到一個相同屬性的物件，那麼就可以使用原型模式，比如這裡就獲取到了一個Intent物件，Intent裡面的屬性與被clone的相同，但是兩者並無關聯，可以單獨使用。

除了實現Cloneable介面，你完全可以自己定義一個方法，來獲取一個物件。我這裡以PhoneLayoutInflater為例子介紹。

PhoneLayoutInflater是LayoutInflater的子類，如果我們在Activity中獲取LayoutInflate的話，是通過下面方法

 @Override public Object getSystemService(Stringname) {

        if (LAYOUT_INFLATER_SERVICE.equals(name)){

            if(mInflater == null) {

                mInflater = LayoutInflater.from(getBaseContext()).cloneInContext(this);

            }

            returnmInflater;

        }

        returngetBaseContext().getSystemService(name);

    }

可以看到，如果為null，就會呼叫cloneInContext()，這個方法在LayoutInflate是抽象方法，具體實現在PhoneLayoutInflater中

  publicLayoutInflater cloneInContext(Context newContext) {

        returnnewPhoneLayoutInflater(this, newContext);

    }

可以看到，這也是一個原型模式，所以我們不要太糾結於形式，更重要的是理解這樣做的好處。

除了在原始碼中可以看到原型模式，在開源框架中也可以看到，比如OkHttpClient中就存在著下面的方法

/** Returns a shallow copy of thisOkHttpClient. */

  @OverridepublicOkHttpClient clone() {

    returnnewOkHttpClient(this);

  }

可以看到，實現和前面的完全相同，也是new了一個物件返回，因為OkHttpClient的構造過程比較複雜，引數眾多，所以用這種方式來直接生成新物件，成本很低，而且能保留之前物件的引數設定。

工廠方法模式

書中對於工廠方法模式的一個觀點很新奇，就是Activity.onCreate()可以看做是工廠方法模式，來生成不同的View物件填充介面。

但是我對這個說法不太苟同，原因有兩點：一是這種形式不太符合工廠方法，沒有抽象，沒有實現，不符合一般格式，也不是靜態方法，不可看做是靜態工廠方法；二是沒有以生成物件為結果，即不是return view來生成物件，只是通過setContentView()來設定了屬性而已。這就像是給一個Activity設定了背景顏色一樣。當然，設計模式這東西一個人有一個人的看法。

靜態工廠方法在Android中比較明顯的例子應該就是BitmapFactory了，通過各種decodeXXX()就可以從不同渠道獲得Bitmap物件，這裡不再贅述。

策略模式

在書中策略模式講得非常好，結合動畫的插值器用法，我們可以很好的理解策略模式的形式和用法。

在我看來，策略模式就相當於一個影碟機，你往裡面插什麼碟子，就能放出什麼電影。

同樣，在OkHttpPlus的封裝中，為了對網路返回值進行解析，我使用了策略模式。當然我寫程式碼的時候還不知道策略模式，是寫完了之後突然想到，這就是策略模式啊！

策略模式的精髓就在於，你傳入一個類，後面的處理就能按照這個類的實現去做。以動畫為例，設定不同的插值器物件，就可以得到不同的變化曲線；以返回值解析為例，傳入什麼樣的解析器，就可以把二進位制資料轉換成什麼格式的資料，比如String、Json、XML。

責任鏈模式

書中對於責任鏈模式選取的例子非常有代表性，那就是Android的觸控機制，這個看法讓我從另一個維度去理解Android中的觸控事件傳遞。

我在這裡提到這個模式，並不想說太多，只是簡單的推薦你讀一下這一章的內容，相信你也會有收穫的。

觀察者模式

Android中的觀察者模式應該是用的非常頻繁的一種模式了，對於這個模式的使用場景就一句話：你想在某個物件發生變化時，立刻收到通知。

書中介紹觀察者模式使用的是ListView的Adapter為例子，我之前知道Adapter屬於介面卡模式，不知道這裡還有觀察者模式的身影，學到了。

Android裡面的各種監聽器，也都屬於觀察者模式，比如觸控、點選、按鍵等，ContentProvider和廣播接收者也有觀察者模式的身影，可以說是無處不在。

除此之外，現在很多基於觀察者模式的第三方框架也是非常多，比如EventBus、RxJava等等，都是對觀察者模式的深入使用，感興趣的同學可以研究一下。

模板方法模式

這個模式我之前見的比較少，但是理解之後，就會發現這個模式很簡單。

我覺得，模板方法模式的使用場景也是一句話：流程確定，具體實現細節由子類完成。

這裡要關注一下『流程』這個關鍵字，隨便拿一個抽象類，都符合”具體實現細節由子類完成”的要求，關鍵就在於是否有流程，有了流程，就叫模板方法模式，沒有流程，就是抽象類的實現。

書中講這個模式用的是AsyncTask，各個方法之間的執行符合流程，具體實現由我們完成，非常經典。

另外一個方面，Activity的生命週期方法可以看做是模板方法模式，各個生命週期方法都是有順序的，具體實現我們可以重寫，是不是和前面的要求很符合？關於這方面的理解，可以參考我的這篇文章：對Activity生命週期的理解。

除了Android裡面的模板方法模式，在其他開源專案中也存在著這個模式的運用。比如鴻洋的OkHttp-Utils專案，就是模板方法模式的典型實現。將一個Http請求的過程分割成幾部分，比如獲取URL，獲取請求頭，拼接請求資訊等步驟，這幾個步驟之前有先後順序，就可以這樣來做。

代理模式和裝飾器模式

之所以把這兩個放在一起說，是因為這兩種模式很像，所以這裡簡單介紹下他們之間的區別，主要有兩點。

1.               裝飾器模式關注於在一個物件上動態的新增方法，而代理模式關注於控制對物件的訪問

2.               代理模式，代理類可以對它的客戶隱藏一個物件的具體資訊。因此，當使用代理模式的時候，我們常常在一個代理類中建立一個物件的例項。而當我們使用裝飾器模式的時候，通常的做法是將原始物件作為一個引數傳給裝飾者的構造器

這兩句話可能不太好理解，沒關係，下面看個例子。

代理模式會持有被代理物件的例項，而這個例項一般是作為成員變數直接存在於代理類中的，即不需要額外的賦值。

比如說WindowManagerImpl就是一個代理類，雖然名字上看著不像，但是它代理的是WindowManagerGlobal物件。從下面的程式碼中就可以看出來。

publicfinalclassWindowManagerImplimplementsWindowManager {

    privatefinalWindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();

    privatefinal DisplaymDisplay;

    privatefinal WindowmParentWindow;

 

    ......

 

    @Override

    publicvoidaddView(Viewview, ViewGroup.LayoutParams params) {

        mGlobal.addView(view, params, mDisplay,mParentWindow);

    }

 

    @Override

    publicvoidupdateViewLayout(Viewview, ViewGroup.LayoutParams params) {

        mGlobal.updateViewLayout(view, params);

    }

 

    @Override

    publicvoidremoveView(Viewview) {

        mGlobal.removeView(view, false);

    }

 

    @Override

    publicvoidremoveViewImmediate(Viewview) {

        mGlobal.removeView(view, true);

    }

 

    @Override

    public Display getDefaultDisplay() {

        return mDisplay;

    }

}

從上面的程式碼中可以看出，大部分WindowManagerImpl的方法都是通過WindowManagerGlobal實現的，而WindowManagerGlobal物件不需要額外的賦值，就存在於WindowManagerImpl中。另外，WindowManagerGlobal中其實有大量的方法，但是通過WindowManagerImpl代理之後，都沒有暴露出來，對開發者是透明的。

我們再來看一下裝飾器模式。裝飾器模式的目的不在於控制訪問，而是擴充套件功能，相比於繼承基類來擴充套件功能，使用裝飾器模式更加的靈活。

書中是以Context和它的包裝類ContextWrapper講解的，也非常的典型，我這裡就不在贅述了，貼出一些程式碼來說明裝飾器模式的形式。

publicclassContextWrapperextendsContext {

    Context mBase;

 

    publicContextWrapper(Contextbase) {

        mBase = base;

    }

}

但是還有一個問題，就是在ContextWrapper中，所有方法的實現都是通過mBase來實現的，形式上是對上號了，說好的擴充套件功能呢？

功能擴充套件其實是在ContextWrapper的子類ContextThemeWrapper裡面。

在ContextWrapper裡面，獲取系統服務是直接通過mBase完成的

@Override

    public Object getSystemService(Stringname) {

        returnmBase.getSystemService(name);

    }

   但是在ContextThemeWrapper裡面，對這個方法進行了重寫，完成了功能擴充套件

@Override public Object getSystemService(Stringname) {

        if(LAYOUT_INFLATER_SERVICE.equals(name)) {

            if(mInflater == null) {

                mInflater = LayoutInflater.from(getBaseContext()).cloneInContext(this);

            }

            returnmInflater;

        }

        returngetBaseContext().getSystemService(name);

    }

當然，如果不存在功能擴充套件就不算是裝飾器模式了嗎？其實設計模式本來就是『仁者見仁，智者見智』的事情，只要你能理解這個意思就好。

外觀模式

外觀模式可能看到的比較少，但是其實不經意間你就用到了。

這裡以我的一個開源專案KLog來說吧，在最開始寫這個類的時候，就只有KLog這一個類，完成基本的Log列印功能，後來又添加了JSON解析、XML解析、Log資訊儲存等功能，這個時候一個類就不太合適了，於是我把JSON、XML、FILE操作相關的程式碼抽取到單獨的類中，比如JSON列印的程式碼

publicclass JsonLog {

 

    publicstaticvoidprintJson(Stringtag, String msg, String headString) {

 

        String message;

 

        try {

            if(msg.startsWith("{")) {

                JSONObject jsonObject = newJSONObject(msg);

                message =jsonObject.toString(KLog.JSON_INDENT);

            } elseif(msg.startsWith("[")) {

                JSONArray jsonArray = newJSONArray(msg);

                message =jsonArray.toString(KLog.JSON_INDENT);

            } else {

                message = msg;

            }

        } catch(JSONException e) {

            message = msg;

        }

 

        Util.printLine(tag, true);

        message = headString +KLog.LINE_SEPARATOR + message;

        String[] lines =message.split(KLog.LINE_SEPARATOR);

        for (Stringline : lines) {

            Log.d(tag, "║ " + line);

        }

        Util.printLine(tag, false);

    }

}

程式碼很簡單，就一個方法，但是在使用的時候，無論列印哪種格式，都是這樣使用的

//普通列印

 KLog.d(LOG_MSG);

 //JSON格式列印

 KLog.json(JSON);

 //XML格式列印

 KLog.xml(XML);

可以看到，雖然功能不同，但是都通過KLog這個類進行了封裝，使用者只知道用KLog這個類能完成所有需求即可，完全不需要知道程式碼實現是幾個類完成的。

實際上，在KLog內部，是多個類共同完成列印功能的。

 private static voidprintLog(int type, String tagStr, Object...objects) {

 

        if(!IS_SHOW_LOG) {

            return;

        }

 

        String[]contents = wrapperContent(tagStr, objects);

        String tag =contents[0];

        String msg =contents[1];

        StringheadString = contents[2];

 

        switch (type) {

            case V:

            case D:

            case I:

            case W:

            case E:

            case A:

                BaseLog.printDefault(type, tag,headString + msg);

                break;

            caseJSON:

                JsonLog.printJson(tag, msg,headString);

                break;

            case XML:

                XmlLog.printXml(tag, msg,headString);

                break;

        }

    }

但是通過外觀模式，這些細節對使用者隱藏了，這樣如果以後我想更換JSON的解析方式，使用者的程式碼不需要任何改動，這也是這個設計模式的優勢所在。

總結

嘮嘮叨叨的，總算是把這幾種設計模式介紹完了，看完這篇文章，你應該就會發現其實Android中的設計模式確實到處都存在，不是缺少設計模式，而是缺少一雙發現的眼睛。

當然，設計模式的提出是為了解決特定的問題，當我們遇到類似問題的時候，可以從設計模式的角度思考和解決問題，這應該是我最大的收穫吧