在本系列教程當中，我們了解了在進行應用程序創建過程中需要使用到的各種Android基礎開發功能。到目前為止，我們已經一同學習了Android應用程序中的結構與典型元素，其中包括用戶界面元素以及數據存儲。利用當下已經掌握的知識，大家完全可以著手創建自己的Android應用。不過在實際操作之前，我們還要梳理一遍部分常用Android組件——這也正是今天這篇文章的主要內容。在本系列的下一篇文章中，我們將探討SDK示例代碼。

介紹

Android應用程序當中包含四大組件：Activity、Service、Content Provider以及Broadcast Receiver。只要大家創建或者使用其中的任何一種，就必須將對應元素添加到項目清單當中。我們之前已經跟Activity打了不少交道，因此在今天的文章中我就不再浪費篇幅加以介紹了。現在讓我們把注意力集中在另外三種主要應用程序組件身上。需要強調的是，我還將介紹大家在應用程序當中最可能用到的其它一些資源，其中包括fragment以及action bar。

1.Service

在Android系統當中，一項Service就相當于一個后臺進程。Service通常被用于那些正在進行或者需要持續很長一段時間的進程。事實上Service并不具備用戶界面，因此它們通常需要與其它組件結合起來以實現功效，例如與Activity聯手。最典型的例子就是，在應用程序當中Activity會在用戶操作的同時啟動一項Service，這項Service也許會將數據上傳至Web資源當中。用戶可以繼續與該Activity進行交互，但與此同時Service的運作卻不受影響——因為它的執行一直在后臺完成。

提示:如果大家希望執行獲取互聯網數據之類的后臺進程，其中也不一定非要使用Service類。根據應用實際需求的不同，大家可能更適合在自己的Activity中利用內部AsyncTask類來解決問題。它能讓后臺進程與用戶界面徹底分離，但我們的Activity仍然可以接收來自AsyncTask的運作結果并將其上更新至用戶界面當中。

要將一項Service組件添加到清單當中，我們需要利用以下語法及其元素取代應用程序元素：

大家可以在Eclipse當中創建一個Service類，其過程與之前介紹過的Activity一樣、只不過這次是把Service選擇為超級類。Service與Activity組件的區別我們之前已經談到過，二者之間存在多種重大差異。如果我們以Activity為起點啟動一項Service，而用戶又通過導航從該Activity切換到了其它應用程序處，那么該Service仍將繼續運行。因此，Service擁有的生命周期與我們所熟知的Activity完全不同，大家需要將這一點牢記于心、從而確保自己的應用程序能夠有效運轉。

其它應用程序組件可以與Service綁定，并向其請求并接收數據。如果一項綁定Service正處于運行當中，那么所有與之相綁定的組件停止之后它也將同時進入停止狀態。盡管Service與應用程序的用戶界面并無關聯，但隨Activity啟動的Service會與之運行在同一線程當中。然而，如果大家的Service需要使用大量處理資源，那么我們最好為其創建一個獨立的運行線程。請大家 點擊此處 查看更多來自《Android開發者指南》中關于Service的說明。

2.Content Provider

另一種組件Content Provider用于管理數據集。這里指的數據集既可以單純歸屬于我們的應用程序，也可以與其它應用所共享、能夠對數據進行查詢及修改。如果大家為自己的應用程序創建了一個用于管理數據的Content Provider，那么我們的UI組件（例如Activity）就能夠使用該Content Provider，通常是利用Content Resolver類來實現與數據的交互。當被其它應用程序使用時，該Content Provider則通過標準方法來訪問數據、從而與數據庫等結構化數據集實現交互。

如果大家對于關系類數據庫已經非常熟悉，那么應該非常了解Content Provider所使用的數據訪問方法。數據會被Content Provider提交給一系列包含行與列的表格，其中每行（或者每條記錄）中的列都包含一個單獨的數據值。因此，處理通過Content Provider返回的數據與處理數據庫查詢結果非常相似。

雖然有時候我們可能會創建一個專門的Content Provider程序，但在最初著手開發自己的第一款應用時、大家基本上還是會直接使用由其他開發者或者Android系統本身所提供的Content Provider——例如設備日程表或者聯系人。Content Provider能夠定義客戶端應用所需要的權限，從而實現內容使用。為了在應用程序當中使用Content Provider，大家需要在清單當中為其添加相應的權限。

提示:如果大家只是需要一套應用程序當中的結構化數據源，那么我們通常并不需要單獨創建Content Provider。大家可以創建一套只適用于我們應用程序本身的SQLite數據庫，而完全不需要使用Content Provider類。我們需要創建Content Provider的惟一情況在于，大家希望從我們的應用程序當中將結構化數據復制到其它應用處，或者大家希望使用搜索框架。

3.Broadcast Receiver

Android系統能夠發出多種應用程序能夠響應的廣播信息。大家也可以開發出應用程序來發出這些廣播，但這種可能性與監聽現有廣播相比要低得多，至少對我們的第一款應用來說是這樣。系統通知當中包含關于設備硬件的各類信息，例如電池電量、屏幕關閉以及充電器是否接入插座等等。

為了接收來自Android系統的廣播通知，我們的應用程序需要使用Broadcast Receiver。舉個典型的例子，電池電量工具會在電池電量發生實際變化時更新顯示結果。在這種情況下，大家可以將Service類與Broadcast Receiver配合使用，從而保證應用程序始終在后臺監聽通知內容。

Android系統將廣播通知稱為intent，它能夠被用于啟動Activity。作為系統執行的操作，intent可以實現Activity啟動或者發出通知。要使用Broadcast Receiver，我們的應用程序必須在清單中對其作出聲明；此外還有一套備選intent filter，用于指示我們想要接收的操作：

通過以上代碼，我們應用中的Broadcast Receiver就能夠接收“battery low（電池電量低）”這一intent。請注意，我們無法通過在清單中聲明action這種方式接收全部系統通知。在某些情況下，大家必須完成注冊來實現通知接收，例如在Java當中使用BATTERY_CHANGED action。

4.其它類

正如大家所見，Android組件的設計初衷在于為不同應用程序提供彼此之間的交互效果。正如廣播通知可用于系統之上的任何應用，Android還提供其它一系列action、幫助我們在應用程序中完成各類常見任務——例如撥打電話號碼。同樣，大家也可以使用由其他開發人員所提供的功能，從而快速實現預定處理流程、節約代碼開發量并幫助自己將更多精力集中在應用程序的獨特之處上。當我們啟動一項intent時，可以通過設置使其向啟動中的Activity返回一個結果——即使所啟動的intent并非我們應用程序的組成部分。這就使我們的應用能夠在要求操作完成之后繼續運行。

其它值得關注的Android組件還包括fragment以及action bar。下面就讓我們簡單對二者進行探討：

Fragment

比起單純利用Activity以及布局配置來定義應用程序中各個屏幕下的用戶界面，使用fragment的話效率可能會更高一些。在fragment的幫助下，大家可以將自己的用戶界面拆分為邏輯部分，甚至在應用程序的多個屏幕之間重復使用同樣的部分。這樣一來，我們不僅能夠節約大量花在實現同樣視覺/交互元素上的重復勞動，同時也實現了修改一點即完成對整款應用變更的效果。Fragment在Android系統中屬于Activity中的組成部分，因此每個fragment都要與其所在的Activity生命周期相適應。

Action Bar

在應用程序開發過程中，action bar也是我們經常需要用到的關鍵性用戶界面元素。它的作用在于為我們的應用程序提供足以作用于整套Android系統的用戶界面，這也使它成為該平臺用戶們最熟悉的元素。一般來說，action bar當中所顯示的條目包括用戶在應用程序當中所處的位置以及應用程序各個部分之間的導航系統。要在Activity當中使用action bar，大家需要保證自己的類當中包含ActionBarActivity類，并在清單當中將AppCompat主題應用在該Activity當中。

總結

具體使用哪一種Android類及組件取決于大家的應用程序到底要執行哪些任務。不過經過文章的論述，相信應該能夠幫助大家對類與組件的類型及數量有所了解，并根據實際情況作出正確選擇。對于特定特性或者功能來說，我們往往很難決定具體該使用哪款組件或者類，因此請大家在判斷之前確保自己對它們的作用擁有清晰的了解。在接下來的教程當中，我們將探討Android示例代碼以及應用程序的發布流程。

原文鏈接：

http://mobile.tutsplus.com/tutorials/android/android-sdk-common-android-components/