个人理解:本文的核心思想就是说明,所谓的四大组件,只是让你的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系统来说到底意味着什么。
这是一个APP与用户交互的入口。从系统的角度看,系统为Activity提供的关键交互动作是:
- 持续跟踪用户当前正在关心的(也就是显示在屏幕上的东西),以确保当前进程保持运行。
个人理解:这里,作者实际上的含义是,当你的应用被系统从Activity启动时,在Activity的start与stop状态之间,系统会确保这个Activity始终占据着设备的屏幕,并且确保你的应用绝不会被系统杀死。这是你从Activity启动自己的APP时,系统给予你的APP的一种承诺(just a promise)。
-
知道那些之前使用过的进程,这些进程包含着用户可能会返回获取的东西(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与系统之间的约定(在适当的状态下启动它,正确地保存/恢复它的状态)。
这是一种让系统在正常的用户流(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机制
。
当由于各种各样的原因需要APP在后台运行时,Service就是一个这样的入口。有两种语义上截然不同的Services(一种是Started Service,一种是Bound Service)来告诉系统怎样管理一个APP。
Started Service就相当于因为某种原因你的APP告诉系统:“系统大哥,我有事要干,请让我一直运行,直到我告诉你我干完了。”(这里的我相当于APP,因为此时的Service就代表了APP,而系统是只跟APP对话的)这里的“事”可能是在后台同步数据或者在用户离开APP后播放音乐。
同时,Started Service又有两种,一种是用户可感知的,一种是用户无法感知的。这两种不同的Started Service会让系统对它们采取不同的管理方式。
-
播放音乐的Service是用户可以直接感知的,所以Service会对系统说:“我想成为前台(foreground),并且在通知栏挂一个通知,让用户能够感到我的存在。”这种情况下,系统知道,必须使出吃奶的劲保证这个service进程的运行,因为如果这个进程宕掉,用户会不高兴。
-
另一种后台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的各部分连接到一起。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
写在最后
由于本文罗列的知识点是根据我自身总结出来的,并且由于本人水平有限,无法全部提及,欢迎大神们能补充~
将来我会对上面的知识点一个一个深入学习,也希望有童鞋跟我一起学习,一起进阶。
提升架构认知不是一蹴而就的,它离不开刻意学习和思考。
**这里,笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家,**梳理了多年的架构经验,筹备近1个月最新录制的,相信这份视频能给你带来不一样的启发、收获。
最近还在整理并复习一些Android基础知识点,有问题希望大家够指出,谢谢。
希望读到这的您能转发分享和关注一下我,以后还会更新技术干货,谢谢您的支持!
转发+点赞+关注,第一时间获取最新知识点
Android架构师之路很漫长,一起共勉吧!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
注一下我,以后还会更新技术干货,谢谢您的支持!
转发+点赞+关注,第一时间获取最新知识点
Android架构师之路很漫长,一起共勉吧!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!