詳解Android組件的使用
加入技術交流群
組件（Component），在談及所謂架構和重用的時候，是一個重要的事情。很多時候都會說基于組件的軟件架構，指的是期望把程序做樂高似的，有一堆接口標準封裝完整的組件放在哪里，想用的時候取上幾個一搭配，整個程序就構建完成了。
在開篇的時候就在說，Android是一個為組件化而搭建的平臺，它引入所謂Mash-Up的概念，這使得你在應用的最上層，想做的不組件化都是很困難的一件事情（底層邏輯，好吧，管不了...）。具體說來，Android有四大組件四喜丸子：Activity、Service、Broadcast Receiver、Content Provider。
Activity
做一個完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口，在我看來，從這個層面的視角來看，Android的Activity特像網站的頁面。
首先，一個網站，如果一張頁面都沒有，那...，真是一顆奇葩。而一張頁面往往都有個獨立的主題和功能點，比如登錄頁面，注冊頁面，管理頁面，如是。
在每個頁面里面，會放一些鏈接，已實現(xiàn)功能點的串聯(lián)，有的鏈接點了，刷，跑到同一站點的另一個頁面去了；有的鏈接點了，啾，可能跳到其他網站的頁面去；還有的鏈接點了，恩...，這次沒跑，但當前頁面的樣子可能有所變化了。這些模式，和Activity給人的感覺很像，只不過實現(xiàn)策略不同罷了，畢竟Android這套架構的核心思想，本身就來自源于Web的Mash-Up概念，視為頁面的客戶端化，也未嘗不可。
Activity，在四大組件中，無疑是最復雜的，這年頭，一樣東西和界面掛上了勾，都簡化不了，想一想，獨立做一個應用有多少時間淪落在了界面上，就能琢磨清楚了。從視覺效果來看，一個Activity占據當前的窗口，響應所有窗口事件，具備有控件，菜單等界面元素。從內部邏輯來看，Activity需要為了保持各個界面狀態(tài)，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉跳邏輯。對于開發(fā)者而言，就需要派生一個Activity的子類，然后埋頭苦干上述事情。對于Activity的更多細節(jié)，先可以參見：reference/android/app/Activity.html。后續(xù)，會獻上更為詳盡的剖析。
Service
服務，從最直白的視角來看，就是剝離了界面的Activity，它們在很多Android的概念方面比較接近，都是封裝有一個完整的功能邏輯實現(xiàn)，只不過Service不拋頭露臉，只是默默無聲的做堅實的后盾。
但其實，換個角度來看，Android中的服務，和我們通常說的Windows服務，Web的后臺服務又有一些相近，它們通常都是后臺長時間運行，接受上層指令，完成相關事務的模塊。用運行模式來看，Activity是跳，從一個跳到一個，呃...，這有點像模態(tài)對話框（或者還像web頁面好了...），給一個輸入（抑或沒有...），然后不管不顧的讓它運行，離開時返回輸出（同抑或沒有...）。
而Service不是，它是等，等著上層連接上它，然后產生一段持久而纏綿的通信，這就像一個用了Ajax頁面，看著沒啥變化，偷偷摸摸的和Service不知眉來眼去多少回了。
但和一般的Service還是有所不同，Android的Service和所有四大組件一樣，其進程模型都是可以配置的，調用方和發(fā)布方都可以有權利來選擇是把這個組件運行在同一個進程下，還是不同的進程下。這句話，可以拿把指甲刀刻進腦海中去，它凸顯了Android的運行特征。如果一個Service，是有期望運行在于調用方不同進程的時候，就需要利用Android提供的RPC機制，為其部署一套進程間通信的策略。
 |
Android中用來做數(shù)據序列化的類是Parcel，參見：/reference/android/os/Parcel.html，封裝了序列化的細節(jié)，向外提供了足夠對象化的訪問接口，Android號稱實現(xiàn)非常高效。
還有就是AIDL (Android Interface Definition Language) ，一種接口定義的語言，服務的RPC接口，可以用AIDL來描述，這樣，ADT就可以幫助你自動生成一整套的代理模式需要用到的類，都是想起來很乏力寫起來很苦力的那種。更多內容，可以再看看：guide/developing/tools/aidl.html，如果有興致，可以找些其他PRC實現(xiàn)的資料lou幾眼。
關于Service的實現(xiàn)，還強推參看API Demos這個Sample里面的RemoteService實現(xiàn)。它完整的展示了實現(xiàn)一個Service需要做的事情：那就是定義好需要接受的Intent，提供同步或異步的接口，在上層綁定了它后，通過這些接口（很多時候都是RPC的...）進行通信。在RPC接口中使用的數(shù)據、回調接口對象，如果不是標準的系統(tǒng)實現(xiàn)（系統(tǒng)可序列化的），則需要自定義aidl，所有一切，在這個Sample里都有表達，強薦。
Service從實現(xiàn)角度看，最特別的就是這些RPC的實現(xiàn)了，其他內容，都會接近于Activity的一些實現(xiàn)，也許不再會詳述了。
Broadcast Receiver
在實際應用中，我們常需要等，等待系統(tǒng)抑或其他應用發(fā)出一道指令，為自己的應用擦亮明燈指明方向。而這種等待，在很多的平臺上，都會需要付出不小的代價。
比如，在Symbian中，你要等待一個來電消息，顯示歸屬地之類的，必須讓自己的應用忍辱負重偷偷摸摸的開機啟動，消隱圖標隱藏任務項，潛伏在后臺，監(jiān)控著相關事件，等待轉瞬即逝的出手機會。這是一件很發(fā)指的事情，不但白白耗費了系統(tǒng)資源，還留了個流氓軟件的罵名，這真是賣力不討好的正面典型。
在Android中，充分考慮了廣泛的這類需求，于是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發(fā)事件（有不知道Intent的么，后面會知道了...），當發(fā)生這樣事件的時候，系統(tǒng)會負責喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以后，Broadcast Receiver是否在運行都變得不重要了，及其綠色環(huán)保。
這個實現(xiàn)機制，顯然是基于一種注冊方式的，Broadcast Receiver將其特征描述并注冊在系統(tǒng)中，根據注冊時機，可以分為兩類，被我冠名為冷熱插拔。所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，后續(xù)奉上...），系統(tǒng)會負責在相關事件發(fā)生的時候及時通知到該Broadcast Receiver，這種模式適合于這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如，監(jiān)聽來電、郵件、短信之類的，都隸屬于這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。比如，一款優(yōu)秀的詞典軟件（比如，有道詞典...），可能會有在運行期間關注網絡狀況變化的需求，使其可以在有廉價網絡的時候優(yōu)先使用網絡查詢詞匯，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗，一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過Broadcast Receiver實現(xiàn)的，僅以為例...）。而這樣的監(jiān)聽，只需要在其工作狀態(tài)下保持就好，不運行的時候，管你是天大的網路變化，與我何干。其模式可以歸結為：啟動應用 -> 監(jiān)聽事件 -> 發(fā)生時進行處理。
除了接受消息的一方有多種模式，發(fā)送者也有很重要的選擇權。通常，發(fā)送這有兩類，一個就是系統(tǒng)本身，我們稱之為系統(tǒng)Broadcast消息，在reference/android/content/Intent.html的Standard Broadcast Actions，可以求到相關消息的詳情。除了系統(tǒng)，自定義的應用可以放出Broadcast消息，通過的接口可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發(fā)出的稱為Normal broadcast，所有關注該消息的Receiver，都有機會獲得并進行處理；后者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在后面的只能吃前面吃剩下的，前面的心情不好私吞了，后面的只能喝西北風了。
當Broadcast Receiver接收到相關的消息，它們通常做一些簡單的處理，然后轉化稱為一條Notification，一次振鈴，一次震動，抑或是啟動一個Activity進行進一步的交互和處理。所以，雖然Broadcast整個邏輯不復雜，卻是足夠有用和好用，它統(tǒng)一了Android的事件廣播模型，讓很多平臺都相形見絀了。更多Broadcast Receiver相關內容，參見：/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider，聽著就和數(shù)據相關，沒錯，這就是Android提供的第三方應用數(shù)據的訪問方案。在Android中，對數(shù)據的保護是很嚴密的，除了放在SD卡中的數(shù)據，一個應用所持有的數(shù)據庫、文件、等等內容，都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。
比如，一個聯(lián)系人管理的應用。如果不允許第三方的應用對其聯(lián)系人數(shù)據庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然后另立門戶，自個玩自個的去了。
Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都準備了一扇窗，這就是Content Provider。應用想對外提供的數(shù)據，可以通過派生ContentProvider類，封裝成一枚Content Provider，每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列表的，但實現(xiàn)者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數(shù)據，只要調用者明白，就無妨，不用苛求所謂的REST。
另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數(shù)，這樣，就可以像數(shù)據庫那樣進行投影，選擇和排序。查詢到的結果，以Cursor（參見：reference/android/database/Cursor.html ）的形式進行返回，調用者可以移動Cursor來訪問各列的數(shù)據。
Content Provider屏蔽了內部數(shù)據的存儲細節(jié)，向外提供了上述統(tǒng)一的接口模型，這樣的抽象層次，大大簡化了上層應用的書寫，也對數(shù)據的整合提供了更方便的途徑。Content Provider內部，常用數(shù)據庫來實現(xiàn)，Android提供了強大的Sqlite支持，但很多時候，你也可以封裝文件或其他混合的數(shù)據。
在Android中，ContentResolver是用來發(fā)起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的接口。但通常，Content Provider需要訪問的可能是數(shù)據庫等大數(shù)據源，效率上不足夠快，會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler（參見：reference/android/content/AsyncQueryHandler.html），幫助進行異步訪問Content Provider。
在各大組件中，Service和Content Provider都是那種需要持續(xù)訪問的。Service如果是一個耗時的場景，往往會提供異步訪問的接口，而Content Provider不論效率如何，都提供的是約定的同步訪問接口。我想這遵循的就是場景導向設計的原則，因為Content Provider僅是提供數(shù)據訪問的，它不能確信具體的使用場景如何，會怎樣使用它的數(shù)據；而相比之下，Service包含的邏輯更復雜更完整，可以抉擇大部分時候使用某接口的場景，從而確定最貼切的接口是同步還是異步，簡化了上層調用的邏輯。
配置
四大組件說完了，四大組件幕后的英雄也該出場了，那就是每個應用都會有一份的配置文件，名稱是AndroidManifest.xml，在工程的根目錄下。在這個配置文件中，不僅會描述一些應用相關的信息，很重要的，會包含一個應用中所有組件的信息。如果你派生Activity或者Service實現(xiàn)了一個相關的類，這只是把它組件化的第一步，你需要把這個類的相關信息寫到配置文件中，它才會作為一個組件被應用到，否則只能默默無聞的黯淡度過余生。
擺了一幅圖出來，這次不是偷來的，是敝帚自珍原創(chuàng)，所以沒有意外的畫的很丑，但基本還是可以體現(xiàn)出一些意思。在In Others的部分，這里是一般平臺應用之間通信和交互的模型，每個應用都有很強烈的應用邊界（往往表現(xiàn)為進程邊界...），App 1的還是App 2的，分得很是清楚。每個應用內部，都有自己的邏輯去切分功能組件，這樣的切分通常沒有什么標準，率性而為。應用間的交互邏輯也比較零散，App 1與App 2交互，往往需要明確知道對方應用的具體信息，比如進程ID，進程名稱之類的，這樣使得應用和應用之間的聯(lián)系，變得很生硬。而上層應用和系統(tǒng)應用的通信，往往有很多特定的模式，這種模式，很可能是無法直接應用在普通應用之間的，換而言之，系統(tǒng)應用是有一定特殊性的。
重點，在圖的下半部，描述的是Android的應用情形。在Android中，應用的邊界，在組件這個層面，是極度模糊，什么進程、什么應用，都可以不必感知到。舉個例子，App 1，實現(xiàn)了A和B兩個組件，App 2，實現(xiàn)了C這個組件。A和C，都想使用B這個組件，那么它們的使用方式是完全一致的，都需要通過系統(tǒng)核心的組件識別和通信機制，找到和使用組件B。A，雖說和B是一個娘胎里蹦出來的，很不好意思，沒有任何特殊的后面和捷徑，還是要跑規(guī)矩的途徑才能用到，一片和諧社會的景象油然而生。
在Android中，所有組件的識別和消息傳遞邏輯都必須依賴底層核心來進行（通信可以沒有底層核心的參與，比如一旦Service找到了，就可以和它產生持久的通信...），沒有底層核心的牽線搭橋，任何兩個組件都無法產生聯(lián)系。比如一個Activity，跳到另一個Activity，必須要向底層核心發(fā)起一個Intent，有底層解析并認可后，會找到另一個Activity，把相關消息和數(shù)據傳給它。一個Activity想使用Content Provider中的數(shù)據，必須通過底層核心解析相關的uri，定位到這個Content Provider，把參數(shù)傳遞給它，然后返回Activity需要的Cursor。這樣的設計，保證了底層核心對所有組件的絕對掌控權和認知權，使得搭積木似的開發(fā)變成可能。
為了，使得核心系統(tǒng)能夠完整的掌握每個組件的信息，這就需要配置文件了。配置文件，就是將組件插到底層核心上的這個插頭。只有通過這個插頭插在底層核心的插座上（不要亂想，非十八禁...），組件才能夠發(fā)光發(fā)熱，閃耀光芒。
組件的配置信息在我看來主要包含兩個方面，一部分是描述如何認知。比如，Activity、Service、Broadcast Receiver都會有名字信息，和希望能夠把握的Intent信息（姑且看成消息好了...），Content Provider會有一個描述其身份的uri。當其他組件通過這樣的名字或者Intent，就可以找到它。
另一部分是運行相關的信息。這個組件，期望怎么來運行，放在單獨的進程，還是和調用者一個進程，還是找相關的其他組件擠在同一個進程里面，這些內容，都可以在配置的時候來決定（調用者在這個約束范圍內，有進一步的選擇權...）。更多配置項，請參見：guide/topics/manifest/manifest-intro.html。
通過前續(xù)內容，也許可以幫助大家對Android組件有個初略的了解。但這些了解都還停留在靜態(tài)層面，程序是個動態(tài)的概念，關于各個組件具體是怎么聯(lián)系在一起的，如何手拉手運行起來完成一項功能的，這便是后話了。
發(fā)布者：博子
評論