這篇文章主要內(nèi)容來自于之前我講的一個PPT文檔，現(xiàn)在將其整理如下。歡迎指正。以下的內(nèi)容都是來自于我自身的經(jīng)驗，歡迎大家多提自己的建議。
模式的定義：
每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心。通過這種方式，你可以無數(shù)次地使用那些已有的解決方案，無需在重復相同的工作。
什么是設計模式？
設計模式是在某種特別的情況下，針對某種問題的某種典型、通用的解決方法。
我們是需要適當了解并學習一些設計模式，在程序開發(fā)過程中，總是會涉及到一些框架設計，模塊設計之類的東西，如果能很好理解并運行設計模式，你所設計的模塊或框架將會要穩(wěn)定得多，因為這些設計模式它們都是通用的解決方案，是經(jīng)過實踐經(jīng)驗了的。
比如說，在程序里，可能會有通知模塊，A模塊的數(shù)據(jù)發(fā)生變化，B模塊需要得到通知，對于這樣的需要，你可能會想到用"廣播"，"消息"或者"回調(diào)"的方式來解決，的確，剛才我所說的那三種也能解決，但是，這三種都是存在一些缺點，比如說廣播，用Intent來傳輸數(shù)據(jù)很困難，對于"消息"，無法很好的跟蹤，對于"回調(diào)"，有可能你A與B模塊根本不可相互訪問。此時，如果你會用觀察者模式的問題，這種問題可以很輕松解決。
當然，這里是需要具體問題具體分析的，我主要的意思就是說，要適當利用模式，我們不能為了用模式而去用模式，我們是要用模式來解決我們實際的問題。
概念完整性
關于概念完整性，在《人月神話》一書在有大量的闡述，這里，我把我的理解寫出來，與大家分享。
1）概念完整性是系統(tǒng)設計中最重要的考慮因素。當你的系統(tǒng)規(guī)模越大，這一點體現(xiàn)得越明顯。
2）為了獲取概念的完整性，設計必須由一個人或者具有共識的小型團隊來完成。這一點很好理解，關于設計，可以讓所有的人參與，但是決定權(quán)在少數(shù)人手里，如果大家都想?yún)⑴c設計，這是根本沒有辦法保證系統(tǒng)設計是統(tǒng)一完整的。
3）要獲得概念上的完整性，就必須有人控制這些概念，類似于貴族的專制統(tǒng)治。這里，對于團隊中的項目經(jīng)理或架構(gòu)師必須對項目有絕對的權(quán)威，不然，這個項目里面的就無法統(tǒng)一號令。
4）概念完整性表現(xiàn)有：
- 開發(fā)過程中，需求、設計、編碼的一致性
- 整個程序具有統(tǒng)一的風格，比如對話框樣式，按鈕風格，色調(diào)等UI元素
- 整個程序具體統(tǒng)一的結(jié)構(gòu)，比如不同模塊訪問網(wǎng)絡，它們的調(diào)用方式一致，例如異步訪問都用回調(diào)方式通知結(jié)果，相同的功能應該提取成共通模塊。
- 開發(fā)人員能很好的執(zhí)行需求人員和設計人員的意圖。
- 有完整的文檔，需求文檔，設計文檔，測試文檔，處理流程的文檔等。
如何保持概念完整性
- 在制度上給予保證，產(chǎn)品的負責人必須建立技術(shù)上的絕對權(quán)威
- 技術(shù)負責人員（SE，SL）必須嚴格執(zhí)行項目的需求，設計，必須深入到編碼細節(jié)
- 在不同階段，保持與所有人員的持續(xù)溝通，鼓勵開發(fā)人員提意見。
- 讓開發(fā)人員參與設計，但不決定設計
- 通過持續(xù)的反饋和溝通來實現(xiàn)模塊重用
2.1 共通類的設計
2.1.1 Widget設計
為什么要提供這些共通控件？
2.1.2 Adapter Items
數(shù)據(jù)驅(qū)動
下面代碼示例了Adapter#getView()方法的實現(xiàn)，它返回BookView，BookView提供方法來接收數(shù)據(jù)，至于BookView的顯示，則根據(jù)設置的數(shù)據(jù)來顯示，這就是數(shù)據(jù)驅(qū)動UI。
2.1.3 Dialog
2.1.4 Utility
2.2 Task管理
線程只是一種機制，保證我們要完成的任務不運行在UI線程（也就是說不阻塞UI），完成的任務才是我們關注的核心，因此，我們可以通過設計，把線程封裝，讓使用者根本感覺不到是線程，他只用關心他要做的事情就行了。
這里，我們可以設計一種"異步鏈式調(diào)用"的框架，把線程進行了封裝。使用都只需要這樣用：
這里，task1, task2, task3是順序執(zhí)行的，舉個例子：我們要訪問網(wǎng)絡，取得一個圖片，使用這個TaskManager我們需要3個task，
task1:顯示一個ProgressDialog。
task2:訪問網(wǎng)絡，創(chuàng)建bitmap。
task3:關閉對話框，顯示bitmap。
這一點，可以參考CoreLib工程中的task.TaskManager類。
關于TaskManager，有以下幾點需要注意：
2.3 緩存設計
關于緩存的更多詳細細節(jié)，請參考[ 請參考CoreLib工程中的cache包 ]。
這樣做，有什么好處， 不用再手動釋放bitmap內(nèi)在，該操作有風險，因為該bitmap是否有View引用，如果當一個View在試圖繪制一個已經(jīng)回收的bitmap，這里會拋出異常。
2.4 線程管理
無消息循環(huán)的線程：
什么情況下使用這種線程：
在使用線程，最好給線程加上名字，這樣利用高度與跟蹤。
有消息循環(huán)的線程：
這樣的線程擁有消息循環(huán)，當消息隊列中沒有消息時，這個線程會被掛起。我們要做一件事情時，只需要給它發(fā)送一個消息就行了。
這種情況通常是為了復用線程，不用頻繁創(chuàng)建線程，比如音樂播放器程序，專門啟動一個有消息循環(huán)的線程來獲得音樂的專輯圖片。
我們通常還要創(chuàng)建一個與這個線程的消息循環(huán)（Looper）相關聯(lián)的Handler，由它來處理消息，注意，這做的事情是運行在后臺線程的。
Android程序的結(jié)構(gòu)
下面，我試著畫了一個Android程序的結(jié)構(gòu)，如果有不好的地方，歡迎指正。
下面列出一些通常的原則，我們應當在開發(fā)過程中遵循，歡迎補充與指正。
4.1 提供initialize()方法
在Activity.onCreate()或者View的構(gòu)造方法中調(diào)用，在以后看代碼時，人們通常首先會去找initialize()這樣的方法。
4.2 封裝點擊事件
把View的點擊事件，提成方法，這樣在listener處只是一個方法調(diào)用者，一般的事件封裝為：onXXXClick(View v)。
4.3 設計一個BaseActivity類
讓所有的Activity都繼承自BaseActivity類，這樣，我們可以做很多有用的事情
4.4 設計Application類
4.5 異常處理
4.6 標注的使用
4.7 注冊與反注冊
4.8 封裝Bitmap操作
我們應當把Bitmap操作封裝起來，比如從文件加載，保存，網(wǎng)絡下載，動態(tài)計算sample size等。有了封裝后，我們可以對其集中優(yōu)化。
4.9 繪制處理
一定要注意繪制方面的東西，不要在onDraw()/onTouchEvent()中創(chuàng)建新對象。
