【Android】四大基本元件——Activity、Service、ContentProvider和BroadcastReceive

Android應用中通常由一個或多個基本元件構成整個應用程式APP，最常見的就是Activity了。Android有四大元件，六大布局（好像也有人說四大元件，五大布局）。Activity就是四大元件之一，除了Activity之外還有Service、ContentProvider和BroadcastReceive。

什麼是Activity呢？它給我們最直接的感受就是我們打開APP之後我們所看到的就是一個Activity。每個Android App至少會有一個Activity。Activity主要負責螢幕顯示畫面，并處理與使用者的互動。就是監聽并對使用者事件做出響應。起初我誤認為，Activity還是各種控件的容器和載體，其實不對。控件的容器是View元件，Activity隻能通過setContentView（view）顯特定元件。而或許可以把Activity看成是view的容器，因為通過Activity可以講View顯示出來。

每個Activity或者說每次使用四大元件都應該跟擷取權限一樣在AndroidManifests.xml中聲明。而且，我們發現Android開發過程中沒有C語言或是C++語言中必須要有的main函數。同樣是在AndroidMainfests.xml中聲明了App啟動哪個Activity，這個Activity就是這個App的入口。類似于main函數。

Service是沒有界面的元件，它不能自己啟動，隻能由其他元件來啟動它，當然Service也是可以啟動其他Service的，它隻能在背景運作，可以和其他元件進行互動。舉例：我們進入音樂播放器的Activity中點選了播放音樂的Button，此時就開始播放音樂了。如果這時候，我們要和朋友聊天或是要使用别的App，那麼我們就會切出去。此時能音樂并不會是以而停止，因為Sevice在背景運作并沒有停止。Service有兩種方式：

（1）Context.startService（）

      啟動時，startService –> onCreate() –> onStart()

       停止時，stopService –> onDestroy()

（2）Context.bindService（）：

       綁定時,bindService  -> onCreate() –> onBind()

       解綁定時,unbindService –>onUnbind() –> onDestory()

這兩者的差別在于Service将自己的生命周期交給誰？如果是采用第一種方法，Service将生命周期控制在自己手中，即使啟動它的元件例如Activity已經銷毀了，但是Service并不會被銷毀；如果采用第二種綁定的方式，就是将自己的生命周期和啟動它的元件綁定在一起了。此時，如果啟動它的元件銷毀了，Service也會跟着被銷毀。

ContentProvider：各個應用程式是互相獨立的，但是有的時候對我們而言是很不友善的。比如，我們準備通過社交軟體發送一張我們之前出去旅遊時候用手機照相機拍攝的照片的時候，如果各個程式是互相獨立的，那麼社交軟體是無法通路到我們拍攝的照片的。那麼就有了ContentProvider這種機制來解決這個問題。它可以讓App之間實作資料交換。通常情況下，ContentProvider與ContentResolver結合使用，一個應用程式使用ContentProvider暴露自己的資料，另一個應用程式使用ContentResolver來通路資料。Android為這種跨應用的資料交換提供了一個标準，當使用者實作自己的ContentProvider時，需要實作如下抽象方法：

（1）insert（Uri，ContentValues）：向ContentProvider插入資料

（2）delete（Uri，ContentValues）：删除ContentProvider中指定的資料

（3）update（Uri，ContentValues，String，String[ ]）：更新ContentProvider中指定的資料

（4）query（Uri，String[ ]，String，String[ ]，String）：從ContentProvider查詢資料

Broadcast是一種廣泛應用在應用程式之間的傳輸資訊的機制。而BroadcastReceive是對發送出來的Broadcast進行過濾并響應的一類元件。可以使用BroadcastReceive讓應用對外部事件做出響應。比如：鬧鐘。BroadcastReceive在沒到我們設定時間的時候是不會發生響應的，是以此時的時間事件不是它需要的，是以被它過濾了。當且僅當到了我們設定的時間的時候，此時的時間是有用的，那麼BroadcastReceive就會對此做出響應。

而且，BroadcastReceive有别與前面三個元件的一點是：BroadcastReceive沒有強制要求要在AndroidManifest.xml中聲明。因為BroadcastReceive也可以在運作是的代碼中使用Context.registerReceive（）進行注冊聲明。不論使用哪種方法進行注冊，當時間來臨的時候，即使程式沒有啟動，系統也在需要的時候啟動程式。各種應用還可以通過使用Context.sendBroadcast（）将他們自己的Intent Broadcast廣播給其他應用程式。應該也是利用了這一點，各種全家桶才能夠互相喚醒，不斷自啟。