android組件庫
㈠ Android系統四大組件
Android系統四大組件分別是活動（Activity）、服務（Service）、廣播接收器（Broadcast Receiver）和內容提供（Content Provider）。其中活動是所有Android應用程序的門面，凡是在應用中你看得到的東西，都是放在活動中的。而服務就比較低調了，你無法看到它，但它會一直在後台默默地運行，即使用戶退出了應用，服務仍然是可以繼續運行的。廣播接收器允許你的應用接收來自各處的廣播消息，比如電話、簡訊等，當然你的應用同樣也可以向外發出廣播消息。內容提供器則為應用程序之間共享數據提供了可能，比如你想要讀取系統電話簿中的聯系人，就需要通過內容提供器來實現。
開發工具：
JDK 。
JDK是java語言的軟體開發工具包，它包含了Java的運行環境、工具集合、基礎類庫等內容。需要注意的是，本書中的Android程序必須要使用JDK 8或以上版本才能進行開發。
Android SDK 。
Android SDK是谷歌提供的Android開發工具包，在開發Android程序時，我們需要通過引入該工具包，來使用Android相關的API。
㈡ 請問Android中4大組件有哪些他們的作用是什麼
Activity
官方解釋：Activity是Android程序與用戶交互的窗口，是Android構造塊中最基本的一種，它主要為保持各界面的狀態做很多持久化的事情，妥善管理生命周期以及一些跳轉邏輯。
解釋說明：我們也可以簡單的理解為當前的操作界面。
Service
官方解釋：Service後台服務於Activity，封裝有一個完整的功能邏輯實現，接受上層指令，完成相關的事務，定義好需要接受的Intent提供同步和非同步的介面。
解釋說明：例如當我們打開音樂播放器後我們想讓該音樂播放器至於後台運行。這時我們就可以啟動服務來實現。
ContentProvider
官方解釋：ContentProvider是Android中提供的第三方應用數據的訪問方案，可以派生ContentProvider類，對外提供數據，可以像資料庫一樣進行選擇排序，屏蔽內部存儲的存儲細節，向外提供統一的數據介面模型，大大簡化上層應用對數據的整合提供了更方便的途徑。
解釋說明：我們可以簡單的理解為在我們的應用程序中我們在一塊區域定製了一些規則來存儲應用程序的相關信息。如果第三方應用程序想要訪問到我們應用程序中的信息就需要滿足我們定製的規則來進行獲取。
BroadcastReceiver
官方解釋：BroadcastReceiver接受一種或者多種Intent作觸發事件，接受相關消息，做一些簡單處理，轉換成一條Notification，統一了Android的事件廣播機制。
解釋說明：這個機制可以理解為電視廣播，我們通過廣播發送一個節目。人們可以通過收音機調到對應的頻率來進行接受廣播而獲取相應的信息。我們的應用程序可以通過廣播發送信息，也可以通過一定的條件篩選來獲取到被人發送的廣播信息。而且廣播的作用范圍不局限於本應用程序內進行信息傳遞。
可以在秒秒學上看看Android的課程，講解的可以，希望對你有幫助。
㈢ android怎麼封裝ui組件庫
封裝就是要主要不要和任務相關,提供的介面要盡量合理和便捷使用.
㈣ UI設計師，是時候了解一下組件庫了
在開始這個話題之前，UI設計師先來回想一下自己的工作流程，當我們開始做一個界面時，不外乎兩種情況，一種是新產品，一種是現有產品迭代界面重繪。對於前者，是不是先扒拉扒拉參考一下競品的界面設計，然後套一套自己產品的功能，然後就可以開工了，這里需要放個導航條，嗯，這里用選項卡，再加個搜索框，搜索圖標放裡面好還是放外面好呢，就放外面吧，熱門搜索要不要做成標簽呢，不行，這事決定不了，去問問項目經理去，這里還需要一個文本輸入框，限制200字，那就給它個高度300像素吧。而第二種情況，更簡單，重新配配色，布布局，畫畫圖標，就醬。不出意外的話，絕大多數UI不會脫離這個套路。（「大神級」UI自然也不會在看這篇文章，這一部分人就暫時忽略了）
如果作為UI設計師的你現在仍然停留在這個階段的話，那從現在開始，你需要重新規劃一下自己的設計思路了，並且，最最重要的是，你需要了解兩個東東，「框架」和「庫」。這兩個概念我自己也比較模糊，從UI設計師的角度出發，我們需要知道的一點是和你們合作的前端極少極少不使用框架，而UI庫是一些封裝好的組件的樣式，你發給攻城獅的設計稿，他們拿到後的第一反應就是趕快看看（咳咳，當我沒說）有沒有現成的可使用的組件樣式，最好越接近你的設計越好，然後簡單改改，攻城獅們的工作思路和我們是一樣一樣的，最好不改交互方式，只改樣式。（什麼控制項、組件、插件的，我也不能嚴格區分，所以即使有錯誤的地方，也請勿糾正，哈哈）
說到這里，UI設計師又開始各種煩躁了，設計師到底為毛要掌握這些莫名其妙的知識？？舉個例子先，我們都知道給響應不是那麼快的頁面設計一個載入動畫，那作為設計師的你知不知道載入狀態是和伺服器存在數據交互時使用，如果是本地行為，則不需要載入狀態。只有了解這個，你才會知道你的載入動畫應該在哪些頁面出現，進行什麼操作時出現，以什麼形式出現合適。（咦，這個例子似乎舉得沒有代表性，那麼來看下面這個例子）
就說個最簡單的tab選項卡吧，SUI組件庫里的tab選項卡樣式是下面這樣子的：
樣式似乎沒有什麼參考性，但你從中要得到的一個重要信息就是，作為選項卡而言，內容要和選中標簽頁看上去成為一個整體，也就是說你可以重新設計成下面這個樣式
但如果你設計成了這種樣式
那麼請來告訴我，這神秘的橫線我該如何理解呢？即使下面這種，仍然不是最佳方式，因為我們的選項卡需要「第一眼看上去就知道哪個tab頁處於選中狀態」。
目前廣泛應用的UI組件庫，包括easyUI、amazeUI、Bootstrap等等，我們可以從這些來入手，在設計時進行一下參考，如果它的按鈕有四個狀態，OK，你也來對應設計四個狀態，如果它的input輸入框有禁用狀態，獲得焦點狀態，那同樣你也要在自己的設計文檔中予以體現。（當然，並非絕對，也要考慮項目的實際情況，靈活變通）
現在重新理一下工作流程，你要先咨詢一下前端開發人員他們常用什麼，或者項目中已經使用了什麼，咱們來舉例說明，如果前端攻城獅們已經使用了EasyUI，而碰巧你的項目中需要一個日期選擇的功能，那正確的思路應該是怎樣的呢？
首先，你需要先看一下EasyUI庫里日期控制項的樣子。就是下面這樣
然後試一下功能，再進行設計時，心裡就有底了，比如可以改成下面這樣
但這樣就完了么？作為UI還需要考慮對於這個控制項而言都提供了幾種狀態？默認載入的當前日期、選中其他日期後的當前日期、滑鼠經過、周六/周日的日期顏色、非本月的日期的顏色，這些都需要一一體現在你的標注文檔里，事無巨細，一旦疏忽了其中任何一個小細節，好點的情況是負責的前端開發人員會過來和你溝通，而有時可能攻城獅們一疏忽，那隻有寄希望於視覺走查和測試了。這么簡單的一個日期控制項都需要考慮全面，所以，一個合格的UI還是需要多沉浸的。
如果你不沒有看過UI庫里日期組件的樣式，而自作主張的設計成了下面的樣子
還拿出很多理論來支持自己的設計，你看，年和月的選擇都很方便快捷嘛，嗯，好想看你被開發人員暴打的樣子……當然了，這里不是說不讓你發揮你的創意，不過除非你有非常說服力的理由和讓別人心服口服的設計理論支持，否則，不要做這種出力不討好的事情，因為作為成熟的組件庫，經過多年的發展，已經被很多人所認可和使用，也能更大程度上和其他用戶經常使用的產品保持一致的交互。
對於移動端，Android SDK提供的界面UI基本沒有看的必要，而絕大多數開源UI庫源碼在github，給設計師們直觀的查看設置了門檻，比如GreenDroid等等，Android的UI框架和web的有個比較大的區別就是按組件分類，像Side-Menu分類側滑菜單，Pull-to-Refresh下拉刷新，給UI設計師推薦一個awesome-android-ui，自帶Demo， https://github.com/wasabeef/awesome-android-ui/blob/master/pages/Material.md ，包括一些動效，很直觀。
比如這種水紋效果的樣式。
還有這種漢堡菜單/關閉/返回按鈕的變換
作為UI設計師，在做原型稿的時候基本不用費盡心思用AE來做什麼特效，直接附上效果和庫的源文件地址就好，方便自己也方便開發。
另外移動端的UI日常尤其要注意控制項樣式的積累，自己建好文件夾，分好類，按鈕/編輯框/switch/文本控制項/進度條/滾動條/對話框/日歷/導航/圖表/菜單/輪播廣告位/搜索框/標簽組等等，為了減輕開發人員的負擔，在看到不錯的效果時，可以把Demo動畫和項目地址同時保存下來，因為你的天馬行空的想像或者簡單一句「在XXX上好像看過這種效果」會讓開發人員非常抓狂。
多看UI庫的另外一個好處是拓展自己的設計思路，像下面這種Floating Action Button
還有粘連效果的頁面指示器
如果不是看到這種動效，或許我們自己也想不出可以做成這種樣子。
iOS開發的話因為我本人也只涉及過寥寥數個項目，而且都是和Android用的同一套界面，所以未總結出足夠的經驗，最多看看最新版的HIG人機交互指南，參考過幾個競品，所以這里就不獻丑了。
㈤ android四大組件的作用是什麼
Android 開發的四大組件分別是：活動（activity），用於表現功能；服務（service），後台運行服務，不提供界面呈現；廣播接受者（Broadcast Receive），勇於接收廣播；內容提供者（Content Provider），支持多個應用中存儲和讀取數據，相當於資料庫。
活動
Android中，activity是所有程序的根本，所有程序的流程都運行在activity之中，activity可以算是開發者遇到的最頻繁，也是android當中最基本的模塊之一。在android的程序中，activity一般代表手機屏幕的一屏。如果把手機比作一個瀏覽器，那麼activity就相當於一個網頁。在activity當中可以添加一些Button、Checkbox等控制項，可以看到activity概念和網頁的概念相當類似。
一般一個android應用是由多個activity組成的，這多個activity之間可以進行相互跳轉。例如，按下一個Button按鈕後，可能會跳轉到其他的activity，與網頁跳轉稍微有點不一樣的是，activity之間的跳轉有可能返回值。例如，從activity A跳轉到activity B，那麼當activity B運行結束時，有可能會給activity A一個返回值。這樣做在很多時候是相當方便的。
當打開一個新的屏幕時，之前一個屏幕會被置為暫停狀態，並且壓入歷史堆棧中。用戶可以通過回退操作返回到以前打開過的屏幕。可以選擇性的一處一些沒有必要保留的屏幕，因為Android會把每個應用的開始到當前的每個屏幕保存在堆棧中。
Android 開發的四大組件分別是：活動（activity），用於表現功能；服務（service），後台運行服務，不提供界面呈現；廣播接受者（Broadcast Receive），勇於接收廣播；內容提供者（Content Provider），支持多個應用中存儲和讀取數據，相當於資料庫。
2.服務
Service是android系統中的一種組件，跟activity的級別差不多，但是他不能自己運行，只能後台運行，並且可以和其他組件進行交互。Service是沒有界面長生命周期的代碼。Service是一種程序，可以運行很長時間的，但是卻沒有用戶界面。這么說有點枯燥，來看個例子。打開一個音樂播放器的程序，這時如果想上網，那麼打開Android瀏覽器，這時雖然已經進入瀏覽器這個程序，但是歌曲播放並沒有停止，而是在後台繼續一首接一首的播放，其實這個播放就是由播放音樂的Service進行控制。當然這個播放音樂的Service也可以停止。例如，當播放列表裡的歌曲都結束，或用戶按下了停止音樂播放的快捷鍵等。Service可以在很多場合的應用中使用，如播放多媒體時用戶啟動了其他Activity，這時程序要在後台繼續播放，比如檢測SD卡上文件的變化，或在後台記錄地理信息位置的改變等，而服務卻藏在後台。
開啟Service有兩種方式：
（1）Context.starService（）：Service會經歷onCreat ——>onStar(如果Service還沒有運行，則Android先調用onCreat()，然後調用onStar（），所以一個Service的onStar方能會重復調用多次)；如果是調用者自己直接退出而沒有調用StopService，服務會一直在後台運行。該服務的調用者再啟動起來後可以通過stopService關閉服務。注意，多次調用Context.starService（）不會被嵌套（即使會有相應的onStar（）方法被調用），所以無論同一個服務被啟動多少次，一旦調用Context.stopService（）或者StopSelf（），都會被停止。
說明：傳遞給starService（）的Intent對象會傳遞給onStar()方法。調用順序為onCreat——onStar（可調用多次）——onDestroy.
（2）Context.bindService()：服務會經歷onCreate（）——onBind（），onBind將返回給客戶端一個IBind介面實例，IBind允許客戶端回調服務的方法，比如得到服務運行的狀態或其他操作。這個時候把調用者（Context，如Activity）會和服務綁定在一起，Context退出了，服務就會調用onUnbind——onDestroy相應退出，所謂綁定在一起就是「共存亡」了。
3.廣播接收器
在Android中，廣播是一種廣泛運用的在應用程序之間傳輸信息的機制。而廣播接收器是對發送出來的廣播進行過濾接受並響應的一類組件。可以使用廣播接收器來讓應用對一個外部時間做出響應。例如，當電話呼入這個外部事件到來時，可以利用廣播接收器進行處理。當下載一個程序成功完成時，仍然可以利用廣播接收器進行處理。廣播接收器不NotificationManager來通知用戶這些事情發生了。廣播接收器既可以在AndroidManifest.xml中注冊，也可以在運行時的代碼中使用Context.registerReceive（）進行注冊。只要是注冊了，當事件來臨時，即使程序沒有啟動，系統也在需要的時候啟動程序。各種應用還可以通過使用Context.sendBroadcast（）將它們自己的Intent廣播給其他應用程序。
4.內容提供者
內容提供者（Content Provider）是Android提供的第三方應用數據的訪問方案。
在Android中，對數據的保護是很嚴密的，除了放在SD卡中的數據，一個應用所持有的資料庫、文件等內容，都是不允許其他直接訪問的。Android當然不會真的把每一個應用都做成一座「孤島」，它為所有應用都准備可一扇窗，這就是Content Provider。應用想對外提供的數據，可以通過派生Content Provider類，封裝成一枚Content Provider。每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有應用看著像REST的樣子，但實際上它比REST更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的；另一種是列表的，但實現者不需要按照這個模式來做，給id的uri也可以返回列表類型的數據。
㈥ Android四大組件是什麼講講你對它們的理解
Android有四大組件：Activity、Service、Broadcast Receiver、Content Provider。
Activity
做一個完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口，在我看來，從這個層面的視角來看，Android的Activity特像網站的頁面。
Activity，在四大組件中，無疑是最復雜的，這年頭，一樣東西和界面掛上了勾，都簡化不了，想一想，獨立做一個應用有多少時間淪落在了界面上，就能琢磨清楚了。從視覺效果來看，一個Activity占據當前的窗口，響應所有窗口事件，具備有控制項，菜單等界面元素。從內部邏輯來看，Activity需要為了保持各個界面狀態，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉跳邏輯。對於開發者而言，就需要派生一個Activity的子類，然後埋頭苦幹上述事情。對於Activity的更多細節，先可以參見：reference/android/app/Activity.html。後續，會獻上更為詳盡的剖析。
Service
服務，從最直白的視角來看，就是剝離了界面的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的實現，還強推參看API Demos這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情：那就是定義好需要接受的Intent，提供同步或非同步的介面，在上層綁定了它後，通過這些介面（很多時候都是RPC的...）進行通信。在RPC介面中使用的數據、回調介面對象，如果不是標準的系統實現（系統可序列化的），則需要自定義aidl，所有一切，在這個Sample里都有表達，強薦。
Service從實現角度看，最特別的就是這些RPC的實現了，其他內容，都會接近於Activity的一些實現，也許不再會詳述了。
Broadcast Receiver
在實際應用中，我們常需要等，等待系統抑或其他應用發出一道指令，為自己的應用擦亮明燈指明方向。而這種等待，在很多的平台上，都會需要付出不小的代價。
比如，在Symbian中，你要等待一個來電消息，顯示歸屬地之類的，必須讓自己的應用忍辱負重偷偷摸摸的開機啟動，消隱圖標隱藏任務項，潛伏在後台，監控著相關事件，等待轉瞬即逝的出手機會。這是一件很發指的事情，不但白白耗費了系統資源，還留了個流氓軟體的罵名，這真是賣力不討好的正面典型。
在Android中，充分考慮了廣泛的這類需求，於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件（有不知道Intent的么，後面會知道了...），當發生這樣事件的時候，系統會負責喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以後，Broadcast Receiver是否在運行都變得不重要了，及其綠色環保。
這個實現機制，顯然是基於一種注冊方式的，Broadcast Receiver將其特徵描述並注冊在系統中，根據注冊時機，可以分為兩類，被我冠名為冷熱插拔。所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，後續奉上...），系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver，這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如，監聽來電、郵件、簡訊之類的，都隸屬於這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在 OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。比如，一款優秀的詞典軟體（比如，有道詞典...），可能會有在運行期間關注網路狀況變化的需求，使其可以在有廉價網路的時候優先使用網路查詢詞彙，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗，一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過 Broadcast Receiver實現的，僅以為例...）。而這樣的監聽，只需要在其工作狀態下保持就好，不運行的時候，管你是天大的網路變化，與我何干。其模式可以歸結為：啟動應用 -> 監聽事件 -> 發生時進行處理。
除了接受消息的一方有多種模式，發送者也有很重要的選擇權。通常，發送這有兩類，一個就是系統本身，我們稱之為系統Broadcast消息，在reference/android/content/Intent.html 的Standard Broadcast Actions，可以求到相關消息的詳情。除了系統，自定義的應用可以放出Broadcast消息，通過的介面可以是 Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast，所有關注該消息的Receiver，都有機會獲得並進行處理；後者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在後面的只能吃前面吃剩下的，前面的心情不好私吞了，後面的只能喝西北風了。
當Broadcast Receiver接收到相關的消息，它們通常做一些簡單的處理，然後轉化稱為一條Notification，一次振鈴，一次震動，抑或是啟動一個 Activity進行進一步的交互和處理。所以，雖然Broadcast整個邏輯不復雜，卻是足夠有用和好用，它統一了Android的事件廣播模型，讓很多平台都相形見絀了。更多Broadcast Receiver相關內容，參見：/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider，聽著就和數據相關，沒錯，這就是Android提供的第三方應用數據的訪問方案。在Android中，對數據的保護是很嚴密的，除了放在SD卡中的數據，一個應用所持有的資料庫、文件、等等內容，都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。
比如，一個聯系人管理的應用。如果不允許第三方的應用對其聯系人資料庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然後另立門戶，自個玩自個的去了。
Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都准備了一扇窗，這就是Content Provider。應用想對外提供的數據，可以通過派生ContentProvider類， 封裝成一枚Content Provider，每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST 更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列
表的，但實現者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數據，只要調用者明白，就無妨，不用苛求所謂的REST。
另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數，這樣，就可以像資料庫那樣進行投影，選擇和排序。查詢到的結果，以Cursor（參見：reference/android/database/Cursor.html ）的形式進行返回，調用者可以移動Cursor來訪問各列的數據。
Content Provider屏蔽了內部數據的存儲細節，向外提供了上述統一的介面模型，這樣的抽象層次，大大簡化了上層應用的書寫，也對數據的整合提供了更方便的途徑。Content Provider內部，常用資料庫來實現，Android提供了強大的sqlite支持，但很多時候，你也可以封裝文件或其他混合的數據。
在Android中，ContentResolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常，Content Provider需要訪問的可能是資料庫等大數據源，效率上不足夠快，會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler（參見：reference/android/content/AsyncQueryHandler.html），幫助進行非同步訪問Content Provider。
在各大組件中，Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的場景，往往會提供非同步訪問的介面，而Content Provider不論效率如何，都提供的是約定的同步訪問介面。我想這遵循的就是場景導向設計的原則，因為Content Provider僅是提供數據訪問的，它不能確信具體的使用場景如何，會怎樣使用它的數據；而相比之下，Service包含的邏輯更復雜更完整，可以抉擇大部分時候使用某介面的場景，從而確定最貼切的介面是同步還是非同步，簡化了上層調用的邏輯。
㈦ android開發要哪些jar
am.jar：終端下執行am命令時所需的java庫。源碼目錄：framework/base/cmds/am
android.policy.jar：鎖屏界面需要用到的jar包，該包引用了android.test.runner.jar，源碼目錄：framework/base/policy
android.test.runner.jar：測試應用所需的jar包，該包引用了core.jar,core-junit.ajr以及framework.jar，源碼目錄：framework/base/test-runner
bmgr.jar：adb shell命令下對Android Device所有package備份和恢復的操作時所需的java庫。 不過這個android服務默認是Disabled，而且要backup的應用必須實現BackupAgent，在AndroidManifest.xml的application標簽中加入android：backupAgent屬性。源碼目錄：framework/base/cmds/bmgr
bouncycastle.jar： java三方的密匙庫，網上資料說用來apk簽名、https鏈接之類，官網 ：http://www.bouncycastle.org/java.html
com.android.future.usb.accessory.jar：用於管理USB的上層java庫，在系統編譯時hardware層會調用到。源碼目錄：frameworks/base/libs/usb
com.android.location.provider.jar：
com.android.nfc_extras.jar：NFC外部庫。android/nfc/NfcAdapter.java會調用到包中的NfcAdapterExtras.java。源碼目錄：frameworks/base/nfc-extras
core-junit.jar ：junit核心庫，在運行*Test.apk時被調用。
core-junitrunner.jar：未知，公司話機上有。
core-tests*.jar：framework下的一系列測試jar包，不做測試時可刪除。
core.jar：核心庫，啟動桌面時首先載入這個。源碼目錄：
ext.jar：android外部三方擴展包，源碼主要是external/nist-sip（java下的sip三方庫）、external/apache-http（apache的java三方庫）、external/tagsoup（符合SAX標準的HTML解析器）。其實這個jar包可以添加外部擴展jar包，只需在framework/base/Android.mk中的ext-dir添加src目錄即可。
framework-res.apk：android系統資源庫。
framework.jar：android的sdk中核心代碼。
ime.jar：ime命令所需jar包，用於查看當前話機輸入法列表、設置輸入法。源碼目錄：framework/base/cmds/ime
input.jar：input命令所需的jar包，用於模擬按鍵輸入。源碼目錄：framework/baes/cmds/input
javax.obex.jar：java藍牙API，用於對象交換協議。源碼目錄：framework/base/obex
monkey.jar：執行monkey命令所需jar包。源碼目錄：framework/base/cmds/monkey
pm.jar：執行pm命令所需的jar包，pm詳情見adb shell pm，源碼目錄：framework/base/cmds/pm
services.jar：話機框架層服務端的編譯後jar包，配合libandroid_servers.so在話機啟動時通過SystemServer以循環閉合管理的方式將各個service添加到ServiceManager中。源碼目錄：framework/base/service
sqlite-jdbc.jar： sqlite的Java DataBase Connextivity jar包。
svc.jar：svc命令所需jar包，可硬用來管理wifi,power和data。源碼目錄：framework/base/cmds/svc
㈧ 什麼是android的四大組件
Android四大組件有Activity，Service服務，Content Provider內容提供，BroadcastReceiver廣播接收器。
Android應用程序由一些零散的有聯系的組件組成，通過一個工程manifest綁定在一起。在manifest中，描述了每一個組件以及組件的作用，其中有6個組件，它們是Android應用程序的基石
(8)android組件庫擴展閱讀
Activities(活動)
應用程序的顯示層。每一個畫面對應於你的應用程序，將會是Activity類的擴展。Activity使用Views去構建UI來顯示信息和響應用戶的行為。就桌面開發而言，一個Activity相當於一張Form。
Services(服務)
Android應用程序中不可見的「工人」。 Service組件運行時不可見，但它負責更新的數據源和可見的Activity，以及觸發通知。它們常用來執行一些需要持續運行的處理，當你的 Activity已經不處於激活狀態或不可見。
Content(內容)
提供共享的數據存儲。Content Provider(內容提供器)用來管理和共享應用程序的資料庫。在應用程序間，Content Provider是共享數據的首選方式。
Broadcast Receivers(廣播接收器)
Intent廣播的「消費者」。通過創建和注冊一個Broadcast Receiver，應用程序可以監聽符合特定條件的廣播的Intent。Broadcast Receiver 會自動的啟動你的Android應用程序去響應新來的Intent。Broadcast Receiver是事件驅動程序的理想手段。
參考資料來源：網路-Android組件