Activity启动流程笔记

妖狐艹你老母 2022-05-29 11:43 219阅读 0赞

一直遇到这个问题，而且提示与生命周期不同，很是疑惑。于是网上搜罗，并翻看《Android开发艺术探索》，发现多是代码，长篇大论。好奇心所致，一路ctrl+B，看看能收获些什么。

Activity的启动流程，涉及应用进程端和系统服务端两部分，因此，为跨进程通讯。既然是跨进程，那就离不开Android的Binder机制。

Binder机制，为C/S模式，是单向的。而应用进程端与系统服务端的通讯是双向的，互为Client/Server。所以，需要两个Binder。ActivityManagerNative和ApplicationThreadNative就是这两个Binder。先说一下，这两Binder及其子类。

## ActivityManagerNative ##

ActivityManagerNative继承自Binder，实现了IActivityManager接口（该接口定义了与Activity manager Service通讯的接口）。ActivityManagerNative还包含一个内部类ActivityManagerProxy。但ActivityManagerNative仍是一个抽象类。

## ActivityManagerService ##

ActivityManagerService继承于ActivityManagerNative，并实现了内部的抽象方法。该类对象位于系统进程中。

因此，ActivityManagerProxy对象可以看做是ActivityManagerService在应用进程端的代理。可以通过ActivityManagerNative的getDefault静态方法来获取到该代理。

通过调用ActivityManagerProxy对象所提供的方法，完成应用进程端至系统服务端的通讯。

## ApplicationThreadNative ##

ApplicationThreadNative继承自Binder，实现了IApplicationThread接口（该接口定义了与Application通讯的接口）。ApplicationThreadNative也包含一个内部类ApplicationThreadProxy。ApplicationThreadNative也是一个抽象类。

## ApplicationThread ##

ApplicationThread继承自ApplicationThreadNative，并实现了内部抽象方法。

ApplicationThread是ActivityThread的一个内部私有类。

ActivityThread是应用的主线程。

ActivityThread还存在一个内部私有类H，实为Handler，用于处理内部消息。

通过调用ApplicationThreadProxy对象所提供的方法，完成系统服务端至应用进程端的通讯。

由于ApplicationThread和ActivityManagerService的存在，使得双向通讯得以完成。

## 与生命周期的关系 ##

Activity的启动，涉及android framework，需要阅读核心代码，且代码十分繁琐。因此，对于其流程，也只能看一下顺序，了解个大概的机制。

结合Activity的生命周期，整个流程大致分以下几步:

(1)    执行栈顶activity的onPause；

(2)    查看当前要启动的目标activity所在进程是否被创建。若未创建则，则执行步骤（3）；否则，跳至步骤（4）；

(3)    启动activity所在进程；

(4)    依次触发activity的生命周期方法，onCreate，onStart，onResume；

(5)    触发原栈顶activity的onStop方法。

但，毕竟启动过程，不仅仅是生命周期方法的调用。硬着头皮，捋着代码走了一遍。才有了以下笔记。希望有助于记忆。

## 参考 ##

整理过程中，参考了部分文章，也列在下面。

[http://blog.csdn.net/qq\_23547831/article/details/51224992][http_blog.csdn.net_qq_23547831_article_details_51224992]

[http://blog.csdn.net/tellh/article/details/57418651][http_blog.csdn.net_tellh_article_details_57418651]

[http://blog.csdn.net/ccjhdopc/article/details/72551767][http_blog.csdn.net_ccjhdopc_article_details_72551767]

[http://blog.csdn.net/zhaokaiqiang1992/article/details/49428287][http_blog.csdn.net_zhaokaiqiang1992_article_details_49428287]

[http://blog.csdn.net/tfygg/article/details/52086621][http_blog.csdn.net_tfygg_article_details_52086621]

文中有部分描述还是模糊，仍需要查看代码，才得以确认。

此外，对于android framework代码，若不想下载，可访问网址

[http://grepcode.com/search?query=&start=0&entity=type&n][http_grepcode.com_search_query_start_0_entity_type_n]=

在线查看。只需要输入要查找的类即可，很方便。

## 小结 ##

先把小结写在前面，时因为整个Go To Definition过程多少有些乏味和漫长。

这个过程中，会在ActivityThread（将要启动的Activity）,ActivityThread（当前处于栈顶的Activity）和ActivityManagerService间不断的跳转。因为前两者是不同的进程，不能直接通讯，所以需要系统服务进程ActivityManagerService这个管理者出现，为两者传递信息。

系统核心进程zygote，也会参与到启动过程中。当将要启动的Activity所在的进程未被启动时，zygote将创建该进程。

（1）调用startActivity时，当前进程会通过ActivityManagerProxy向AMS(ActivityManagerService）发送信息。通知其执行当前栈顶的Activity的onPause。

（2）AMS收到请求后，通过ApplicationThreadProxy向当前栈顶Activity的ActivityThread发送信息。

（3）当前栈顶Activity的ActivityThread接收到请求后，发送message给H，H触发该Activity的onPause。执行完毕后，当前栈顶Activity的ActivityThread，通过ActivityManagerProxy通知AMS(ActivityManagerService），操作完成。

（4）AMS收到请求后，查看将要启动的目标Activity所在进程是否已被启动。若未启动，则通知系统核心zygote创建进程，并将进程启动类ActivityThread名称作为参数，提供给zygote.

（5）zygote创建完进程后，触发ActivityThread的Main方法，初始化进程。初始化结束后，ActivityThread通过ActivityManagerProxy通知AMS(ActivityManagerService）操作完毕。

（6）AMS收到请求后，通过ApplicationThreadProxy向目标ActivityThread（新建成的）发送请求，要求其启动目标Activity。

（7）目标ActivityThread收到请求后，发送message给H，H依次触发handleLaunchActivity操作，和handleResumeActivity操作。前者执行目标Activity的onCreate和onStart，后者执行onResume。handleResumeActivity最后会再次通过ActivityManagerProxy通知AMS(ActivityManagerService），进行Idle操作。

（8）AMS接收请求后，会在空闲时通过ApplicationThreadProxyt通知原栈顶Activity的ActivityThread,对原栈顶Activity执行onPause操作。或在内存不足时，执行onSaveInstanceState操作。

整个流程小结完毕。

## Go to Definition ##

下面是走流程时做的笔记。

### （1）栈顶activity的onPause ###

启动一个Activity，是从startActivity()方法开始的逐级调用。

startActivity
            ->startActivityForResult
                    ->Instrumentation.execStartActivity
                            ->ActivityManagerNative.getDefault().startActivity

Instrumentation是Activity的一个应用进程端的实际操作类。

当调用ActivityManagerNative.getDefault().startActivity时，根据Binder机制，实际是调用了ActivityManagerService对象的startActivity方法。操作从应用进程端，跳转至系统服务端。

ActivityManagerService.startActivity 
            ->startActivityAsUser
                    ->StackSupervisor.startActivityMayWait
                            -> StackSupervisor.startActivityLocked
                                    -> StackSupervisor.startActivityUncheckedLocked
                                            -> ActivityStack.startActivityLocked
                                                    -> ActivityStackSupervisor.resumeTopActivitiesLocked
                                                            ->ActivityStack.resumeTopActivityLocked 
                                                                    ->ActivityStack.startPausingLocked
                                                                            -> prev.app.thread.schedulePauseActivity

prev.app.thread为一个IApplicationThread对象，即ApplicationThreadProxy对象。

因此，此时操作又从系统服务端，跳转至应用进程端。该进程为栈顶Activity所在的进程。继续，

ApplicationThread.schedulePauseActivity
            ->ActivityThread.sendMessage (PAUSE_ACTIVITY_FINISHING)
                    ->H.sendMessage
                            ->H.handleMessage
                                    ->ActivityThread.handlePauseActivity
                                            ->ActivityThread.performPauseActivity
                                                    ->mInstrumentation.callActivityOnPause
                                                            ->activity.performPause
                                            ->ActivityManagerNative.getDefault().activityPaused

在应用进程中，ApplicationThread发送PAUSE\_ACTIVITY\_FINISHING消息至H，H处理后，触发mInstrumentation，最终调用了activity.performPause方法。

至此，栈顶activity 在应用进程端的Pause处理结束。

### （2）启动目标Activity所在进程。 ###

在上一阶段的ActivityThread.handlePauseActivity方法中，处理完应用进程端的Pause处理后，还调用了ActivityManagerNative.getDefault().activityPaused，使得处理流程，再次从应用进程端，跳转至系统服务端。

ActivityManagerService.activityPaused
            ->ActivityStack.activityPausedLocked
                    ->ActivityStack.completePauseLocked
                            ->ActivityStackSupervisor.resumeTopActivitiesLocked
                                    ->ActivityStack.resumeTopActivityLocked
                                            ->ActivityStack.resumeTopActivityInnerLocked
                                                    ->ActivityStackSupervisor.startSpecificActivityLocked
                                                            ->ActivityStackSupervisor.realStartActivityLocked
                                                            Or
                                                            ->mService.startProcessLocked

其中，ActivityStackSupervisor.startSpecificActivityLocked方法，会判断一下需要启动的目标Activity所在应用进程是否已经启动，若启动的话，则直接调用ActivityStackSupervisor.realStartActivityLocked方法，触发目标Activity的生命周期；否则，调用mServicestartProcessLocked方法，用于启动应用进程。

而mService是什么？一个ActivityManagerService对象。

因此，在目标Activity所在应用进程未被启动的情况下，调用StartProcessLocked方法时，操作又从应用进程端，转至系统服务端。

ActivityManagerService. startProcessLocked
            ->Process.start
                    -> Process.startViaZygote
                            ->Process.zygoteSendArgsAndGetResult

Zygote是android系统中用于创建新进程的核心进程。每个进程都有一个启动类。

进程的启动类名“android.app.ActivityThread”被当做参数，在Process.start方法中设置，并传入Process.startViaZygote中。

当新进程创建完毕后，会依照启动类名反射至启动类，并自动执行进程启动类的main方法。即ActivityThread的main方法。

ActivityThread.main
            ->new ActivityThread
                    -> ActivityThread.attach
                            -> ActivityManagerNative.getDefault.attachApplication

再次跳转至ActivityManagerService中。

ActivityManagerService.attachApplicationLocked
                  ->ActivityStackSupervisor.attachApplicationLocked
                          ->ActivityStackSupervisor.realStartActivityLocked

又见到realStartActivityLocked方法了。之前提过，该方法是用于启动Activity的。因此，说明从当前位置开始，将进行目标activity的生命周期操作。进程启动操作完毕。

### （3）启动Activity。 ###

ActivityStackSupervisor.realStartActivityLocked
            ->app.thread.scheduleLaunchActivity

操作从系统服务端跳转至应用进程端。

ActivityThread.scheduleLaunchActivity
            ->sendMessage(H.LAUNCH_ACTIVITY)
                    ->H.handleMessage
                            ->ActivityThread.handleLaunchActivity
                                    ->ActivityThread.performLaunchActivity
                                            ->mInstrumentation.callActivityOnCreate
                                                    ->activity.performCreate
                                                            ->activity.onCreate
                                            ->activity.performStart
                                                    ->mInstrumentation.callActivityOnStart
                                                            -> activity.onStart
                                    ->ActivityThread.handleResumeActivity
                                            ->ActivityThread.performResumeActivity
                                                    ->r.activity.performResume
                                                            ->mInstrumentation.callActivityOnResume
                                                                    ->activity.onResume
                                            ->Looper.myQueue().addIdleHandler(new Idle)

从过程中可以看到，在处理LAUNCH\_ACTIVITY消息时，handler执行了ActivityThread.handleLaunchActivity方法。该方法依次执行了两个方法，ActivityThread.performLaunchActivity和ActivityThread.handleResumeActivity。前者触发了目标activity的onCreate方法，和onStart方法。而后者，则触发了activity的onResume方法。

至此Activity完成显示。但这并未结束。此前栈顶的activity还有操作未完成。

### （4）执行栈顶Activity的onStop。 ###

在处理目标activity onResume生命周期的handleResumeActivity方法中，结尾处，调用了Looper.myQueue().addIdleHandler(new Idler())。这个方法很不起眼，但却触发了空闲情况下的处理机制。

Idler继承于MessageQueue.IdleHandler。用于在线程空闲时，执行某种操作。空闲时，其queueIdle方法将被触发。

Idler.queueIdle
            ->ActivityManagerNative.getDefault().activityIdle

又是一个熟悉的身影~再次跳转至系统服务端。

ActivityManagerService.activityIdle
                    ->ActivityStack.stopActivityLocked() 
                            ->r.app.thread.scheduleStopActivity

再次跳转至应用进程端，原置顶activity所在的进程。

ActivityThread.scheduleStopActivity
           -> ActivityThread.sendMessage
                  ->H.handleMessage
                         ->ActivityThread.handleStopActivity
                                -> ActivityThread.performStopActivityInner
                                       ->ActivityThread.callCallActivityOnSaveInstanceState
                                       or
                                       ->Activity.performStop

在ActivityThread.performStopActivityInner方法中，根据情况，会触发两个不同的操作。若内存不足，需要回收，则触发ActivityThread.callCallActivityOnSaveInstanceState；而正常情况下，则会触发Activity.performStop。

我们先来看一下正常情况。

Activity.performStop
           ->mInstrumentation.callActivityOnStop
                  ->Activity.onStop

终于，onStop出现。 原栈顶activity的onStop完成。

再来看，内存不足的情况。

ActivityThread.callCallActivityOnSaveInstanceState
           ->mInstrumentation.callActivityOnSaveInstanceState
                  ->Activity.performSaveInstanceState
                         ->Activity.onSaveInstanceState

原栈顶activity的onSaveInstanceState方法完成。

至此，整个Activity的启动完毕。

[http_blog.csdn.net_qq_23547831_article_details_51224992]: http://blog.csdn.net/qq_23547831/article/details/51224992
[http_blog.csdn.net_tellh_article_details_57418651]: http://blog.csdn.net/tellh/article/details/57418651
[http_blog.csdn.net_ccjhdopc_article_details_72551767]: http://blog.csdn.net/ccjhdopc/article/details/72551767
[http_blog.csdn.net_zhaokaiqiang1992_article_details_49428287]: http://blog.csdn.net/zhaokaiqiang1992/article/details/49428287
[http_blog.csdn.net_tfygg_article_details_52086621]: http://blog.csdn.net/tfygg/article/details/52086621
[http_grepcode.com_search_query_start_0_entity_type_n]: http://grepcode.com/search?query=&start=0&entity=type&n