各种启动过程 通过Launcher启动MainActivity的过程

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/doom20082004/article/details/53435424

参考罗升阳《Android系统源代码情景分析(修订版)》


一、Zygote的启动过程

Zygote是由Android系统的第一个进程init启动起来的,init是内核在加载完成之后就启动起来的;

Zygote进程通过复制自身的方式创建System进程和应用程序进程,同时复制虚拟机实例;

通过init.rc来启动,并创建一个名称为zygote的socket,便于各种服务与之通信;

1. init.c中创建新进程以及相应的socket;

2. 新进程执行app_process.main创建了AppRuntime对象,在后者中创建Java虚拟机,并运行ZygoteInit类的main;

3. 创建Socket并监听子进程的消息,复制自身创建System server进程。


二、System进程的启动过程

1. 设置时区和键盘,启动binder线程池,调用SystemServer的main方法;

2. 调用init1启动一些C++开发的系统服务,如SurfaceFlinger和SensorService等,

3. 调用init2启动Java语言开发的系统服务AMS,PMS,ContentService和WMS等,并注册在ServerManager中。


三、应用程序的启动过程

应用程序进程在启动的过程中,除了可以获得一个虚拟机实例之外,还可以获得一个Binder线程池和一个消息循环。

1. Process.start调用后,创建连接到zygote的socket对象,发送启动进程的参数,返回新建进程的pid。

2. zygote接收到数据后,调用runOnce,fork出新的进程,设置时区和键盘布局,创建Binder线程池;

3. 通过抛出异常的方式清理调用栈,然后调用ActivityThread的main,创建消息循环。


四、从Launcher启动一个应用进程

1. Launcher组件向AMS发送一个启动MainActivity组件的进程间通信请求,带着FLAG_ACTIVITY_NEW_TASK的标记,应用程序进程的ApplicationThread对象和AMS内部的ActivityRecord在应用程序端的代理对象token;

2. AMS借助PMS获取更多MA的信息后,将该信息保存在ActivityInfo中,创建MA对应的ActivityRecord,创建新的ActivityTask,将MA的ActivityRecord放在ActivityStack的栈顶,然后中止当前正在激活的Launcher,即向Launcher组件发送一个进入中止状态的进程间通信请求(异步Binder请求);

3. Launcher组件通过Handler处理中止的请求,调用onUserLeaveHint和onPause进入到中止状态之后,就会向AMS发送一个已经进入中止状态的进程间通信请求;

4. AMS在规定时间内收到Launcher发来的请求后,继续启动MA,发现用来运行的MA的应用程序进程不存在,就会先启动一个新的应用程序进程和ProcessRecord。调用Process.start创建新进程后,调用ActivityThread的main函数。

5. 新进程启动后,创建ApplicationThread发送给AMS,并进入消息循环;

6. AMS再将第二步保存的MA信息发送给新进程的ActivityThread,以便它可以启动MA。

7. ActivityThread通过Handler切换到主线程,然后用ClassLoader创建MA、Context,调用attach初始化MA,再调用onCreate。

8. 之后会调用onResume,然后调用wm.addView(decor, l);


五、Service组件在新进程中的启动过程

1. Client组件向AMS发送一个启动Server组件的进程间通信请求;

2. AMS发现运行Server组件的应用程序不存在,就会先将Server组件的信息保存下来,接着再创建一个新的进程;

3. 新进程启动后,向AMS发送启动完成的请求;

4. AMS将第二步保存下来的Server组件信息发送给新进程,以便将Server启动起来。


六、Service组件在进程内的绑定过程

1. 客户端组件向AMS发送一个绑定Service组件的进程间通信请求;

2. AMS发现用来运行Service组件的应用程序进程即为客户端组件进程,因此就直接通知该进程将Service组件启动起来;

3. Service组件启动之后,AMS就请求它返回一个Binder本地对象,以便客户端可以通过该对象来和Service建立连接;

4. AMS将前面从Service组件获得的本地Binder发送给客户端;

5. 客户端组件获得AMS发送给它的Binder本地对象之后,就可以通过它来获得Service所提供的服务,相当于Service组件绑定在客户端内部了。


七、AMS功能概述

1. 四大组件状态管理:startActivity, startService, removeContentProvider等;

2. 查询组件当前的运行情况:getCallingActivity, getServices等;

3. 管理ActivityStack和Task相关操作;

4. 辅助功能getMemoryInfo, getCPUInfo等。


八、WMS概述

1. Activity通过调用openSession获得IWindowSession与WMS通信,而WMS通过relayout传来的IWindow与Activity通信,WMS和AMS可以直接通信;

2. WMS利用WindowState来保存一个窗口相关的信息,还用AppWindowToken来对应AMS中的一个ActivityRecord;

3. 窗口分为Application Window,Sub Window和System Window,各自有各自的层级范围;

4. 窗口有创建的策略,窗口属性,如type,flags,和systemUiVisibility;

5. WindowManagerGlobal中保存着mViews,mRoots和mParams,是一一对应的关系;

6. 通过root.setView(view, wparams, panelParentView)开始跨进程调用,其中的requestLayout内部调用了scheduleTraversal

7. WNS并不关心View树所表达的具体UI内容,它只要知道各应用进程显示界面的大小、层级值等。

8. 在WMS的addWindow中会创建WindowToken,WindowState,计算窗口ContentInset区域以及调整窗口的层级


九、Surface管理

1. WMS原则上只负责管理窗口的层级和属性,而SurfaceFlinger才是真正将窗口数据合成并最终显示到屏幕上的。WMS对窗口大小、ZOrder调整的同时也必须要通知SF;

2. ViewRoot进行performTraversals时会向WMS申请Surface,自己先创建一个空的Surface,再传到WMS中获得SF的Surface的内容;



展开阅读全文

没有更多推荐了,返回首页