有關(guān)Android 配置問題進(jìn)行講析
對(duì)于每一個(gè)IT行業(yè)的從業(yè)人員，無論是開發(fā)人員、項(xiàng)目經(jīng)理、還是測試人員，掌握了Android 配置問題這個(gè)很難理解的難題會(huì)使我們的下一階段的工作更加輕松。
比如，在Symbian中，你要等待一個(gè)來電消息，顯示歸屬地之類的，必須讓自己的應(yīng)用忍辱負(fù)重偷偷摸摸的開機(jī)啟動(dòng)，消隱圖標(biāo)隱藏任務(wù)項(xiàng)，潛伏在后臺(tái)，監(jiān)控著相關(guān)事件，等待轉(zhuǎn)瞬即逝的出手機(jī)會(huì)。這是一件很發(fā)指的事情，不但白白耗費(fèi)了系統(tǒng)資源，還留了個(gè)流氓軟件的罵名，這真是賣力不討好的正面典型。
在Android 配置問題中，充分考慮了廣泛的這類需求，于是就有了Broadcast Receiver這樣的一個(gè)組件。每個(gè)Broadcast Receiver都可以接收一種或若干種Intent作為觸發(fā)事件（有不知道Intent的么，后面會(huì)知道了...）。
當(dāng)發(fā)生這樣事件的時(shí)候，系統(tǒng)會(huì)負(fù)責(zé)喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以后，Broadcast Receiver是否在運(yùn)行都變得不重要了，及其綠色環(huán)保。這個(gè)實(shí)現(xiàn)機(jī)制，顯然是基于一種注冊(cè)方式的，Broadcast Receiver將其特征描述并注冊(cè)在系統(tǒng)中，根據(jù)注冊(cè)時(shí)機(jī)，可以分為兩類，被我冠名為冷熱插拔。
所謂冷插拔，就是Broadcast Receiver的相關(guān)信息寫在配置文件中（求配置文件詳情？稍安，后續(xù)奉上...），系統(tǒng)會(huì)負(fù)責(zé)在相關(guān)事件發(fā)生的時(shí)候及時(shí)通知到該Broadcast Receiver，這種模式適合于這樣的場景。某事件方式 -> 通知Broadcast -> 啟動(dòng)相關(guān)處理應(yīng)用。
比如，監(jiān)聽來電、郵件、短信之類的，都隸屬于這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應(yīng)用自己來處理的，通常是在OnResume事件中通過registerReceiver進(jìn)行注冊(cè)，在OnPause等事件中反注冊(cè)，通過這種方式使其能夠在運(yùn)行期間保持對(duì)相關(guān)事件的關(guān)注。
比如，一款優(yōu)秀的詞典軟件（比如，有道詞典...），可能會(huì)有在運(yùn)行期間關(guān)注網(wǎng)絡(luò)狀況變化的需求，使其可以在有廉價(jià)網(wǎng)絡(luò)的時(shí)候優(yōu)先使用網(wǎng)絡(luò)查詢?cè)~匯，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗(yàn)。
一舉兩得一石二鳥一箭雙雕（注，真實(shí)在有道詞典中有這樣的能力，但不是通過Broadcast Receiver實(shí)現(xiàn)的，僅以為例...）。而這樣的監(jiān)聽，只需要在其工作狀態(tài)下保持就好，不運(yùn)行的時(shí)候，管你是天大的網(wǎng)路變化，與我何干。其模式可以歸結(jié)為：啟動(dòng)應(yīng)用 -> 監(jiān)聽事件 -> 發(fā)生時(shí)進(jìn)行處理。
除了接受消息的一方有多種模式，發(fā)送者也有很重要的選擇權(quán)。通常，發(fā)送這有兩類，一個(gè)就是系統(tǒng)本身，我們稱之為系統(tǒng)Broadcast消息，在reference/android/content/Intent.html的Standard Broadcast Actions。
可以求到相關(guān)消息的詳情。除了系統(tǒng)，自定義的應(yīng)用可以放出Broadcast消息，通過的接口可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發(fā)出的稱為Normal broadcast，所有關(guān)注該消息的Receiver，都有機(jī)會(huì)獲得并進(jìn)行處理；后者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在后面的只能吃前面吃剩下的。
前面的心情不好私吞了，后面的只能喝西北風(fēng)了。當(dāng)Broadcast Receiver接收到相關(guān)的消息，它們通常做一些簡單的處理，然后轉(zhuǎn)化稱為一條Notification，一次振鈴。一次震動(dòng)，抑或是啟動(dòng)一個(gè)Activity進(jìn)行進(jìn)一步的交互和處理。所以，雖然Broadcast整個(gè)邏輯不復(fù)雜，卻是足夠有用和好用，它統(tǒng)一了Android 配置問題的事件廣播模型，讓很多平臺(tái)都相形見絀了。
Content Provider，聽著就和數(shù)據(jù)相關(guān)，沒錯(cuò)，這就是Android提供的第三方應(yīng)用數(shù)據(jù)的訪問方案。在Android 配置問題中，對(duì)數(shù)據(jù)的保護(hù)是很嚴(yán)密的。除了放在SD卡中的數(shù)據(jù)，一個(gè)應(yīng)用所持有的數(shù)據(jù)庫、文件、等等內(nèi)容。
都是不允許其他直接訪問的，但有時(shí)候，溝通是必要的，不僅對(duì)第三方很重要，對(duì)應(yīng)用自己也很重要。比如，一個(gè)聯(lián)系人管理的應(yīng)用。如果不允許第三方的應(yīng)用對(duì)其聯(lián)系人數(shù)據(jù)庫進(jìn)行增刪該查，整個(gè)應(yīng)用就失去了可擴(kuò)展力，必將被其他應(yīng)用拋棄，然后另立門戶，自個(gè)玩自個(gè)的去了。
Andorid當(dāng)然不會(huì)真的把每個(gè)應(yīng)用都做成一座孤島，它為所有應(yīng)用都準(zhǔn)備了一扇窗，這就是Content Provider。應(yīng)用想對(duì)外提供的數(shù)據(jù)。可以通過派生ContentProvider類，封裝成一枚Content Provider。
每個(gè)Content Provider都用一個(gè)uri作為獨(dú)立的標(biāo)識(shí)，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實(shí)際上，它比REST更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列表的。
但實(shí)現(xiàn)者不需要按照這個(gè)模式來做，給你id的uri你也可以返回列表類型的數(shù)據(jù)，只要調(diào)用者明白，就無妨，不用苛求所謂的REST。另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數(shù)，這樣，就可以像數(shù)據(jù)庫那樣進(jìn)行投影，選擇和排序。查詢到的結(jié)果。
【編輯推薦】
