做一個完整的Android程式,不想用到Activity,真的是比較困難的一件事情,除非是想做綠葉想瘋了。因為Activity是Android程式與使用者互動的視窗,歡迎大家學習參考。
在我看來,從這個層面的視角來看,Android的Activity特像網站的頁面。首先,一個網站,如果一張頁面都沒有,那...,真是一顆奇葩。而一張頁面往往都有個獨立的主題和功能點。
比如登入頁面,註冊頁面,管理頁面,如是。在每個頁面裡面,會放一些連結,已實現功能點的串聯,有的連結點了,刷,跑到同一網站的另一個頁面去了;有的連結點了,啾,可能跳到其他網站的頁面去;
還有的連結點了,恩...,這次沒跑,但當前頁面的樣子可能有所變化了。這些模式,和Activity給人的感覺很像,只不過實現策略不同罷了,畢竟Android這套架構的核心思想,本身就來自源於Web的Mash-Up概念。
視為頁面的用戶端化,也未嘗不可。Android程式,在四大組件中,無疑是最複雜的,這年頭,一樣東西和介面掛上了勾,都簡化不了,想一想,獨立做一個應用有多少時間淪落在了介面上,就能琢磨清楚了。
從視覺效果來看,一個Activity佔據當前的視窗,響應所有視窗事件,具備有控制項,菜單等介面元素。從內部邏輯來看,Activity需要為了保持各個介面狀態。需要做很多持久化的事情,還需要妥善管理生命週期,和一些轉跳邏輯。對於開發人員而言,就需要派生一個Activity的子類,然後埋頭苦幹上述事情。對於Activity的更多細節。
服務,從最直白的視角來看,就是剝離了介面的Activity,它們在很多Android的概念方面比較接近,都是封裝有一個完整的功能邏輯實現,只不過Service不拋頭露臉,只是默默無聲的做堅實的後盾。
但其實,換個角度來看,Android中的服務,和我們通常說的Windows服務,Web的後台服務又有一些相近,它們通常都是後台長時間運行,接受上層指令,完成相關事務的模組。
用運行模式來看,Activity是跳,從一個跳到一個,呃...,這有點像模態對話方塊或者還像web頁面好了...),給一個輸入抑或沒有...),然後不管不顧的讓它運行,離開時返回輸出同抑或沒有...)。而Service不是,它是等,等著上層串連上它,然後產生一段持久而纏綿的通訊,這就像一個用了Ajax頁面,看著沒啥變化,偷偷摸摸的和Service不知眉來眼去多少回了。
但和一般的Service還是有所不同,Android的Service和所有四大組件一樣,其進程模型都是可以配置的,調用方和發布方都可以有權利來選擇是把這個組件運行在同一個進程下。
還是不同的進程下。這句話,可以拿把指甲刀刻進腦海中去,它凸顯了Android的運行特徵。如果一個Service,是有期望運行在於調用方不同進程的時候,就需要利用Android提供的RPC機制,為其部署一套處理序間通訊的策略。
Android的RPC實現,如所示好吧,也是從SDK中拿來主義的...),無甚稀奇,基於代理模式的一個實現,在調用端和服務端都去產生一個代理類,做一些序列化和還原序列化的事情,使得調用端和伺服器端都可以像調用一個本地介面一樣使用RPC介面。
Android中用來做資料序列化的類是Parcel,參見:/reference/android/os/Parcel.html,封裝了序列化的細節,向外提供了足夠對象化的提供者,Android號稱實現非常高效。還有就是AIDL (Android Interface Definition Language) 。
一種介面定義的語言,服務的RPC介面,可以用AIDL來描述,這樣,ADT就可以協助你自動產生一整套的代理模式需要用到的類,都是想起來很乏力寫起來很苦力的那種。更多內容,可以再看看:guide/developing/tools/aidl.html,如果有興緻,可以找些其他PRC實現的資料lou幾眼。
關於Service的實現,還強推參看Android程式這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情:那就是定義好需要接受的Intent,提供同步或非同步介面。
在上層綁定了它後,通過這些介面很多時候都是RPC的...)進行通訊。在RPC介面中使用的資料、回調介面對象,如果不是標準的系統實現系統可序列化的),則需要自訂aidl,所有一切,在這個Sample裡都有表達,強薦。