Activity
Activity是一个应用组件,承担了主要的与用户的交互工作。它需要依赖WindowManagerService来完成界面显示和绘制,它依赖ActivityManagerService来完成启动过程、生命周期的管理以及Activity任务盏的管理。
- Activity有两个启动方式,显式启动和隐式启动,两种方式AMS都是通过PackageManagerService的
queryIntentActivities
方法获取对应组件信息,然后再启动对应的Activity - Activity有四种启动模式:
standard
singleTop
singleTask
singleInstance
这四种启动模式的区别主要是通过任务栈完成,Activity在AMS中对应着一条ActivityRecord,而通常情况下一个应用的ActivityRecord都由同一个TaskRecord(栈型结构)管理,所有的TaskRecord又由ActvityStack管理,我们真正意义上的任务栈指的就是TaskRecord,不同的启动模式则是对应着对TaskRecord的不同处理。 - 多进程启动:在manifest的Activity标签配置android:process即可多线程启动.
在AMS的startProcessLocked的方法中会试图通过processName和uid获取已有的进程进程记录并在后续返回,如果对应的Activity为设置了不同的process,则此处会为null,最终会通过调用Process.start开启一个新的进程
Service
Service是一个长期在后台执行任务而不提供界面的组件,但是默认情况下Service没有提供额外线程能力去处理任务,Service有两种形式,一种是绑定在类似Activity的用户可交互的组件上,协助完成部分后台任务,一种是单独启动,完成任务后自动结束
startService() 启动服务
和启动Activity类似,都是先通过通过AMS已经其辅助的ActiveServices来创建和获取Service相关信息,最终通过ActivityThread来创建和启动Service
当Service已经开始运行之后,再次startService时在AvtiveServices的bringUpServiceLocked中通过判断Service 的ProcessRecord和对应的IApplicationThread后,直接通过scheduleServiceArgs最终调用Service的onStartCommand,同时不会继续进行后续的Service创建过程,即重复调用startService()也只会调用一次onCreate。bindService() 绑定服务
启动过程类似StartService,但不同点是在bind后,ServiceConnection回掉方法中会返回一个Service的IBinder对象,用于控制可能在不同进程的Service。
但是这里存在一个问题,既然时跨进程通信,那Service如何返回这个IBinder对象?这里Android创建了LoadedApk.ServiceDispatcher对象,并把ServiceConnection和它绑定在了一起,ServiceDispatcher内部有一个Binder也就是InnerConnection上,然后在调用AMS绑定Service的同时把InnerConnection对象也传递了过去
当目标Service启动会,也会通过AMS、通过InnerConnection把Service的Binder传递给Dispatcher最终调用onServiceConnected完成绑定多进程
上面已经多次提到Service极有可能是另一个进程的Service,所以Service必然是可以多进程的,方法和Activity一样即可
BroadcastReceiver
Android中用于发布或者接受消息的一个组件,类似发布订阅模式,这个是四大组件中唯一可以不在manifest中注册的组件(当然注册也是可以的)。BroadcastReceiver主要包括两个部分的内容,一个是广播接受者的register和广播的发射。
注册广播
广播可以通过代码或者manifest进行注册,效果是一样的,只是manifest中的是PMS在解析后自动帮我们注册的,同时和Service类似,广播也是跨进程的,则必须要由跨进程的机制,所以Android中有LoadedApk.ReceiverDispatcher对象, 是不是和ServiceDispatcher很像,其实效果也是一样的,这里BroadcastReceiver扮演了和ServiceConnection一样的角色,通过InnerReceiver这样一个Binder对象来完成进程间的通信。
广播的注册过程也是由AMS完成的,AMS中会接受广播注册是传递过来的InnerReceiver和IntentFilter,同时在BroadcastIntentLocked方法中把他们保存了下来,以便后面接收到广播后去检索广播接受者和回掉其方法。
发射广播
我们通过sendBroadcast发射的广播最终也是由AMS来处理的,它会分别从PMS中检索出静态注册的广播接受者和我们自己动态注册保存在AMS中的广播接受者。同时这里会对不同的广播分别处理和不同方式注册的广播分开处理:,
- 有序广播:按照优先级合并广播接受者,统一处理
- 普通广播(无序广播):首先处理动态注册的广播,因为manifest注册的广播接受者可能还没有启动,需要先启动对应的组件然后在处理广播
多进程启动方式?和上面的Activity、Service类似
ContentProvider
Android用于提供结构化数据访问以及对应的安全机制的一个组件,我们可以把我们的数据通过ContentProvider提供出去,然后可以使用 ContentResolver通过uri获取对应的操作。因此ContentProvider也分为两个部分,数据的提供和数据的访问
数据的提供
使用ContentProvider提供数据只需要继承ContentProvider,然后实现其方法同时创建UriMatcher,在manifest中声明后即可。
数据的访问
数据的访问需要使用ContentResolver通过指定的Uri获取,这个过程也是一个潜在的跨进程行为,这个过程中如果目标的ContentProvider还未启动则会先通过AMS先启动目标组件,而后通过数据共享模型进行数据获取。
多进程启动方式?和上面的Activity、Service类似
总结
本想对四大组件做一个相对深入的介绍,但是奈何前期积累不足,加上时间比较紧张,只能作出个一个不伦不类的东西,特别是ContentProvider远比想象中复杂的多,希望后期能有时间对四大组件做一个更加全面深入的了解