y23462001的部落格

一、        Activity

是四個元件中最基本的模組，每一個Activity就代表著一個畫面，可以把它當成是User Interface。系統中的每一個Activity會藉由堆疊來進行管理，若有新的Activity被啟動，會加入至堆疊的最上層。Activity的狀態如下：

l   Runing：代表該Activity在前景中執行，使用者可以看到的狀態。

l   Paused：該Activity處於透明的狀態，使用者仍然看的見，此時的狀態為暫停，該Activity仍然存在，若使用者重新啟動該程式，原本所輸入的內容仍然存在。除非手機上的記憶體嚴重不足，則有可能遭到關閉。

l   Stopped：畫面完全被其它Activity給覆蓋掉，就代表該Activity為停止，仍保留使用者原先輸入之內容，但使用者已經完全看不到這個畫面。除非手機上的記憶體嚴重不足，則有可能遭到關閉。

l   Restarted：若Activity處於Stopped狀態的話，系統可以進行關閉的動作或要求該Activity完成其工作。若要重新顯示時，就必需重新啟動並恢復到之前的狀態。 

二、        Service

可以讓程式於背景執行，如播放音樂時就可以透過Service來處理，而一般的Activity要與Service溝通就會透過IPC。

1、             IPC

IPC的方法有兩種，分別是Intent和Binder，就是為了Activity與Service溝通而建立出來的輕量級IPC框架。

基於Linux的Android系統不支援當前程序訪問其它程序的資料，因此會透過特定的方法來實現，Android藉由Binder來達到程序間的通訊。

2、             Intent

最常使用的時機，是用來喚起其它Activity，是最常使用的IPC機制，若要透過Intent來忽叫Service，則必需在AndroidManifest檔案中對接收此Intent的Service做說明，只要附合Intent就可以和此Service做關聯。但是Intent只能攜帶一些資料來開啟另一個ctivity或Service，沒辦法在程序運行時進行資料的交換。

3、             Binder

最主要是將各個不同的Service連結起來，就像是Service的中心。以實例來說，Service就像是一輛車，而Binder就像是停車場。藉由此機制，我們得以取得其它Service的介面。

一般Service分成兩種，一種是自行定義的Service、一種是系統已建立好的Service(如聽音樂)，若我們想播放音樂，不可能從最底層開始實作，而是採用SDK提供的API，如下圖所示。

此圖說明所建立的OurService會呼叫SDK的MediaPlayer API，此API會透過JNI(Java Native Interface)來呼叫底層的c++函式，圖中也可看出，Binder Driver紀錄了所有的Service的接口，可由此找出MediaPlayerService所在的接口並進行呼叫。當然，Binder所紀錄的不只有系統Service，而是包含自行定義的OurService皆有紀錄。

撰寫Service時會複寫一名為onBind()的函式，這是與Binder相關的函式，這裡會先談到Service Managerment。若Binder是停車場，則Service Managerment便是停車場管理員，它本身也是一個Service。當程式想透過Binder與Service溝通時，皆會先向Service Managerment請求，取的目標的Binder物件，再透過Transact() Method將訊息傳送過去。

Binder和Intent的差別在於，Intent是屬於上層的資料交換，若使用Binder時則是透過JNI與底層的Binder互動，一般狀況下使用Intent是較簡單的方式，但溝通的目標若是屬於較底層的Service，則採用Binder較為合適。

4、             AIDL

是幫助實現Binder通信的一種工具，只要用簡單的函數設定，就會自動產生一個JAVA檔案，其包含了Proxy與Stub的訪問接口。Proxy用於使用者端的程、Stub用於Service的程序，這些程式也可以自行建立，AIDL只是提供一個產生的工具。

三、        Broadcast Receiver

不同於Activity沒有顯示的介面，共分為廣播接收與廣播發送兩大類，廣播實際上指的就是Intent，發送者可以藉由Context.sendBroadcast接口發送廣播，接收者通過Context.registReceiver()動態註冊，或經由AndroidManifiest.xml來進行靜態註冊。(當應用程式發送廣播時，會將發送的Intent與系統註冊的BroadcastReceive進行配對，若配對成功則執行onReceive的函式進行接收)

動態與靜態註冊差別

l   bindService的使用：<receive>註冊的廣播，在onReceive結束後就不存在，所以不能在其中給自己進行異步傳輸，bindService只能使用startService、想跟Service交互可使用peekService。

l   手動控制：若採用動態註冊，可以隨時註冊或取消註冊；若是採用靜態註冊，系統開機後就會自動掃描，開機後一直運行。

l   資源消耗不同：由於動態註冊可以手動控制，因此可以適當的註冊或取消，以節省資源。

l   有效期限不同：透過動態註冊時，若對其進行註冊的Context對像被關閉或是運行了unregisterReceiver方法時就失效了；而靜態註冊時，只要該程式未被關閉，就一直存在。

l   使用情況不同：自己發送與接收的廣播可以採用動態註冊；若是系統常用的廣播可以用靜態註冊。

生命周期方面，BroadcastReceiver在onReceive函數執行結束後就會被釋放掉，不適合做一些異步操作(如下載檔案)，有可能在完成前就被系統關閉。同時由於ANR限制BroadcastReceiver的onReceive必需在主程序進行，因此不適合用於耗時的操作。

1、             分類

BroadcastReceive又分為普通和有序兩類，藉由Context.sendBroadcast發送的廣播接收到的順序是不固定的，而經由Context.sendOrderedBroadcast的廣播則是有序廣播，接收者是有順序的接收到資訊，並且可以對廣播進行修改再往下傳送。

四、        Content Provider

Android提供了四種資料存取機制：Preferences、Files、SQLite與Network。但這四種皆屬於一個應用程式，其它程式無法共享。而Content Provider就是可以讓一個應用程式分享他的資料給其它應用程式，且是以資料庫的型式來呈現資料。例如系統中的通訊錄、系統設定等，就是以SQLite資料庫的方式來儲存，而每一個應用程式都可以建立自己的資料庫，其它的程式想要取用，就必需要有Content Provider開放出來才可以存取。