    Service
Service，即服务。Activity在前面展示，而service则是真正在后台进行相关的数据处理的单元，很多服务都是在后台默默进行，它是没有界面的长生命周期的代码。它可以运行很长时间而没有界面，仅仅在开始和完成的时候通过 activity来告知用户，例如下载文件或者通话拦截等。服务，从最直白的视角来看，就是剥离了界面的Activity，它们在很多Android的概念方面比较接近，都是封装有一个完整的功能逻辑实现。
    BroadcastReceiver
BroadcastReceiver，即广播接收器。在实际应用中，我们常常需要等，等待系统或者其他的一些应用程序发送一些相关的指令，为自己的应用擦亮明灯指明方向。而这种等待，在很多的平台上，都需要付出很大的代价才可以实现。比如，在Symbian中，你要等待一个来电消息，进而显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，并且消隐图标隐藏任务项，潜伏在后台，监控着相关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。
而在Android中，设计者充分的考虑到了这种需求，于是添加了Broadcast -Receiver组件，它通过 NotificationManager 来通知用户这些事情发生了。BroadcastReceiver 既可以在 AndroidManifest.xml 中注册，也可以在运行时的代码中使Context.registerReceiver（)进行注册。不同的应用程序之间，或者同一个应用程序的不同组件之间，可以借此来发送通知和接收通知。从而大大简化了应用程序之间的通信和捕获事件所带来的资源消耗浪费。
    Content provider
Content provider,即内容提供者。在Android中，安全权限机制比较健全，某个应用如果想要读取用户的通讯录、通话记录以及本地图片等相关个人私密内容，就需要实现申请权限，另外，一个应用也不能随便对另一个应用的数据进行非法访问和操作。那么如果多个应用想要进行沟通和交流，岂不是就无法实现了。比如通讯类应用如果不允许其他的应用对它的联系人数据进行相关的操作，那么应用本身就失去了可扩展性，也很难发挥其存在的价值。
Android提供了Content Provider。应用想对外提供的数据，可以通过派生ContentProvider类， 封装成一枚Content Provider，每个Content Provider都用一个uri作为独立的标识。在Android中，ContentResolver是用来发起Content Provider的定位和访问的。不过它仅提供了同步访问的Content Provider的接口。但通常，Content Provider需要访问的可能是数据库等大数据源，效率上不足够快，会导致调用线程的拥塞。所以我们在编程中如果发现了本次资源变化，而应用未能很快发现，很可能是这里的问题。总之，我们可以理解为内容提供者对应用程序的数据进行了封装，阻止了非法访问和保障了数据的安全性和可靠性。
2.2.    云存储的发展
目前，云计算服务已经演变成多种多样的方式来提供服务。主要有下面的几种方式：
2.2.1.    云计算基础架构
这类云服务的提供商主要有Amazon和谷歌，他们都提供底层的技术平台以及核心的云服务，他们能够起到支撑整个互联网的形态和架构，将对于类似于内存、硬盘空间和带宽这样的资源进行整合管理，再将这些资源形成的虚拟资源池加以运用，发挥更大的效率和利益。
2.2.2.    云计算开发环境
顾名思义，这一类的提供商将基础架构的功能进行了一定的封装，开发出一套自己的开发环境，然后将其提供给开发商，开发商在这个开发环境中进行开发并且通过供应商的网络将开发所得的程序提供给用户。 基于云存储和智能电视技术的家庭相册系统设计(4):http://www.youerw.com/jisuanji/lunwen_14473.html