Android应用程序基础（Application Fundamentals）之一

正在尝试分析SDK中的示例程序NotePad，发现仍然还欠缺不少知识。今天看到 API Guides 下有一部分应用程序基础 Application Fundamentals，感受须要进一步学习。因而准备采用以前的策略，边翻译，边学习。虽然这样作，学起来很慢，可是，好在能够慢慢理解，转化为本身的语言的同时也是一种加深记忆的过程。反正，我也只是业余学习，不赶时间，呵呵。

整个API指南有不少个章节，下面先把章节的名字列一下，这样知道还有多长的路要走。

API Guides （developer.android.com/guide/components/index.html）

• [App Components]
• [User Interface]
• [App Resources]
• [Animation and Graphics]
• [Computation]
• [Media and Camera]
• [Location and Sensors]
• [Connectivity]
• [Text and Input]
• [Data Storage]
• [Administration]
• [Web Apps]
• [Best Practices]

其中第一章 应用程序组件（App Components）就有多个子章节。各章节的名字以下：

App Components

• [App Fundamentals]
• [Activities]
• [Services]
• [Content Providers]
• [Intents and Intent Filters]
• [Processes and Threads]
• [Permissions]
• [App Widgets]
• [Android Manifest]

下面正式进入第一小节 App Fundamentals 的学习。

Android应用程序基础（Application Fundamentals）

Android应用程序使用JAVA语言编程。Android SDK工具编译源代码，并连同全部的数据文件和资源文件，打成一个Android包（以.apk为后缀的存档文件）。在一个.apk文件里的全部代码被认为是一个应用程序。基于Android系统的设备（手机或者平板）经过这个文件来安装应用程序。

Android应用程序一旦被安装到设备（手机或平板电脑）上，那么它就只存活在属于它本身的安全沙盒中。

译者注：现实中的沙盒，是一种儿童玩具，类如KFC中一个装满小球的容器，儿童能够在随意玩耍，起到保护儿童的做用。（也能够理解为一种安全环境）。一样在网络技术中也是一种按照安全策略限制程序行为的执行环境。

• Android操做系统是一个多用户Linux系统，每个应用程序在其中都是一个不一样的用户。
• 默认状况下，系统为每个应用程序分配一个惟一的Linux用户ID（这个ID仅供系统使用，对应用程序不可见）。系统为应用程序中的全部文件设置权限，这样只有分配给该应用程序的用户ID能够访问它们。
• 每个处理进程都有它本身的虚拟机（VM），这样一个应用程序的代码是与其余应用程序隔离运行的。
• 默认状况下，每一个应用程序运行在它本身的Linux进程中。当应用程序的任何组件须要执行的时候，Android启动其处理进程。当再也不须要它，或当系统须要为其余应用程序恢复内存时，关闭该处理进程。

在这种方式中，Android系统实现了最小特权原则。也就是，默认状况下，每一个应用程序只能访问的它须要为其工做的组件，而没有更多权限。这创造了一个很是安全的环境，应用程序不能访问它没有得到权限的系统的一部分。

不过，也有一些方法可使应用程序之间共享数据，或者让应用程序访问系统服务： 

• 当两个应用程序须要互相访问对方的文件时，就可能为这两个应用程序分配同一个Linux用户ID。为了节省系统资源，具备相同用户ID的程序能够运行在同一个Linux进程中，并共享同一个虚拟机（应用程序也必须使用相同的签名证书）。
• 应用程序能够请求访问设备（手机或平板）数据，如联系人信息，短信，可插拔的存储设备（SD卡），相机，蓝牙，和更多。应用程序的全部权限必须在安装的时候由用户授予。

本文介绍关于Android应用程序如何在系统运行的基础知识。本文档的其他部分将向你介绍：

• 用来定义应用程序的核心框架组件。
• 用来为应用程序声明组件和所需设备功能的清单文件（manifest file）。
• 将资源从应用程序代码中分离，让应用程序能够在各类设备上都能完美运行。

应用程序组件（Application Components）

应用程序组件是应用程序的基本构建块。每一个组件都是不一样的切入点。经过它们，系统能够进入你的应用程序。并不是全部的组件都是用户的实际切入点，它们其中的某一些是相互依赖的。但每个组件都做为本身实体存在并扮演一个特定的角色，都是用来帮助定义你的应用程序总体行为的一个独特的建筑块。

有四种不一样类型的应用程序组件。每种类型服务于不一样的目的，有不一样的生命周期（定义了如何建立和销毁）。

下面列举了这四种不一样类型的应用程序组件：

Activities

一个activity就是一个用户界面。例如，一个电子邮件应用程序可能有一个activity，用于展现新电子邮件的列表，另外一个activity用于编写电子邮件，还有一个用于读取邮件的activity。虽然在电子邮件这个应用中，多个activity共同做用造成了一个总体的用户体验。可是，每个activity都是独立的。所以，另一个应用程序能够启动这些activity中的任何一个（若是邮件应用程序容许的话）。例如，一个摄像头的应用能够经过启动邮件应用程序中的activity来新建一封电子邮件，从而实现照片分享功能。

一个activity要做为Activity的子类来实现，更多的信息能够参考Activity的开发指南。

Services

服务是一个在后台运行的组件，用来执行长时间操做或执行远程操做。服务不提供用户界面。例如，一个服务能够在后台播放音乐，而此时用户在另一个不一样的应用程序中。也能够用来从网络获取数据，而同时不阻塞用户与一个activity的交互。别的组件，如activity，能够启动一个服务，并让它运行，或者与它绑定，并进行交互。

一个服务要做为Service的子类来实现，更多的信息能够参考Services的开发指南。

Content providers

内容提供者管理应用程序用来共享的数据集合。你能够将数据存储在文件系统，SQLite数据库，互联网，或者其它任何你的应用程序能够访问的持久化存储位置。经过内容提供商，其余应用程序能够查询甚至修改数据（若是内容提供者容许的话）。例如，Android系统提供一个内容提供者用于管理用户的联系人信息。所以，任何拥有合适权限的应用程序能够查询内容提供者的某一部分（如ContactsContract.Data）来读取和写入一个特定联系人的信息。

内容提供者也能够用于读写那些应用程序私有的没有共享的数据。例如，记事本示例程序就使用内容提供者来保存记录信息。

内容提供商做为ContentProvider的一个子类来实现，而且必须实现了一套标准的API接口，方便其余应用程序来调用执行。欲了解更多信息，请参阅Content Providers开发人员指南。

Broadcast receivers

广播接收器是一个用于响应系统范围内广播公告的组件。许多广播都是由系统所产生的。例如，一个广播能够报告屏幕已关闭，电量低，或者捕获到了一个图片。应用程序也能够发起广播——好比，让其余应用程序知道，有一些数据已经被下载到设备上，能够被他们使用了。虽然广播接收器不会有用户UI界面的显示，可是它们可能会建立一个状态栏通知，来告知用户有广播事件发生。一般来讲，广播接收机只是一个到其它组件的“网关”，它要作的事情很是少。例如，它可能会启动一个服务来执行一些基于这一事件的工做。

一个广播接收机做为BroadcastReceiver的一个子类来实现，每一个广播是做为一个Intent对象来交付的。更多的信息，请参见BroadcastReceiver类。

Android系统有一个不一样寻常的特性，任何应用程序均可以启动另一个应用程序的组件。例如，若是你但愿用户使用设备（手机或者平板电脑）的摄像头去拍一张照片，这颇有多是另一个应用程序所实现的功能，而你的应用程序能够直接去使用它。而不须要你本身开发一个activity去实现拍照的功能。你不须要合并或者连接相机应用程序的代码。相反地，你只须要简单地启动相机应用程序中的一个activity来实现拍照的功能。当拍照完成以后，所拍的照片甚至会返回到你的应用程序，这样你能够直接使用它。对于用户而言，照相机功能就好像是你的应用程序的一部分。

当系统启动一个组件时，应用程序就开始运行了（若是这以前并无运行），而且实例化这个组件所须要的类。例如，若是你的应用程序启动了相机应用程序中的activity来捕捉一张照片，那么这个activity其实是运行在相机应用程序的处理进程中，而不是在你的应用程序的处理进程中。所以，与大多数其余系统上的应用程序不一样，Android应用程序没有一个单一的入口点（例如，没有main()函数）。

由于每一个应用程序运行在一个单独的进程里，其文件权限限制了其余应用程序的访问。因此，你的应用程序不能直接激活另一个应用程序中的组件。然而，Android系统能够。因此，要想激活另一个应用程序中的组件，你必须给系统发一个消息，指定一个启动特定组件的intent。而后，系统就帮你去激活该组件。

Activating Components

四个组件类型的三个：活动、服务、广播接收器都是被一个称为intent的异步消息所激活的。Intent能够在运行时，将组件与组件之间结合起来（你能够把它们想象成信使，用于请求其余组件的动做），而不论这个组件是不是属于你的应用程序仍是别的应用程序。

经过建立一个Intent对象来建立intent。它定义一个消息，用来激活一个特定组件或者特定类型的组件。一个intent能够是显式的，也能够是隐式的。

对于活动和服务，intent须要定义将要执行的操做（例如，“查看”或“发送”某些东西），同时也可能会给出操做时须要的数据的URI（或者组件开始工做时须要的其余什么东西）。例如，一个intent可能会请求一个活动来显示一个图像或打开一个网页。在某些状况下，你能够开始一个活动来得到结果，在这种状况下，该活动也会将结果放在Intent中返回（例如，能够发出一个intent，让用户选择一个联系人并返回给你，返回的intent包含一个指向所选定联系人的URI）。

对于广播接收器，intent只是简单地定义了要广播的公告（例如，一个指示设备电量不足的广播就只包含一个已知动做的字符串，以表示“电量不足”）。

其余组件类型，内容提供商，则不是被intent激活的。相反，它是被ContentResolver的一个请求所激活的。内容解析器（ContentResolver）处理全部与内容供应商（Content Provider）的直接交易，这样，执行事务的组件就不须要了，而是调用ContentResolver对象上的方法。这使得内容提供者和请求信息的组件之间有一个抽象层（为了安全）。

每一个类型的组件都有单独的激活方法：

经过传递一个Intent给startActivity()或者startActivityForResult()（当须要返回结果时），你能够启动一个活动（或者给它一些新的东西去作）。

经过传递一个Intent给startService()，你能够启动一个服务（或者将新的指令发给正在运行的服务）。或者经过传递一个Intent给bindService()来实现服务的绑定。

经过传递一个Intent给sendBroadcast(),sendStickyBroadcast()或者sendOrderedBroadcast()，你能够发起一个广播。

经过调用ContentResolver的query()方法，你能够给内容提供者发起查询请求。

对于如何使用intent的更多信息，请参见Intents and Intent Filters文件。更多有关于激活特定的组件的信息，也在下列文件中提供：Activities，Services，BroadcastReceiver，Content Providers。

未完待续……