android分享組件

❶ Android N 四大組件的工作原理

本文側重講解android N 系統中四大組件的工作原理，不同系統原理略有差別。通過分析四大組件的工作流程加深對Android Framework的理解，也為插件化開發打下基礎。

Activity
展示一個界面並和用戶交互，它扮演的是一個前台界面的角色。

Service
計算型組件，用於後台執行一系列計算任務，工作在主線程，耗時操作需要另起線程， 分為啟動狀態和綁定狀態。

BroadcastReceiver
消息型組件，主要用於不同組件或者不同應用之間的消息傳遞，它工作在系統內部，不適合執行耗時操作，操作超過5s，會出現ANR。

ContentProvider
數據共享型組件，用於向其他組件或者應用共享數據，主要執行CURD操作。

我們啟動一個activity有兩種方法，
第一種（Activity直接啟動方式）：
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);

第二種（Context啟動方式）
Intent intent = new Intent(this, MainActivity.class);
getApplicationContext().startActivity(intent);

不同的啟動方式Activity的工作流程有點差別。

兩種啟動都會調用到Instrumentation類中的execStartActivity的方法，系統最終是通過ActivityThread中的performLaunchActivity完成Activity的創建和啟動。
performLaunchActivity方法主要完成以下工作：
1、通過ActivityClientRecord對象獲取啟動activity的組件信息
2、通過mInstrumentation對象的newActivity方法調用classloader完成activity的創建
3、通過r.packageInfo(LoadedApk 對象)的makeApplication方法嘗試創建Application對象
4、創建ContextImpl對象並調用Activity的attach方法完成一些數據的初始化
5、調用Activity的onCreate方法

在Activity啟動的過程中，App進程會頻繁地與AMS進程進行通信：

App進程會委託AMS進程完成Activity生命周期的管理以及任務棧的管理；這個通信過程AMS是Server端，App進程通過持有AMS的client代理IActivityManager完成通信過程；
AMS進程完成生命周期管理以及任務棧管理後，會把控制權交給App進程，讓App進程完成Activity類對象的創建，以及生命周期回調；這個通信過程也是通過Binder完成的，App所在server端的Binder對象存在於ActivityThread的內部類ApplicationThread；AMS所在client通過持有IApplicationThread的代理對象完成對於App進程的通信。

Service有兩種啟動方式，startService()和bindService()，兩種狀態可以並存:
startService流程

bindService流程

BroadcastReceiver的工作過程主要包括廣播的注冊、發送和接收:

動態注冊過程：

發送過程

靜態注冊是由PackageManagerService（PMS）在應用安裝的時候完成整個注冊過程的，除廣播以外，其他三大組件也都是在應用安裝時由PMS解析並注冊的。

每個進程的入口都是ActivityThead.main()，App的啟動流程如下：

從源碼中可以看出：
應用啟動的入口為ActivityThread的main方法，main方法會創建ActivityThread實例並創建主線程消息隊列。
attach方法中遠程調用AMS的attachApplication方法，並提供ApplicationThread用於和AMS的通信。
attachApplication方法會通過bindApplication方法和H來調回ActivityThread的handleBindApplication，這個方法會先創建Application，再載入ContentProvider，然後才會回調Application的onCreate方法。

由上圖可以看出，在ContentProvider的啟動過程中伴隨著app進程的啟動。

ContentProvider的其他CURD操作如insert，delete，update跟query的流程類似。

❷ 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 面試怎麼介紹四大組件

先概括性介紹：
1.Activity :
應用程序中，一個Activity通常就是一個單獨的屏幕，它上面可以顯示一些控制項也可以監聽並處理用戶的事件做出響應。
2.BroadcastReceive廣播接收器:
應用可以使用它對外部事件進行過濾只對感興趣的外部事件(如當電話呼入時，或者數據網路可用時)進行接收並做出響應。
3.Service 服務:
一個Service 是一段長生命周期的，沒有用戶界面的程序，可以用來開發如監控類程序。
4.Content Provider：
android平台提供了Content Provider使一個應用程序的指定數據集提供給其他應用程序。
最後具體說明，再加總結。

❹ Android的四大組件是哪些，它們的作用

Android四大組件分別為activity、service、content provider、broadcast receiver。
一、android四大組件詳解
1、activity
（1）一個Activity通常就是一個單獨的屏幕（窗口）。
（2）Activity之間通過Intent進行通信。
（3）android應用中每一個Activity都必須要在AndroidManifest.xml配置文件中聲明，否則系統將不識別也不執行該Activity。
2、service
（1）service用於在後台完成用戶指定的操作。service分為兩種：
（a）started（啟動）：當應用程序組件（如activity）調用startService()方法啟動服務時，服務處於started狀態。
（b）bound（綁定）：當應用程序組件調用bindService()方法綁定到服務時，服務處於bound狀態。
(2)startService()與bindService()區別：
(a)started service（啟動服務）是由其他組件調用startService()方法啟動的，這導致服務的onStartCommand()方法被調用。當服務是started狀態時，其生命周期與啟動它的組件無關，並且可以在後台無限期運行，即使啟動服務的組件已經被銷毀。因此，服務需要在完成任務後調用stopSelf()方法停止，或者由其他組件調用stopService()方法停止。
(b)使用bindService()方法啟用服務，調用者與服務綁定在了一起，調用者一旦退出，服務也就終止，大有「不求同時生，必須同時死」的特點。
(3)開發人員需要在應用程序配置文件中聲明全部的service，使用標簽。
(4)Service通常位於後台運行，它一般不需要與用戶交互，因此Service組件沒有圖形用戶界面。Service組件需要繼承Service基類。Service組件通常用於為其他組件提供後台服務或監控其他組件的運行狀態。
3、content provider
（1）android平台提供了Content Provider使一個應用程序的指定數據集提供給其他應用程序。其他應用可以通過ContentResolver類從該內容提供者中獲取或存入數據。
（2）只有需要在多個應用程序間共享數據是才需要內容提供者。例如，通訊錄數據被多個應用程序使用，且必須存儲在一個內容提供者中。它的好處是統一數據訪問方式。
（3）ContentProvider實現數據共享。ContentProvider用於保存和獲取數據，並使其對所有應用程序可見。這是不同應用程序間共享數據的唯一方式，因為android沒有提供所有應用共同訪問的公共存儲區。
（4）開發人員不會直接使用ContentProvider類的對象，大多數是通過ContentResolver對象實現對ContentProvider的操作。
（5）ContentProvider使用URI來唯一標識其數據集，這里的URI以content://作為前綴，表示該數據由ContentProvider來管理。
4、broadcast receiver
（1）你的應用可以使用它對外部事件進行過濾，只對感興趣的外部事件(如當電話呼入時，或者數據網路可用時)進行接收並做出響應。廣播接收器沒有用戶界面。然而，它們可以啟動一個activity或serice來響應它們收到的信息，或者用NotificationManager來通知用戶。通知可以用很多種方式來吸引用戶的注意力，例如閃動背燈、震動、播放聲音等。一般來說是在狀態欄上放一個持久的圖標，用戶可以打開它並獲取消息。
（2）廣播接收者的注冊有兩種方法，分別是程序動態注冊和AndroidManifest文件中進行靜態注冊。
（3）動態注冊廣播接收器特點是當用來注冊的Activity關掉後，廣播也就失效了。靜態注冊無需擔憂廣播接收器是否被關閉，只要設備是開啟狀態，廣播接收器也是打開著的。也就是說哪怕app本身未啟動，該app訂閱的廣播在

❺ 什麼是android的四大組件

Android四大組件有Activity，Service服務，Content Provider內容提供，BroadcastReceiver廣播接收器。

Android應用程序由一些零散的有聯系的組件組成，通過一個工程manifest綁定在一起。在manifest中，描述了每一個組件以及組件的作用，其中有6個組件，它們是Android應用程序的基石

(5)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組件

❻ 請android四大組件是什麼android常見合布局有哪些

Android有四大組件：Activity、Service、Broadcast Receiver、Content Provider

在這些組件之間的通訊中，主要是由Intent協助完成的。
Intent負責對應用中一次操作的動作、動作涉及數據、附加數據進行描述，Android則根據此Intent的描述，負責找到對應的組件，將 Intent傳遞給調用的組件，並完成組件的調用。
因此，Intent在這里起著一個媒體中介的作用，專門提供組件互相調用的相關信息，實現調用者與被調用者之間的解耦。
例如，在一個聯系人維護的應用中，當我們在一個聯系人列表屏幕(假設對應的Activity為listActivity)上，點擊某個聯系人後，希望能夠跳出此聯系人的詳細信息屏幕(假設對應的Activity為detailActivity)
為了實現這個目的，listActivity需要構造一個 Intent，這個Intent用於告訴系統，我們要做「查看」動作，此動作對應的查看對象是「某聯系人」，然後調用startActivity (Intent intent)，
將構造的Intent傳入，系統會根據此Intent中的描述，到ManiFest中找到滿足此Intent要求的Activity，系統會調用找到的 Activity，即為detailActivity，最終傳入Intent，detailActivity則會根據此Intent中的描述，執行相應的操作。

如果您認可我的答案，請點擊下面的「選為滿意回答」按鈕，謝謝！

❼ 瀹夊崜鍥涘ぇ緇勪歡鍙婂叾浣滅敤

瀹夊崜鍥涘ぇ緇勪歡錛欰ctivity銆丼ervice銆丅roadcastReceiver鍜孋ontentProvider錛屼綔鐢錛

銆銆1銆丄ctivity緇勪歡鐨勪富瑕佷綔鐢ㄦ槸灞曠ず涓涓鐣岄潰騫跺拰鐢ㄦ埛浜や簰錛屽畠鎵婕旂殑鏄涓縐嶅墠鍙扮晫闈㈢殑瑙掕壊

銆銆Activity鏄涓縐嶅睍紺哄瀷緇勪歡錛屼富瑕佹槸鍚戠敤鎴峰睍紺轟竴涓鐣岄潰錛屽苟涓斿彲浠ユ帴鏀剁敤鎴風殑杈撳叆淇℃伅浠庤屽拰鐢ㄦ埛榪涜屼氦浜掋傚圭敤鎴鋒潵璇達紝Activity灝辨槸Android搴旂敤鐨勫叏閮錛屽洜涓哄叾浠栦笁澶х粍浠跺圭敤鎴鋒潵璇存槸涓嶅彲鎰熺煡鐨勩侫ctivity鐨勫惎鍔ㄧ敱Intent瑙﹀彂錛屽叾涓璉ntent鍒嗕負鏄懼紡鍚鍔ㄥ拰闅愬紡鍚鍔ㄣ

銆銆2銆丼ervice緇勪歡鐨勪富瑕佷綔鐢ㄦ槸鍦ㄥ悗鍙版墽琛岃＄畻浠誨姟錛屾墽琛屼換鍔＄殑緇撴灉鍙浠ュ拰澶栫晫榪涜岄氫俊

銆銆Service鏄涓縐嶈＄畻鍨嬬粍浠訛紝鐢ㄤ簬鍦ㄥ悗鍙版墽琛屼竴緋誨垪璁＄畻浠誨姟銆傜敱浜嶴ervice緇勪歡宸ヤ綔鍦ㄥ悗鍙幫紝鍥犳ょ敤鎴鋒棤娉曠洿鎺ユ劅鐭ュ埌瀹冪殑瀛樺湪銆係ervice緇勪歡鍜孉ctivity緇勪歡涓嶅悓錛孉ctivity緇勪歡鍙鏈変竴縐嶈繍琛屾ā寮忥紝鍗矨ctivity澶勪簬鍚鍔ㄧ姸鎬侊紝浣嗘槸Service緇勪歡鍗存湁涓ょ嶇姸鎬侊細鍚鍔ㄧ姸鎬佸拰緇戝畾鐘舵併係ervice緇勪歡澶勪簬鍚鍔ㄧ姸鎬佹椂錛屽畠鐨勫唴閮ㄥ彲浠ユ墽琛屼竴浜涘悗鍙拌＄畻錛屽苟涓斾笉闇瑕佸拰澶栫晫鏈夌洿鎺ョ殑浜や簰銆係ervice澶勪簬緇戝畾鐘舵侊紝Service鍐呴儴鍚屾牱涔熷彲浠ユ墽琛屽悗鍙拌＄畻錛屼絾鏄澶勪簬榪欑嶇姸鎬佺殑Service鍙浠ュ緢鏂逛究鍦板拰澶栫晫榪涜岄氫俊銆

銆銆3銆丅roadcastReceiver緇勪歡鐨勪富瑕佷綔鐢ㄦ槸娑堟伅鐨勪紶閫掞紝璇ユ秷鎮鐨勪紶閫掑彲浠ュ湪搴旂敤鍐咃紝涔熷彲浠ュ湪搴旂敤涔嬮棿錛屽畠鐨勮掕壊鏄涓涓娑堟伅鐨勪紶閫掕

銆銆BroadcastReceiver鏄涓縐嶆秷鎮鍨嬬粍浠訛紝鐢ㄤ簬鍦ㄤ笉鍚岀粍浠朵箖鑷充笉鍚屽簲鐢ㄤ箣闂翠紶閫掓秷鎮銆侭roadcastReceiver鍚屾牱鏃犳硶琚鐢ㄦ埛鎵鎰熺煡錛屽洜涓哄畠宸ヤ綔鍦ㄧ郴緇熷唴閮ㄣ侭roadcastReceiver涔熷彨鍋氬箍鎾錛屽箍鎾鐨勬敞鍐屾柟寮忔湁涓ょ嶏細闈欐佹敞鍐屽拰鍔ㄦ佹敞鍐屻傞潤鎬佹敞鍐屾寚鍦ˋndroidManifest涓娉ㄥ唽騫挎挱錛岃繖縐嶅箍鎾鍦ㄥ簲鐢ㄥ畨瑁呮椂琚緋葷粺瑙ｆ瀽錛屾ょ嶅艦寮忕殑騫挎挱涓嶉渶瑕佸簲鐢ㄥ惎鍔ㄥ氨鍙浠ユ帴鏀跺埌鐩稿簲鐨勫箍鎾銆傚姩鎬佸箍鎾闇瑕侀氳繃Context.registerReceiver()鏉ュ疄鐜幫紝騫朵笖鍦ㄤ笉闇瑕佺殑鏃跺欓氳繃Context.unRegisterReceiver()瑙ｉ櫎騫挎挱錛屾ょ嶅艦鎬佺殑騫挎挱蹇呴』瑕佸簲鐢ㄥ惎鍔ㄦ墠鑳芥敞鍐屽苟鎺ユ敹騫挎挱銆

銆銆4銆丆ontentProvider緇勪歡鐨勪富瑕佷綔鐢ㄦ槸浣滀負涓涓騫沖彴錛屾彁渚涙暟鎹鐨勫叡浜錛屽苟涓旀彁渚涙暟鎹鐨勫炲垹鏀規煡鍔熻兘銆備富瑕佸簲鐢ㄤ簬搴旂敤涔嬮棿鐨勬暟鎹鍏變韓鍦烘櫙

銆銆ContentProvider鏄涓縐嶆暟鎹鍏變韓鍨嬬粍浠訛紝鐢ㄤ簬鍚戝叾浠栫粍浠朵箖鑷沖叾浠栧簲鐢ㄥ叡浜鏁版嵁銆傚悓鏍風殑錛屽畠涔熸棤娉曡鐢ㄦ埛鎵鎰熺煡銆傚逛簬ContentProvider緇勪歡鏉ヨ達紝瀹冪殑鍐呴儴闇瑕佸疄鐜板炲垹鏀規煡榪欏洓縐嶆搷浣溿傞渶瑕佹敞鎰忕殑鏄錛孋ontentProvider鍐呴儴鐨刣elete銆乽pdate鍜宷uery鏂規硶闇瑕佸勭悊濂界嚎紼嬪悓姝ワ紝鍥犱負榪欏嚑涓鏂規硶閮芥槸鍦˙inder綰跨▼奼犱腑琚璋冪敤鐨勩侰ontentProvider緇勪歡涓嶉渶瑕佹墜鍔ㄥ仠姝銆