应用程序基本原理(Application Fundamentals)

题记:本人英文水平一般,纯属自娱自乐性质,请各位嘴下留情,尽量每天更新一部分,欢迎指正错误(明天继续)
原文地址:http://developer.android.com/guide/components/fundamentals.html
Application Fundamentals

Android程序由Java语言别写而成.Android SDK 工具编译代码时,将所有的代码和资源文件编译为一个以.apk结尾的压缩文件.apk文件是Android设备用来安装程序的文件.

一旦被安装在设备上,每一个应用程序都会运行在它自己的安全沙盒中:

Android系统是一个多用户的Linux系统,每一个程序都是一个不同的用户

默认情况下,系统会为每一个程序分配一个唯一的Linux用户ID(这个ID只能被系统使用,对于程序是不可见的).系统会为程序的所有文件设置权限,所以只有分配了相应ID的应用程序才可以访问这些文件.

每一个进程都有自己的虚拟机,所以每一个程序运行的时候都是和其他程序相隔离的.

默认情况下,每一个程序都运行在自己的Linux进程中.当程序中的任一组件要执行时,Android系统将会开启进程,当不在需要或系统需要为其他程序分配内存时,Android系统会关闭这些进程.

通过这种方式,Android系统实现了最少权限原则.那就是,每个程序默认情况下,只能访问他运行时必须要使用的组件,更多的组件无法访问.这样就创建了一个非常安全的环境,让一个程序无法访问系统没有赋予它权限的部分.

然而,一个程序仍然可以和其他程序共享数据,而且也可以访问系统服务.

也有可能会为两个程序分配一个相同的Linux 用户ID,这样他们就可以互相访问对方的文件.为了节约系统资源,拥有相同用户ID的程序也可以运行在相同的Linux进程中,共享相同的虚拟机(程序必须使用了相同的签名).

程序可以申请权限以访问用户的通讯录,短信,内存卡,相机,蓝牙等等.所有的权限必须在程序安装的时候由用户授权.

以上几点介绍了一个程序怎样在系统中存在.下面的文档为您介绍:

程序的核心框架组件

区别于代码的资源文件,使程序能够流畅运行的一些设置

Application Components(应用程序组件)

应用程序组件是一个安卓应用的基本组成部分.每一个组件都是系统进入你的应用的一个切入点.尽管有些组件可能并不是用户进入程序的入口,也有些组件可能要依赖另一些组件,但是每一个组件又都真实的存在并发挥自己的作用,对于我们的应用来说,每一个组件都是独一无二的,并构成了整个程序的功能.

一共有四种类型的应用程序组件.每一种都有独特的功能,每一种都有自己的生命周期来定义组件的创建和销毁.

以下是四种类型的应用程序组件:
Activities

Activity的表现形式是用户界面.例如:一个邮件程序可能有一个Activity用来显示新邮件的列表,另一个Activity来创建邮件,还有一个Activity来读邮件.尽管这些Activity一起协作给我们提供了邮件功能,但是他们之间却是互相独立的.一个不同的应用也可以开启这个应用中的Activity,前提是邮件应用允许它这样做.例如,我们可以在邮件应用中的新建邮件组件里开启相机应用,拍摄一张照片并分享.

所有的自定义Activity都要继承Activity这个类,你可以通过Activities developer guide 来了解更多.

Services

Service组件通常运行在后台来执行耗时操作,或者为远程进程执行一些操作.Service通常没有界面.例如:我们可能在使用一个其他的应用但是后台在播放音乐,又比如,在不影响我们正常的操作的时候,它在后台从网络获取数据.其他的组件,比如Activity可以开启一个Service,或者绑定一个Service并和他进行交互.

所有的自定义Service都要继承Service类.可以通过Service Developer Guide了解更多.

Content providers

一个Content provider管理一组共享的数据.你可以把数据储存在系统中,或者一个SQLite数据库,或者网络上,或者其他你的程序可以访问到的储存位置.通过Content provider,其他应用程序也可以查询甚至修改你的数据(前提是Content provider允许).比如,安卓系统提供了一个Content provider用来管理用户的通讯录.同样,一个拥有适当权限的程序可以通过Content provider(比如ContactsContract.Data)来读取或者修改一个特定联系人的信息.

Content providers同样可以用来读写你程序中的私有数据.比如SDK例子中的Note Pad小应用就使用Content providers来保存笔记.

所有的自定义Content providers都必须继承ContentProvider类以让其他程序来执行操作.可以通过ContentProvider Developer Guide了解更多.

Broadcast receivers

broadcast receiver是一个对系统范围内的广播通知做出相应的组件.许多广播都是由系统发出的,比如说屏幕熄灭的广播,电池电量低,或者拍了一张照片.应用程序也可以发出广播,例如,可以通知其他程序:一些数据已经被下载到设备上,可以使用了.尽管broadcast receiver没有用户界面,但是它可能会创建一个状态栏通知,来提示用户广播事件的发生.更为常见的是,broadcast receiver通常是进入其他组件的入口,它一般只做很少的工作.例如,broadcast receiver可能会初始化一个service,让这个service来进行具体的操作.

所有的broadcast receiver都必须继承BroadcastReceiver并通过Intent来传递.关于BroadcastReceiver 的更多信息,可以查看BroadcastReceiver 类.

Android系统的一个独一无二的特性是:一个程序可以启动另一个程序的组件.例如:如果你想让用户通过相机来拍一张照片,其他程序可能已经实现了这个功能,那你可以复用他,而不用自己去开发.你不需要把相机的代码组合进来,甚至连链接这些代码都不用.你要做的只是打开相机中拍照片的Activity,当拍照完成得时候,照片就会返回到你的应用,你就可以使用了.这让相机应用看起来好像就是你的应用的一部分.

当系统启动一个组件的时候,系统会为该程序开启一个进程(如果还没有开启),并初始化这个类所需要的组件.例如:如果你的应用开始了相机应用中拍照的Activity,该Activity会运行在相机应用的进程中,而不是你的程序的进程中.因此,和其他平台上的程序相比,android程序通常并不会只有一个入口(例如,它没有main()函数).

由于在系统中每一个程序都是运行在独立的进程中,并有文件权限系统来严格限制访问权限,所以你的程序并不能直接激活其他程序的组件.但是android系统却可以.所以,如果你想激活其他程序中的一个组件,你就必须给android系统传递一个消息来指明你要激活的组件.android系统将会为你激活这个组件
Activating Components

有三种类型的组件是被一个叫做Intent的异步消息激活的,他们是:activities, services, 和broadcast,Intent在运行的时候会绑定一个组件(你可以把他们当作一个请求其他组件做出响应的信使),这个组件可以是你的程序的,也可以是其他程序的.

一个意图通常由叫做Intent 的对象创建,Intent 定义了一个消息用来激活一个组件,或者一种类型的组件.Intent 可以是明确指定的,也可以是隐式指定的.

对于ctivities and services来说,一个Intent可能指定了要执行的动作(比如:"view"或者"send"),也可能指定了要执行的数据的URI(除了其他事项,该组件启动所需要知道的).例如,一个Intent可以传递一个请求给一个Activity来显示一个图片或者打开一个网页.某些情况下,你可以打开一个Activity并接收结果,这种情况下Activity会在Intent中返回结果(例如,你可以发送一个意图让用户在通讯录中选择一个联系人并返回给你,这个返回的Intent中就包含了指向那个联系人的URI).

对于broadcast receivers,Intent简单的定义了要广播的通知(例如,一个指示电池电量低的广播,只是包含了一个动作名称来只是电池电量低).

另外一个组件,content provider,不是由Intent激活,而是由ContentResolver发来的请求激活的.(剩余部分理解不是太好,暂留)The content resolver handles all direct transactions with the content provider so that the component that's performing transactions with the provider doesn't need to and instead calls methods on the ContentResolver object. This leaves a layer of abstraction between the content provider and the component requesting information (for security).

激活每一种类型组件的特有方法:

你可以通过传递Intent给startActivity() 或者startActivityForResult()(当你希望启动的Activity返回数据时) 来启动一个Activity(或者让它进行一些新的操作).

你可以通过传递Intent给startService()来启动一个Service(或者给正在运行的Service传递新的指令).也可以通过传递Intent给bindService()来绑定一个Service.

你可以通过传递Intent给sendBroadcast(),sendOrderedBroadcast(), 或者 sendStickyBroadcast()来创建一个Broadcast.

你可以通过调用ContentResolver的query()方法来对ContentProvider进行查询.关于Intent的更多信息,你可以查看Intent和Intent Filter的文档.更多激活组件的特有方法,可以参考Activities, Services,BroadcastReceiver 和 Content Providers.
The Manifest File

在Android系统启动应用程序的组件之前,系统必须通过读取程序的Manifest.xml文件来知道该组件是存在的.你的程序必须在该文件中声明所有的组件,该文件必须位于工程的根目录中.

Manifest文件通过如下的方式来声明程序的组件,例如:

识别程序所需要的权限,比如,网络权限,读取联系人等等.

声明程序支持的最低API版本,和程序是基于那个版本的API开发的.

声明程序所需要的硬件和软件支持,例如,摄像头,蓝牙,多点触摸等等.

程序需要使用的类库(不同于Android 的API),例如Google Maps library.

更多

Declaring components
声明组件

Manifest文件最重要的作用就是通知android系统本程序中的组件.例如,Manifest文件可以像下面这样声明一个Activity.
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
<application android:icon="@drawable/app_icon.png" ... >
<activity android:name="com.example.project.ExampleActivity"
android:label="@string/example_label" ... >
</activity>
...
</application>
</manifest>
In the <application> element, the android:icon attribute points to resources for an icon that identifies the application.
在<application>节点中,android:icon属性指定了一个识别程序的图标资源.

在<activity>节点中,android:name属性指定了该Activity的全类名,android:label属性指定了一个字符串,当用户打开这个Activity时,可以看到这个字符串,类似于标签,用来识别这个Activity.

你必须使用如下方法来声明所有的组件:
<activity> 节点声明 activities
<service> 节点声明 services
<receiver> 节点声明 broadcast receivers
<provider> 节点声明 content providers

Activities, services, and content providers 如果只存在于你的代码中,而你没有在Manifest文件中声明的话,那这些组件对于android系统来说是不可见的,因此也无法运行.broadcast receivers既可以在Manifest文件中声明,也可以动态的在代码中创建并通过调用registerReceiver()方法来注册.

更多关于Manifest的信息,请参考AndroidManifest.xml 信息.
Declaring component capabilities

如上所述,你可以通过Intent来启动activities, services, and broadcast receivers. 你可以在Intent中明确指定要启动的组件的类名来启动它.但是Intent更强大的地方在于intent actions.通过intent actions你可以简单的描述你想要进行的操作,并允许android系统在设备上查找能执行该操作的组件,然后启动它.如果有多个组件都可以执行这个操作,那么可以让用户进行选择.

系统通过比较设备上其他程序的Manifest文件中的Intent Filter接收到的Intent,来识别那个组件可以对Intent做出响应.
When you declare a component in your application's manifest, you can optionally include intent filters that declare the capabilities of the component so it can respond to intents from other applications. You can declare an intent filter for your component by adding an <intent-filter> element as a child of the component's declaration element.

For example, an email application with an activity for composing a new email might declare an intent filter in its manifest entry to respond to "send" intents (in order to send email). An activity in your application can then create an intent with the “send” action (ACTION_SEND), which the system matches to the email application’s “send” activity and launches it when you invoke the intent with startActivity().

For more about creating intent filters, see the Intents and Intent Filters document.

Declaring application requirements

There are a variety of devices powered by Android and not all of them provide the same features and capabilities. In order to prevent your application from being installed on devices that lack features needed by your application, it's important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read them, but external services such as Google Play do read them in order to provide filtering for users when they search for applications from their device.

For example, if your application requires a camera and uses APIs introduced in Android 2.1 (API Level 7), you should declare these as requirements in your manifest file. That way, devices that do not have a camera and have an Android version lower than 2.1 cannot install your application from Google Play.

However, you can also declare that your application uses the camera, but does not require it. In that case, your application must perform a check at runtime to determine if the device has a camera and disable any features that use the camera if one is not available.

Here are some of the important device characteristics that you should consider as you design and develop your application:

Screen size and density
In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical density of the pixels on the screen, or dpi—dots per inch). To simplify all the different types of screen configurations, the Android system generalizes them into select groups that make them easier to target.
The screen sizes are: small, normal, large, and extra large.
The screen densities are: low density, medium density, high density, and extra high density.
By default, your application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, using alternative layout resources, and by declaring in your manifest exactly which screen sizes your application supports with the <supports-screens> element.
For more information, see the Supporting Multiple Screens document.
Input configurations
Many devices provide a different type of user input mechanism, such as a hardware keyboard, a trackball, or a five-way navigation pad. If your application requires a particular kind of input hardware, then you should declare it in your manifest with the <uses-configuration> element. However, it is rare that an application should require a certain input configuration.
Device features
There are many hardware and software features that may or may not exist on a given Android-powered device, such as a camera, a light sensor, bluetooth, a certain version of OpenGL, or the fidelity of the touchscreen. You should never assume that a certain feature is available on all Android-powered devices (other than the availability of the standard Android library), so you should declare any features used by your application with the <uses-feature> element.
Platform Version
Different Android-powered devices often run different versions of the Android platform, such as Android 1.6 or Android 2.3. Each successive version often includes additional APIs not available in the previous version. In order to indicate which set of APIs are available, each platform version specifies an API Level(for example, Android 1.0 is API Level 1 and Android 2.3 is API Level 9). If you use any APIs that were added to the platform after version 1.0, you should declare the minimum API Level in which those APIs were introduced using the <uses-sdk> element.
It's important that you declare all such requirements for your application, because, when you distribute your application on Google Play, the store uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements.

For more information about how Google Play filters applications based on these (and other) requirements, see the Filters on Google Play document.

Application Resources
An Android application is composed of more than just code—it requires resources that are separate from the source code, such as images, audio files, and anything relating to the visual presentation of the application. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using application resources makes it easy to update various characteristics of your application without modifying code and—by providing sets of alternative resources—enables you to optimize your application for a variety of device configurations (such as different languages and screen sizes).

For every resource that you include in your Android project, the SDK build tools define a unique integer ID, which you can use to reference the resource from your application code or from other resources defined in XML. For example, if your application contains an image file named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo, which you can use to reference the image and insert it in your user interface.

One of the most important aspects of providing resources separate from your source code is the ability for you to provide alternative resources for different device configurations. For example, by defining UI strings in XML, you can translate the strings into other languages and save those strings in separate files. Then, based on a language qualifier that you append to the resource directory's name (such as res/values-fr/ for French string values) and the user's language setting, the Android system applies the appropriate language strings to your UI.

Android supports many different qualifiers for your alternative resources. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used. As another example, you should often create different layouts for your activities, depending on the device's screen orientation and size. For example, when the device screen is in portrait orientation (tall), you might want a layout with buttons to be vertical, but when the screen is in landscape orientation (wide), the buttons should be aligned horizontally. To change the layout depending on the orientation, you can define two different layouts and apply the appropriate qualifier to each layout's directory name. Then, the system automatically applies the appropriate layout depending on the current device orientation.

For more about the different kinds of resources you can include in your application and how to create alternative resources for various device configurations, see the Application Resources developer guide.