【文章內(nèi)容簡介】 可以很快的入手了。源碼到這里，很多看官一定很不屑，前面所謂的學(xué)習(xí)入門介紹，只不過是圍著SDK打轉(zhuǎn)。其實(shí)，事實(shí)也是如此，SDK中包含的內(nèi)容是真的非常重要，我只是期望通過一些簡短的介紹，激起一些初學(xué)者的重視，如是而已。當(dāng)然，SDK每一個(gè)平臺(tái)都有，沒什么稀罕的。但Android有另一個(gè)非常稀罕而值錢的看家法寶，就是源代碼。從Android Source的主站上：，你可以獲得整個(gè)平臺(tái)的源碼以及相關(guān)介紹。非?？嗫谄判牡钠谕蠹叶既own一份源碼放在機(jī)器上，哪怕你不需要進(jìn)行修改編譯，放在機(jī)器上當(dāng)百科全書也是遠(yuǎn)勝于任何一本Android教學(xué)書籍的。本系列文章后續(xù)很多內(nèi)容，都是從源碼中學(xué)習(xí)到的一些淺薄見識(shí)。對(duì)于大部分開發(fā)者都有學(xué)習(xí)價(jià)值的源碼，主要在源碼的frameworks和packages目錄下。前者包含的是平臺(tái)核心的一些實(shí)現(xiàn)，比如你需要自定義一個(gè)控件，也許你就可以翻到一個(gè)系統(tǒng)控件的實(shí)現(xiàn)中去，看看它是怎么來做的。后者包含一些系統(tǒng)的應(yīng)用實(shí)現(xiàn)，比如你想做個(gè)播放器，也許你可以先去參考參考系統(tǒng)自帶的是具體怎么做的。這樣的實(shí)現(xiàn)，即便不算是最華美，至少也是最標(biāo)準(zhǔn)，其價(jià)值不容小視。另外，你也可以把它當(dāng)個(gè)代碼庫來使，不會(huì)使用某個(gè)類，grep一把，也許就能獲得一份最漂亮的Sample。當(dāng)然，如果你有時(shí)候?qū)δ承┫到y(tǒng)機(jī)制表示費(fèi)解，抑或有一些bug不知道源頭在哪，都可以跟著源碼順藤摸瓜的搞清楚。這樣的好東西，可不是每個(gè)平臺(tái)都能夠享用的。其他論壇，其實(shí)對(duì)于開發(fā)和學(xué)習(xí)都是很重要的資源。畢竟，所有的資料都是死的，只有人是活得，能夠最大限度的因地制宜解決問題。只不過，標(biāo)準(zhǔn)的官方論壇，放在Google Group上，已經(jīng)惆悵的被盾了。中文論壇方面，沒有特別優(yōu)秀和活躍的，這一方面是由于Android的發(fā)展現(xiàn)狀還不算很磅礴，另一方面是由于Android的開發(fā)相對(duì)于Symbian而言，奇技淫巧少了很多，沒有那么多好問的。也許你可以去去csdn這樣的傳統(tǒng)論壇，或者eoe這樣專門的論壇。有的時(shí)候，還是多少能獲得一些幫助的。書籍方面，真沒有什么推薦，豆瓣上搜索一下，你可以看到，目前的書籍，基本上還是集中在SDK使用層面上，很少有解析的很透徹，做的很深入的。而SDK的使用，看SDK的文檔就足夠了，如果實(shí)在對(duì)e文不感冒，買一兩本評(píng)價(jià)不太差的中文書籍，放著翻翻也還是挺好。更進(jìn)一步，也許可以讀讀一些經(jīng)驗(yàn)性的文檔，去Google Code上搜索一些代碼回來看看。比如，SDK文檔中，有個(gè)經(jīng)驗(yàn)性文檔的集合：resources/articles/，就可以翻看一下。最后，更多的一切還需要自己在工程和思考中，慢慢總結(jié)。相信，好的代碼，會(huì)垂青一個(gè)勤于動(dòng)手和思考的人?！救?—— 組件入門組件（Component），在談及所謂架構(gòu)和重用的時(shí)候，是一個(gè)重要的事情。很多時(shí)候都會(huì)說基于組件的軟件架構(gòu)，指的是期望把程序做樂高似的，有一堆接口標(biāo)準(zhǔn)封裝完整的組件放在哪里，想用的時(shí)候取上幾個(gè)一搭配，整個(gè)程序就構(gòu)建完成了。在開篇的時(shí)候就在說，Android是一個(gè)為組件化而搭建的平臺(tái)，它引入所謂MashUp的概念，這使得你在應(yīng)用的最上層，想做的不組件化都是很困難的一件事情（底層邏輯，好吧，管不了...）。具體說來，Android有四大組件四喜丸子：Activity、Service、Broadcast Receiver、Content Provider。Activity做一個(gè)完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因?yàn)锳ctivity是Android程序與用戶交互的窗口，在我看來，從這個(gè)層面的視角來看，Android的Activity特像網(wǎng)站的頁面。首先，一個(gè)網(wǎng)站，如果一張頁面都沒有，那...，真是一顆奇葩。而一張頁面往往都有個(gè)獨(dú)立的主題和功能點(diǎn)，比如登錄頁面，注冊頁面，管理頁面，如是。在每個(gè)頁面里面，會(huì)放一些鏈接，已實(shí)現(xiàn)功能點(diǎn)的串聯(lián)，有的鏈接點(diǎn)了，刷，跑到同一站點(diǎn)的另一個(gè)頁面去了；有的鏈接點(diǎn)了，啾，可能跳到其他網(wǎng)站的頁面去；還有的鏈接點(diǎn)了，恩...，這次沒跑，但當(dāng)前頁面的樣子可能有所變化了。這些模式，和Activity給人的感覺很像，只不過實(shí)現(xiàn)策略不同罷了，畢竟Android這套架構(gòu)的核心思想，本身就來自源于Web的MashUp概念，視為頁面的客戶端化，也未嘗不可。Activity，在四大組件中，無疑是最復(fù)雜的，這年頭，一樣?xùn)|西和界面掛上了勾，都簡化不了，想一想，獨(dú)立做一個(gè)應(yīng)用有多少時(shí)間淪落在了界面上，就能琢磨清楚了。從視覺效果來看，一個(gè)Activity占據(jù)當(dāng)前的窗口，響應(yīng)所有窗口事件，具備有控件，菜單等界面元素。從內(nèi)部邏輯來看，Activity需要為了保持各個(gè)界面狀態(tài)，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉(zhuǎn)跳邏輯。對(duì)于開發(fā)者而言，就需要派生一個(gè)Activity的子類，然后埋頭苦干上述事情。對(duì)于Activity的更多細(xì)節(jié)，先可以參見：reference/android/app/。后續(xù)，會(huì)獻(xiàn)上更為詳盡的剖析。Service服務(wù)，從最直白的視角來看，就是剝離了界面的Activity，它們在很多Android的概念方面比較接近，都是封裝有一個(gè)完整的功能邏輯實(shí)現(xiàn)，只不過Service不拋頭露臉，只是默默無聲的做堅(jiān)實(shí)的后盾。但其實(shí)，換個(gè)角度來看，Android中的服務(wù)，和我們通常說的Windows服務(wù)，Web的后臺(tái)服務(wù)又有一些相近，它們通常都是后臺(tái)長時(shí)間運(yùn)行，接受上層指令，完成相關(guān)事務(wù)的模塊。用運(yùn)行模式來看，Activity是跳，從一個(gè)跳到一個(gè)，呃...，這有點(diǎn)像模態(tài)對(duì)話框（或者還像web頁面好了...），給一個(gè)輸入（抑或沒有...），然后不管不顧的讓它運(yùn)行，離開時(shí)返回輸出（同抑或沒有...）。而Service不是，它是等，等著上層連接上它，然后產(chǎn)生一段持久而纏綿的通信，這就像一個(gè)用了Ajax頁面，看著沒啥變化，偷偷摸摸的和Service不知眉來眼去多少回了。但和一般的Service還是有所不同，Android的Service和所有四大組件一樣，其進(jìn)程模型都是可以配置的，調(diào)用方和發(fā)布方都可以有權(quán)利來選擇是把這個(gè)組件運(yùn)行在同一個(gè)進(jìn)程下，還是不同的進(jìn)程下。這句話，可以拿把指甲刀刻進(jìn)腦海中去，它凸顯了Android的運(yùn)行特征。如果一個(gè)Service，是有期望運(yùn)行在于調(diào)用方不同進(jìn)程的時(shí)候，就需要利用Android提供的RPC機(jī)制，為其部署一套進(jìn)程間通信的策略。Android的RPC實(shí)現(xiàn)，如上圖所示（好吧，也是從SDK中拿來主義的...），無甚稀奇，基于代理模式的一個(gè)實(shí)現(xiàn)，在調(diào)用端和服務(wù)端都去生成一個(gè)代理類，做一些序列化和反序列化的事情，使得調(diào)用端和服務(wù)器端都可以像調(diào)用一個(gè)本地接口一樣使用RPC接口。Android中用來做數(shù)據(jù)序列化的類是Parcel，參見：/reference/android/os/，封裝了序列化的細(xì)節(jié)，向外提供了足夠?qū)ο蠡脑L問接口，Android號(hào)稱實(shí)現(xiàn)非常高效。還有就是AIDL (Android Interface Definition Language) ，一種接口定義的語言，服務(wù)的RPC接口，可以用AIDL來描述，這樣，ADT就可以幫助你自動(dòng)生成一整套的代理模式需要用到的類，都是想起來很乏力寫起來很苦力的那種。更多內(nèi)容，可以再看看：guide/developing/tools/，如果有興致，可以找些其他PRC實(shí)現(xiàn)的資料lou幾眼。關(guān)于Service的實(shí)現(xiàn)，還強(qiáng)推參看API Demos這個(gè)Sample里面的RemoteService實(shí)現(xiàn)。它完整的展示了實(shí)現(xiàn)一個(gè)Service需要做的事情：那就是定義好需要接受的Intent，提供同步或異步的接口，在上層綁定了它后，通過這些接口（很多時(shí)候都是RPC的...）進(jìn)行通信。在RPC接口中使用的數(shù)據(jù)、回調(diào)接口對(duì)象，如果不是標(biāo)準(zhǔn)的系統(tǒng)實(shí)現(xiàn)（系統(tǒng)可序列化的），則需要自定義aidl，所有一切，在這個(gè)Sample里都有表達(dá)，強(qiáng)薦。Service從實(shí)現(xiàn)角度看，最特別的就是這些RPC的實(shí)現(xiàn)了，其他內(nèi)容，都會(huì)接近于Activity的一些實(shí)現(xiàn)，也許不再會(huì)詳述了。Broadcast Receiver在實(shí)際應(yīng)用中，我們常需要等，等待系統(tǒng)抑或其他應(yīng)用發(fā)出一道指令，為自己的應(yīng)用擦亮明燈指明方向。而這種等待，在很多的平臺(tái)上，都會(huì)需要付出不小的代價(jià)。比如，在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ī)制，顯然是基于一種注冊方式的，Broadcast Receiver將其特征描述并注冊在系統(tǒng)中，根據(jù)注冊時(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)行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運(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ò)查詢詞匯，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗(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/ Broadcast Actions，可以求到相關(guān)消息的詳情。除了系統(tǒng)，自定義的應(yīng)用可以放出Broadcast消息。前者發(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)都相形見絀了。更多Broadcast Receiver相關(guān)內(nèi)容，參見：/reference/android/content/。Content ProviderContent 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://。所有東西看著像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é)果，以Cursor（參見：reference/android/database/ ）的形式進(jìn)行返回，調(diào)用者可以移動(dòng)Cursor來訪問各列的數(shù)據(jù)。Content Provider屏蔽了內(nèi)部數(shù)據(jù)的存儲(chǔ)細(xì)節(jié)，向外提供了上述統(tǒng)一的接口模型，這樣的抽象層次，大大簡化了上層應(yīng)用的書寫，也對(duì)數(shù)據(jù)的整合提供了更方便的途徑。Content Provider內(nèi)部，常用數(shù)據(jù)庫來實(shí)現(xiàn)，Android提供了強(qiáng)大的Sqlite支持，但很多時(shí)候，你也可以封裝文件或其他混合的數(shù)據(jù)。在Android中，ContentResolver是用來發(fā)起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的接口。但通常，Content Provider需要訪問的可能是數(shù)據(jù)庫等大數(shù)據(jù)源，效率上不足夠快，會(huì)