Android应用开发原理_android应用开发原理资源-CSDN文库

需积分: 10 52 浏览量 2011-02-11 10:18:41 上传评论收藏 408KB PDF 举报

### Android应用开发原理 #### 应用程序基础 Android应用程序主要使用Java编程语言编写，并通过aapt工具将编译后的Java代码以及任何所需的数据和资源文件打包成一个Android包（带有`.apk`后缀的存档文件）。这个文件是应用程序分发及安装到移动设备上的载体，也是用户下载至其设备的文件。同一`.apk`文件中的所有代码被视为一个应用。 #### 应用程序的隔离性在很多方面，每个Android应用都处于自己的独立世界： 1. **进程隔离**：默认情况下，每个应用运行在自己的Linux进程中。当应用的任何代码需要执行时，Android会启动该进程；当不再需要此进程且系统资源需分配给其他应用时，则关闭该进程。 2. **虚拟机隔离**：每个进程有自己的虚拟机（VM），这意味着应用代码运行在与其他所有应用代码隔离的环境中。 3. **用户权限隔离**：默认情况下，每个应用被分配一个唯一的Linux UserID。权限设置使得应用文件仅对该用户及其自身应用可见，虽然也有方法可以将这些文件导出给其他应用使用。 #### 应用共享选项 - 可以安排两个应用共享同一个UserID，在这种情况下，它们可以查看彼此的文件。 - 为了节省系统资源，具有相同ID的应用还可以选择在同一Linux进程中运行，共享相同的VM。 #### 应用组件 Android的一个核心特点是，一个应用可以利用其他应用的部分元素（前提是这些应用允许这样做）。例如，如果您的应用想要显示地图或播放音乐，它可以通过启动其他专为这些任务设计的应用来实现这一功能，而无需自己重新实现这些功能。这主要依赖于以下四种主要的组件： 1. **Activity**：Activity是用户与之交互的界面，如登录屏幕、游戏界面等。它是构成应用程序的基本单元之一。 2. **Service**：Service是在后台执行长时间运行操作的组件，例如播放音乐或上传数据到服务器，无需用户交互。 3. **BroadcastReceiver**：BroadcastReceiver用于接收来自系统或其他应用程序的重要事件广播，如设备重启或网络状态变化。 4. **ContentProvider**：ContentProvider管理应用程序之间的数据共享，提供了一种安全的方式来让不同的应用程序访问其数据。 5. **Intent**：Intent是一种消息对象，用来请求应用程序内部或跨应用程序的Action。它允许Activity、Service和BroadcastReceiver之间进行通信。 #### 组件激活与关闭 - **激活组件：Intents**：通过Intent激活组件，如启动新的Activity或开始Service。 - **关闭组件**：组件可以在完成任务后自行停止，也可以由其他组件显式停止。 #### 清除任务栈与启动任务 - **清除任务栈**：可以通过Intent的标志来控制任务栈的行为，比如清空当前任务并启动一个新的Activity实例。 - **启动任务**：可以通过指定Intent中的组件名称或者使用Intent过滤器来启动特定的Activity或Service。 #### 进程与线程 - **进程**：每个应用通常运行在单独的进程中，确保了应用间的隔离性。 - **线程**：多线程允许应用在后台执行任务而不阻塞UI线程，保证用户体验流畅。 #### 远程过程调用 - 在Android中，通过Binder机制实现了远程过程调用(RPC)，允许不同进程间通信(IPC)。 #### 线程安全的方法 - 当多线程同时访问共享资源时，必须采取措施保证线程安全性，避免出现数据不一致的问题。 #### 组件生命周期 - **Activity 生命周期**：包括创建、启动、暂停、恢复、停止和销毁等多个阶段。 - **Service 生命周期**：包括创建、启动、停止和销毁等阶段。 - **BroadcastReceiver 生命周期**：包括接收到广播、处理广播等关键步骤。 #### 总结 Android应用开发基于一套完整的框架和模式，其中包括了核心组件（Activity、Service、BroadcastReceiver、ContentProvider）、进程与线程管理、远程过程调用以及组件生命周期管理等。了解这些基本概念对于构建高质量的Android应用程序至关重要。

资源推荐

资源详情

资源评论

10-10-28 2:45Application Fundamentals | Android Developers

 1  19 file:///Volumes/JinuxHD/android-sdk-mac_x86/docs/guide/topics/fundamentals.html

Key classes

Activity

Service

BroadcastReceiver

ContentProvider

Intent

In this document

Application Components

Activating components: intents

Shutting down components

The manifest file

Intent filters

Activities and Tasks

Affinities and new tasks

Launch modes

Clearing the stack

Starting tasks

Processes and Threads

Processes

Threads

Remote procedure calls

Thread-safe methods

Component Lifecycles

Activity lifecycle

Service lifecycle

Broadcast receiver lifecycle

Processes and lifecycles

Application Fundamentals

Android applications are written in the Java programming

language. The compiled Java code — along with any data

and resource files required by the application — is bundled

by the aapt tool into an Android package, an archive file

marked by an .apk suffix. This file is the vehicle for

distributing the application and installing it on mobile

devices; it's the file users download to their devices. All the

code in a single .apk file is considered to be one

application.

In many ways, each Android application lives in its own

world:

By default, every application runs in its own Linux

process. Android starts the process when any of the

application's code needs to be executed, and shuts

down the process when it's no longer needed and

system resources are required by other applications.

Each process has its own virtual machine (VM), so

application code runs in isolation from the code of all

other applications.

By default, each application is assigned a unique Linux

user ID. Permissions are set so that the application's

files are visible only to that user and only to the

application itself — although there are ways to export

them to other applications as well.

It's possible to arrange for two applications to share the

same user ID, in which case they will be able to see each

other's files. To conserve system resources, applications

with the same ID can also arrange to run in the same Linux process, sharing the same VM.

Application Components

A central feature of Android is that one application can make use of elements of other applications (provided those

applications permit it). For example, if your application needs to display a scrolling list of images and another

application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the

work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it.

Rather, it simply starts up that piece of the other application when the need arises.

For this to work, the system must be able to start an application process when any part of it is needed, and instantiate

the Java objects for that part. Therefore, unlike applications on most other systems, Android applications don't have a

single entry point for everything in the application (no main() function, for example). Rather, they have essential

components that the system can instantiate and run as needed. There are four types of components:

10-10-28 2:45Application Fundamentals | Android Developers

 2  19 file:///Volumes/JinuxHD/android-sdk-mac_x86/docs/guide/topics/fundamentals.html

Activities

An activity presents a visual user interface for one focused endeavor the user can undertake. For example, an

activity might present a list of menu items users can choose from or it might display photographs along with their

captions. A text messaging application might have one activity that shows a list of contacts to send messages to,

a second activity to write the message to the chosen contact, and other activities to review old messages or

change settings. Though they work together to form a cohesive user interface, each activity is independent of the

others. Each one is implemented as a subclass of the Activity base class.

An application might consist of just one activity or, like the text messaging application just mentioned, it may

contain several. What the activities are, and how many there are depends, of course, on the application and its

design. Typically, one of the activities is marked as the first one that should be presented to the user when the

application is launched. Moving from one activity to another is accomplished by having the current activity start the

next one.

Each activity is given a default window to draw in. Typically, the window fills the screen, but it might be smaller

than the screen and float on top of other windows. An activity can also make use of additional windows — for

example, a pop-up dialog that calls for a user response in the midst of the activity, or a window that presents

users with vital information when they select a particular item on-screen.

The visual content of the window is provided by a hierarchy of views — objects derived from the base View class.

Each view controls a particular rectangular space within the window. Parent views contain and organize the layout

of their children. Leaf views (those at the bottom of the hierarchy) draw in the rectangles they control and respond

to user actions directed at that space. Thus, views are where the activity's interaction with the user takes place.

For example, a view might display a small image and initiate an action when the user taps that image. Android

has a number of ready-made views that you can use — including buttons, text fields, scroll bars, menu items,

check boxes, and more.

A view hierarchy is placed within an activity's window by the Activity.setContentView() method. The

content view is the View object at the root of the hierarchy. (See the separate User Interface document for more

information on views and the hierarchy.)

Services

A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time.

For example, a service might play background music as the user attends to other matters, or it might fetch data

over the network or calculate something and provide the result to activities that need it. Each service extends the

Service base class.

A prime example is a media player playing songs from a play list. The player application would probably have one

or more activities that allow the user to choose songs and start playing them. However, the music playback itself

would not be handled by an activity because users will expect the music to keep playing even after they leave the

player and begin something different. To keep the music going, the media player activity could start a service to

run in the background. The system would then keep the music playback service running even after the activity

that started it leaves the screen.

It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While

connected, you can communicate with the service through an interface that the service exposes. For the music

service, this interface might allow users to pause, rewind, stop, and restart the playback.

Like activities and the other components, services run in the main thread of the application process. So that they

won't block other components or the user interface, they often spawn another thread for time-consuming tasks

(like music playback). See Processes and Threads, later.

Broadcast receivers

A broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many

broadcasts originate in system code — for example, announcements that the timezone has changed, that the

battery is low, that a picture has been taken, or that the user changed a language preference. Applications can

also initiate broadcasts — for example, to let other applications know that some data has been downloaded to the

device and is available for them to use.

10-10-28 2:45Application Fundamentals | Android Developers

 3  19 file:///Volumes/JinuxHD/android-sdk-mac_x86/docs/guide/topics/fundamentals.html

An application can have any number of broadcast receivers to respond to any announcements it considers

important. All receivers extend the BroadcastReceiver base class.

Broadcast receivers do not display a user interface. However, they may start an activity in response to the

information they receive, or they may use the NotificationManager to alert the user. Notifications can get the

user's attention in various ways — flashing the backlight, vibrating the device, playing a sound, and so on. They

typically place a persistent icon in the status bar, which users can open to get the message.

Content providers

A content provider makes a specific set of the application's data available to other applications. The data can be

stored in the file system, in an SQLite database, or in any other manner that makes sense. The content provider

extends the ContentProvider base class to implement a standard set of methods that enable other

applications to retrieve and store data of the type it controls. However, applications do not call these methods

directly. Rather they use a ContentResolver object and call its methods instead. A ContentResolver can talk to

any content provider; it cooperates with the provider to manage any interprocess communication that's involved.

See the separate Content Providers document for more information on using content providers.

Whenever there's a request that should be handled by a particular component, Android makes sure that the

application process of the component is running, starting it if necessary, and that an appropriate instance of the

component is available, creating the instance if necessary.

Activating components: intents

Content providers are activated when they're targeted by a request from a ContentResolver. The other three

components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents.

An intent is an Intent object that holds the content of the message. For activities and services, it names the action

being requested and specifies the URI of the data to act on, among other things. For example, it might convey a

request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, the

Intent object names the action being announced. For example, it might announce to interested parties that the camera

button has been pressed.

There are separate methods for activating each type of component:

An activity is launched (or given something new to do) by passing an Intent object to

Context.startActivity() or Activity.startActivityForResult(). The responding activity can look

at the initial intent that caused it to be launched by calling its getIntent() method. Android calls the activity's

onNewIntent() method to pass it any subsequent intents.

One activity often starts the next one. If it expects a result back from the activity it's starting, it calls

startActivityForResult() instead of startActivity(). For example, if it starts an activity that lets the

user pick a photo, it might expect to be returned the chosen photo. The result is returned in an Intent object that's

passed to the calling activity's onActivityResult() method.

A service is started (or new instructions are given to an ongoing service) by passing an Intent object to

Context.startService(). Android calls the service's onStart() method and passes it the Intent object.

Similarly, an intent can be passed to Context.bindService() to establish an ongoing connection between the

calling component and a target service. The service receives the Intent object in an onBind() call. (If the service

is not already running, bindService() can optionally start it.) For example, an activity might establish a

connection with the music playback service mentioned earlier so that it can provide the user with the means (a

user interface) for controlling the playback. The activity would call bindService() to set up that connection, and

then call methods defined by the service to affect the playback.

A later section, Remote procedure calls, has more details about binding to a service.

An application can initiate a broadcast by passing an Intent object to methods like Context.sendBroadcast(),

Context.sendOrderedBroadcast(), and Context.sendStickyBroadcast() in any of their variations.

Android delivers the intent to all interested broadcast receivers by calling their onReceive() methods.

剩余18页未读，继续阅读

评论收藏

内容反馈

vimdoer

粉丝: 1
资源: 1

Android应用开发原理

Android应用开发揭秘

android应用开发揭秘

Android应用开发详解

Android应用程序开发

android应用开发

Android应用开发原理PDF.zip

移动操作系统原理与实践——基于Java语言的Android应用开发.zip

Android系统原理与开发要点详解_培训课件下载

android网络开发原理

Android开发工具及其原理

Android应用开发

安卓应用开发

Android应用开发精解

Android系统原理及开发要点详解(超清)

Android Telephony原理解析与开发指南_杨青平.zip

Android应用开发揭秘pdf

android系统原理与开发要点详解

Android_应用框架原理与程序开发 免费

程序开发原理

andriod应用开发揭秘

\Android应用开发

android应用开发-从设计到实现

《Android应用开发揭秘》读书笔记

深入理解android telephony原理剖析与最佳实践

Android应用开发揭秘高清版

Android系统原理与开发要点详解

最新资源

Android_应用框架原理与程序开发免费