建站
咨詢
售后
建站咨詢
新聞中心
對于每一個IT行業(yè)的從業(yè)人員，無論是開發(fā)人員、項目經(jīng)理、還是測試人員，掌握了Android 配置問題這個很難理解的難題會使我們的下一階段的工作更加輕松。
比如，在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)中，根據(jù)注冊時機，可以分為兩類，被我冠名為冷熱插拔。
所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，后續(xù)奉上...），系統(tǒng)會負責在相關事件發(fā)生的時候及時通知到該Broadcast Receiver，這種模式適合于這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。
比如，監(jiān)聽來電、郵件、短信之類的，都隸屬于這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。
比如，一款優(yōu)秀的詞典軟件（比如，有道詞典...），可能會有在運行期間關注網(wǎng)絡狀況變化的需求，使其可以在有廉價網(wǎng)絡的時候優(yōu)先使用網(wǎng)絡查詢詞匯，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗。
一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過Broadcast Receiver實現(xiàn)的，僅以為例...）。而這樣的監(jiān)聽，只需要在其工作狀態(tài)下保持就好，不運行的時候，管你是天大的網(wǎng)路變化，與我何干。其模式可以歸結為：啟動應用 -> 監(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 配置問題的事件廣播模型，讓很多平臺都相形見絀了。
Content Provider，聽著就和數(shù)據(jù)相關，沒錯，這就是Android提供的第三方應用數(shù)據(jù)的訪問方案。在Android 配置問題中，對數(shù)據(jù)的保護是很嚴密的。除了放在SD卡中的數(shù)據(jù)，一個應用所持有的數(shù)據(jù)庫、文件、等等內(nèi)容。
都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。比如，一個聯(lián)系人管理的應用。如果不允許第三方的應用對其聯(lián)系人數(shù)據(jù)庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然后另立門戶，自個玩自個的去了。
Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都準備了一扇窗，這就是Content Provider。應用想對外提供的數(shù)據(jù)。可以通過派生ContentProvider類，封裝成一枚Content Provider。
每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列表的。
但實現(xiàn)者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數(shù)據(jù)，只要調用者明白，就無妨，不用苛求所謂的REST。另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數(shù)，這樣，就可以像數(shù)據(jù)庫那樣進行投影，選擇和排序。查詢到的結果。
【編輯推薦】
- Android應用程序組建原理深入剖析
- Android SMS短信服務相關概念簡述
- PythonAndroid數(shù)據(jù)庫相關代碼解讀
- PythonAndroid安裝卸載程序具體操作方法解析
- Android應用程序的四個關鍵點
本文標題：有關Android 配置問題進行講析
網(wǎng)站路徑：http://www.dlmjj.cn/article/cdoicii.html
