以前只做過模組功能的開發，在開源專案或者別人搭建的專案框架下敲碼。突然讓我來搭建一個app的框架，竟然不知道如何下手了！鬱悶，好吧先從網上收集了一些資料看看。好吧，拿來主義一篇來自csdn的部落格

1、一些概念

模式的定義：

每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心。通過這種方式，你可以無數次地使用那些已有的解決方案，無需在重複相同的工作。

什麼是設計模式？

設計模式是在某種特別的情況下，針對某種問題的某種典型、通用的解決方法。

我們是需要適當瞭解並學習一些設計模式，在程式開發過程中，總是會涉及到一些框架設計，模組設計之類的東西，如果能很好理解並執行設計模式，你所設計的模組或框架將會要穩定得多，因為這些設計模式它們都是通用的解決方案，是經過實踐經驗了的。

比如說，在程式裡，可能會有通知模組，A模組的資料發生變化，B模組需要得到通知，對於這樣的需要，你可能會想到用"廣播"，"訊息"或者"回撥"的方式來解決，的確，剛才我所說的那三種也能解決，但是，這三種都是存在一些缺點，比如說廣播，用Intent來傳輸資料很困難，對於"訊息"，無法很好的跟蹤，對於"回撥"，有可能你A與B模組根本不可相互訪問。此時，如果你會用觀察者模式的問題，這種問題可以很輕鬆解決。

當然，這裡是需要具體問題具體分析的，我主要的意思就是說，要適當利用模式，我們不能為了用模式而去用模式，我們是要用模式來解決我們實際的問題。

（ps,應為對設計模式知道的也不多，程式中會設計單例模式+觀察者模式。。其他的模式還需要學習後再用）

概念完整性

關於概念完整性，在《人月神話》一書在有大量的闡述，這裡，我把我的理解寫出來，與大家分享。

1）概念完整性是系統設計中最重要的考慮因素。當你的系統規模越大，這一點體現得越明顯。

2）為了獲取概念的完整性，設計必須由一個人或者具有共識的小型團隊來完成。這一點很好理解，關於設計，可以讓所有的人蔘與，但是決定權在少數人手裡，如果大家都想參與設計，這是根本沒有辦法保證系統設計是統一完整的。

3）要獲得概念上的完整性，就必須有人控制這些概念，類似於貴族的專制統治。這裡，對於團隊中的專案經理或架構師必須對專案有絕對的權威，不然，這個專案裡面的就無法統一號令。

4）概念完整性表現有：（ps:這個還真沒有，需求目前是對比專案經理要求和web端功能新增）

    - 開發過程中，需求、設計、編碼的一致性
    - 整個程式具有統一的風格，比如對話方塊樣式，按鈕風格，色調等UI元素
    - 整個程式具體統一的結構，比如不同模組訪問網路，它們的呼叫方式一致，例如非同步訪問都用回撥方式通知結果，相同的功能應該提取成共通模組。
    - 開發人員能很好的執行需求人員和設計人員的意圖。
    - 有完整的文件，需求文件，設計文件，測試文件，處理流程的文件等。

如何保持概念完整性

    - 在制度上給予保證，產品的負責人必須建立技術上的絕對權威
    - 技術負責人員（SE，SL）必須嚴格執行專案的需求，設計，必須深入到編碼細節
    - 在不同階段，保持與所有人員的持續溝通，鼓勵開發人員提意見。
    - 讓開發人員參與設計，但不決定設計
    - 通過持續的反饋和溝通來實現模組重用

2、設計之前應該做什麼

2.1 共通類的設計（ps:這個很有必要）

2.1.1 Widget設計

• TextView
• EditText
• Button
• Title bar
• Tool bar
• ...

      為什麼要提供這些共通控制元件？

• 統一字型大小，如App字型不隨系統字型變化而變化
• 統一UI式樣，如Button， EditText具有相同的背景等
• 複用程式碼

2.1.2 Adapter Items

• 根據式樣，提取需要在AdapterView中顯示的Item
• 簡單的複合佈局
• 自繪製，從而提高滑動效能
  - ListView中放Gallery時，提高上下滑動效能
  - 儘量優化繪製

       資料驅動

• Adapter Items提供核心的方法
  - setData(Object data)
  - getData();
• Adapter#getView實現更加簡單
  - 實現簡單
  - 不會因為UI變化而變化

下面程式碼示例了Adapter#getView()方法的實現，它返回BookView，BookView提供方法來接收資料，至於BookView的顯示，則根據設定的資料來顯示，這就是資料驅動UI。

1. @Override
2. public View getView(int position, View convertView, ViewGroup parent) { 
3. if (null == convertView) { 
4.         convertView = new BookView(getContext()); 
5.         convertView.setLayoutParameter(new AbsListView.LayoutParameter(150, 150)); 
6.     } 
7.     Book book = m_bookList.get(position); 
8.     BookView bookView = (BookView)convertView; 
9.     bookView.setBook(book); 
10. return convertView; 
11. } 

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

    if (null == convertView) {
        convertView = new BookView(getContext());
        convertView.setLayoutParameter(new AbsListView.LayoutParameter(150, 150));
    }

    Book book = m_bookList.get(position);
    BookView bookView = (BookView)convertView;
    bookView.setBook(book);

    return convertView;
}

2.1.3 Dialog

• 擴充套件於Dialog類
• 提供Dialog關閉的事件
• Dialog的高度隨內容的變化而變化
• 可以設定按鈕的文字，可見性，字型等方法
• 設定按鈕點選事件的listener
• 要考慮對話方塊的三個屬性：Title, Content area, Action buttons

2.1.4 Utility

• Log
• DateFormat
• Bitmap
• Notification
• Shared Preference
• Environment
• Device
• ...

2.2 Task管理

執行緒只是一種機制，保證我們要完成的任務不執行在UI執行緒（也就是說不阻塞UI），完成的任務才是我們關注的核心，因此，我們可以通過設計，把執行緒封裝，讓使用者根本感覺不到是執行緒，他只用關心他要做的事情就行了。
這裡，我們可以設計一種"非同步鏈式呼叫"的框架，把執行緒進行了封裝。使用都只需要這樣用：

1. new TaskManager() 
2. .next(task1) 
3. .next(task2) 
4. .next(task3). 
5. .execute(); 

new TaskManager()
.next(task1)
.next(task2)
.next(task3).
.execute();

這裡，task1, task2, task3是順序執行的，舉個例子：我們要訪問網路，取得一個圖片，使用這個TaskManager我們需要3個task，

task1:顯示一個ProgressDialog。

task2:訪問網路，建立bitmap。

task3:關閉對話方塊，顯示bitmap。

這一點，可以參考CoreLib工程中的task.TaskManager類。

關於TaskManager，有以下幾點需要注意：

• 封裝了執行緒
• 讓呼叫者只關注自己的業務處理
• 保證順序鏈式地執行某一個任務
• 上一個任務的輸出，作為下一個任務的輸入
• 能暫停、恢復任何一個任務
  

2.3 快取設計（ps:根據之前專案經驗，避免oom，我打算選擇imageLoad開源庫）

• 把記憶體佔用量大的物件存放在快取中，如bitmap
• 利用了LruCache類來實現
• 利用了AsyncTask類來載入bitmap
• 不用再手動釋放bitmap記憶體，該操作有風險
• 不用再關心AbsListView的scroll狀態

關於快取的更多詳細細節，請參考[ 請參考CoreLib工程中的cache包 ]。

這樣做，有什麼好處， 不用再手動釋放bitmap內在，該操作有風險，因為該bitmap是否有View引用，如果當一個View在試圖繪製一個已經回收的bitmap，這裡會丟擲異常。

2.4 執行緒管理

無訊息迴圈的執行緒：

1. new Thread(null, new Runnable() { 
2. publicvoid run() { 
3. // Do you works.
4.     } 
5. }, "Thread_name_xxx").start(); 

new Thread(null, new Runnable() {
    public void run() {
        // Do you works.
    }

}, "Thread_name_xxx").start();

什麼情況下使用這種執行緒：

• 做完一件事情就結束，這件事發生頻率不高，比如從SD card中讀取圖片資料
• 不需要複用執行緒

在使用執行緒，最好給執行緒加上名字，這樣利用高度與跟蹤。

  有訊息迴圈的執行緒：

這樣的執行緒擁有訊息迴圈，當訊息佇列中沒有訊息時，這個執行緒會被掛起。我們要做一件事情時，只需要給它傳送一個訊息就行了。

這種情況通常是為了複用執行緒，不用頻繁建立執行緒，比如音樂播放器程式，專門啟動一個有訊息迴圈的執行緒來獲得音樂的專輯圖片。

我們通常還要建立一個與這個執行緒的訊息迴圈（Looper）相關聯的Handler，由它來處理訊息，注意，這做的事情是執行在後臺執行緒的。

3，程式框架如何設計

Android程式的結構

• UI層
  • 資料展示與管理
  • 使用者互動
  • 繪製
  • Adapter
• 業務邏輯層
  • 持久化資料（記憶體中，相當於全域性資料）
  • 資料加式（資料層的資料有時候需要進行加工成UI層需要的資料）
  • 資料變化的通知機制
• 資料層
  • 資料訪問（DB，檔案，網路等）
  • 快取（圖片，檔案等）
  • 配置檔案（shared perference）

下面，我試著畫了一個Android程式的結構，如果有不好的地方，歡迎指正。

4，一些基本原則

下面列出一些通常的原則，我們應當在開發過程中遵循，歡迎補充與指正。

4.1 提供initialize()方法

在Activity.onCreate()或者View的構造方法中呼叫，在以後看程式碼時，人們通常首先會去找initialize()這樣的方法。

4.2 封裝點選事件

把View的點選事件，提成方法，這樣在listener處只是一個方法呼叫者，一般的事件封裝為：onXXXClick(View v)。

4.3 設計一個BaseActivity類

讓所有的Activity都繼承自BaseActivity類，這樣，我們可以做很多有用的事情

• 定義共通屬性
• 顯示共通對話方塊（Progress dialog)
• 取得top activity
• 可以手動管理啟動的activity

4.4 設計Application類

• 存全域性資料，比top activity, application context。

4.5 異常處理

• 報告功能是處理異常的精髓
• 在finally塊中執行清理操作
• 不要用try-catch-finally來判斷業務邏輯
• 考慮設計自定義的異常類

4.6 標註的使用

• 重寫的方法一定要加@Override
• 不使用的方法，不要刪除，可以標記為@Deprecated，這個做法在維護型的專案中特別有用。

4.7 註冊與反註冊

• 區域性廣播
• 各種listener
• Service等

4.8 封裝Bitmap操作

我們應當把Bitmap操作封裝起來，比如從檔案載入，儲存，網路下載，動態計算sample size等。有了封裝後，我們可以對其集中優化。

4.9 繪製處理

一定要注意繪製方面的東西，不要在onDraw()/onTouchEvent()中建立新物件。