Android 四大组件的解读

这篇文章是转载自 milter:关于Android四大组件最权威最深刻最准确的解读 ,翻译自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），并因此给予这些进程更高的优先级。

3. 帮助应用处理进程被杀死的情况，以便用户能够返回到之前的activities，并且这些activities能够加载自己之前的状态

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

4. 提供一种在不同应用之间的用户流（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会让系统对它们采取不同的管理方式。

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来说合适的数据模型。