Android Activity启动流程分析--------基于Android O版本分析

工作多年,首次写文章,确实有些汗颜,作为一个Android系统开发人员,还是应该觉得记录点心得和经验,否则感觉从来没踏入过这个领域一般.

废话不多说,直接上正题:

作为Android四大组件之一的Activity想必大家知道它的重要性,那么大家知道它如何创建,怎么出现生命周期的,如何呈现在大家眼前,以及如何与用户事件交互等等一系列的问题,这篇先从它如何被创建以及如何出现生命周期,怎么管理开始.

启动Activity的方式:

1.adb shell am start -n ｛包(package)名｝/｛包名｝.{活动(activity)名称}   可以打开相应的Activity

2.用户点击Launcher应用图标启动一个应用的入口Activity(android.intent.action.main所指的Activity) ,这个动作会最终调用Launcher的startActivity方法.查看源码可知道

Launcher#startActivity-------->Activity#startActivity--------->Activity#startActivityForResult---------->Instrumentation#execStartActivity方法

这里讲下Instrumentation#execStartActivity方法Instrumentation.execStartActivity(this, mMainThread.getApplicationThread(), mToken, this,intent, requestCode, options);可以发现mMainThread.getApplicationThread() 该参数是个IBinder类型,mToken也是个IBinder类型,这里主要关注一下mMainThread.getApplicationThread(),有Binder即有进程间交互,目前还是处于launcher进程,因为是launcher启动的App,目前App进程还没创建出来,继续看源码可以看到

Instrumentation#execStartActivity---------->ActivityManager.getService()#startActivity--------->ActivityManager.getService()#startActivity 这里面第一个参数为whoThread即是launcher进程.再看ActivityManager.getService()这条线

ActivityManager.getService()------------->IActivityManagerSingleton.get()单例模式具体可以看Singleton这个类get方法---------->可以发现这里就是我们所熟悉的获得系统服务的步骤,即可以通过binder机制获得服务端的Ibinder转成客户端的IActivityManager,其实对应的还是服务端的ActivityManagerService在处理.如果有了解Binder机制的同学可以知道服务端和客户端都有对应的Manager，比如ActivityManagerService和ActivityManager,他们基本上名字多了个Service除外,方法基本一模一样,调用客户端的方法会通过binder机制传到服务端去处理(这里的客户端服务端都是相对的,可以自行查看binder机制,此处不做扩展).即目前从launcher进程转到了AMS所在进程也就是系统进程.

也就是ActivityManager.getService()#startActivityAsUser---------------->AMS#startActivityAsUser方法,接下来AMS#startActivityAsUser-------------------->ActivityStarter#startActivityMayWait------------------>ActivityStarter#startActivityLocked-------------------->ActivityStarter#startActivity(ActivityStarter里面重载方法太多,找准对应的参数= =)------------->ActivityStarter#startActivityUnchecked-------->ActivityStackSupervisor#resumeFocusedStackTopActivityLocked---------------->ActivityStack#resumeTopActivityUncheckedLocked------------>ActivityStack#resumeTopActivityInnerLocked

这里大致讲下resumeTopActivityInnerLocked该方法主要判断next.app和next.app.thread(这里就是我们新的app进程)是否被创建,如果没被创建则走下面流程

接着ActivityStack#resumeTopActivityInnerLocked----------------->ActivityStackSupervisor#startSpecificActivityLocked----------------->AMS#startProcessLocked(由于是第一次启动新的app,此时app线程(也就是ActivityThread)没有创建,最终还是由底层的zygote进程孵化,具体请参照源码)等到app进程创建好之后再到ActivityStackSupervisor#realStartActivityLocked方法中.

ActivityStackSupervisor#realStartActivityLocked--------->app.thread.scheduleLaunchActivity(app.thread==ProcessRecord.IApplicationThread这里有"I"大家明白了吧,此处是个binder)            那么看下IApplication的实现类是在ActivityThread中(通过binder机制已经转回到新的app进程中)

app.thread.scheduleLaunchActivity-------->ApplicationThread#scheduleLaunchActivity------>通过LAUNCH_ACTIVITY找到对应的处理方法ActivityThread#handleLaunchActivity------>ActivityThread#performLaunchActivity

看performLaunchActivity该方法可以知道通过反射创建所需的Activity类

之后就调用我们熟悉的onCreate方法了.到此Activity源码启动过程分析结束了..

对于以上知识总结如下:

1.前一个进程调用.2.创建新的Activity信息.3.创建新的app进程.4.将activity生命周期进行管理是在ApplicationThread中,Handler来接收消息通过Instrument辅助类处理.4.整个流程用了三次跨进程通信,一个是launcher进程通知系统进程,一个是系统进程通知zygote进程,另一个是系统进程通知新的app进程.

最后本文涉及到遗留问题说明: 

1.Binder机制没有详细写出

2.系统进程如何创建的没有写出

3.系统如何通过AMS#startProcessLocked该方法把要启动的app进程创建的,没有深入探究

4.一些Activity的相关类没有详细介绍比如ActivityStack,ActivityStack,ProcessRecord,ActivityStackSupervisor,ActivityStarter

至此,一个大致流程已经出来,仅供参考.如发现有任何问题,欢迎指正.