⑴ 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 應用開發怎麼在應用中隱藏魅族的smarkbar組件
您好，
如果是最新版Flyme3或者Flyme4，進入設置——輔助功能里就有「智能隱藏smartbar」選項的，開啟後即可隱藏。
⑶ 安卓有幾個組件
Android中有四大組件。分別為：activity顯示界面、service服務、BroadcastReceiver廣播、ContentProvider數據通信。
Android是由Google公司和開放手機聯盟領導並開發的一種基於Linux的自由且開放源代碼的操作系統，主要使用於移動設備。其最初由Andy Rubin開發，後被Google於2005年8月收購。之後Google與84家硬體製造商、軟體開發商及電信營運商組建開放手機聯盟，共同研發改良Android系統，完成開發後，Google以Apache開源許可證的授權方式，發布了Android的源代碼。Android一詞的本義指「機器人」，同時也是Google於2007年11月5日宣布的基於Linux平台的開源手機操作系統的名稱，該平台由操作系統、中間件、用戶界面和應用軟體組成。
⑷ android 顯示intent和隱士inent的區別
以下內容為CSDN上（網名：yuan1590）對安卓顯示意圖和隱身意圖的總結（ps前人種樹，樹，後人乘涼，所以我就粘過來了，希望幫到您）：
1. Intent
Android基本的設計理念是鼓勵減少組件間的耦合，因此Android提供了Intent (意圖) ，
Intent提供了一種通用的消息系統，它允許在你的應用程序與其它的應用程序間傳遞 Intent 來執行動作和產生事件。
使用 Intent 可以激活 Android 應用的三個核心組件：活動(Activity)、服務(Service)和廣播接收器(BroadcastReceiver)。
2. 顯式意圖、隱式意圖
Intent可以劃分成顯式意圖和隱式意圖。
顯式意圖：調用Intent.setComponent() 或 Intent.setClassName() 或 Intent.setClass()方法明確指定了組件名的Intent為顯式意圖，顯式意圖明確指定了Intent應該傳遞給哪個組件。
如: 在 MainActicity 中打開一個新的 Acticity -- OtherActivity
1. Intent intent = new Intent();
2. intent.setComponent(new ComponentName(MainActivity.this, OtherActivity.class));
3. 第二行代碼可以更換為：intent.setClass(MainActivity.this, OtherActivity.class);
4. 也可以使用構造器來指定組件： Intent intent = new Intent(MainActivity.this, OtherActivity.class)
三種 「顯式意圖」 指定方式等價
隱式意圖：沒有明確指定組件名的Intent為隱式意圖。
Android系統會根據隱式意圖中設置的動作(action)、類別(category)、數據（data: URI和數據類型）找到最合適的組件來處理這個意圖
例如撥打電話的意圖:
Uri uri = Uri.parse("tel:" + phoneCode);
Intent intent = new Intent(Intent.ACTION_CALL, uri);
對於隱式意圖，Android是怎樣尋找到這個最合適的組件呢？記的前面我們在定義活動時，指定了一個intent-filter，Intent Filter（意圖過濾器）其實就是用來匹配隱式Intent的，當一個意圖對象被一個意圖過濾器進行匹配測試時，只有三個方面會被參考到：動作、數據（URI以及數據類型）和類別。
動作測試（Action test）
一個意圖對象只能指定一個動作名稱，而一個過濾器可能列舉多個動作名稱。如果意圖對象或過濾器沒有指定任何動作，結果將如下：
+ 如果過濾器沒有指定任何動作，那麼將阻塞所有的意圖，因此所有的意圖都會測試失敗。沒有意圖能夠通過這個過濾器。
<intent-filter><!-- 空的 --></intent-filter>
+ 另一方面，只要過濾器包含至少一個動作，一個沒有指定動作的意圖對象自動通過這個測試
類別測試（Category test）
對於一個能夠通過類別匹配測試的意圖，意圖對象中的類別必須匹配過濾器中的類別。這個過濾器可以列舉另外的類別，但它不能遺漏在這個意圖中的任何類別。
原則上一個沒有類別的意圖對象應該總能夠通過匹配測試，而不管過濾器里有什麼。大部分情況下這個是對的。
但有一個例外，Android把所有傳給startActivity()的隱式意圖當作他們包含至少一個類別："android.intent.category.DEFAULT" （CATEGORY_DEFAULT常量）。
因此自定義 Activity 的時候，不要以為光定義一個 action 就夠了。這樣用 startActivity() 來激活這個 Activity 的時候將一直報錯。
原因就是，他內部要求去匹配 android.intent.category.DEFAULT 這個類別。
因此，想要接收隱式意圖的活動必須在它們的意圖過濾器中包含"android.intent.category.DEFAULT"。
（帶"android.intent.action.MAIN"和"android.intent.category.LAUNCHER"設置的過濾器是例外）
數據測試（Data test）
當一個意圖對象中的URI被用來和一個過濾器中的URI比較時，比較的是URI的各個組成部分。
例如，如果過濾器僅指定了一個scheme，所有該scheme的URIs都能夠和這個過濾器相匹配；
如果過濾器指定了一個scheme、主機名但沒有路經部分，所有具有相同scheme和主機名的URIs都可以和這個過濾器相匹配，而不管它們的路經；
如果過濾器指定了一個scheme、主機名和路經，只有具有相同scheme、主機名和路經的URIs才可以和這個過濾器相匹配。
當然，一個過濾器中的路徑規格可以包含通配符，這樣只需要部分匹配即可。
數據測試同時比較意圖對象和過濾器中指定的URI和數據類型。規則如下：
a. 一個既不包含URI也不包含數據類型的意圖對象僅在過濾器也同樣沒有指定任何URIs和數據類型的情況下才能通過測試。
b. 一個包含URI但沒有數據類型的意圖對象僅在它的URI和一個同樣沒有指定數據類型的過濾器里的URI匹配時才能通過測試。
這通常發生在類似於mailto:和tel：這樣的URIs上：它們並不引用實際數據。
c. 一個包含數據類型但不包含URI的意圖對象僅在這個過濾器列舉了同樣的數據類型而且也沒有指定一個URI的情況下才能通過測試。
d. 一個同時包含URI和數據類型（或者可從URI推斷出數據類型）的意圖對象可以通過測試，如果它的類型和過濾器中列舉的類型相匹配的話。
如果它的URI和這個過濾器中的一個URI相匹配或者它有一個內容content:或者文件file: URI而且這個過濾器沒有指定一個URI，那麼它也能通過測試。
換句話說，一個組件被假定為支持content:和file: 數據如果它的過濾器僅列舉了一個數據類型。
⑸ android的listview一鍵隱藏所有子項中的某一個組件
同時隱藏所有Items比隱藏單一的一個簡單點，直接一個boolean去控制就行。
在getView裡面去判斷這個值是true或false，來決定tv1和tv2的顯示/隱藏。
當你在ListView的上面，比如你是一個按鈕去實現的，那就是第一次點擊後，將boolean設成true，然後adapter.setNotifyChanged讓listView再去更新一下，相當於getView再走一次，就會重新判斷boolean去顯示或者隱藏tv1和tv2。你再點擊按鈕，同樣去修改boolean值，再adapter更新一下。