基于Android系统的校园生活服务平台的设计与实现外文翻译资料

Android Application Fundamentals

（href:http://developer.android.com/guide/components/fundamentals.html）

Android apps are written in the Java programming language. The Android SDK tools compile your code—along with any data and resource files—into an APK: an Android package, which is an archive file with an .apk suffix. One APK file contains all the contents of an Android app and is the file that Android-powered devices use to install the app.

Once installed on a device, each Android app lives in its own security sandbox:

• The Android operating system is a multi-user Linux system in which each app is a different user.
• By default, the system assigns each app a unique Linux user ID (the ID is used only by the system and is unknown to the app). The system sets permissions for all the files in an app so that only the user ID assigned to that app can access them.
• Each process has its own virtual machine (VM), so an apps code runs in isolation from other apps.
• By default, every app runs in its own Linux process. Android starts the process when any of the apps components need to be executed, then shuts down the process when its no longer needed or when the system must recover memory for other apps.

In this way, the Android system implements the principle of least privilege. That is, each app, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an app cannot access parts of the system for which it is not given permission.

However, there are ways for an app to share data with other apps and for an app to access system services:

• Its possible to arrange for two apps to share the same Linux user ID, in which case they are able to access each others files. To conserve system resources, apps with the same user ID can also arrange to run in the same Linux process and share the same VM (the apps must also be signed with the same certificate).
• An app can request permission to access device data such as the users contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. The user has to explicitly grant these permissions.

That covers the basics regarding how an Android app exists within the system. The rest of this document introduces you to:

• The core framework components that define your app.
• The manifest file in which you declare components and required device features for your app.
• Resources that are separate from the app code and allow your app to gracefully optimize its behavior for a variety of device configurations.

App Components

App components are the essential building blocks of an Android app. Each component is a different point through which the system can enter your app. Not all components are actual entry points for the user and some depend on each other, but each one exists as its own entity and plays a specific role—each one is a unique building block that helps define your apps overall behavior.

There are four different types of app components. Each type serves a distinct purpose and has a distinct lifecycle that defines how the component is created and destroyed.

Here are the four types of app components:

Activities

An activity represents a single screen with a user interface. For example, an email app might have one activity that shows a list of new emails, another activity to compose an email, and another activity for reading emails. Although the activities work together to form a cohesive user experience in the email app, each one is independent of the others. As such, a different app can start any one of these activities (if the email app allows it). For example, a camera app can start the activity in the email app that composes new mail, in order for the user to share a picture.

An activity is implemented as a subclass of Activity and you can learn more about it in theActivities developer guide.

Services

A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not provide a user interface. For example, a service might play music in the background while the user is in a different app, or it might fetch data over the network without blocking user interaction with an activity. Another component, such as an activity, can start the service and let it run or bind to it in order to interact with it.

A service is implemented as a subclass of Service and you can learn more about it in theServices developer guide.

Content providers

A content provider manages a shared set of app data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access. Through the content provider, other apps can query or even modify the data (if the content provider allows it). For example, the Android system provides a content provider that manages the users contact information. As such, any app with the proper permissions can query part of the content provider (such as ContactsContract.Data) to read and write information about a particular person.

Content providers are also useful for reading and writing data that is private to your app and not shared. For example, the Android 应用基本原则

Android应用使用Java编程语言编写。Android的SDK工具编译你的代码连同任何数据和资源文件到一个APK文件中：一个以.apk结尾的Android的包。一个APK文件包含了一个Android应用的所有组成，并且这个文件用于在Android设备商安装这个程序。

Android操作系统是一个多用户Linux系统，每个应用程序是一个不同的用户。

• 每个进程都有它自己的虚拟机（VM），所以应用程序的代码会独立于其他应用程序。
• 通过这种方式，Android系统实现了最小特权原则，也就是说，每个应用程序，默认情况下，只能调用它工作所需的组件。这创造了一个非常安全的环境，应用程序无法访问它没有给予权限的部分。

  为两个应用程序分配同一个Linux用户ID是可行的，在这种情况下，它们能够相互访问的文件。为了节约系统资源，拥有相同用户ID的应用程序也可以分配运行在同一个Linux进程中和共享一个VM(应用程序必须使用相同的证书签名)。

• 以上概括了一个Android程序在系统中的存在方式。接下来将介绍:
  • 清单文件中为你的应用程序声明组件和请求设备特性。
  • 应用程序组件(Application Components)

    有四种不用的组件类型。每一种类型的组件都有不同的目的以及不同的生命周期，这个生命周期定义了组件的创建和销毁。

    活动(Activities)

    一个activity作为 Activity的一个子类被实现。你可以在 Activities 开发者指导部分了解更多。

    服务(Services)

    service 是在后台运行可以执行长时间操作或者执行远程操作的组件。 service 不提供用户界面。例如，当用户在另一个应用程序时，一个 service 可在后台播放音乐，或者是从网络上获取数据，而不阻断用户与当前 activity 的交互。其他组件，比如一个 activity，可以启动或者 绑定它以便与它交互。

    一个service作为一个Service的子类被实现。你可以通过 Services 开发者指南了解更多。

    内容提供者(Content providers)

    一个content provider负责管理应用程序的数据共享集。 你可以通过文件系、SQLite数据库、网站，或者其它的你的应用程序可以访问的持久化存储位置来存储数据。通过content provider,其它的应用程序可以查询甚至修改你的数据（如果这个content provider允许它们这么做）。 例如，Android系统提供了content provider来管理用户的联系信息。这样，任何拥有适当权限的应用程序可以访问一部分content provider（比如 ContactsContract.Data）来读写一个人的信息。

    Content provider在读写程序的私有数据时也很有用。例如，Note Pad范例程序就使用了一个content provider来保存笔记。

    一个content provider是作为ContentProvider的一个子类被实现的。 并且必须实现一些标准的API集，这样其它的应用程序才能执行事务。更多信息，请查阅 Content Providers开发者指南。

    广播接收器(Broadcast receivers)

    广播接收器是一个用来响应系统范围内的广播的组件。很多广播是源自于系统──比如，一个广播通知屏幕关闭，电池电量低，拍摄了一张照片。应用程序也可以初始化广播──比如说，通知其它应用程序一些数据下载完成并处于可用状态。尽管BroadcastReceiver没有用户界面，它们也可以创建一个通知栏通知来提醒用户一个广播事件发生了。但是，更多的情况是，一个BroadcastReceiver只是作为进入其他组件的一个“大门”，并且只做少量的工作。例如，它可以初始化一个服务来做基于这个事件的一些工作。

    Broadcast receiver是BroadcastReceiver 的子类实现，而且每一个广播通过Intent 对象来传递。 更多信息，请阅读 BroadcastReceiver 类。

    Android系统设计的一个独特方面是任何的一个程序都可以启动另一程序的组件。比如，你想让用户可以使用照相机拍照，如果已经有了实现这种功能的程序并且你的程序能使用它，而不是自己再写一个实现拍照的新Activity。你不必从相机程序中嵌入代码或者连链接代码也不需要。取而代之地，你可以简单地启动相机程序中拍照的activity。 当拍照完成，相片就会返回给你的程序供你使用。从用户的角度，就好像相机就是你程序的一部分。

    当系统启动一个组件之后，它其实就启动了这个程序的进程（如果这个进程还未被启动的话）并实例化这个组件所需要的类。 比如，如果你的程序启动了相机程序里的activity去拍照，这个activity实际上是运行在相机程序的进程里，而不是你自己的进程。 因此，不像其它系统里的程序，Android程序并不是单入口的（例如它没有main方法）。

    因为系统运行每一个应用程序都在独立进程中，并且程序中的文件都有自己的权限限制其他程序访问的权限，所以，你的应用程序不能直接激活其他程序中的组件。但是Android系统就可以。具体是这样的实现的，为了激活其他程序中的组件，你必须向系统发送一个消息来详细说明你要启动其他组件的意图，这样系统才会为你激活这个组件。

    激活组件(Activating Components)

    四大组件中的三个组件——activities、services和broadcast receiver——是由一种叫intent的异步消息来激活的。这些intents把不同的独立的组件在运行期绑定在一起(你可以把它们当作从其它组件中请求动作的消息), 无论这些组件属于你的或者其它的程序。

    一个intent就是一个Intent对象，这个intent定义了一种可以激活某个特定组件或者某种特定类型的组件，这两种情况分别对应两种intent的定义方式或者显示的或者隐式的。

    对于activities和services，一个intent定义了要执行的动作(比如，要“view”或者“send”什么)和要操作的数据的指定URI(启动组件所需要知道的其它数据)。比如，一个intent可能会为一个activity发送一个请求来展示一张图片或者打开一个网页。有时，你可以启动一个activity来得到返回的结果，在这个例子中这个activity的返回的结果也是一个Intent（比如，你可以发送一个intent让用户选择一个联系人并返回给你——这个返回的intent就包含了一个指向用户选择的联系人的URI）。

    对于broadcast receiver来说，intent只是简单的定义了要广播的内容（比如，一个用以指明电池电量很低的广播只包含了一个已知的动作字符串：“电量低”）。

    另外一种组件类型content provider并不是由intent来激活的。而是由接收到ContentResolver的请求时激活的。这个content resolver掌握了所有content provider的直接事务，所以用这个provider来执行事务的组件不需要直接执行而是调用这个ContentResolver对象的方法。它在content provider和这个组件请求信息之间放置了一个抽象层（为了安全）。

    它们都各自有自己的方法来激活相应的组件：

    • 你可以通过传递一个Intent给startActivity()或startActivityForResult()(当你想让一个activity为你返回一个结果)启动一个activity（或者给他一些新的要做的内容）。使用startActivityForResult()你将得到一个返回结果。
    • 你可以通过传递一个Intent给startService()来开启一个service（或者给一个正在运行的service一些新的指令）。或者你可以通过把一个Intent传递给bindService()来绑定一个service。
    • 你可以通过传递一个Intent给诸如sendBroadcast()、sendOrderedBroadcast()或者sendStickyBroadcast()等方法来初始化一个广播。
    • 你可以通过调用ContentResolver的query()方法来执行一次content provider的查询操作。
    • 更多的关于intent的内容，可以参看文档中的Intents and Intent Filters。更多的关于激活特定组件的内容可以参看文档中的：Activities、Services、BroadcastReceiver、Content Providers。

    清单文件（The Manifest File）

    在Android系统可以启动一个应用程序组件之前，Android系统必须通过读取这个程序的AndroidManifest.xml（即manifest文件）文件来确定要启动的组件存在。你的程序必须在这个manifest文件声明用到的所有的组件，并且这个manifest文件必须在项目的根目录下。

    • 除了声明程序组件外，这个配置文件还做一些其它的工作，例如：
    • 确定这个程序需要的所有权限，比如Internet访问权限或者读取用户联系人权限。
    • 声明这个运行这个程序所需要的最低API版本，这个基于开发该程序所使用的API版本。
    • 声明该程序所需要的硬件或软件特征，比如照相机、蓝牙服务或者多点触屏。
    • 声明该程序需要链接（link against）的API库（不是Andorid的framework APIs），比如Google Maps library。

    组件声明（Declaring components）

    Manifest文件的首要任务就是通知系统关于程序中要使用的组件。比如，一个manifest文件可以用如下的方式来声明一个activity：

    lt;?xml version='1.0' encoding='utf-8'?gt;
    lt;manifest ... gt;
    lt;application android:icon='@drawable

    剩余内容已隐藏，支付完成后下载完整资料

    ---

    资料编号：[30938]，资料为PDF文档或Word文档，PDF文档可免费转换为Word