1.zygote进程。
由init进程fork出来。
zygote主要有两个作用,启动systemserver进程和fork子进程。 WMS,AMS,PMS等都运行在systemserver进程中。而我们平常的app进程则是由zygote进程fork出来。
为什么zygote在fork子线程的时候需要单线程?
fork的原理就是copy-on-write机制。zygote进程中已经启动了jvm虚拟机,类预加载资源等。在fork的时候可以继承父进程的资源。但是fork只支持单线程,不支持多线程。zygote在创建子进程的时候,只能有一个线程,负责可能会出现死锁或者资源不同步等问题。而父进程里有很多线程。zygote在fork子进程的时候,先将父进程主线程外的其余的线程停掉,等fork进程完毕之后再启动。 但是有一点需要强调的是,zygote进程可不是单线程,因为它还有守护线程再运行。
为什么不直接用systemserver来孵化呢
1.从架构设计原则来看,尽量做到类或者模块单一原则。
2.从功能实现上看.在fork进程的时候,子继承会继承父进程的一些资源。 我们在启动一个新继承的时候需要最很多的准备。如创建虚拟机,加载各种资源等。这些如果提前加载的话,则可以大大优化进程的创建流程。 systemserver进程主要是用来孵化各种个样的服务,是不能继承到子进程中去的。我们在启动进程的时候,除了一些必备的资源,其它最好是干净的。 所以系统创建了一个zygote进程。既满足了fork子进程时候高效的目的,同时也做到了模块功能的单一和解耦。
zygote的IPC采用的是socket,而不是binder
1.多线程问题 fork子线程时候为了避免死锁,需要单线程环境。而binder是多线程,在fork子线程时候容易出死锁的问题。
2.binder调用比较麻烦。 如果zygote用binder进行通信,需要打开binder驱动,获取文件描述符,mmap内存映射,同时创建binder对象到serviceManager。同时再调用的时候还要从serviceManager中查询binder对象。几个来回比较麻烦。而zygote和systemServer进程本来就是父子关系,对于这种简单的消息,socket比较方便。
3.MMAP数据复写 如果zygote采用binder来fork出systemserver进程的话,那systemserver会继承zygote的描述符和内存映射。这两个进程在binder驱动层会共用一套数据结果。子进程的copy-on-write会造成地址空间重新映射。而子进程还在访问之前的父进程mmap地址,从而引发SIGSEGV、SEGV_MAPERR等错误
2. Android系统的启动
Android系统启动整体比较复杂。主要节点可简单介绍为。 1.init进程fork出zygote进程。zygote通过runOnce方法fork出systemserver进程和其它子进程。
2.systemserver通过startSystemServer()方法来启动。通过nativeZygoteInit()方法来启动binder。然后调用systemserver的main函数。main函数中主要有以下几个功能。
private void run(){
Looper.prepareMainLooper();
System.loadLibrary("system_service");
createSystemContext();
startBootStrapService();
startCoreService();
startOtherService();
Looper.loop();
}
系统服务怎么发布的:
publishBinderService(String name ,IBinder service),将服务注册到serviceManager里面
系统服务跑在什么线程:
displayThead,fgThread,IoThread,UIThread(这里这个UIThread是子线程),binder线程
服务间的相互依赖是怎么解决的:
分批启动:如ams,pms 分阶段启动:不同的阶段启动不同的service
启动桌面
最后调用systemReady()方法,通过startHomeActivityLocked来启动launcher
3.系统服务和bind服务区别
具体类型 | 系统服务 | bind服务 |
---|---|---|
启动方式 | 在ststemService进程的startBootStrapService();startCoreService();startOtherService();中启动 | startService(Intent intent) ,classLoader加载类,然后创建context |
注册方式 | public static void addService(String name,IBInder service){getServiceManager().addService(name,service,false)}(夸进程通信) | binder service到AMS |
注册位置 | 注册到serviceManager | 注册到AMS |
注册时机 | (1)systemService中启动各种服务时候(java方式) (2)surfaceflinger这种独立进程,通过jni添加 | 手动注册 |
使用方式 | context.getSystemService(Context.POWER_SERVICE) | binderService(serviceIntent,ServiceConnection) |
4. 进程 & binder启动
在启动进程过程中,binder通信是绕不开的一个点。 应用在启动完毕通知AMS时候是通过binder通信进行通知。而binder的启动时在zygote启动启动进程的时候。zygote在收到AMS的启动请求的时候,会调用runOnce函数
boolean runOnce(){
String args=readArgumentList();
int pid=Zygote.forkAndSpecialize(...);
if(pid==0){
handleChildProc();
return true;
}else {
// deal parentProc
}
}
在handleChildProc()中的nativeZygoteInit()中会启动binder。binder启动主要分为四个步骤
- 打开binder驱动
- 映射内存,分配缓冲区
- 注册binder线程
- 进入binder loop
5.Application
一般用来:
- 保存全局的应用变量
- 初始化操作
- 提供上下文
初始化: 从main函数跟进
public static void main(String[] args){
Looper.prepareMainLooper();
ActivityThread thread=new ActivityThread();//只是一个普通java类,不是thread
thread.attach(false);
Looper.loop();
}
在attach函数当中调用
private void attach(){
final IActivityManager mgr=ActivityManagerNative.getDefault();//AMS在应用进程的binder代理对象
mgr.attachApplication(mAppthread);//mAppthread是应用进程的binder对象,传入AMS中
}
然后在ASM中调用函数
boolean attachApplicationLocked(IApplicationThread thread){
thread.bindApplication();//IPC通信到应用进程中
}
应用进程的bindApplication函数为
public final void bindApplication(){
AppBindData data=new AppBindData();
sendMessage(H.BIND_APPLICATION,data);//抛到应用主线程去处理
}
在主线程创建Application对象并调用mInstrumentatio.callApplicationOnCreate(app); 所以Application的总体的执行顺序为
new Application() -> Application.attachBaseContext() -> Application.onCreate
不能在Application的构造函数中调用上下文
因为这个时候上下文还没有被初始化。
不要在Application的生命周期中执行耗时参数。
不同于AMS的ONEWAY(发起调用马上返回)的调用方式,Application执行耗时函数会阻塞UI线程。阻碍Application自身后续组件的初始化。
Application中使用静态变量的坑。
在Application中声明一个static Strting name;在A activity中赋值,在B activity中使用。假如此时长时间压后台,然后重新切回来的时候,Application和B activity会重新创建,但是这个时候拿到的静态变量name不会被A activity赋值,从而引发异常。 为解决这个问题,建议B activity接收name参数是用getIntent()的方式从A activity接收参数。同时在onSaveInstanceState中保存这个值。在恢复重建的时候从onCreate(Bundle savedState) 的savedState里读取
6.Context
应用中context的数量=activity数量+service数量+application数量 方便访问系统资源,调用系统服务。
application context
application继承自ContextWrapper.
public class ContextWrapper extends Context{
Context mBase;//在activity中getBaseContext时候返回。所以是context中还包含了一个context。
protected void attachBaseContext(Context base){
mBase=base;
}
public Resources getResources(){
return mBase.getResources();//静态代理。context的所有调用
//都委托给了mBase
}
}
getApplication和getApplicationContext都是返回Application全局对象。 getApplicationContext是属于Context的抽象函数。 getApplication是activity和service中特有的函数。
activity context
整体跟application的创建比较类似。但是activity是继承自ContextThemeWrapper. 代码执行也是先执行attachBaseContext,再执行onCreate; 具体创建包括
private Activity perfirmLaunchActivity(){
Activity activity=null;
activity=mInstrumenttation.newActivity();//内部通过classloader加载类
Application app=r.packageInfo.makeApplication();//获取Application对象
Context appContext =createBaseContextForActivity(r,activity);
activity.attach(appContext,app,...);//会调用attachBaseContext(context)
activity.onCreate();
return activity;
}
servixe context
继承自ContextWrapper。创建流程和perfirmLaunchActivity差不多。
BroadcaseReceiver和Context Provider的上下文由外边传入。但是Context Provider的onCreate调用是在application的onCreate之前调用,但是在application的attachBaseContext之后。
7.Activity 启动流程 & 显示原理 & UI线程
冷启动流程大致如图:
而普通的应用启动流程如下:
发送startActivity请求到AMS,AMS通过socket发送消息到zygote,zygote发送socket消息到应用进程。后边的流程如上图对应的位置
UI线程
UI线程:UI刷新所在的线程,且UI是单线程刷新的 对activity来说,UI线程就是主线程。runOnUiThread(); 对View来说,UI线程是ViewRootImpl创建所在的线程.View.post(only the origin thread that created a view hoerarchy can touch int view) 随之而来的另外一个问题就是:子线程刷新UI? 参考主线程创建:
final void handleResumeActivity(IBinder token,...){
final Activity a=r.activity:
ViewManager wm =a.getWindowManager();
wm.addView(decor,l);//该方法中会创建ViewRootImpl
}
root=new ViewRootImpl()
root.setView(view,wparams,panelParentView)
所以类似的我们也可以在子线程中刷新view
new Thread(){
public void run(){
Looper.prepare();
getWindowManager().addView(view,parmas);//可以正常显示和操作UI
Looper.loop();
}
}.start();
8.屏幕刷新
带着问题去思考
- 丢帧一般是什么原因引起的?
- Android 刷新频率是60帧/秒,每隔16ms调onDraw绘制一次?
- onDraw完之后屏幕会马上刷新吗?
- 如果界面没有重绘,还会每隔16ms刷新屏幕吗?
- 如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗?
Choreographer:编舞者(通过threadLoacl创建)
public static Choregrapher getInstance(){
return sThreadInstance.get();//不同的线程调用getInstance返回的是不同的Choreographer对象
}
requestLayout(){//在一个vsync周期内,只会执行一次刷新
scheduleTraversals();//插入同步屏障
}
绘制的时候如果跳帧严重,源码会打印出日志提示,SKIPPED_FRAME_WARNING_LIMIT默认是30
void doFram(long framTimenanos,int frame){
if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
Log.i(TAG, "Skipped " + skippedFrames + " frames! "
+ "The application may be doing too much work on its main thread.");
}
当view调用requestLayout()时候,将一个callBack传到Choreographer中,Choreographer没有直接处理callBack,而是先向SurfaceFlinger发送requestNextVsync请求下一个vsync信号,SurfaceFlinger在下一个vsync信号来的时候通过postSynEvent通知给Choreographer,Choreographer收到通知后执行真正的绘制performTraversal()方法。
Choreographer作为编舞者,主要是起协调作用。将代码绘制控制到和vsync协调到一个节奏,避免在一个vsync信号的中间位置开始绘制,而是将真正绘制代码的起点和收到vsync信号的起点保持一致。从而减少卡顿。
Choreographer编舞前: Choreographer编舞后:
1. 丢帧一般是什么原因引起的?
主线程耗时操作
2. Android 刷新频率是60帧/秒,每隔16ms调onDraw绘制一次?
刷新频率指得是vsync信号发生的频率,不一定每次vsync信号都去绘制,需要应用端主动发起重绘,然后才会向SurfaceFlinger请求接受vsync信号,然后再下次vsync信号来的时候才会去真正绘制
3. onDra完之后屏幕会马上刷新吗?
不会。要等到下次vsync信号来的时候才刷新
4. 如果界面没有重绘,还会每隔16ms刷新屏幕吗?
不发生重绘,就不会接受vsync信号,但是屏幕还是会每隔16m刷新屏幕,只不过刷新是旧的数据
5. 如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗?
不一定。我们代码中发起的绘制是要等到下次vsync信号来的时候才会执行,跟发起绘制操作的时机没有太大联系
9.surface
surface夸进程传递
- 怎么理解surface,它是一块buffer吗?
- 如果是,surface跨进程传递怎么带上这个buffer?
- 如果不是,那surface和buffer是什么关系?
- surface是怎么进行夸进程传递回应用的?
private void performTraversals(){
if(mFirst){
relayoutResult=relayoutWindow(params,...);
}
}
int relayoutWindow(WindowManager.LayoutParams params,...){
//mWindowSession是一个binder对象,像wms申请surface,所以view的绘制也涉及跨进程通信
return mWindowSession.relayout(mWindow,...mSurface);
}
WMS端创建了一个native的surface对象,并跟java层的surface对象绑定在一起。(将native层surface对象的指针保存在java层的surface对象中)。WMS端native service的核心是GraphicBufferProducer这个binder对象(简称GBP)。 所以 surface的本质是GraphicBufferProducer,而不是buffer surface夸进程传递,本质是GraphicBufferProducer这个binder对象的传递。
1. 怎么理解surface,它是一块buffer吗?
不是,它只是一个壳子,里面包含了能生产buffer对象的GraphicBufferProducer这个binder对象
2. 如果是,surface跨进程传递怎么带上这个buffer?
3. 如果不是,那surface和buffer是什么关系?
通过GraphicBufferProducer(GBP)这个binder对象来传递
4. surface是怎么进行夸进程传回应用的?
通过GraphicBufferProducer夸进程通信
surface绘制原理
-
surface 绘制的buffer是怎么来的
通过GBP向BufferQueue申请.BufferQueue是在surfaceFlinger进程中创建的双端队列。应用端的一个surface对应surfaceFlinger进程端的一个BufferQueue。通过binder跨进程通信将buffer传给应用端的surface。buffer作为canvas和bitmap的缓冲区。等canvas绘制完之后再返回给BufferQueue。BufferQueue通知consumer回调去消费,表示这一帧数据绘制好了。
-
buffer绘制完了是怎么提交的
通过GBP提交给BufferQueue(surfaceFlinger进程中)。