Android剖析Framework

Zygote进程是怎么启动的?

首先Init进程是Linux进程启动后用户空间的第一个进程,然后去加载inti.rc配置文件,看需要加载哪些服务,Zygote就是其中之一。还有ServiceManager进程。 父进程fork出子进程,如果子进程挂了,那么父进程会收到子进程发送过来的SIGCHLD信号,进而做处理。比如Zygote进程挂了,那么Init进程就收到SIGCHLD信号,继而重启Zygote进程。

Zygote的作用是什么?

1.孵化应用进程。

2.启动systemserver进程。因为启动systemserver进程的时候需要Zygote里面的一些资源,比如常用类,JNI函数,主题资源,共享库等,这样可以避免重复加载资源,提升性能。

 

Zygote进程启动之后做了什么?

1.Zygote的native层:启动Android虚拟机,注册Android的JNI函数,进入Java层。

2.Zygote的Java层:预加载资源(包括主题资源,共享库等),fork出SystemServer,然后进入loop循环.

 

Zygote注意事项:

Zygote的IPC没有采用Binder机制,而是Socket,所以我们应用的Binder机制不是从Zygote继承过来的,而是应用程序创建之后自己启动的Binder机制。

 

孵化应用进程为什么不交给SystemServer来做,而让Zygote来做?

因为SystemServer主要用来提供系统服务,比如AMS,PMS等,如果SystemServer直接孵化应用进程的话,应用进程也会继承这些并不需要的服务,同时职责也变得混乱。

Zygote的IPC通信机制为什么不采用Binder机制?如果这样做有什么问题?

1.Zygote与IPC通信对象systemServer或应用进程为父子关系,使用socket更合适,反而使用binder机制反而复杂繁琐。

2.如果这样做,Zygote和systemServer都有binder机制,会导致相关资源冲突,比如描述符,映射内存。

 

Zygote工作流程图如下:

Android剖析Framework_第1张图片

 

Android系统启动流程?

init.rc里面需要加载的进程有zygote,servicemanager,surfaceflinger和media等。主要需要了解zygote的启动流程,如上。还要了解systemserver的启动流程。下面来看看systemserver启动流程。

zygote启动systemserver进程后,在systemserver进程中初始化相关系统服务AMS,PMS,包括启动bind线程。因为systemserver里面的系统服务需要与我们的应用进程通信,而通信就是通过bind机制。还包括调用Java类的入口函数main(),在main()函数里面加载loop,共享库,创建上下文等。

系统服务是怎么启动的?

把系统服务的binder注册到serviceManager里面,通过这种方式发布系统服务。系统服务跑在什么线程?bind线程。

systemServer启动系统服务时怎么解决相互依赖?

分批启动,分阶段启动。

 

如何使用系统服务?

通过getSystemService(name)方法获取ServiceFetcher,并调用其getService方法。

如何注册系统服务?

通过调用ServiceManager的addService方法。

什么时候注册的系统服务?

SystemServer启动的时候。系统服务不完全是在SystemServer进程里面,还有一小部分单独开辟进程,比如ServiceManager。

系统服务和bind的应用服务有什么区别?

启动方式上的区别:系统服务大部分跑在SystemServer进程里面,也是在SystemServer里面启动的,如AMS,WMS,PMS。大部分服务跑在binder线程,少部分服务才跑在自己的工作线程。这里启动服务主要是服务初始化工作。而应用服务是客户端主动请求。

注册方式上的区别:先看系统服务的注册,无论是跑在SystemServer进程,还是独立进程,都要把binder实体对象注册到ServiceManager,是在启动的注册。而应用服务则是客户端向AMS发起bindService调用,AMS根据该bind对象是否已经注册进行不同的处理。

使用方式上的区别:系统服务通过上下文的getSystemServer()方法。而应用服务通过bindService发送请求,然后通过回调返回binder。

ServiceManager的启动:

1.启动进程:init进程读取init.rc配置文件,然后开启ServiceManager进程。

2.启用binder机制:

3.发布自己的服务:

4.等待并响应请求:

进程启动方式:

1.fork,子进程共享父进程资源

2.fork + execve(path,...),子进程资源由path指定。

什么时候触发应用进程启动?

启动组件时,如果没有该组件所在的进程没有启动,则启动进程,这是由framework层实现。

 

如何启动应用进程,即APP?

当我们启动应用组件(比如Activity)时,如果应用进程还未启动,则通过binder调用向AMS请求启动应用进程, AMS通过socket向zygote发消息,zygote收到消息后去启动应用进程。zygote fork出应用进程后,执行ActivityThread的main函数。应用进程启动后向AMS报告,注册ApplicationThread。

 

如何启动binder机制?

binder启动时机,应用进程启动流程中,zygote启动应用进程后,应用进程自己启动了binder机制。

1.打开binder驱动;

2.映射内存,分配缓冲区;

3.注册binder线程;

4.进入binder loop;

 

谈谈你对Application的理解。

Application的作用。

1.保存应用的全局变量。

2.初始化操作。

3.提供应用上下文。应用开启几个进程,就创建几个Application对象。

Application的继承关系。

Application继承ContextWrapper,ContextWrapper继承Context。

Application的生命周期。

1.Application构造函数。

2.attachBaseContext,获取上下文的方法,因此如果在上面Application构造方法里面使用了上下文就会报错。

3.onCreate。

注意,如果在Application里使用static静态变量,如果APP出现“内存重启”(由于系统内存不够,可能会回收Application和Activity),重启后该静态变量的值可能未初始化,可能导致bug。

 

谈谈对Context的理解

Application继承关系:Application继承ContextWrapper,ContextWrapper继承Context。

Application调用顺序:先调用Application构造函数,然后调用attachBaseContext,最后调用onCreate。

Activiy的继承关系:Activity继承ContextThemeWrapper,ContextThemeWrapper继承ContextWrapper。

Activiy调用顺序:先调用Activiy构造函数,然后调用attachBaseContext,最后调用onCreate。

Service继承关系:Service继承ContextWrapper,ContextWrapper继承Context。

Service调用顺序:先调用Service构造函数,然后调用attachBaseContext,最后调用onCreate。

第一个问题:应用里面有多少个Context?不同的Context之间有什么区别?

只有Application,Activity和Service有Context,而广播和ContentProvider没有。所以,Application,Activity和Service这三者的数量加起来,就是Context的数量。Activity由于需要显示UI,所以继承的是ContextThemeWrapper,而Application和Service继承的是ContextWrapper。

第二个问题:Activity里面的this和getBaseContext有什么区别?

this返回的是Context。 getBaseContext返回的是ContextWrapper里面的mBase。

第三个问题:getApplication和getApplicationContext有什么区别?

都是返回Application对象,getApplicationContext是Context里面的抽象方法,而getApplication是Activity和Service特有的,在别的地方不能用,比如广播不能用。

第四个问题:应用组件的构造函数,attachBaseContext,onCreate的调用顺序?

先调用构造函数,然后调用attachBaseContext,最后调用onCreate。

第五个问题:Context的作用。

Context是组件的上下文,便于访问系统资源,调用系统服务等。

 

Activity的启动流程?

创建Activity对象,获取Application,创建ContextImpl,attach上下文,生命周期回调onCreate()以及其他。

第一个问题:启动Activity会经历哪些生命周期回调?

第二个问题:冷启动大致流程,涉及哪些组件,通信过程是怎样的?

第三个问题:启动过程中,生命周期的回调原理?

Android剖析Framework_第2张图片

 

Activity的显示原理?

WMS给应用端的Window分配并管理Surface,当应用端在Surface绘制完后,SurfaceFlinger就把Surface的

这些图像数据根据WMS提供的数据来进行合成,最后写到屏幕的缓冲区显示出来。

DecorView对应一个ViewRootIml对象(负责DecorView的绘制),这个ViewRootImp对象能和WMS通信,ViewRootImp通过IWindowSession

向WMS发起binder调用,而WMS通过IWindow向ViewRootImp发起binder调用。

第一个问题:PhoneWindow是什么,怎么创建的?

第二个问题:setContentView的原理,DecorView是什么?

第三个问题:ViewRoot是什么?有什么作用?

第四个问题:View的显示原理是什么?WMS发挥什么作用?

Android剖析Framework_第3张图片

 

应用的UI线程是怎么启动的?

第一个问题:什么是UI线程?

UI线程就是刷新UI所在的线程,而且是单线程。

UI线程==主线程吗?

对于Activity来说,UI线程就是主线程。

对于View来说,UI线程就是View对应的VIewRootImpl创建时所在的线程。

Activity的DecorView对应VIewRootImpl是在主线程创建的。 

因此,如果VIewRootImpl不是在主线程创建,也可以刷新UI。

第二个问题:UI线程的启动流程,消息循环是怎么创建的?

第三个问题:了解Android的UI显示原理,UI线程和UI之间是怎么关联的?

 

Service启动原理

Android剖析Framework_第4张图片

 

BinderService绑定原理

应用向AMS发起bindService调用,如果binder句柄存在,则AMS直接回调binder句柄,然后应用拿到bindre句柄去调用Service。

如果应用向AMS发起bindService调用时,binder句柄不存在,则AMS先向Service请求binder句柄,Service返回binder句柄给AMS,然后AMS回调binder句柄给应用,应用拿到bindre句柄去调用Service。当然,这个流程的前提是Service已经存在,如果Service不存在,则进入启动Service流程。

Android剖析Framework_第5张图片

动态广播的注册和收发原理

Android剖析Framework_第6张图片

1.注册广播封装了一个binder到AMS;

2.发广播的时候通过intent找到对应的receiver;

3.普通动态广播在系统端是并行分发,应用端串行分发;

 

静态广播是怎么注册的?

先在配置文件配置广播,然后android系统启动的时候,PMS扫描所有应用的配置文件,解析里面的广播,然后注册到PMS里面。静态广播是串行分发的,如果应用进程未启动,则先启动应用进程,如果分发超时,则废弃该广播。

 

Content Provider启动原理

应用A向AMS请求provider的binder对象,如果provider组件没有启动,则先启动该组件。provider启动后通过attachApplication向AMS报告自己启动完毕,AMS收到后向provider发起bindApplication让provider创建application同时初始化provider。然后provider通过publishContentProvider将binder对象发布给AMS,AMS收到后将该binder对象返回给应用A。应用A就可以向provider发起CRUD调用。流程图如下:

Android剖析Framework_第7张图片

应用A向AMS请求provider的binder对象,如果provider已经启动,则AMS通过scheduleInstallProvider初始化Binder,然后将Binder对象发布给AMS,然后AMS将Provider返回被应用A。

Android剖析Framework_第8张图片

 

 

屏幕刷新机制

首先View调用requestLayout()方法要重绘,也就是把Runnable放入choreographer的消息队列,choreographer并没有马上去处理该消息,而是向SurfaceFliger请求下一个Vsync信号,当下一个Vsync信号到来时向choreographer发通知,choreographer收到该通知后才处理消息队列里的消息。流程如下:

Android剖析Framework_第9张图片

丢帧一般是什么原因引起的?

主线程有耗时操作,耽误了 View的绘制。

Android刷新频率60帧每秒,每隔16ms调用onDraw绘制一次?

刷新频率是指Vsync发出的频率,但不一定每次都去绘制。需要应用层主动发起绘制,在下一个Vsync信号来临时才绘制。

 onDraw完后屏幕会立即刷新吗?

不会,要等下一个Vsync信号。 

如果界面没有重绘,还会每隔16ms刷新屏幕吗?

会,只是看不出来。界面没有重绘表示应用层不会收到Vsync信号,但是屏幕还是每隔16ms发出Vsync信号。

如果在屏幕快要刷新的时候才去绘制会丢帧吗?

不一定,要等下一个Vsync信号。

 

Android Framework用到了哪些IPC方式?

1.管道:两次拷贝,半双工,单向,一般在父子进程之间使用,一般用于数据量不大的跨进程通信。

2.socket通信,两次拷贝,全双工,既可以读,也可以写,可以用于两个无亲缘关系的进程,Zygoge与AMS通信使用了socket。

3.共享内存,很快,不需要拷贝,可以用于两个无亲缘关系的进程,适用于进程间大数据传输,如图像。

4.信号,单向的,发出去后就不管了,只能带一个信号,不能带别的参数。知道进程的pid就能发信号。比如杀掉应用进程就使用了信号。

 

 

 

 

 

你可能感兴趣的:(安卓开发进阶系列)