温故而知新Android篇之二

现在继续对android进行温习，上一篇日记主要温习了android比较宏观的知识和四大组件中的activity.现在开始下一个组件的温习:

Content Provider：

Content Provider内容提供者，在android系统中数据是私有的，两个应用程序之间可以通过Content Provider来实现。通过它将自己的数据暴露出去，外界不知道这些数据是如何存储的，重要的是外界可以通过这一套标准及统一的接口和程序里的数据打交道。外界的程序通过contentResolver()接口可以访问contentProvider提供的数据，通过getContentResolver()得到当前应用的contentResolver实例。另外，每个content Provider存储的数据都是以表的形式存在，那用什么来为这些表做标识呢？没错就是URI，URI的形式是这样<scheme>://<authority><path>?<query>对于content Provider的数据表，<scheme>字段内容固定为"content",<authority>字段内容指定了content Provider的具体类别。我们知道了用URI来标识content provider,那么如何生成我们需要的URI呢？其实生成具体URI常用方法有ContentUris类的Uri ContentUris.withAppendedId(Uri contentUri,long id)和 Uri类的Uri.withAppendedPath(Uri baseUri,String PathSegment).我们必须为URI与对应的表或者数据类型建立映射，在Content Provider解析URI以确定具体的表及数据时，通常使用UriMatcher类的addURI(string authority,string path,int code)方法来建立URI和指定数据表的记录的关系。根据content Provider的实现及声明方式，content Provider和使用它的应用可以在同一进程内，也可以不在同一进程内。当处于同一进程时，可以互相访问对方在系统/data/data中的资源，实现资源共享。

介绍完content provider的使用方法后，我们来了解一下content provider的加载机制吧，当启动时平台通过acquireProvider（）解析AndroidManifest.xml文件中content Provider声明的<authority>字段，并自动加载所有content provider,content provider的android:multiprocess属性值决定了该content provider能否在多个应用进程中被创建，默认为false.当其它应用使用该content provider,则会通过进程间通信(IPC)方式调用content provider对象。如果此时该content provider存储数据不用在多个进程间同步，则可以将android:multiprocess赋为true,当多个调用该content provider应用进程分别创建content provider实例。

Service:

接下来要介绍的就是Service，Service的生命周期包括:onCreate、onStart、和onDestroy，应该注意的是在一个生命周期中，onCreate只会调用一次，而onStart可以被调用多次。我们可以通过以下两种方式启动一个Service。a.通过startService:Service会经历onCreate()->onStart()->stopService(),stopService的时候会直接onDestroy.b.通过bindService:Service只会onCreate,调用者和Service会绑定在一起，当调用者退出时，Service会调用onUnbind->onDestoyed。当我通过这些方法启动Service时，如果service还没有运行，则android会调用onCreate方法，然后再调用onStart，而如果service已运行，则通过新的Intent调用onStart方法.同时我们应该注意先bind和先start是有区别的，如果我们先bind时，start的时候就会直接运行service的onStart方法，而且先bind,stop不了，只可以先unbindService再stopService。而先start时，bind的时候直接运行onBind.

BroadcastReceiver:

广播接收者的注册方式有两种:AndroidMinfest.xml中注册BroadcastReceiver之外;还可以在代码中注册.需要注意的是为减轻系统的负载，注销注册的BroadcastReceiver是良好的习惯.

在onReceive()方法执行中，则Android系统认为Receiver处于活动状态,onReceive()执行完后，则认为非活动状态，系统会任意时间销毁。在所调用的onReceive(Context,Intent),函数里，不能有过于耗时的操作，不能使用线程来执行，对于耗时的操作，请startService来完成。因为当得到其它异步操作所返回的结果时，BroadcastReceiver可能已经无效了.需要记住的是BroadcastReceiver是四大组件中唯一一个被动接收数据的组件.

到目前为止，已经重新粗略地温习了一次Android四大组件的一些用法和知识点，下一次就要开始Intent和IntentFilter与四大组件之间的关系和知识点

更多相关文章

随机推荐