×
广告

关于Android四大组件最权威最深刻最准确的解读(绝不标题党)

96
milter 595a1b60 08f6 4beb 998f 2bf55e230555
2016.07.30 16:05* 字数 4524
Dianne Hackborn.jpg

这篇文章翻译自Dianne Hackborn发表在google+上的一篇post,她是google资深大牛,2005年就进入Android Framework团队。即使在google内部,论起对Android系统的理解把握,鲜有出其右者。在文章中,她深刻地阐明了Android设计四大组件的初衷,各个组件的目的作用,适用情景。我相信,读完此文,你会觉得重新认识了Android。如果想阅读原文,请在google+上搜索Dianne Hackborn。

“我应该怎样设计我的APP?我应该采用什么样的架构模式?我需要使用event bus吗?”

我们经常看到Android平台开发者询问在APP中采用什么设计模式和架构之类的问题。但是答案很可能会令你惊讶,那就是,我们(我们指的是Android Platform Team)对此并没有一个明确的观点,甚至可以说我们压根就没有观点。

你应该使用MVC还是MVP还是MVVM?我不知道。实际上,我在学校时只知道MVC,其他的架构模式是我临时google搜索后才写在这里的。

这也许令人吃惊,因为Android给人的感觉是,它对应当怎么写APP有着自己很强烈的看法,这种看法体现在它的Java APIs和四大组件等一些高级概念上,这些东西看上去组成了一个典型的应用开发框架,告诉我们开发者,你应当这样去实现你的功能。但实际情况是,根本不是这样。

我们可以将Android核心APIs(core APIs)叫做“系统框架”(system framework),而平台APIs(platform APIs)最主要的功能是定义APP应如何与操作系统交互,与APP内部运行逻辑毫不相关。

个人理解:可以简单地将core APIs看做操作系统内核,而将platform APIs看做我们常说的Android Framework。

这就是说,对于platform APIs,从开发者角度与从操作系统角度看其功能作用经常是不一致的,这很容易让人们在使用中感到困惑。

举例来说,我们来考虑一下操作系统是怎样定义“怎样运行一个APP”的。在一个经典的系统里,最基本的就是要求APP包含一个main方法,里面定义了自己要怎样运行:

int main(...){
//我的APP从这里开始运行
}

个人理解:本文的核心思想就是说明,所谓的四大组件,只是让你的APP告诉操作系统,自己要怎样运行而已,跟怎样设计自己的APP,压根没有关系。传统的应用通过一个main方法,告诉操作系统:“嘿哥们,main方法就是我的入口,请从这个方法开始运行我。”而Android却给了你四个选择,每一个组件都是让操作系统运行你的APP的一种入口。

好了,操作系统要运行你的APP了,于是它调用你的main方法,然后你的应用就开始运行了,你可以做任何你想做的事情,直到你认为自己完成任务为止。请注意,这里要求你定义main方法,并不是要求你去做什么事,或是完成一个叫做main的功能,main方法所有的作用仅仅是提供一个APP运行入口而已。

但是在Android的世界,我们决定,我们不要一个明确的main方法作为APP的入口。因为我们需要让系统对APP怎样运行有更多的控制权。尤其是,我们希望构建一个这样的系统,在该系统中,用户永远不需要考虑开启和停止一个APP,而把这些事交给系统去管理。所以,系统需要知道更多的每个APP的内部运行情况,以便能够在需要的时候,以定义好的方式启动APP,即使该APP当时并不在运行。

个人理解:这个系统所需要了解的每个APP的内部运行情况,其实就是Manifest.xml文件中的内容。

为了达到这一点,我们将一个APP的main方法分解成几种系统可以与之交互的形式。这几种形式就是Activity,BroadcastReceiver,Service和ContentProvider APIs,广大的Android开发者都很熟悉它们。

这些类好像在告诉你,你的APP内部应当怎样工作,但这是一种误解!事实上,这些类只是定义你的APP需要怎样与系统交互(以及系统怎样协调你的APP与其他APP进行交互)。这种与系统的交互一旦开始,系统就不再关心你的APP内部是怎样运行了。

为了更好地说明这一点,让我们简要地看看这些APIs对于Android系统来说到底意味着什么。

Activity

这是一个APP与用户交互的入口。从系统的角度看,系统为Activity提供的关键交互动作是:

  1. 持续跟踪用户当前正在关心的(也就是显示在屏幕上的东西),以确保当前进程保持运行。
    个人理解:这里,作者实际上的含义是,当你的应用被系统从Activity启动时,在Activity的start与stop状态之间,系统会确保这个Activity始终占据着设备的屏幕,并且确保你的应用绝不会被系统杀死。这是你从Activity启动自己的APP时,系统给予你的APP的一种承诺(just a promise)。

  2. 知道那些之前使用过的进程,这些进程包含着用户可能会返回获取的东西(stopped activities),并因此给予这些进程更高的优先级。

  • 帮助应用处理进程被杀死的情况,以便用户能够返回到之前的activities,并且这些activities能够加载自己之前的状态
    个人理解:很显然,系统所承诺的这种状态恢复能力,是依靠Activity的 onSaveInstanceState和onRestoreInstanceState方法,也就是说,你在Save方法中保存好你想在进程被杀死时想要保存的Activity状态,然后你就可以在Restore方法中获取这些状态以恢复Activity。当你把这些做完后,剩下的就是系统的事情了,系统会承诺,如果由于内存压力杀死了你的Activity所在的进程,那么当你返回时,系统会重建你的应用进程,并帮助你恢复之前Activity的状态。

  • 提供一种在不同应用之间的用户流(user flow)的方式,当然这要靠系统来协调。最经典的例子就是分享功能的实现。

对于Activity来说,系统并不关心的是:

一旦系统从Activity入口进入到你的APP UI之中,系统将不再关心Activity内部逻辑的组织。你可以将所有的应用逻辑全放入这一个Activity中,比如你可以手动地改变它的views,使用fragments或者其他框架,你也可以把你的应用逻辑分拆成额外的内部activities。你也可以三者同时使用(指的是改变views,使用fragemnts,分拆成额外的activities)。这些事情系统是毫不关心的,只要你遵循Activity与系统之间的约定(在适当的状态下启动它,正确地保存/恢复它的状态)。

BroadcastReceiver

这是一种让系统在正常的用户流(user flow)之外,传递事件给APP的机制。最重要的是,因为这是另一个被精心定义的APP的入口,即使APP当前并不在运行,系统也可以将broadcasts传递给APP。所以,举例来说,一个APP可以提前调度一个alarm,以便通知用户一个马上到来的事件,通过将这个alarm传递给该APP的一个BroadcastReceiver,在alarm发生之前,APP都没必要运行。

对于BroadcastReceiver来说,系统并不关心的是:

在APP内部分发事件是一个与BroadcastReceiver接收事件完全不同的事,不管你是使用一些eventbus 框架,实现你自己的回调系统,还是任何其他方法...你都没有理由使用系统的广播机制,因为你并不是在App之间分发事件。(事实上,不使用系统的广播机制还有一个很好的原因,这会带来许多不必要的负担,而且使用全局广播机制来实现APP内部的事件分发会引发许多安全问题)。当然,我们也提供了一个LocalBroadcastManager便利类,它实现了一个纯粹的进程内的intent分发系统,而且它的API与系统BroadcastReceiver API很相似,如果你喜欢当然也可以使用。但再次强调,你没有理由在仅仅发生在APP中的事情上使用BroadcastReceiver机制。

Service

当由于各种各样的原因需要APP在后台运行时,Service就是一个这样的入口。有两种语义上截然不同的Services(一种是Started Service,一种是Bound Service)来告诉系统怎样管理一个APP。

Started Service就相当于因为某种原因你的APP告诉系统:“系统大哥,我有事要干,请让我一直运行,直到我告诉你我干完了。”(这里的我相当于APP,因为此时的Service就代表了APP,而系统是只跟APP对话的)这里的“事”可能是在后台同步数据或者在用户离开APP后播放音乐。

同时,Started Service又有两种,一种是用户可感知的,一种是用户无法感知的。这两种不同的Started Service会让系统对它们采取不同的管理方式。

                              Service
                               |   
                       —————————————————— 
                       |                |
                   Started            Bound   
                     |
              ————————————————
             |               | 
      user awareness    user unawareness

(此图为本人草画,方便大家理解。)

  1. 播放音乐的Service是用户可以直接感知的,所以Service会对系统说:“我想成为前台(foreground),并且在通知栏挂一个通知,让用户能够感到我的存在。”这种情况下,系统知道,必须使出吃奶的劲保证这个service进程的运行,因为如果这个进程宕掉,用户会不高兴。

  2. 另一种后台Service是用户无法直接感知的,所以系统可以更加灵活地处理这个Service的进程。在系统急需RAM以保证用户眼前的事情正常运转时,系统可能会允许该进程被杀死(然后可以在之后有能力时再启动该Service)。

Bound Service 之所以会运行,是因为其他APP或者系统要使用它。通常情况该Service都会给其他进程提供一个API。在这种情况下,系统知道这两个进程之间存在一个依赖关系。所以,如果进程A绑定了进程B中的一个Service,系统就会知道,它要为进程A保证进程B和它里面的Service正常运行。进一步讲,如果进程A是用户当前正在关心的进程,系统将知道把进程B也当作用户正在关心的进程。

由于Service的灵活性(有好也有坏),Service已经成为各种类型的系统中一个非常有用的构建块(building block)。实时墙纸,通知监听器和许多其他的系统核心特性都被构建为Service,当它们需要运行时,系统再绑定它们。

对于Service,系统不关心的是:

Android不关心你的APP中那些不影响它怎样对待你的进程的事,所以这些情况下,是没有理由使用Service的。举例来说,如果你想在后台为你的UI下载数据,你不应该使用Service来做这件事----做这些事时,不告诉系统保持你的进程运行真的是很重要的,因为确实没有必要!!这样做也让系统有更多的自由去管理你的进程,以便与用户正在做的事情相协调(注:可以让系统在内存紧急的情况下,杀死你的进程,优先保证用户正在做的事情,这里忍不住吐槽一句:每个APP肯定都会觉得自己是最重要的哈,Google开发Android的人也是典型的理想主义!

如果你只是简单地开启了一个后台线程来做数据下载(或者其他不是Service的办法),你将会得到你想要的结果:如果用户在你的UI里,系统将会确保你的进程运行,所以下载绝不会被中断。当用户离开了你的UI,你的进程仍将被保持(缓存)因而可以继续下载数据,只要RAM不告急就行。

同样,为了将你的APP的不同部分连接起来,你也没有理由去绑定同一个进程中的Service。这样做倒是没有什么明显的害处,因为系统会看到,该进程对自己有一个依赖,它将会忽略这个依赖,仍将你的APP当作普通进程看待。但是这样做对你和系统实际上都是没有必要的。作为替代,你可以使用单例或者其他进程内的模式来将你的APP的各部分连接到一起。

ContentProvider

最后,ContentProvider是一个专用的办法,用来将你的APP的数据公开到其他地方。人们通常会将它们当作对数据库的抽象,因为有许多的API和支持库就是这样使用ContentProvider的。但是从系统设计的角度,这并不是ContentProvider的初衷。

对于系统来说,ContentProvider实际上是一个入口,用于获取一个APP内部的公开的被命名的数据项(data items),每个数据项都被一个URI scheme所标识。这样,APP就可以决定怎样将自己的数据项映射到一个URI scheme,怎样将这个URI scheme公开给其他APP或者系统,好让APP或者系统使用这个URI scheme来获取自己内部的数据。这将让系统能够用一些很独特的方式来管理你的APP:

  1. 将URI scheme公开出去并不要求你的APP一直保持运行,所以即使你的APP没有运行,这些URI scheme也可以公开给任何APP和系统。只有当某个人告诉系统:“请把这个URI代表的数据拿给我。”时,系统将会让你的APP运行起来向你索要对应于URI的数据项并返回给请求者。
  2. 这些URIs也提供了一个很重要的细粒度的安全模型。比如,你的APP可以将代表一张你的APP内的图片的URI放在剪贴板上,但是让它的ContendProvider 保持在锁定状态,所以没有人能够自由地获取它。当其他APP从剪贴板上获取了这个URI,并向系统请求获取对应的图片时,系统可以给它一个临时的“URI许可”,以便让它仅能获取该URI所对应的图片,你的APP的其他内容都是安全的。

对于ContentProvider,系统不关心的是:

在一个ContentProvider背后,你的APP如何管理你的数据,系统毫不关心;如果你不需要SQLite database中的结构化数据,你可以不使用SQLite。比如,FileProvider帮助类可以让你的APP内的原始文件轻松通过一个ContentProvider获取。

同样,如果你不打算公开你的APP中的数据给其他人使用,你也可以不实现ContentProvider。是这样的,因为围绕着ContentProvider,有许多便利的方法,这些方法让你很容易地将数据存入SQLite database,并用这些数据填充UI元素如ListView。但是如果这些方法让你觉得实现自己的想法有许多困难,你可以不使用它们,请自由地选择一个对你的APP来说合适的数据模型。

好了,文章翻译完了,为了避免直译的生硬晦涩,我花费了整整一天的休息时间,尽可能在不违背原文意思的情况下,加入了一些个性化的语句表达,还加入了“个人理解”部分,目的就是方便大家的理解。

如果你觉得这篇文章对你有帮助,那么,打个小赏或者点个小赞对我都是一种鼓励。谢谢!

Android开发
Web note ad 1