有關Android 配置問題進行講析

對於每一個IT行業的從業人員，無論是開發人員、項目經理、還是測試人員，掌握了android 配置問題這個很難理解的難題會使我們的下一階段的工作更加輕松。

比如，在Symbian中，你要等待一個來電消息，顯示歸屬地之類的，必須讓自己的應用忍辱負重偷偷摸摸的開機啟動，消隱圖標隱藏任務項，潛伏在後台，監控著相關事件，等待轉瞬即逝的出手機會。這是一件很發指的事情，不但白白耗費了系統資源，還留了個流氓軟件的罵名，這真是賣力不討好的正面典型。

在android 配置問題中，充分考慮了廣泛的這類需求，於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件（有不知道Intent的麼，後面會知道了...）。

當發生這樣事件的時候，系統會負責喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以後，Broadcast Receiver是否在運行都變得不重要了，及其綠色環保。這個實現機制，顯然是基於一種注冊方式的，Broadcast Receiver將其特征描述並注冊在系統中，根據注冊時機，可以分為兩類，被我冠名為冷熱插拔。

所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，後續奉上...），系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver，這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。

比如，監聽來電、郵件、短信之類的，都隸屬於這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。

比如，一款優秀的詞典軟件（比如，有道詞典...），可能會有在運行期間關注網絡狀況變化的需求，使其可以在有廉價網絡的時候優先使用網絡查詢詞匯，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗。

一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過Broadcast Receiver實現的，僅以為例...）。而這樣的監聽，只需要在其工作狀態下保持就好，不運行的時候，管你是天大的網路變化，與我何干。其模式可以歸結為：啟動應用 -> 監聽事件 -> 發生時進行處理。

除了接受消息的一方有多種模式，發送者也有很重要的選擇權。通常，發送這有兩類，一個就是系統本身，我們稱之為系統Broadcast消息，在reference/android/content/Intent.Html的Standard Broadcast Actions。

可以求到相關消息的詳情。除了系統，自定義的應用可以放出Broadcast消息，通過的接口可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast，所有關注該消息的Receiver，都有機會獲得並進行處理；後者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在後面的只能吃前面吃剩下的。

前面的心情不好私吞了，後面的只能喝西北風了。當Broadcast Receiver接收到相關的消息，它們通常做一些簡單的處理，然後轉化稱為一條Notification，一次振鈴。一次震動，抑或是啟動一個Activity進行進一步的交互和處理。所以，雖然Broadcast整個邏輯不復雜，卻是足夠有用和好用，它統一了android 配置問題的事件廣播模型，讓很多平台都相形見绌了。

Content Provider，聽著就和數據相關，沒錯，這就是android提供的第三方應用數據的訪問方案。在android 配置問題中，對數據的保護是很嚴密的。除了放在SD卡中的數據，一個應用所持有的數據庫、文件、等等內容。

都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。比如，一個聯系人管理的應用。如果不允許第三方的應用對其聯系人數據庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然後另立門戶，自個玩自個的去了。

Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都准備了一扇窗，這就是Content Provider。應用想對外提供的數據。可以通過派生ContentProvider類，封裝成一枚Content Provider。

每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列表的。

但實現者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數據，只要調用者明白，就無妨，不用苛求所謂的REST。另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數，這樣，就可以像數據庫那樣進行投影，選擇和排序。查詢到的結果。