Android

Activity設計模式之MVC模式（介紹MVP之前的引子）

MVC即Model-View-Controller

M:邏輯模型。 負責建立資料結構和相應的行為操作處理。

V:檢視模型。 負責在螢幕上渲染出相應的圖形資訊展示給使用者看。

C:控制器。 負責截獲使用者的按鍵和螢幕觸控等事件，協調Model物件和View物件。

使用者與檢視互動，檢視接受並反饋使用者的動作；檢視把使用者的請求傳給相應的控制器，由控制器決定呼叫哪個模型，然後由模型呼叫相應的業務邏輯對使用者請求進行加工處理，如果需要返回資料，模型會把相應的資料返回給控制器，由控制器呼叫相應的檢視，最終由檢視格式化和渲染返回的資料，對於返回的資料完全可以增加使用者體驗效果展現給使用者。

一個模型可以有多個檢視，一個檢視可以有多個控制器，一個控制器也可以有多個模型。

　
1. 模型（Model）

Model是一個應用系統的核心部分，代表了該系統實際要實現的所有功能處理。

比如：在視訊播放器中，模型代表一個視訊資料庫及播放視訊的程式函式程式碼；在拍照應用中，模型代表一個照片資料庫，及看圖片時的程式函式程式碼。在一個電話應用中，Model代表一個電話號碼簿，以及撥打電話和傳送簡訊的程式函式程式碼。

Model在values目錄下通過xml檔案格式生成，也可以通過硬編碼的方式直接Java程式碼生成。==View和Model是通過橋樑Adapter來連線起來。==

2. 檢視 (View)

View是軟體應用傳送給使用者的一個反饋結果。它代表軟體應用中的圖形展示、聲音播放、觸覺反饋等職責。檢視的根節點是應用程式的自身視窗。比如，視訊播放器中可能包含當前播放的畫面，這個畫面就是一個檢視。另一個檢視元件可能是該視訊的文字標題。再一個就是一些播放按鍵，比如：Stop、Start、Pause等按鈕。

View在layout目錄下通過xml檔案格式生成，用findViewById()獲取；也可以通過硬編碼的方式直接Java程式碼生成。

3. 控制器 （Controller）

Controller在軟體應用負責對外部事件的響應，包括：鍵盤敲擊、螢幕觸控、電話呼入等。Controller實現了一個事件佇列，每一個外部事件均在事件佇列中被唯一標識。框架依次將事件從佇列中移出並派發出去。

Android中最典型MVC是ListView，要顯示的資料是Model，介面中的ListView是View，控制資料怎樣在ListView中顯示是Controller。

Activity設計模式之MVP模式

Model-View-Presenter

MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供資料，View負責顯示。

作為一種新的模式，MVP與MVC有著一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是通過Presenter (MVC中的Controller)來進行的，所有的互動都發生在Presenter內部，而在MVC中View會直接從Model中讀取資料而不是通過 Controller。

在MVC裡，View是可以直接訪問Model的！從而，View裡會包含Model資訊，不可避免的還要包括一些業務邏輯。 在MVC模型裡，更關注的Model的不變，而同時有多個對Model的不同顯示，即View。所以，在MVC模型裡，Model不依賴於View，但是View是依賴於Model的。不僅如此，因為有一些業務邏輯在View裡實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。

雖然 MVC 中的 View的確“可以”訪問Model，但是我們不建議在 View 中依賴Model，而是要求儘可能把所有業務邏輯都放在 Controller 中處理，而 View 只和 Controller 互動。

MVP如何解決MVC的問題？

在MVP裡，Presenter完全把Model和View進行了分離，主要的程式邏輯在Presenter裡實現。而且，Presenter與具體的View是沒有直接關聯的，而是通過定義好的介面進行互動，從而使得在變更View時候可以保持Presenter的不變，即重用！

不僅如此，我們還可以編寫測試用的View，模擬使用者的各種操作，從而實現對Presenter的測試–而不需要使用自動化的測試工具。 我們甚至可以在Model和View都沒有完成時候，就可以通過編寫MockObject（即實現了Model和View的介面，但沒有具體的內容的）來測試Presenter的邏輯。

在MVP裡，應用程式的邏輯主要在Presenter來實現，其中的View是很薄的一層。因此就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程中，View是很簡單的，能夠把資訊顯示清楚就可以了。在後面，根據需要再隨便更改View，而對Presenter沒有任何的影響了。 如果要實現的UI比較複雜，而且相關的顯示邏輯還跟Model有關係，就可以在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯。而同時，因為Adapter實現了View的介面，從而可以保證與Presenter之間介面的不變。這樣就可以保證View和Presenter之間介面的簡潔，又不失去UI的靈活性。 在MVP模式裡，View只應該有簡單的Set/Get的方法，使用者輸入和設定介面顯示的內容，除此就不應該有更多的內容，絕不容許直接訪問Model–這就是與MVC很大的不同之處。

MVP的優點
1. 模型與檢視完全分離，我們可以修改檢視而不影響模型
2. 可以更搞笑的使用模型，因為所有的互動都發生在一個地方：Presenter內部
3. 我們可以將一個Presenter用於多個檢視，而不需要改變Presenter的邏輯。這個特性非常的有用，因為檢視的變化總是比模型的變化頻繁。
4. 如果我們把邏輯放在Presenter中，那麼我們就可以脫離使用者介面來測試這些邏輯（單元測試）

Activity生命週期、啟動模式

參考書：《第一行Android程式碼》
參考書：《Android開發藝術探索》

Android是使用任務棧（Task）來管理活動的，一個任務就是一組存放在棧裡的活動的集合，這個棧也被稱作返回棧（Back Stack）。在預設情況下，每當我們啟動一個新的活動，他就會在返回棧中入棧，並處於棧頂的位置。而每當我們按下Back鍵或呼叫finsh()方法去銷燬一個活動時，處於棧頂的活動會出棧。

活動在其生命週期中最多會有四種狀態：執行狀態、暫停狀態、停止狀態、銷燬狀態。

Activity類中定義了七個回撥方法，覆蓋了活動生命週期的每一個環節：
1. ==onCreate()==:活動第一次建立時呼叫，完成活動的初始化操作，比如載入佈局、繫結事件等。
2. ==onStart()==：活動由不可見變為可見時呼叫。
3. ==onResume()==：活動準備好和使用者進行互動時呼叫。此時活動一定位於返回棧的棧頂，並且處於執行狀態。
4. ==onPause()== ：系統準備去啟動或者恢復另一個活動時呼叫。通常會在這個方法中將一些消耗CPU的資源釋放掉，以及儲存一些關鍵資料。但這個方法執行速度一定要快，不然會影響到新的棧頂活動的使用。
5. ==onStop()==： 活動完全不可見的時候呼叫。
6. ==onDestroy()== ：活動被銷燬前呼叫，之後活動的狀態將變為銷燬狀態。
7. ==onRestart()== ：活動由停止狀態變為執行狀態之前呼叫，也就是活動被重新啟動了。

活動的啟動模式分為四種：standard,singleTop,singleTask,singleInstance.

可以根據實際的需求為Activity設定對應的啟動模式，從而可以避免建立大量重複的Activity等問題。

設定Activity的啟動模式，只需要在AndroidManifest.xml裡對應的標籤設定Android:launchMode屬性，例如：

<activity  
    android:name=".A1"  
    android:launchMode="standard" />  

standard:標準模式

預設模式，不用寫配置。系統不會在乎這個活動是否已經在返回棧中存在，每次啟動都會建立一個新的例項。因此，在standard模式下，可以有多個相同的例項，也允許多個相同Activity疊加。退出時，按Back依次按棧順序退出。

singleTop: 棧頂複用模式

在這種模式下，如果新Activity已經位於任務棧的棧頂，那麼此Activity不會被重新建立，同時它的onNewIntent方法會回撥，通過此方法的引數我們可以取出當前請求的資訊。需要注意的是，此時這個Activity的onCreate、onStart不會被系統呼叫，因為它並沒有發生改變。

如果新Activity的例項已經存在但不是位於棧頂，那麼新Activity仍然會重新重建。

SingleTask： 棧內複用模式

只有一個例項。在同一個應用程式中啟動他的時候，若Activity不存在，則會在當前task建立一個新的例項；若存在，則會把task中在其之上的其他Activity destroy掉並呼叫他的onNewInstant方法。
具體一點，當一個具有singleTask模式的Activity請求啟動後，比如Activity A，系統首先會尋找是否存在A的任務棧，如果不存在，就重新建立一個任務棧，然後建立A的例項後把A放到棧中。如果存在任務棧且有例項，就把A調到棧頂並呼叫onNewIntent方法，如果例項不存在，就建立A的例項並把A壓入棧中。

舉幾個例子：

• 比如目前任務棧S1中的情況為ABC,這個時候ActivityD以singleTask模式請求啟動，其所需的任務棧為S2，由於S2和D的例項都不存在，所以系統會先建立任務棧S2,然後再建立D的例項並將其入棧到S2.
• 另一種情況，假設D所需的任務棧為S1，其他情況如上面的例子所示，那麼由於S1已經存在，所以系統會直接建立D的例項並將其入棧到S1。
• 如果D所需的任務棧為S1，並且當前任務棧S1的情況為ADBC,根據棧內複用原則，此時D不會重新建立，系統會把D切換到棧頂並呼叫其onNewIntent方法，同時由於singleTask預設具有clearTop的效果，會導致棧內所有在D上面的Activity全部出棧，於是最終S1中的情況為AD。

singleInstance:

單例項模式。這是一種加強的singleTask模式，它除了具有singleTask模式的所有特性外，還加強了一點，那就是具有此種模式的Activity只能單獨的位於一個任務棧中，換句話說，比如Activity A是singleInstance模式，當A啟動後，系統會為它建立一個新的任務棧，然後A獨自在這個新的任務棧中，由於棧內複用的特性，後續的請求均不會建立新的Activity，除非這個獨特的任務棧被系統銷燬了。

任務棧

從一個引數說起：TaskAffinity，可以翻譯為任務相關性。這個引數標識了一個Activity所需要的任務棧的名字，預設情況下，所有Activity所需的任務棧的名字為應用的包名。當然，我們可以為每個Activity都單獨制定TaskAffinity屬性，這個屬性必須不能和包名相同，否則就相當於沒有制定。TaskAffinity屬性主要和singleTask啟動模式配對使用。

指定Activity啟動模式

一、通過AndroidManifest為Activity指定啟動模式：

       <activity android:name=".MainActivity"
            android:launchMode="standard">

二、通過在Intent中設定標誌位來為Activity指定啟動模式：

        Intent intent = new Intent(MainActivity.this,MyActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        startActivity(intent);

點選事件傳遞dispatch,intercept,onTouchEvent

上圖顯示：

　　在ViewGroup中可以通過onInterceptTouchEvent方法對事件傳遞進行攔截。onInterceptTouchEvent方法：

　　　　返回true代表不允許事件繼續向子View傳遞，將會觸發當前View的onTouchEvent()，進行事件的消費;

　　　　返回false代表不對事件進行攔截，事件可以傳遞給孩子

　　　　預設返回false

跟touch事件相關的3個方法：

public boolean dispatchTouchEvent(MotionEvent ev);    //用來分派event

public boolean onInterceptTouchEvent(MotionEvent ev); //用來攔截event

public boolean onTouchEvent(MotionEvent ev);          //用來處理event

事件分發：public boolean dispatchTouchEvent(MotionEvent ev)

當有監聽到事件時，首先由Activity的捕獲到，進入事件分發處理流程。

如果事件分發返回true，表示改事件在本層不再進行分發且已經在事件分發自身中被消費了。至此，事件已經完結。

如果事件分發返回 false，表明事件在本層不再繼續進行分發，並交由上層控制元件的onTouchEvent方法進行消費。

事件攔截：public boolean onInterceptTouchEvent(MotionEvent ev)

如果 onInterceptTouchEvent 返回 true，則表示將事件進行攔截，並將攔截到的事件交由本層控制元件 的 onTouchEvent 進行處理；

如果返回結果是false；則表示不對事件進行攔截，事件得以成功分發到子View。並由子View的dispatchTouchEvent進行處理。

如果返回super.onInterceptTouchEvent(ev)，事件預設不會被攔截，交由子View的dispatchTouchEvent進行處理。

事件響應：public boolean onTouchEvent(MotionEvent ev)

如果onTouchEvent返回true，表示onTouchEvent處理完事件後消費了此次事件。此時事件終結，將不會進行後續的冒泡。

如果onTouchEvent返回false，事件在onTouchEvent中處理後繼續向上層View冒泡，且有上層View的onTouchEvent進行處理。

如果返回super.onTouchEvent(ev)，則預設處理的邏輯和返回false時相同。

service，兩種啟動方式及特點，如何與activity通訊

==採用start的方式開啟服務==

步驟：

1. 定義一個類繼承Service
2. 在Manifest.xml檔案中配置該Service
3. 使用Context的startService(Intent)方法啟動
4. 不再使用時，呼叫stopService(Intent)方法停止

用這種start方式啟動的Service的生命週期如下：

onCreate()—>onStartCommand()（onStart()方法已過時） —> onDestory()

說明： 如果服務已經開啟，不會重複的執行onCreate()， 而是會呼叫onStart()和onStartCommand()。

服務停止的時候呼叫 onDestory()。服務只會被停止一次。

特點： 一旦服務開啟跟呼叫者(開啟者)就沒有任何關係了。
開啟者退出了，開啟者掛了，服務還在後臺長期的執行。
開啟者不能呼叫服務裡面的方法。

==採用bind的方式開啟服務==

步驟：

1. 定義一個類繼承Service
2. 在Manifest.xml檔案中配置該Service
3. 使用Context的bindService(Intent, ServiceConnection, int)方法啟動
4. 不再使用時，呼叫unbindService(ServiceConnection)方法停止

使用這種start方式啟動的Service的生命週期如下：
onCreate() —>onBind()—>onunbind()—>onDestory()

注意： 繫結服務不會呼叫onstart()或者onstartcommand()方法

特點： bind的方式開啟服務，繫結服務，呼叫者掛了，服務也會跟著掛掉。
繫結者可以呼叫服務裡面的方法。

Handler-Looper-MessageQueue，AsyncTask原理相關

由於Android不允許在子執行緒中進行UI操作，因為UI是執行緒不安全的，如果想要更新UI則必須在主執行緒中進行，否則就會異常。Android提供的一套非同步訊息處理機制，完美的解決在子執行緒中進行UI操作的問題。

Android中的非同步訊息處理主要由四個部分組成：Message、Handler、MessageQueue和Looper。

Message:
Message是線上程之間傳遞的訊息，他可以在內部攜帶少量的資訊，用於在不同執行緒之間交換資料。比如what欄位、arg1、arg2帶一些整型資料，obj欄位攜帶一個Object物件。

Handler
Handler顧名思義就是處理者的意思，它主要是用於傳送和處理訊息的，傳送訊息一般使用Handler的sendMessage()方法，而發出的訊息經過一系列的輾轉處理後，最終會傳遞到Handler的handleMessage()方法中。

MessageQueue
MessageQueue是訊息佇列的意思，它主要用於存放所有通過Handler傳送的訊息。這部分訊息會一直存在於訊息佇列中，等待被處理。每個執行緒只有一個MessageQueue物件。

Looper
Looper是每個執行緒中的MessageQueue的管家，呼叫Looper的loop()方法後，就會進入到一個無限迴圈當中，然後每發現MessageQueue中存在一條訊息，就會將它取出，並傳遞到Handler的handleMessage()方法中。每個執行緒也只有一個Looper物件。

==非同步訊息處理流程：==
1. 主執行緒中建立一個Handler物件，並重寫handleMessage()方法
2. 當子執行緒需要進行UI操作時，就建立一個Message物件，並通過handler.sendMessage()將這條訊息傳送出去
3. 這條訊息被新增到MessageQueue的佇列中等待被處理
4. Looper一直嘗試從MessageQueue中提出待處理訊息，分發會Handler的handleMessage()方法中。

==AsyncTask：==

AsyncTask是Android提供的輕量級非同步類，可以直接繼承。其實現原理也是基於非同步訊息處理機制的，只是Android幫我們做了很好的封裝而已。

由於AsyncTask是一個抽象類，要使用必須要建立一個子類去繼承他，並提供三個泛型引數，同時過載幾個方法：

AsyncTask定義了三種泛型型別Params，Progress和Result

• Params：在執行AsyncTask時需要傳入的引數，可用於在後臺任務中使用（doInBackground方法的引數型別）如HTTP請求的URL
• Progress：後臺任務執行時，如果需要在介面上顯示當前的進度，則指定進度型別
• Result：後臺任務的返回結果型別

例子：一個最簡單的自定義AsyncTask:

class DownloadTask extends AsyncTask<void,Integer,Boolean>{
}

//Params為void，表示在執行AsyncTask的時候不需要傳入引數給後臺任務
//Progress為Integer,表示用整型資料來作為進度顯示單位
//Result為Boolean，表示使用布林型資料來反饋執行結果

目前自定義的DownloadTask還是一個空任務，還需要重寫AsyncTask中的幾個方法才能完成對任務的定製。

使用過AsyncTask 的同學都知道一個非同步載入資料最少要重寫以下這兩個方法：

• doInBackground(Params…): 這個方法的所有程式碼都會在後臺子執行緒中執行，比較耗時的操作都可以放在這裡。任務一旦完成就可以通過return語句來將任務的執行結果返回（這裡返回型別就是當初給定的第三個泛型引數）。注意這裡不能直接操作UI.在執行過程中可以呼叫publicProgress(Progress…)來更新任務的進度。
• onPostExecute(Result):
  當後臺任務執行完畢並通過return語句返回時，這個方法就會被呼叫。返回的資料會作為引數傳遞到此方法中，相當於Handler 處理UI的方式。可以利用返回的資料進行一些UI操作。此方法在主執行緒執行，任務執行的結果作為此方法的引數返回

有必要的話你還得重寫以下這三個方法，但不是必須的：

• onPreExecute() 這裡是終端使用者呼叫Excute時的介面，當任務執行之前開始呼叫此方法，可以在這裡顯示進度對話方塊。
• onProgressUpdate(Progress…) 當後臺任務中呼叫了publicProgress(Progress…)方法後，這個方法很快就會被呼叫。可以使用進度條增加使用者體驗度。 此方法在主執行緒執行，用於顯示任務執行的進度。
• onCancelled() 使用者呼叫取消時，要做的操作

AsyncTask的侷限性

AsyncTask的優點在於執行完後臺任務後可以很方便的更新UI，然而使用它存在著諸多的限制。先拋開記憶體洩漏問題，使用AsyncTask主要存在以下侷限性：

• 在Android 4.1版本之前，AsyncTask類必須在主執行緒中載入，這意味著對AsyncTask類的第一次訪問必須發生在主執行緒中；
• 在Android 4.1以及以上版本則不存在這一限制，因為ActivityThread（代表了主執行緒）的main方法中會自動載入AsyncTask
• AsyncTask物件必須在主執行緒中建立
• AsyncTask物件的execute方法必須在主執行緒中呼叫
• 一個AsyncTask物件只能呼叫一次execute方法

動畫相關

一、Drawable Animation

也就是所謂的幀動畫，Frame動畫。指通過指定每一幀的圖片和播放時間，有序的進行播放而形成動畫效果。可以理解成多張圖片播放，圖片不能過大。

二、View Animation

檢視動畫，也就是所謂補間動畫，Tween動畫。指通過指定View的初始狀態、變化時間、方式，通過一系列的演算法去進行圖形變換，從而形成動畫效果，主要有Alpha、Scale、Translate、Rotate四種效果。注意：只是在檢視層實現了動畫效果，並沒有真正改變View的屬性。view的實際位置還是移動前的位置

三、Property Animation

屬性動畫，通過不斷的改變View的屬性，不斷的重繪而形成動畫效果。相比於檢視動畫，View的屬性是真正改變了。注意：Android 3.0(API 11)以上才支援。

binder機制

這裡只對Binder機制進行一個簡要的概括，詳細binder的介紹在這裡就不展開了。

• Binder是Android系統中的一種IPC程序間通訊結構。
  在Android中，每一個應用程式都執行在獨立的程序中，這也保證了當其中一個程式出現異常而不會影響另一個應用程式的正常運轉。在許多情況下，我們activity都會與各種系統的service打交道，很顯然，我們寫的程式中activity與系統service肯定不是同一個程序，但是它們之間是怎樣實現通訊的呢？Binder是android中一種實現程序間通訊（IPC）的方式之一。

• Binder屬於一個驅動，工作在linux層面，執行在核心態，它的操作完成是基於一段記憶體。所以我們開發的程式中對binder的使用都是通過系統的呼叫來完成的。

• Binder的整個設計是C/S結構，Binder架構由服務端，binder驅動，客戶端三個部分構成。 客戶端程序通過binder驅動獲取服務端程序的代理，並通過向這個代理介面方法中讀寫資料來完成程序間的資料通訊。

為什麼Android選用Binder來實現程序間通訊？

1. 安全。Android是一個開放式的平臺，所以確保應用程式安全是很重要的。每個程序都會被Android系統分配UID和PID，其中程序的UID是可用來鑑別程序身份。不像傳統的在資料包里加入UID，這就讓那些惡意程序無法直接和其他程序通訊，保證了程序間通訊的安全性。

1. 高效。socket主要用於跨網路的程序間通訊和本機上程序間的通訊，但傳輸效率低，開銷大。訊息佇列和管道採用儲存-轉發方式，即資料先從傳送方快取區拷貝到核心開闢的一塊快取區中，然後從核心快取區拷貝到接收方快取區，其過程至少有兩次拷貝。雖然共享記憶體無需拷貝，但控制複雜。比較各種IPC方式的資料拷貝次數。共享記憶體：0次。Binder：1次。Socket/管道/訊息佇列：2次。在手機這種資源緊張的情況下很重要。

BroadCast動態、靜態註冊

在Android中，Broadcast是一種廣泛運用的在應用程式之間傳輸資訊的機制。而BroadcastReceiver是對傳送出來的 Broadcast進行過濾接受並響應的一類元件。下面將詳細的闡述如何傳送Broadcast和使用BroadcastReceiver過濾接收的過程：

首先在需要傳送資訊的地方，把要傳送的資訊和用於過濾的資訊(如Action、Category)裝入一個Intent物件，然後通過呼叫 Context.sendBroadcast()、sendOrderBroadcast()或sendStickyBroadcast()方法，把 Intent物件以廣播方式傳送出去。

當Intent傳送以後，所有已經註冊的BroadcastReceiver會檢查註冊時的IntentFilter是否與傳送的Intent相匹配，若匹配則就會呼叫BroadcastReceiver的onReceive()方法。所以當我們定義一個BroadcastReceiver的時候，都需要實現onReceive()方法。

註冊BroadcastReceiver有兩種方式:

1. 靜態註冊
靜態的在AndroidManifest.xml中用標籤生命註冊，並在標籤內用標籤設定過濾器。

<receiver android:name=".Receiver" >  
            <intent-filter>  
                <action android:name="android.intent.action.BOOT_COMPLETED" />  
            </intent-filter>  
 </receiver>  

2. 動態註冊
動態的在程式碼中先定義並設定好一個 IntentFilter 物件，然後在需要註冊的地方調Context.registerReceiver()方法，如果取消時就呼叫 Context.unregisterReceiver()方法。

UpdateBroadcast  broadcast= new UpdateBroadcast();  
IntentFilter filter = new IntentFilter("com.unit.UPDATE");  
registerReceiver(broadcast, filter); 

1.動態註冊的廣播 永遠要快於 靜態註冊的廣播,不管靜態註冊的優先順序設定的多高,不管動態註冊的優先順序有多低>\

2.動態註冊廣播不是 常駐型廣播 ，也就是說廣播跟隨activity的生命週期。注意: 在activity結束前，移除廣播接收器。

靜態註冊是常駐型 ，也就是說當應用程式關閉後，如果有資訊廣播來，程式也會被系統呼叫自動執行。