View的加载过程

window加载视图的过程

activity的启动过程：

App1进程startActivity -> AMS startActivity -> AMS socket zyogte孵化app2进程 -> app2进程触发activityThread main函数->handlerThread，looper，context，contentProviders，Application准备好->launcherActivity

在launcherActivity的过程中：

会通过classLoader创建出对应的activity。在attach函数里面，创建PhoneWindow。

一个activity或者Dialog会包含一个PhoneWindow，里面创建了DecorView，然后把app xml布局我们app层的view都是贴在decorView里面的。

进程里面的Window，ViewRootImpl都在WindowManagerGlobal里面管理。

它会跟WMS交互。

WMS里面addView，就是校验和分组token，type，创建WindowState，对window层级。

同时，ViewRootImpl里面setView，requestLayout，scheduleTraversals()

View的绘制流程

performTraversal()

​ performMeasue()

​ performLayout()

​ performDraw()

真实5个过程：

1. 预测量阶段performTraversals

   measureHierarchy最后也是调用了performMeasure过程，多了协商的过程。

2. 窗口布局阶段relayoutWindow

3. 测量过程performMeasure

   View的递归遍历View树

   getMeasuredWidth生效

4. 布局过程performLayout

   getWidth生效

5. 绘制过程performDraw()

activity，window，view的关系

activity主要是管理生命周期

window是View的容器，这样的话，activity跟View解耦，windowManger才是真实管理View的。

activity与window就是生命周期与key，touch事件回调

window与view是处理管理

Surface图形系统

其中每一层之间的数据传递是使用Buffer（缓冲区）作为载体, 上层和surfaceFlinger间的buffer为图形缓冲区，framework与显示屏间的buffer是硬件帧缓冲区。

ViewRootImpl发起performTravesal绘制View的流程：

measure，layout，draw，最后就是调用图形处理引擎。skia，或者opengl es。

一个window，对应一个Surface，其实在ViewRootImpl里面，app进程中，hardwareRender。

Surface

上层app通过Surface获取buffer，供上层绘制，绘制过程通过Canvas来完成，底层实现是skia引擎，绘制完成后数据通过Surface被queue进BufferQueue, 然后监听会通知SurfaceFlinger去消费buffer, 接着SurfaceFlinger就acquire数据拿去合成, 合成完成后会将buffer release回BufferQueue。如此循环，形成一个Buffer被循环使用的过程。

所以Surface主要干两件事：获取Canvas来干绘制的活。申请buffer，并把Canvas最终生产的图形、纹理数据放进去。

SurfaceFlinger

System_server进程中的一个线程服务。接收所有surface作为输入。创建layer（BufferQueue）与Surface一一对应。计算每个layer最终合成图像，交给HWComposer或者openGL栅格化数据，最终framebuffer上。

Layer

Layer是SurfaceFlinger 进行合成的基本操作单元，其主要的组件是一个 BufferQueue。Layer在应用请求创建Surface的时候在SurfaceFlinger内部创建，因此一个Surface对应一个 Layer。Layer 其实是一个 FrameBuffer，每个 FrameBuffer 中有两个 GraphicBuffer 记作 FrontBuffer 和 BackBuffer。

HWComposer

Cpu合成还是GPU合成，显示。

Vsync & Buffer个数

一个buffer，撕裂，因为同时写入同时读取；

2个buffer，不会撕裂，但是卡顿，cpu、gpu利用率偏低；因为来一个vsync信号生成一次

3个buffer，避免1个buffer同时需要上屏显示使用不能被修改，2个buffer正在cpu和gpu处理中，弄出第三个可以在vsync来的时候，立刻开始合成。提升cpu、gpu的利用率，减少卡顿发生。但仍然需要引入延迟。

Choreographer

因为vsync其实是给硬件帧缓冲区发信号的。于是android加了上层也能接收屏幕vsync信号的。

向surfaceFlinger注册DisplayEventReceiver。又配合handler里面的屏障机制，优先绘制UI，而不是我们其他的事件。