概述Android中的四大组建

 

Activity、Service、BroadcastReceiver、ContentProvider

 

Activity {

    从视觉效果来看

    一个Activity占据当前的窗口，相应所有的窗口事件，具备有控件、菜单等界面的元素。从内部逻辑来看

    Activity为了保持各个界面的状态，需要做很多持久化的事情，还要妥善管理生命周期、跳转逻辑等..

    对于开发者而言，就需要派生Activity的子类，然后埋头苦干上述事情。

}

 

 

Service {

    服务，从最直白的角度来看，就是剥离了界面的Activity，

    他们在很多概念方面比较接近，都是封装有一个完整的功能逻辑实现。

    Service就如成功男人背后的女人，那个默默无声坚实的后盾

 

    话又说回来，换个角度来看，

    Activity是跳，从一个跳到另一个。

    Service是等，等上层来连接它，然后产生一段持久缠绵的通信，

    就像用了Ajax，看着没啥变化，暗地里偷偷摸摸的不知和Service眉来眼去的多少回。

 

    但它和一般的Service还是有所不同的，Android中的Service是和其他三大组建一样的，其进程模型都是可

    以配置的，调用方和发布方都可以有权利来选择是把这个组建运行在同一个进程下，还是不同的进程下。

    如果一个Service期望运行在与调用方不同于的进程下时，这就需要利用Android提供的RPC机制，为其不熟一套进程间的通信策略。

 

    RPC ｛

        基于代理模式的一个实现，在调用断和服务端都去生成一个代理类，做一些序列化和反序列化的事情，

        使得调用断和服务端都可以调用一个本地接口一样使用RPC接口

 

        Android中用来做序列化的类是Parcel，封装了序列化的细节，向外提供了足够对象化的访问接口。

        Google号称实现非常高效。

 

        再就是AIDL(Android Interface Definition Language)，一种接口定义的语言，

        服务的RPC接口，可以用来AIDL描述，着用，ADT就可以帮助你自动生成一整套的代理模式需要用到的类。

 

        Service的实现：

        定义好需要接受的Intent，提供同步或异步的接口，在上层绑定它之后，通过这些接口进行通信。

        在RPC接口中使用的数据、回调接口对象，如果不是标准的系统实现(系统可序列化的)，则需要定义DIDL。

    ｝

 

    Service从实现角度看，最特别的就是这些RPC的实现了，其他内容都会接近与Activity的一些实现。

}

 

 

 

BroadcastReceiver {

    在实际应用中，我们需要等，等待系统或其他应用发出一道指令，为自己的应用指明方向。

    而这种等，在很多平台上都会需要付出不小的代价。

    比如Symbian中，你要等待一个来电消息，显示归属地之类的，

    必须让自己的应用忍辱负重偷偷摸摸的开机启动，消除图标，隐藏任务项，潜伏在后台，监控着相关的事件，

    等待转瞬即逝的出手机会，不但拜拜浪费了系统资源，还留了个流氓软件的骂名，费力不讨好。

 

    但在Android中，充分考虑了广泛的这类需求，于是就有了BroadcastReceiver这样的一个组件。

    每个BroadcastReceiver都可以接收一种或若干种Intent作为触发事件，当事件触发，

    系统会负责唤醒或传递消息到该BroadcastReceiver，任其处置。而在此之前和这以后BroadcaseReceiver是否

    在运行都不重要了，绿色环保。

 

    这个实现机制显然是基于一种注册方式的，BroadcaseReceiver将其他正描述并注册在系统中，可分为两种。

    1、事件发生 -> 通知Broadcast -> 实施处理 (通常是在OnResume事件中通过registerReceiver进行注册,

    在OnPause等事件中反注册)

    2、启动应用 -> 监听事件 -> 实施处理

 

    除了接收消息的一方有多种模式，发送者有很选择权。通常发送者有两类

    一类是系统本身，我们称之为Broadcase消息。

    除了系统，自定义的应用也可放出Broadcase消息，通过的接口可以是Context.sendBroadcase或Context.sendOrderedBroadcase

    前者走的是共产主义路线，所有关注该消息的Receiver都有机会获得并且进行处理

    后者走的是具有中国特色的社会注意路线、接收者按资排辈，有权有势的先吃饱了，后面的吃剩下的。

    要是还没轮到你就吃没了，那你就只能去喝西北风了

 

    当BroadcaseReceiver接收到相关的消息，他们通常是一些简单的处理，然后转换为一条Notification，

    一次震动、一个响铃、一个Activity进行进一步的交互处理等，虽然Broadcase整个逻辑不复杂，却足够好用，

    它统一了Android的事件和广播模型。

}

 

 

ContentProvider {

    听这名就觉得跟数据库有一腿，没错，这就是Android提供的第三方数据库的访问方案。

    在Android中，对数据库的保护是很严密的，除了放在SD卡中的数据库，一个应用所持有的数据库、文件等，

    都是不允许第三方直接访问的。

    但有时候沟通是必要的，不光对别人，对自己也是。

    比如一个联系人管理的应用，如果不允许第三方应用对其联系人数据库进行增删改查，那整个应用就失去了可拓展能力，

    必将被其他应用所抛弃，只能宅在家里自己安慰自己了。

 

    Android为所有应用都准备了一扇窗，这就是ContentProvider。

    应用想对外提供数据，可以通过派生ContentProvider类，封装成一枚ContentProvider，

    每个ContentProvider都用一个uri作为独立的标识，形如：content://com.xxx...所有的东西都看起来像REST的样子，

    但实际上它比REST更灵活。和REST累死，uri也可以有两种类型，带id的、列表的。

    但实现着不一定非按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨。

    另外，ContentProvider不像REST只能接收uri，ContentProvider还可以接收Projection、Selection、OrderBy等参数，

    这样就可以像数据库那样进行投影、选择和排序。查询到的结果以Cursor的形式进行返回，调用者可以移动Cursor来访问各列的数据。

    ContentProvider内部常用数据库来实现，Android对Sqlite的支持非常强大，但很多时候也可以封装文件或其他混合的数据。

 

    在Android中，ContentResolver是用来发起ContentProvider的定位和访问的。不过它仅提供了同步访问的ContentProvider的接口。

    但通常，ContentProvider需要访问一些大数据源，因此Android提供了一个AsyncQueryHandler帮助进行异步访问ContentProvider。

}

 

 

在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供异步访问的接口，

而Content Provider不论效率如何，都提供的是约定的同步访问接口。我想这遵循的就是场景导向设计的原则，

因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据，

而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。