|
|
|
@ -25,4 +25,19 @@ Launcher 组件是如何获取这些信息的呢?其实是在系统启动时 |
|
|
|
|
|
|
|
|
|
在 handleLauncherActivity 中,通过 Instrumentation 的 newActivity 去创建这个 Activity,然后创建 Application 对象以及 ContextImpl ,最后调用 Activity 的 attach 函数,这个函数里面会 new 一个 PhoneWindow 并关联 WindowManager,也就是 Activity 显示流程的入口函数了。最最后会调用到 Activity 的 onCreate 函数。 |
|
|
|
|
|
|
|
|
|
至此,Activity 的启动流程讲完了。如果是非根 Activity 的启动呢,只需要去掉创建应用程序进程那一步即可。 |
|
|
|
|
至此,Activity 的启动流程讲完了。如果是非根 Activity 的启动呢,只需要去掉创建应用程序进程那一步即可。 |
|
|
|
|
|
|
|
|
|
#### Service 的启动过程 |
|
|
|
|
|
|
|
|
|
首先说一下非绑定 Service 的启动过程。 |
|
|
|
|
|
|
|
|
|
在我们调用 Context 的 startService 方法时,是调用了 ContextImpl 的 startService,这个方法同样是获取 AMS 的代理对象,然后向 AMS transact 一个 START_SERVICE 请求。在 AMS 的 startServiceLocked 去处理这个请求。在 AMS 中,每一个 Service 组件都是用一个 ServiceRecord 对象来描述,就像每一个 Activity 组件都使用一个 ActivityRecord 对象来描述一样。 |
|
|
|
|
|
|
|
|
|
在 startServiceLocked 中,会首先向 AMS 中查找是否存在与参数 Intent 对应的一个 ServiceRecord 对象,如果不存在,就会到 PKMS 中去获取这个 Intent 对应的 Service 组件的信息,然后封装成一个 ServiceRecord 对象,最后调用 bringUpServiceLocked 来启动这个 Service。 |
|
|
|
|
|
|
|
|
|
在 bringUpServiceLocked 中,同 Activity 的启动一样,都会去首先判断该 Service 组件所在的应用程序进程是否已经存在,如果不存在就会先去创建应用程序进程,创建完成之后会把 ApplicationThread 传递给 AMS,以便 AMS 可以和这个新创建的应用程序进程通信。接着,就是 realStartServiceLocked,这个方法无非就是通过 ApplicationThread 向应用程序进程发送一个 CREATE_SERVICE 进程间通信请求,在应用程序进程是如何处理的呢?其实还是老样子,往主线程 Handler 发现一个消息,然后调用 handleCreateService。 |
|
|
|
|
|
|
|
|
|
在 handleCreateService 中,会通过 LoadedApk 的 ClassLoader 去加载这个 Service 类,然后在创建一个 ContextImpl,最后调用 Service 的 attach 和 onCreate 函数。 |
|
|
|
|
|
|
|
|
|
至此,非绑定 Service 组件的启动流程就讲完了。下面再来说说绑定服务的启动流程。 |
|
|
|
|
|
|
|
|
|