我眼中的Activity的工作过程
2016-08-29 15:44
274 查看
我们都知道平常在使用Activity的过程中,只需要调用Activity的startActivity方法,传入适当的参数就可以启动一个我们想要启动的Activity了,但是你知道这个过程中经历了些什么吗?今天我想从FrameWork层面解释下从系统启动到显示出我们的第一个Activity的整个过程,也算是对面试题:说一下一个Android
APP从点击打开开始,是怎样展示在用户面前的回答了,我不打算从源码角度进行分析,只希望能够将整个逻辑流程捋清楚就可以啦;
(1):首先,系统刚刚启动的时候加载的是Linux内核,在Linux内核加载完成之后会创建出来一个init进程,启动init进程解析init.rc文件首先会fork出一个叫ServerManager的子进程,该进程主要用于管理我们的系统服务,他内部存在一个server服务列表,这个列表中存储的就是那些已经注册的系统服务,随后init进程会fork出一个Zygote的子进程,Zygote进程是一个守护进程,之后,当我们的应用程序想要启动的时候,实际上是由Zygote来fork出子进程给我们的应用程序的,这就保证了我们的应用程序运行在单独的子进程中,即使一个应用程序奔溃也不会影响另一个应用程序的执行;
(2):在Zygote进程启动之后,会通过ZygoteInit的main方法fork出一个SystemServer子进程,SystemServer进程在启动的时候会创建ActivityThread对象以及系统上下文,注意一点就是虽然ActivityThread里面带有Thread,但他仅仅是一个普通的final类而已,并没有继承Thread或者实现Runnable接口,在ActivityThread里面存在一个内部类ApplicationThread,虽然ApplicationThread里面带有Thread,同样他也没有继承Thread或者实现Runnable接口,他实际上是一个Binder类,接着在SystemServer的main方法里面会创建ServerThread对象(同样虽然ServerThread里面带有Thread,但他只是一个普通类),并且调用他的initAndLoop方法,在initAndLoop方法里面会初始化诸如ActivityManagerService等一系列系统级Service对象,并且调用ServerManager的addService方法,将这些Service服务注册到ServerManager里面,同时启动这些服务;到这里,系统进程的启动工作就结束了,之后,会开启系统Launcher程序来完成系统界面的加载与显示;
(3):在我们点击应用程序的桌面图标的时候,App就由Launcher开始启动了,Launcher实际上是继承了Activity的,并且实现了点击、长点击等等监听器,在点击桌面图标的时候,实际上执行的是Launcher的onClick方法,在onClick里面会执行我们Activity的startActivitySafely方法,因为Launcher是继承自Activity的嘛,所以它里面的大多数方法都会辗转到Activity中去执行的,在startActivitySafely方法里面实际上执行的就是startActivity方法了,这个方法就是我们通常跳转Activity的时候调用的方法,这个方法里面会执行startActivityForResult方法,紧接着执行的是Instrumentation的execStartActivity方法,Instrumentation可以认为是一个大管家,每个Activity都持有一个Instrumentation对象的一个引用,但是整个进程中是只有一个Instrumentation的,AMS与ActivityThread之间诸如Activity的创建、暂停等的交互工作实际上是由Instrumentation具体操作的,在这里我们应该明白一点就是我们的ActivityManagerService是属于系统级服务的,而ActivityThread是用于管理应用程序的主线程执行的,而系统级服务和应用程序的ActivityThread是属于不同进程的,因此他们两者之间的交互是需要用到Binder通信的,而ActivityThread工作的真正执行者是Instrumentation,因此Instrumentation与AMS的交互是涉及到Binder通信的,也就是说Instrumentation的execStartActivity实际上是通过Binder与AMS进行通信的,在execStartActivity里面通过获得AMS在客户端的代理
ActivityManagerProxy,调用他的startActivity方法实际上最终执行到的就是AMS的startActivity方法,在AMS的startActivity方法中实际上通过ActivityStackSupervision与ActivityStack来交互操作完成Activity启动的,最终会执行到ApplicationThread的scheduleLaunchActivity方法来启动Activity,scheduleLaunchActivity会通过Handler来发送创建Activity的消息给主线程,也就是ActivityThread,而ActivityThread在接收到这个创建消息之后会调用他自己的handleLaunchActivity方法,这个方法会执行performLaunchActivity方法,在performLaunchActivity方法里面就会通过Instrumentation通过反射来创建一个Activity对象出来了,在创建完Activity之后就会调用Instrumentation的callActivityOnCreate方法来启动Activity,callActivityOnCreate实际上执行的是Activity的onCreate方法,进行一些必要的初始化操作;
APP从点击打开开始,是怎样展示在用户面前的回答了,我不打算从源码角度进行分析,只希望能够将整个逻辑流程捋清楚就可以啦;
(1):首先,系统刚刚启动的时候加载的是Linux内核,在Linux内核加载完成之后会创建出来一个init进程,启动init进程解析init.rc文件首先会fork出一个叫ServerManager的子进程,该进程主要用于管理我们的系统服务,他内部存在一个server服务列表,这个列表中存储的就是那些已经注册的系统服务,随后init进程会fork出一个Zygote的子进程,Zygote进程是一个守护进程,之后,当我们的应用程序想要启动的时候,实际上是由Zygote来fork出子进程给我们的应用程序的,这就保证了我们的应用程序运行在单独的子进程中,即使一个应用程序奔溃也不会影响另一个应用程序的执行;
(2):在Zygote进程启动之后,会通过ZygoteInit的main方法fork出一个SystemServer子进程,SystemServer进程在启动的时候会创建ActivityThread对象以及系统上下文,注意一点就是虽然ActivityThread里面带有Thread,但他仅仅是一个普通的final类而已,并没有继承Thread或者实现Runnable接口,在ActivityThread里面存在一个内部类ApplicationThread,虽然ApplicationThread里面带有Thread,同样他也没有继承Thread或者实现Runnable接口,他实际上是一个Binder类,接着在SystemServer的main方法里面会创建ServerThread对象(同样虽然ServerThread里面带有Thread,但他只是一个普通类),并且调用他的initAndLoop方法,在initAndLoop方法里面会初始化诸如ActivityManagerService等一系列系统级Service对象,并且调用ServerManager的addService方法,将这些Service服务注册到ServerManager里面,同时启动这些服务;到这里,系统进程的启动工作就结束了,之后,会开启系统Launcher程序来完成系统界面的加载与显示;
(3):在我们点击应用程序的桌面图标的时候,App就由Launcher开始启动了,Launcher实际上是继承了Activity的,并且实现了点击、长点击等等监听器,在点击桌面图标的时候,实际上执行的是Launcher的onClick方法,在onClick里面会执行我们Activity的startActivitySafely方法,因为Launcher是继承自Activity的嘛,所以它里面的大多数方法都会辗转到Activity中去执行的,在startActivitySafely方法里面实际上执行的就是startActivity方法了,这个方法就是我们通常跳转Activity的时候调用的方法,这个方法里面会执行startActivityForResult方法,紧接着执行的是Instrumentation的execStartActivity方法,Instrumentation可以认为是一个大管家,每个Activity都持有一个Instrumentation对象的一个引用,但是整个进程中是只有一个Instrumentation的,AMS与ActivityThread之间诸如Activity的创建、暂停等的交互工作实际上是由Instrumentation具体操作的,在这里我们应该明白一点就是我们的ActivityManagerService是属于系统级服务的,而ActivityThread是用于管理应用程序的主线程执行的,而系统级服务和应用程序的ActivityThread是属于不同进程的,因此他们两者之间的交互是需要用到Binder通信的,而ActivityThread工作的真正执行者是Instrumentation,因此Instrumentation与AMS的交互是涉及到Binder通信的,也就是说Instrumentation的execStartActivity实际上是通过Binder与AMS进行通信的,在execStartActivity里面通过获得AMS在客户端的代理
ActivityManagerProxy,调用他的startActivity方法实际上最终执行到的就是AMS的startActivity方法,在AMS的startActivity方法中实际上通过ActivityStackSupervision与ActivityStack来交互操作完成Activity启动的,最终会执行到ApplicationThread的scheduleLaunchActivity方法来启动Activity,scheduleLaunchActivity会通过Handler来发送创建Activity的消息给主线程,也就是ActivityThread,而ActivityThread在接收到这个创建消息之后会调用他自己的handleLaunchActivity方法,这个方法会执行performLaunchActivity方法,在performLaunchActivity方法里面就会通过Instrumentation通过反射来创建一个Activity对象出来了,在创建完Activity之后就会调用Instrumentation的callActivityOnCreate方法来启动Activity,callActivityOnCreate实际上执行的是Activity的onCreate方法,进行一些必要的初始化操作;
相关文章推荐
- Activity的工作过程
- Activity的工作过程
- [看书日记20160104]四大组件的工作过程, Activity的生命周期和启动模式
- 第九章四大组件的工作过程(一)Activity的工作过程(Android开发艺术探索)
- Android四大组件的工作过程(一)-Activity的工作过程
- Android Launcher 启动 Activity 的工作过程
- [基础] 3.1 Activity的工作过程
- 四大组件Activity的工作过程
- Activity的工作过程
- Activity工作过程
- (十七)四大组件的工作过程-Activity
- Activity工作过程分析 基于Android O(8.0) API 27
- Activity启动的工作过程知识点
- Activity工作过程源码分析
- Activity的工作过程
- Oracle JOB 用法小结 用法 工作 过程 参数 job 执行 运行 SQL 指示 _中国网管联盟_bitsCN.com
- 软件开发过程工作流程维度概述
- dhcp工作过程中的7个报文
- JWebPro工作过程图
- SQL Mobile 2005 Replication配置全过程完全图解(一、准备工作)