深入android 【三】

《深入android 【三】 》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在工程資料-天天文庫。

1、深入Android【三】　　組件（ponent），在談及所謂架構(gòu)和重用的時(shí)候，是一個(gè)重要的事情。很多時(shí)候都會(huì)說基于組件的軟件架構(gòu)，指的是期望把程序做樂高似的，有一堆接口標(biāo)準(zhǔn)封裝完整的組件放在哪里，想用的時(shí)候取上幾個(gè)一搭配，整個(gè)程序就構(gòu)建完成了?！　≡陂_篇的時(shí)候就在說，Android是一個(gè)為組件化而搭建的平臺，它引入所謂Mash-Up的概念，這使得你在應(yīng)用的最上層，想做的不組件化都是很困難的一件事情（底層邏輯，好吧，管不了...）。具體說來，Android有四大組件四喜丸子：Activity、Serv

2、ice、BroadcastReceiver、ContentProvider?！　ctivity　　做一個(gè)完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因?yàn)锳ctivity是Android程序與用戶交互的窗口，在我看來，從這個(gè)層面的視角來看，Android的Activity特像網(wǎng)站的頁面。　　首先，一個(gè)網(wǎng)站，如果一張頁面都沒有，那...，真是一顆奇葩。而一張頁面往往都有個(gè)獨(dú)立的主題和功能點(diǎn)，比如登錄頁面，注冊頁面，管理頁面，如是?！　≡诿總€(gè)頁面里

3、面，會(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)的核心思想，本身就來自源于ash-Up概念，視為頁面的客戶端化，也未嘗不可?！　ctivity，在四大組件中，無疑是最復(fù)雜的，這年頭，一樣?xùn)|西和界面掛上了勾，都簡化不了，想一想，獨(dú)立做一個(gè)應(yīng)用有多少時(shí)間淪落在了

4、界面上，就能琢磨清楚了。從視覺效果來看，一個(gè)Activity占據(jù)當(dāng)前的窗口，響應(yīng)所有窗口事件，具備有控件，菜單等界面元素。從內(nèi)部邏輯來看，Activity需要為了保持各個(gè)界面狀態(tài)，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉(zhuǎn)跳邏輯。對于開發(fā)者而言，就需要派生一個(gè)Activity的子類，然后埋頭苦干上述事情。對于Activity的更多細(xì)節(jié)，先可以參見：reference/android/app/Activity.html。后續(xù)，會(huì)獻(xiàn)上更為詳盡的剖析。編緝推薦閱讀以下文章深入Android【

5、二】——架構(gòu)和學(xué)習(xí)深入Android【一】——序及開篇　　Service　　服務(wù)，從最直白的視角來看，就是剝離了界面的Activity，它們在很多Android的概念方面比較接近，都是封裝有一個(gè)完整的功能邏輯實(shí)現(xiàn)，只不過Service不拋頭露臉，只是默默無聲的做堅(jiān)實(shí)的后盾?！　〉鋵?shí)，換個(gè)角度來看，Android中的服務(wù)，和我們通常說的l，如果有興致，可以找些其他PRC實(shí)現(xiàn)的資料lou幾眼?！　￡P(guān)于Service的實(shí)現(xiàn)，還強(qiáng)推參看APIDemos這個(gè)Sample里面的RemoteService實(shí)現(xiàn)。

6、它完整的展示了實(shí)現(xiàn)一個(gè)Service需要做的事情：那就是定義好需要接受的Intent，提供同步或異步的接口，在上層綁定了它后，通過這些接口（很多時(shí)候都是RPC的...）進(jìn)行通信。在RPC接口中使用的數(shù)據(jù)、回調(diào)接口對象，如果不是標(biāo)準(zhǔn)的系統(tǒng)實(shí)現(xiàn)（系統(tǒng)可序列化的），則需要自定義aidl，所有一切，在這個(gè)Sample里都有表達(dá)，強(qiáng)薦?！　ervice從實(shí)現(xiàn)角度看，最特別的就是這些RPC的實(shí)現(xiàn)了，其他內(nèi)容，都會(huì)接近于Activity的一些實(shí)現(xiàn)，也許不再會(huì)詳述了。　　Broadcast1234下一頁——感謝閱

7、讀這篇文章，..，Receiver　　在實(shí)際應(yīng)用中，我們常需要等，等待系統(tǒng)抑或其他應(yīng)用發(fā)出一道指令，為自己的應(yīng)用擦亮明燈指明方向。而這種等待，在很多的平臺上，都會(huì)需要付出不小的代價(jià)?！　”热纾赟ymbian中，你要等待一個(gè)來電消息，顯示歸屬地之類的，必須讓自己的應(yīng)用忍辱負(fù)重偷偷摸摸的開機(jī)啟動(dòng)，消隱圖標(biāo)隱藏任務(wù)項(xiàng)，潛伏在后臺，監(jiān)控著相關(guān)事件，等待轉(zhuǎn)瞬即逝的出會(huì)。這是一件很發(fā)指的事情，不但白白耗費(fèi)了系統(tǒng)資源，還留了個(gè)流氓軟件的罵名，這真是賣力不討好的正面典型。編緝推薦閱讀以下文章深入Android【二

8、】——架構(gòu)和學(xué)習(xí)深入Android【一】——序及開篇　　在Android中，充分考慮了廣泛的這類需求，于是就有了BroadcastReceiver這樣的一個(gè)組件。每個(gè)BroadcastReceiver都可以接收一種或若干種Intent作為觸發(fā)事件（有不知道Intent的么，后面會(huì)知道了...），當(dāng)發(fā)生這樣事件的時(shí)候，系統(tǒng)會(huì)負(fù)責(zé)喚醒或傳遞消息到該BroadcastReceiver，任其處置。在此之前和這以后，BroadcastReceiver是否在運(yùn)行都變得不重要了，及