文档介绍：,一切都不正常!在这个关键时刻,中国男足挺身而出,向全世界证明:中国男足还是正常的! 本文由cqhwp贡献
doc文档可能在WAP端浏览体验不佳。建议您优先选择TXT,或下载源文件到本机查看。
Android 组件横看成岭侧成峰,远近高低各不同。—《题西林壁》 ponent),在谈及所谓架构和重用的时候,是一个重要的事情。很多时候都会说基于组件的软件架构, 指的是期望把程序做乐高似的, 有一堆接口标准封装完整的组件放在哪里,想用的时候取上几个一搭配,整个程序就构建完成了。在开篇的时候就在说,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/。后续,会献上更为详尽的剖析。
Service 服务,从最直白的视角来看,就是剥离了界面的 Activity,它们在很多 Android 的概念方面比较接近,都是封装有一个完整的功能逻辑实现,只不过 Service 不抛头露脸,只是默默无声的做坚实的后盾。但其实,换个角度来看,Android 中的服务,和我们通常说的 Windows 服务,Web 的后台服务又有一些相近, 它们通常都是后台长时间运行, 接受上层指令, 完成相关事务的模块。用运行模式来看,Activity 是跳,从一个跳到一个,呃…,这有点像模态对话框(或者还像 web 页面好了…),给一个输入(抑或没有…),然后不管不顾的让它运行,离开时返回输出(同抑或没有…)。而 Service 不是,它是等,等着上层连接上它,然后产生一段持久而缠绵的通信,这就像一个用了 Ajax 页面,看着没啥变化,偷偷摸摸的和 Service 不知眉来眼去多少回了。
但和一般的 Service 还是有所不同,Android 的 Service 和所有四大组件一样,其进程模型都是可以配置的,调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下, 还是不同的进程下。这句话,可以拿把指甲刀刻进脑海中去,它凸显了 Android 的运行特
征。如果一个 Service,是有期望运行在于调用方不同进程的时候,就需要利用 Android 提供的 RPC 机制,为其部署一套进程间通信的策略。
Android 的 RPC 实现,如上图所示(好吧,也是从 SDK 中拿来主义的…),无甚稀奇,基于代理模式的一个实现, 在调用端和服务端都去生成一个代理类, 做一些序列化和反序列化的事情,使得调用端和服务器端都可以像调用一个本地接口一样使用 RPC 接口。
Android 中用来做数据序列化的类是 Parcel,参见: /reference/android/os/,封装了序列化的细节,向外提供