Android應用的基本組件介紹

Activity和View

Activity是Android應用中負責與用戶交互的組件——大致上可以把它想象成Swing變成中的JFrame控件。不過它與JFrame的區別在于：JFrame本身可以設置布局管理器，不斷地向JFrame中添加組件，但Activity只能通過setContentView(View)來顯示指定組件。

View組件是所有UI控件、容器控件的基類，View組件就是Android應用中用戶實實在在看到的部分。但View組件需要放到容器組件中，或者使用Activity將它顯示出來。如果需要通過某個Activity把指定View顯示出來，調用Activity的setContentView()方法即可。

setContentView()方法可接受一個View對象作為參數，例如如下代碼：

//創建一個線性布局管理器 LinearLayout layout = new LinearLayout(this); //設置該Activity顯示layout super.setContentView(layout);

上面的程序通過代碼創建了一個LinearLayout對象（它是ViewGroup的子類，ViewGroup又是View的子類），接著調用Activity的setContentView(layout)把這個布局管理器顯示出來。
setContentView()方法也可接受一個布局管理資源的ID作為參數，例如如下代碼：

//設置該Activity顯示main.xml文件定義的View setContentView(R.layout.main)

從這個角度來看，大致上可以把Activity理解成Swing中的JFrame組件。當然，Activity可以完成的功能比JFrame更多。

Activity為Android應用提供了可視化用戶界面，如果該Android應用需要多個用戶界面，那么這個Android應用將會包含多個Activity，多個Activity組成Activity棧，當前活動的Activity位于棧頂。

Activity包含了一個setTheme(int resid)方法來設置其窗口的風格，例如我們希望窗口不顯示標題、以對話框形式顯示窗口，都可通過該方法來實現。

Service

Service與Activity的地位是并列的，它也代表一個單獨的Android組件。Service與Activity的區別在于：Service通常位于后臺運行，它一般不需要與用戶交互，因此Service組件沒有圖形用戶界面。

與Activity組件需要繼承Activity基類相似，Service組件需要繼承Service基類。一個Service組件被運行起來之后，它將擁有自己獨立的生命周期，Service組件通常用于為其他組件提供后臺服務或監控其他組件的運行狀態。

BroadcastReceiver

BroadcastReceiver是Android應用中另一個重要的組件，顧名思義，BroadcastReceiver代表廣播消息接收器。從代碼實現角度來看，BroadcastReceiver非常類似于事件編程中的監聽器。與普通事件監聽器不同的是：普通事件監聽器監聽的事件源是程序中的對象；而BroadcastReceiver監聽的事件源是Android應用中的其他組件。

使用BroadcastReceiver組件接收廣播消息比較簡單，開發者只要實現自己的BroadcastReceiver子類，并重寫onReceive(Context context, Intent intent)方法即可。當其他組件通過sendBroadcast()、sendStickyBroadcast()或sendOrderedBroadcast()方法發送廣播消息時，如該BroadcastReceiver也對該消息“感興趣”（通過IntentFilter配置），BroadcastReceiver的onReceiver(Context context, Intent intent)方法將會被觸發。

開發者實現了自己的BroadcastReceiver之后，通常有兩種方式來注冊這個系統級的“事件監聽器”。

• 在Java代碼中通過Context.registReceiver()方法注冊BroadcastReceiver。
• 在AndroidManifest.xml文件中使用

ContentProvider

對于Android應用而言，它們必須相互獨立，各自運行在自己的Dalvik虛擬機實例中，如果這些Android應用之間需要實現實時的數據交換。例如我們開發了一個發送短信的程序，當發送短信時需要從聯系人管理應用中讀取指定聯系人的數據——這就需要多個應用程序之間進行實時的數據交換。

Android系統為這種跨應用的數據交換提供了一個標準：ContentProvider。當用戶實現自己的ContentProvider時，需要實現如下抽象方法。

• insert(Uri, ContentValues)：向ContentProvider插入數據。
• delete(Uri, ContentValues)：刪除ContentProvider中指定數據。
• update(Uri, ContentValues, String, String[])：更新ContentProvider中指定數據。
• query(Uri, String[], String, String[], String)：從ContentProvider查詢數據。

通常與ContentProvider結合使用的是ContentResolver，一個應用程序使用ContentProvider暴露自己的數據，而另一個應用程序則通過ContentResolver來訪問數據。

Intent和IntentFilter

嚴格地說，Intent并不是Android應用的組件，但它對于Android應用的作用非常大——它是Android應用內不同組件之間通信的載體。當Android運行時需要連接不同的組件時，通常就需要借助于Intent來實現。Intent可以啟動應用中另一個Activity，也可以啟動一個Service組件，還可以發送一條廣播消息來觸發系統中的BroadcastReceiver。也就是說，Activity、Service、BroadcastReceiver三種組件之間的通信都以Intent作為載體，只是不同組件使用Intent的機制略有區別而已。

• 當需要啟動一個Activity時，可調用Context的startActivity(Intent intent)方法，該方法的Intent參數封裝了需要啟動的目標Activity的信息。
• 當需要啟動一個Service時，可調用Context的startService(Intent intent)方法或bindService(Intent service, ServiceConnection conn, int flags)方法，這兩個方法中的Intent參數封裝了需要啟動的目標Service的信息。
• 當需要觸發一個BroadcastReceiver時，可調用Context的sendBroadcast(Intent intent)、sendStickyBroadcast(Intent intent)或sendOrderedBroadcast(Intent intent, String receiverPermission)方法來發送廣播消息，這三個方法中的Intent參數封裝了需要觸發的目標Broadcas的信息。

當一個組件通過Intent表示了啟動或者觸發另一個組件的“意圖”之后，這個意圖可分為兩類。

• 顯式Intent：顯式Intent明確指定需要啟動或者觸發的組件的名稱。
• 隱式Intent：隱式Intent只是指定需要啟動或者觸發的組件應滿足怎樣的條件。

對于顯式Intent而言，Android系統無須對該Intent做任何解析，系統直接找到指定的目標組件，啟動或觸發它即可。

對于隱式Intent而言，Android系統需要對該Intent進行解析，解析出它的條件，然后再去系統中查找與之匹配的目標條件。如果找到符合條件的組件，就啟動或觸發它們。

那么Android系統如何判斷被調用組件是否符合隱式Intent呢？這就需要靠IntentFilter來實現了，被調用組件可通過IntentFilter來聲明自己所滿足的條件——也就是聲明自己到底能處理哪些隱式Intent。

轉載于:https://www.cnblogs.com/zongzhankui/p/5875324.html

總結

以上是生活随笔為你收集整理的Android应用的基本组件介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。