Android 四大組件理解.

Android開發四大組件分別是：

活動(Activity)： 用於表現功能。

服務(Service)： 後台運行服務，不提供介面呈現。

廣播接收器(BroadcastReceiver)：用於接收廣播。

內容供應商（Content Provider）： 支援在多個應用中儲存和讀取資料，相當於資料庫。

Activity

　　Android 中，Activity 是所有程式的根本，所有程式的流程都運行在Activity 之中，Activity可以算是開發人員遇到的最頻繁，也是Android 當中最基本的模組之一。在Android的程式當中，Activity 一般代表手機螢幕的一屏。如果把手機比作一個瀏覽器，那麼Activity就相當於一個網頁。在Activity 當中可以添加一些Button、Check box 等控制項。可以看到Activity 概念和網頁的概念相當類似。

　　一般一個Android 應用是由多個Activity 組成的。這多個Activity 之間可以進行相互跳轉，例如，按下一個Button 按鈕後，可能會跳轉到其他的Activity。和網頁跳轉稍微有些不一樣的是，Activity 之間的跳轉有可能傳回值，例如，從Activity A 跳轉到Activity B，那麼當Activity B 運行結束的時候，有可能會給Activity A 一個傳回值。這樣做在很多時候是相當方便的。

　　當開啟一個新的螢幕時，之前一個螢幕會被置為暫停狀態，並且壓入曆史堆棧中。使用者可以通過後援動作返回到以前開啟過的螢幕。我們可以選擇性的移除一些沒有必要保留的螢幕，因為Android會把每個應用的開始到當前的每個螢幕儲存在堆棧中。

Service

　　Service 是android 系統中的一種組件，它跟Activity 的層級差不多，但是他不能自己運行，只能後台運行，並且可以和其他組件進行互動。Service 是沒有介面的長生命週期的代碼。Service 是一種程式，它可以運行很長時間，但是它卻沒有使用者介面。這麼說有點枯燥，來看個例子。開啟一個音樂播放器的程式，這個時候若想上網了，那麼，我們開啟Android 瀏覽器，這個時候雖然我們已經進入了瀏覽器這個程式，但是，歌曲播放並沒有停止，而是在後台繼續一首接著一首的播放。其實這個播放就是由播放音樂的Service進行控制。當然這個播放音樂的Service也可以停止，例如，當播放清單裡邊的歌曲都結束，或者使用者按下了停止音樂播放的快速鍵等。service
可以在和多場合的應用中使用，比如播放多媒體的時候使用者啟動了其他Activity這個時候程式要在後台繼續播放，比如檢測SD 記憶卡上檔案的變化，再或者在後台記錄你地理資訊位置的改變等等，總之服務嘛，總是藏在後頭的。

　　開啟service有兩種方式:

　　(1) Context.startService()：Service會經曆onCreate -> onStart（如果Service還沒有運行，則android先調用onCreate()然後調用onStart()；如果Service已經運行，則只調用onStart()，所以一個Service的onStart方法可能會重複調用多次 ）；stopService的時候直接onDestroy，如果是調用者自己直接退出而沒有調用stopService的話，Service會一直在後台運行。該Service的調用者再啟動起來後可以通過stopService關閉Service。
注意，多次調用Context.startservice()不會嵌套（即使會有相應的onStart()方法被調用），所以無論同一個服務被啟動了多少次，一旦調用Context.stopService()或者stopSelf()，他都會被停止。補充說明：傳遞給startService()的Intent對象會傳遞給onStart()方法。調用順序為：onCreate --> onStart(可多次調用) --> onDestroy。

　　(2) Context.bindService()：Service會經曆onCreate() --> onBind()，onBind將返回給用戶端一個IBind介面執行個體，IBind允許用戶端回調服務的方法，比如得到Service啟動並執行狀態或其他動作。這個時候把調用者（Context，例如Activity）會和Service綁定在一起，Context退出了，Srevice就會調用onUnbind --> onDestroyed相應退出，所謂綁定在一起就共存亡了。

BroadcastReceiver

　　在Android 中，Broadcast 是一種廣泛運用的在應用程式之間傳輸資訊的機制。而BroadcastReceiver 是對發送出來的Broadcast進行過濾接受並響應的一類組件。可以使用BroadcastReceiver 來讓應用對一個外部的事件做出響應。這是非常有意思的，例如，當電話呼入這個外來事件到來的時候，可以利用BroadcastReceiver 進行處理。例如，當下載一個程式成功完成的時候，仍然可以利用BroadcastReceiver 進行處理。BroadcastReceiver不能產生UI，也就是說對於使用者來說不是透明的，使用者是看不到的。BroadcastReceiver通過NotificationManager
來通知使用者這些事情發生了。BroadcastReceiver 既可以在AndroidManifest.xml 中註冊，也可以在運行時的代碼中使用Context.registerReceiver()進行註冊。只要是註冊了，當事件來臨的時候，即使程式沒有啟動，系統也在需要的時候啟動程式。各種應用還可以通過使用Context.sendBroadcast () 將它們自己的intent broadcasts廣播給其他應用程式。

　　註冊BroadcastReceiver有兩種方式：

　　(1)在AndroidManifest.xml進行註冊。這種方法有一個特點即使你的應用程式已經關閉了，但這個BroadcastReceiver依然會接受廣播出來的對象，也就是說無論你這個應用程式時開還是關都屬於活動狀態都可以接受到廣播的事件；

　　(2)在代碼中註冊廣播。

　　第一種俗稱靜態註冊，第二種俗稱動態註冊，這兩種註冊Broadcast Receiver的區別：

　　動態註冊較靜態註冊靈活。實驗證明：當靜態註冊一個Broadcast Receiver時，不論應用程式是啟動與否。都可以接受對應的廣播。

　　動態註冊的時候，如果不執行unregister Receiver();方法取消註冊，跟靜態是一樣的。但是如果執行該方法，當執行過以後，就不能接受廣播了。

Content Provider

　　Content Provider 是Android提供的第三方應用資料的訪問方案。

　　在Android中，對資料的保護是很嚴密的，除了放在SD卡中的資料，一個應用所持有的資料庫、檔案等內容，都是不允許其他直接存取的。Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都準備了一扇窗，這就是Content Provider。應用想對外提供的資料，可以通過派生Content Provider類， 封裝成一枚Content Provider，每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST
更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列表的，但實現者不需要按照這個模式來做，給你id的uri你也可以返回清單類型的資料，只要調用者明白，就無妨，不用苛求所謂的REST。

　　另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數，這樣，就可以像資料庫那樣進行投影，選擇和排序。查詢到的結果，以Cursor（參見：reference/android/database/Cursor.html ）的形式進行返回，調用者可以移動Cursor來訪問各列的資料。

　　Content Provider屏蔽了內部資料的儲存細節，向外提供了上述統一的介面模型，這樣的抽象層次，大大簡化了上層應用的書寫，也對資料的整合提供了更方便的途徑。Content Provider內部，常用資料庫來實現，Android提供了強大的Sqlite支援，但很多時候，你也可以封裝檔案或其他混合的資料。

　　在Android中，Content Resolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常，Content Provider需要訪問的可能是資料庫等大資料來源，效率上不足夠快，會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler（參見：reference/android/content/AsyncQueryHandler.html），協助進行非同步訪問Content Provider。

　　在各大組件中，Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的情境，往往會提供非同步訪問的介面，而Content Provider不論效率如何，都提供的是約定的同步提供者。