今天研究了一下Google提供的有關Android應用程式組件的解釋。瞭解點理論原理找找Android應用程式開發的思考方向!
至少知道了要開發一個能夠與Android系統驅動的移動終端互動的軟體,需要從那些方面去撬開Android系統的嘴,讓它跟你的應用程式說話,交流,幫你的應用程式做事。
細想一下,開發一個應用程式安裝到Android驅動的終端裝置上,處理編寫一些應用程式要達到的目標所需要的邏輯以外,主要的還是跟Android系統以及它上面的那些功能軟體互動,比如相機,藍芽,網路,電話,通訊錄,email等等。它們中有些更是需要硬體的支援。問題出來了,我們寫程式是怎麼跟這些東西互動呢?
Android的SDK 眾多通道給我們,它們以應用程式組件的形式存在。我們編寫一般的應用程式基底礎基本上都是它們來搭建的。
Google說它們是你建造應用程式磚瓦。可不要小瞧這些石頭瓦碴,它們可是你的應用程式和Android系統搭上夥的代理人。當然,有些可能不能直接滿足你的應用程式跟系統或者其它軟體交流的需求,但是它的存在就證明了它是有意義的,它所扮演的角色需要我們慢慢瞭解。
Google給出了4類組件,需要程式開發人員詳細研究:
1. Activities:
活動? 其實就是我們在移動終端上開啟一個使用者介面進行相關的操作,這就是一個Activity。比如,我們開啟Email程式的新郵件列表查看新郵件,這就是一個Activity,同樣,開啟寫郵件頁面又是另外一個Activity,從新郵件列表頁面選擇一個新郵件開啟瀏覽介面又是一個新的Activity。這樣看來,一個Email應用程式就成了這麼眾多的Activity的集合了!
Android系統下這些Activity之間都是相互獨立的,當然使用者在使用Email程式的時候是感覺不出來的。這眾多獨立的Activity組合在一起反而給了使用者很好的操作體驗。那麼獨立性體現在哪裡呢?比如上面Email中的那些Activity,一個其它的的應用程式完全可以在郵件應用程式允許的情況下,啟動上面所說的Activity中的任何一個。也就是說Email應用程式可以被肢解這運行,神奇吧!因為Android系統基於Linux核心,Android系統的最獨特設計就是任何應用程式都能啟動其它應用程式的組件,當然首先得活動許可才行!
如此一來,我們可以理解了,我們為什麼能夠開啟拍照的應用軟體,配一張照片然後直接可以選擇發郵件跟朋友們共用了,表面上是拍照軟體具備了發郵件的功能,其實不然!而是拍照程式調用了Email程式中的發郵件Activity而已。
Activity給了我們超強的靈活性啊,隨心所欲的使用其它無論是系統內建的Activity還是其它應用程式中的Activity,只需要事前獲得它們的許可即可。
其實我們編寫Android應用程式,首先就是考慮怎麼把應用定義成一個個的Activity。然後通過執行個體化Android SDK提供的Activity類來產生這些Activity。
2.Services:
服務!任何系統都不會拒絕它,因為它總是給人們帶來默默的協助,讓我們的每一個行動都變得輕鬆舒心!
Android系統中當然也必須得有啦! 那麼服務到底是什麼呢?
Google說:它就是一個運行在後台去執行一個長期操作或者為遠程進程默默工作的組件。
你可能一般看不到它,因為它不提供使用者介面!但是你能感受到它的存在給你帶來的好處。
比如你在跟一個Activity互動呢,另一個組件在幫你從網路上下載資料,但是你沒覺察到它,這個組件就是service了!
要實現一個服務元件你需要定義Google提供的Services類的子類,通過繼承該類擷取一些運行在Android系統的必要介面。
3.Content Providers:
內容提供者,故名思議就是能夠給你提供一些內容的一個組件,相當於一個容器。 提供什麼內容呢? 前面說了,Linux下每個應用程式都是運行在自己的線程裡的。程式之間都是相互隔離的,同時安全規則限制相互訪問時不可能的,那麼Android能夠啟動其它應用程式的組件為自己完成某種功能,完成的結果怎麼交流,估計就靠它了!
它的每一個執行個體都會管理一個應用程式的共用資料集合。說白了,就是給你一個訪問其它應用組件的資料和資源的代理或者通道。
因為在Android系統中你可以把應用程式的資料儲存到系統檔案中,或者整合的一個SQLite資料庫中,或者放到網上雲端伺服器,或者任何你的應用程式能夠訪問到儲存的地方。就通過這個內容提供者,其它的應用程式可以查詢甚至在內容提供者允許的情況下修改這些資料。
比如,Android系統提供了一個內容提供者(ContactsContract.Data)管理著使用者的通訊錄資訊,這樣任何獲得相應許可的應用程式都可以查詢內容提供者的部分來讀取和回寫有關某個特定人的資訊了。
Android系統為開發人員提供了一個ContentProvider類,我們要使用內容提供者就必須繼承這個類,同時你一可以實現一個標準的事務API,來讓其具備交易處理能力。
4.BroadCast recievers:
字面意思廣播接收者,其實它是Android系統中一個系統和其它應用程式的網關或者通道組件,負責系統範圍內廣播通知。
比如,我們用手機沒電時,總會突然接收到電量不足的通知,這就是Android系統產生的一個廣播。其實有許多廣播產生於系統,比如一個廣播通知說螢幕關閉,電池電量過低,或者一個圖片被抓取等等。應用程式也可以初始化廣播,比如,通知其它應用程式一些資料被下載到了裝置上他們可以使用了。儘管廣播系統沒有使用者介面,但它們可能會建立一個狀態列通知來提示使用者一個廣播事件發生。
Android系統同樣提供了父類BroadcastReciever類來完成基本的一些操作,我們定義廣播接收者時需要繼承它。
總結Google介紹給我們的這四類組件,我們能夠感覺出一個Android應用程式的整體組成。
首先是Activity,它就是你程式完成某個功能的一個流程。從建立到執行到結束,說明你要求的一個功能的完成。當然在這個過程中你可能有中斷,之後又繼續,還會有意外終止等。Activity是Android系統用來管理你的一個功能進程生命週期的一個類。宏觀上說你需要通過Activity來管理你的功能執行過程。你在設計應用程式的時候,首先要考慮怎麼設計符合Activity的生命週期。
其次,Service是後台協助你處理某些長期工作的,能為你的Activity提供長久的支援服務。你的Activity可以對它進行操作,比如啟動,暫停,中止,關閉等等。
Service組件可以是你應用程式服務的一部分,也可以是獨立的一個應用,輔助你完成一些功能的實現。
而ContentProvider則是一個開啟共用的視窗,它協助你管理你的應用程式的共用資料包括讀取,寫入儲存等等。你可以通過許可設定,來對其它應用程式的ContentProvider調用,從而擷取其它應用程式的共用資料資源。而至於BroadCast Receivers 它像信使,之前說過每一個應用程式組件包括系統的組件都是運行在自己的進程中的,而Linux系統對每個應用程式都看作一個獨立唯一的使用者來管理,所以上面說的Android系統中一個應用程式的組件要想調用另外一個應用程式的Activity來完成某項功能,它就必須為這個Activity所在的應用程式啟動一個新的進程來運行,這個程序呼叫者是不可能直接調用的,它只能表達自己的意思,也就是產生一個想法意圖,通過廣播或者訊息傳遞給Linux,由Linux幫忙來啟動這個應用程式的進程運行相應的Activity。 而這中間的訊息傳遞處理都是靠廣播接收者了。