有哪些在實際 Android 項目中用到的設計模式？

01-06

求個方向，看了好多代碼但是越看越混亂，公司只有我一個Android，沒人和我討論啊，求點撥！

Builder模式：比如AlertDialog.Builder；例簡單模擬Android中AlertDialog的Builder設計模式
適配器模式：比如GridView、ListView與Adapter；例Android設計模式系列(9)--SDK源碼之適配器模式
命令模式：比如Handler.post；例命令模式下的非同步消息處理（Handler,Message,Looper,Thread）
享元模式：比如Message.obtain；例Android和設計模式：享元模式
單例模式：比如InputMethodManager.getInstance，例Android源碼學習之單例模式應用
觀察者模式：比如ContentObserver；例Android中內容觀察者的使用---- ContentObserver類詳解
抽象工廠模式：比如BaseActivity，例Android Ap 開發設計模式第八篇：抽象工廠模式

我經常用到的就上面這些，設計模式並不是很神秘的東西，我們在寫程序的過程中可能每天都在用設計模式，只是沒有用設計模式的專業術語來稱呼它。我現在越來越感覺到編程方法和設計模式非常重要，因為它能夠指導你寫出較高質量的代碼、避免一些前人遇到過的坑，當你借用這些方法和模式寫出一段代碼，提供給別人使用和回味的時候會很有成就感。程序員都應該去有意地接觸這方面的知識，比如高內聚、低耦合、封裝變化，在設計介面的時候都是非常重要的原則。

關於Android項目中可以用到的設計模式，可以參見：

simple-android-framework-exchange/android_design_patterns_analysis · GitHub
Android設計模式系列

謝邀。

Android的設計模式實際上也就是Java的設計模式，題主想看設計模式在實際工程中的應用，那建議題主去看 JUnit 的源碼或者分析。

JUnit是Java中著名的單元測試框架，其作者是兩位世界級的軟體工程大師：GOF四人幫之一的Erich Gamma和敏捷開發的開創者之一Kent Beck。JUnit很好的體現了兩位的程序設計思想，其中也非常靈活的運用了多種設計模式，如果深入學習一定會能使題主靈活的掌握和使用各類設計模式，設計模式就23種，關鍵是看你怎麼使用。

以下是對於命令模式在JUnit中的使用分析：

3.2 Command（命令）模式

3.2.1 問題

首先要明白，JUnit是一個測試framework，測試人員只需開發測試用例。然後把這些測試用例組成請求(有時可能是一個或者多個)，發送到JUnit FrameWork，然後由JUnit執行測試，最後報告詳細測試結果。其中包括執行的時間，錯誤方法，錯誤位置等。這樣測試用例的開發人員就不需知道JUnit內部的細節，只要符合它定義的請求格式即可。從JUnit的角度考慮，它並不需要知道請求TestCase的操作信息，僅把它當作一種命令來執行，然後把執行測試結果發給測試人員。這樣就使JUnit 框架和TestCase的開發人員獨立開來，使得請求的一方不必知道接收請求一方的詳細信息，更不必知道是怎樣被接收，以及怎樣被執行的，實現系統的松耦合。

3.2.2 模式的選擇

Command（命令）模式則能夠比較好地滿足需求（請參見Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995）。摘引其意圖（intent），將一個請求封裝成一個對象，從而使你可用不同的請求對客戶進行參數化；對請求進行排隊或記錄請求日誌...Command告訴我們可以為一個操作生成一個對象並給出它的一個execute（執行）方法。

3.2.3 實現

為了實現Command模式，首先定義了一個介面Test,其中Run便是Command的Execute方法。然後又使用Default Adapter模式為這個介面提供了預設實現TestCase抽象類，這樣我們開發人員就可以從這個預設實現進行集成，而不必從Test介面進行實現。

我們首先來分析Test介面。它存在一個是countTestCases方法，它來統計這次測試有多少個TestCase，另外一個方法就是我們的Command模式的Excecute方法，這裡命名為run。還有一個參數TestResult，它來統計測試結果

public interface Test { /** * Counts the number of test cases that will be run by this test. */ public abstract int countTestCases(); /** * Runs a test and collects its result in a TestResult instance. */ public abstract void run(TestResult result); }

TestCase是該介面的抽象實現，它增加了一個測試名稱，因為每一個TestCase在創建時都要有一個名稱，因此若一個測試失敗了，你便可識別出是哪個測試失敗。

public abstract class TestCase extends Assert implements Test { /** * the name of the test case */ private String fName; public void run(TestResult result) { result.run(this); } }

這樣我們的開發人員，編寫測試用例時，只需繼承TestCase，來完成run方法即可，然後JUnit獲得測試用例，執行它的run方法，把測試結果記錄在TestResult之中，目前可以暫且這樣理解。

3.2.4 效果

下面來考慮經過使用Command模式後給系統的架構帶來了那些效果：

Command模式將實現請求的一方（TestCase開發）和調用一方（JUnit Fromwork）進行解藕
Command模式使新的TestCase很容易的加入，無需改變已有的類，只需繼承TestCase類即可，這樣方便了測試人員
Command模式可以將多個TestCase進行組合成一個複合命令，實際你將看到TestSuit就是它的複合命令，當然它使用了Composite模式
Command模式容易把請求的TestCase組合成請求隊列，這樣使接收請求的一方（Junit Fromwork）,容易的決定是否執行請求，或者一旦發現測試用例失敗或者錯誤可以立刻停止進行報告
Command模式可以在需要的情況下，方便的實現對請求的Undo和Redo，以及記錄Log,這部分目前在JUnit中還沒有實現，將來是很容易加入的

分析出處：UML軟體工程組織

有句話是這麼說的：語言造下的孽，要用設計模式來還。這句話雖然有些絕對，但是確實有一定道理。你看，Python就很少用什麼設計模式（可能是我見識少？）。題主之所以會對Android如此困惑，還不是因為Android大部分代碼是Java寫的。建議題主Google下Java設計模式，一下午就看完了。Android設計模式不會比這更複雜。

但是一份代碼Android也很少會有多少值得困惑的地方，設計模式常用的也就那幾種。我猜測題主是個新手，對代碼不熟悉很可能是對Android系統架構不熟悉引起的，比如會經常奇怪「咦我的按鈕樣式明明沒有定製為什麼好像和系統樣式不太一樣」一類問題（實際上可能是自定義了theme）。這時候有兩個建議和一個技巧：

1、對照Android developers guideline仔仔細細看至少一周目。不要求每個類、每個介面都熟悉，至少要看完重要的幾個，比如四大組件，UI樣式。看的時候裡邊有重要鏈接可以點進去。

2、在完成第一步情況下，再去看GitHub上邊優秀開源代碼，並對代碼嘗試修改，看看能否達到修改預期效果。如果沒有，出門左轉stackoverflow。

一個技巧（不知道算不算奇技淫巧）：

如果對代碼毫無頭緒，可以從界面入手：將apk裝上，然後找到想要研究的界面，提取這個界面的關鍵wording（比如「添加好友」這樣的wording），然後到string.xml裡邊搜（只要寫這段程序的程序員稍微靠一點譜，都不會把這樣的wording放到Java代碼中），搜到這個欄位定義（比如是contact_ui_add_friend)，然後在IDE裡邊全局搜這個欄位。這樣基本可以找到這個界面所在的XML，進而找到activity，再從這個界面下手，一點點從界面元素開始了解整個界面以及邏輯架構。

單例

組合

工廠

命令

適配

觀察者

策略

代理

狀態機

最近在看，github的開源項目專門講解android 中的設計模式

GitHub - simple-android-framework-exchange/android_design_patterns_analysis: Android源碼設計模式分析項目

肯定用啊，最多的一點，listview中用到adapter模式對吧

然後還有一個eventbus用到了observer觀察者模式對吧

仔細觀察你就會發現好多的

先看看設計模式相關的書吧比如headfirst等先了解設計模式有哪些然後結合代碼你就會發現設計模式很多地方都有涉及。比如最常見的單例模式觀察者模式。 java io用到裝飾起模式 listview的adapter用到的裝飾起模式。構建複雜些對象的build模式。 okhttp請求過程的責任鏈模式。等等理論結合實際代碼相信你在這方面會有一定積累。

其實，在寫安卓應用的時候已經不由自主地在運用一些設計模式了，正如樓上提到的builder，observer等等。其他的就要看java功底了，說到底，還是java語言的設計模式。

MVC？