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缁勪欢涓嶉渶瑕佹坠锷ㄥ仠姝銆