Android 组件
横看成岭侧成峰,远近高低各不同。 -- 《题西林壁》
组件(Component),在谈及所谓架构和重用的时候,是一个重要的事情。很多时候都会说
基于组件的软件架构,指的是期望把程序做乐高似的,有一堆接口标准封装完整的组件放在哪
里,想用的时候取上几个一搭配,整个程序就构建完成了。
在开篇的时候就在说,Android 是一个为组件化而搭建的平台,它引入所谓 Mash-Up 的概念,
这使得你在应用的最上层,想做的不组件化都是很困难的一件事情(底层逻辑,好吧,管不
了...)。具体说来,Android 有四大组件四喜丸子:Activity、Service、Broadcast
Receiver、Content Provider。
Activity
做一个完整的 Android 程序,不想用到 Activity,真的是比较困难的一件事情,除非是想做绿
叶想疯了。因为 Activity 是 Android 程序与用户交互的窗口,在我看来,从这个层面的视角来
看,Android 的 Activity 特像网站的页面。
首先,一个网站,如果一张页面都没有,那...,真是一颗奇葩。而一张页面往往都有个独立的
主题和功能点,比如登录页面,注册页面,管理页面,如是。
在每个页面里面,会放一些链接,已实现功能点的串联,有的链接点了,刷,跑到同一站点的
另一个页面去了;有的链接点了,啾,可能跳到其他网站的页面去;还有的链接点了,恩...,
这次没跑,但当前页面的样子可能有所变化了。这些模式,和 Activity 给人的感觉很像,只不
过实现策略不同罢了,毕竟 Android 这套架构的核心思想,本身就来自源于 Web 的 Mash-Up
概念,视为页面的客户端化,也未尝不可。
Activity,在四大组件中,无疑是最复杂的,这年头,一样东西和界面挂上了勾,都简化不了,
想一想,独立做一个应用有多少时间沦落在了界面上,就能琢磨清楚了。从视觉效果来看,一
个 Activity 占据当前的窗口,响应所有窗口事件,具备有控件,菜单等界面元素。从内部逻辑
来看,Activity 需要为了保持各个界面状态,需要做很多持久化的事情,还需要妥善管理生命
周期,和一些转跳逻辑。对于开发者而言,就需要派生一个 Activity 的子类,然后埋头苦干上
述事情。对于 Activity 的更多细节,先可以参见:reference/android/app/
Activity.html。后续,会献上更为详尽的剖析。
Service
服务,从最直白的视角来看,就是剥离了界面的 Activity,它们在很多 Android 的概念方面比
较接近,都是封装有一个完整的功能逻辑实现,只不过 Service 不抛头露脸,只是默默无声的
做坚实的后盾。
但其实,换个角度来看,Android 中的服务,和我们通常说的 Windows 服务,Web 的后台服
务又有一些相近,它们通常都是后台长时间运行,接受上层指令,完成相关事务的模块。用运
行模式来看,Activity 是跳,从一个跳到一个,呃...,这有点像模态对话框(或者还像 web 页
面好了...),给一个输入(抑或没有...),然后不管不顾的让它运行,离开时返回输出(同抑
或没有...)。
而 Service 不是,它是等,等着上层连接上它,然后产生一段持久而缠绵的通信,这就像一个
用了 Ajax 页面,看着没啥变化,偷偷摸摸的和 Service 不知眉来眼去多少回了。
评论4