Android应用模型的设计思想取自于Web2.0的Mashup概念,是基于组件的应用设计模式。
在该模式下,每个应用都由一系列的组件搭建而成,组件通过应用的配置文件描述功能。Android依照组件的配置信息,了解各个组建的功能并进行 调度。
Android中有四大组建,分别是界面组件Activity,服务组件Setvice,数据源组件Content Provider以及触发器组件Broadcast Receiver。(翻译问题)
3.1 基于Mashup的应用设计
3.1.1 Android中的Mashup
Android中的Mashup是将应用切分成不同类别的组件,通过统一的定位模型和接口标准将它们整合在一起,来共同完成某项任务。
在Android中的Mashup模式下,每个组件的功能都可以被充分利用。来自不同应用的组件可以有机地结合在一起,共同完成任务。
3.1.2 基于Mashup的Android应用模型
在Mashup构造Android应用,有三个基本要素:组件(Component),连接和配置。
组件:有特定功能和接口规范的实现单元。
从代码实现来看,组件就是派生自特定接口或基类的子类实现
每个Android组件都是一个黑盒模块,它们依照系统设计的接口和规范实现相关的功能。
组件的构造,销毁等生命周期管理工作,都是由Android中的组件管理服务统一负责。
连接:是抽象概念,指的是组件之间的通信信道,是Android为不同类别的组件之间进行调用和通信预设的模式。
具体实现根据连接两端组件类别不同而有所变化。如,activity间通过intent,而与数据源组件通信,通过URI地址来定位并搭建连接通 路。
连接的构造:请求连接的组件(需描述所需组件的类型和特征),被连接的实现组件(需描述出它们功能,并完成实现)和组件管理服务(会依照请求者描 述找到符合的实现组件)。
配置:用来描述组件的功能和实现特征的信息。
Android的组件管理服务,就是通过配置文件中的信息去了解每个组件的特征。
整个模型运行的抽象流程:
将相关需求按照规范封装成请求,并将请求发送到android组件管理服务
组件管理服务收到请求后,会扫描各个应用的组件配置信息,寻找并构造与需求匹配,然后将请求传递给该组建,并切换到前台与用户进行交互
组件实现需求,并通过组件管理服务返回给请求组件。
3.1.3 基于Mashup的应用架构特征
基于Mashup的应用,其核心是组件。在Android中,组件执行时的聚合单元是任务,每个任务都有若干个activity对象构成,这些组 件可能来自不同的应用,运行在不同的进程中,彼此独立。
组件间的数据传输,都是通过消息,进程间的通信模型等序列化数据传输的方式来进行,这使得android的应用天生具有了良好的跨进程特征。
基于组件的设计,还具有跨网络的特性。能够响应请求的不仅可以是一个本地已安装应用的组件,还可以是符合该请求的web页面。
关键1:内置浏览器的支持
关键2:android沿用了web中的服务定位等标准。web页面是通过URL进行定位的,通过MIME type对其类型进行描述。android中采取了同样的标准,这就使得每一个web页面都可以归纳到android的识别范围之内
3.2 界面组件Activity解析
功用:构造交互界面
3.2.1 界面组件的功能和特征
从运行模式看,android是个多任务的操作系统。它的上面可以同时运行多个任务。每个任务都有一个界面组件栈,栈中的元素是界面组件对象的实 例,其中负责与用户进行交互的是前台任务的栈顶组件
android的界面组件也是通过类型信息,数据URL信息,数据类型信息等描述信息进行定位的。而界面组件的切换和数据传输,都依赖于 android组件管理服务的统一调度和传递。
android的每个应用进程都有一个应用环境对象(Application Context)。小数据量的共享数据可以通过它来进行存储。
3.2.2 界面组件的开发
构造界面
在Android中,界面样式和内容是通过应用资源文件进行描述的。
系统会提前将资源文件进行预编译,同时生成与应用中的资源相对应的R类。
R类相当于应用资源的目录列表,通过它可以方便地定位到界面所需的资源。
处理交互事件
一类是当前界面的全局事件,可以通过重载Activity中特定的方法来实现
另一类是和具体控件相关的交互事件。android的控件采用了观察者模式,可以通过添加监听者处理相关事件。
构造菜单,对话框等附加的交互资源
辅助交互界面:对话框,菜单,弹出式窗口
在android中,频繁构造上述辅助交互界面是一个耗时的操作,在一些设备上会阻塞主进程,产生明显的停滞感。因此android为这类对象提 供了延迟构造框架,以减少辅助交互界面构造的次数。
管理界面组件中的数据
android是一个多任务的操作系统,当同时运行的任务过多时,就需要自动结束部分应用和组件,以保证系统有充足的内存空间来执行新的任务。
android采取的是进程托管的策略,身处后台的应用进程在内存紧张时会被终止,直到该应用切换至前台,再重新构造运行。
配置界面组件的任务模型
android界面组件在运行时,会通过任务进行组织。同一个任务中的界面组件会按照栈模型线性排列。当不能满足所有类别的应用需求。
android提供了多种组件任务模型,来调整栈中元素的次序,或者是将单个任务拆分成多个任务,甚至将任务放到不同的进程中去,以提升执行效 率。
适配环境配置变化
在默认情况下,当配置信息发生变更时,android会简单地销毁当前交互的界面组件对象,并根据新的配置信息重新构造该组件对象。
这种策略具有很强的适应性,能够统一处理各类复杂的场景。但,付出较多的时间开销
3.2.3 界面组件的数据结构
Activity类派生自Context类,因此Context类在Android组件体系中扮演及其重要的角色。它提供提供了应用运行的基本环 境,是各组件和系统服务通信的桥梁。
Context类是个抽象类,ContextImpl派生实现了它的抽象接口。ContextImpl对象会与Android框架层的各个服务建 立远程连接,通过Android进程间的通信机制IPC和这些服务进行通信。
通过Context的抽象和封装,隐藏了应用与系统服务通信的细节,简化了上层应用的开发。
ContextImpl是在android组件管理服务构造各组件对象时被实例化的。因此,如果上层应用期望改变Context接口的实现,就需 要使用ContentWrapper类。
ContentWrapper的设计应用了修饰模式,派生自Context类,具体的实现都是通过组合的方式调用ContextImpl的实例来 完成的。这样设计,使得ContextImpl与ContentWrapper子类额实现可以单独变化,彼此独立。
activity,service,以及应用基类application都派生于ContextWrapper,它们可以通过重载来修改 Context接口的实现。
其中Activity添加了界面绘制相关的实现,增加了处理界面死见的相关接口。它存放界面中各控件的对象,并与窗口管理服务建立连接,传递界面 相关的事件和操作。