设为首页 加入收藏

TOP

深度探索Android应用程序的基本原理(一)
2014-11-24 13:58:00 来源: 作者: 【 】 浏览:5
Tags:深度 探索 Android 应用程序 基本 原理

从许多方面来说,每个Android应用程序存活在它们自己的世界中:


q 默认地,每一个应用程序运行在它自己的Linux进程中。当应用程序的任何代码需要被执行时,Android启动进程;当不再需要时,或者系统资源被其他应用程序所要求时,关闭进程。


q 每一个进程有它自己的Java虚拟机(JVM),因此应用程序代码独立与所有其他应用程序代码而运行。


q 默认地,每一个应用程序被分配一个唯一的Linux用户ID。通过设置权限许可,应用程序的文件只对该用户可见,只对应用程序本身可见—虽然有办法将其导出到其他应用程序。


有可能安排两个应用程序共享同一用户ID,在这种情况下,它们可以彼此看见对方的文件。要保全系统资源,具有相同ID的应用程序也可以被组织起来运行在同一Linux进程中,共享同一VM。


Android一 个最核心的特性是,一个应用程序可以利用其它应用程序的元素(假设这些程序允许这样做)。例如,如果你的应用程序需要显示一个滚动的图像列表,而其它应用 程序已经开发了一个合适的图像滚动器并且允许其被其他人使用,那么你可以要求使用该图像滚动器来完成这项工作,而不必自己再开发一个。你的应用程序不必合 并或链接到其他应用程序的代码。相反,当需要发生时,它仅是简单地启动其他应用程序。


要能如此地工作,系统必须在需要应用程序任何部分时,能启动该应用程序进程,并为该部分实例化Java对象。因此,不像在其他大多数系统上的应用程序,Android应用程序没有一个为应用程序的任何事设置单一的入口点(例如,没有main()函数)。相反,他们拥有一些主要组件,系统可以实例化这些组件并且根据需要来运行。总共有四类组件:


q Activities


q Services


q Broadcast receivers


q Content providers


Activities


一个activity代表一个可视的用户接口,该接口致力于用户能做一些操作。例如,一个activity可能代表一个菜单项列表,用户可以从中选择,或者它可能显示带有标题说明的图像。一个文本消息应用程序可能有一个activity来显示一个联系人列表以发送消息,有第二个activity来写消息到被选择的联系人,以及其它activity来重新获取旧的消息或改变设置。虽然它们一起工作来形成一个内聚性的用户接口,但实际上每一个activity是独立与其他的activity的。每一个activity作为Activity基类的一个子类来实现的。


一个应用程序可能仅由一个activity组成,也可能象刚才提到的文本消息应用程序一个,由数个activity组成。Activity是什么,以及有多少activity,当然依赖于应用程序及其设计。典型地,其中一个activity被标记为第一个,当应用程序被启动时,它应该被首先呈现出来。从一个activity迁移到另一个activity是通过当前activity启动下一个activity来完成的。


每一个activity都有一个默认的绘制窗口。通常,该窗口填满屏幕,但是它也可能比屏幕小并且浮动在其它窗口上面。一个activity还能利用另外的窗口—例如,一个位于activity中间的弹出对话框用于对用户做出响应,或者一个当用户选择一个屏幕上特定条目时带给用户重要信息的窗口。


窗口的可视内容由一个具有层次的视图所提供—从基类View继承来的对象。每一个视图控制一个窗口中特定的矩形空间。父视图容纳并组织其子视图的布局。叶子视图(在层次的最末端)在它们所控制的矩形中绘制并对作用于这一区域的用户动作做出响应。因此,视图是activity与用户的交互发生的地方。例如,一个视图可能会显示一个小图像,并且当用户轻击该图像时发起一个动作。Android有许多现成的视图可以使用,包括按钮、文本域、滚动条、菜单项、复选框,等等。


一个视图层次是由Activity.setContentView()方法布局到一个activity中的。内容视图(content view)是位于层次根部的View对象。


Services


一个service没有可视化的用户接口,而是运行在后台一个无限期限内。例如,当用户试图做其他事情时,一个service在后台播放音乐,或者它也可能在网络上提取数据,或做些计算并提供结果给需要它的activity。每一个service继承自Service基类。


一个最好的例证是一个媒体播放器从一个播放列表中播放歌曲。播放器应用程序可能有一到多个activity以允许用户来选择歌曲并开始播放。然而,音乐播放本身不能被一个activity处理,因为用户会期望音乐持续播放,甚至是在他们离开播放器并开始做其他事情时。要保持音乐继续播放,媒体播放器activity可以开始一个service来在后台运行。然后系统将保持音乐播放服务持续运行,甚至在启动播放器的activity离开屏幕以后也会持续播放。


连接(绑定)到一个正在进行的service(如果service还没有运行,就启动它)也是可能的。当连接后,你可以通过service暴露的接口与service进行通信。对于音乐service,这个接口可能允许用户暂停、后退、停止以及恢复播放。


像activity和其它组件一样,service运行在应用程序进程的主线程中。因此它们不会阻塞其它组件或用户接口,他们经常为耗时的任务(如音乐播放)产生另外的线程。


Broadcast receivers


一个broadcast receiver是一个什么也不做的组件,除了它接受广播公告并对其做出反应。许多广播源(broadcast orginate)在系统代码中----例如,声明时区的改变,电量过低,一个图像已经被拍照,或者用户改变了一个语言参数。应用程序还可以启动一个广播----例如,让其他应用程序知道一些数据已经被下载到设备上并且可以使用它们了。


一个应用程序可以有许多广播接收器(broadcast receivers)来对任何它认为重要的公告做出响应。所有的接收器扩展自BroadcastReceiver基类。


广播接收器并不显示一个用户接口。然而,在对它们接收到的信息做出响应时,它们可以启动一个activity,或者它们可以使用通知管理器(NotificationManager)来提醒用户。通知可以通过多种方式来获得用户的注意----闪烁背景照明灯,振动设备,播放声音等等。它们典型地会放置一个固定的图标在状态栏,用户可以打开这个图标来查看信息。


Content providers


一个Content provider使得一系列特定的应用程序数据对其他应用程序可用。这些数据可以存放在文件系统中,在一个SQLite数据库中,或者在任何其它可以被感知的形式中。内容提供器(content provider)扩展自ContentProvider基类,实现了一系列标准的方法,这些方法能够使其他应用程序来重新获取并存储它所控制的类型的数据。然而,应用程序并不直接调用这些方法。相反,它们使用一个ContentResolver对象并调用其方法。一个ContentResolver可以与任何内容提供器通话,它与提供者合作来管理任何相关的通信工

首页 上一页 1 2 下一页 尾页 1/2/2
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
分享到: 
上一篇mini6410 实现简单 adc驱动--友善.. 下一篇Android 视频缩略图之 MediaStore

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容: