主页 - Sharry's blog

前言

我们平时开发的过程中最常打交道的是 View 和 Window, 他们是能够呈现视图的关键所在, 这里我们以 Activity 的启动为例, 从如下三个方面来了解一下图形渲染的准备过程

Window 的创建与初始化
为 Window 填充 View
与 WMS 建立联系

下面我们一一分析

前言

Android 的图像处理架构是非常庞大且复杂的, 并且经历了好几个版本的变更, 相关信息如下

Android 版本	渲染变更
Android 3.0 阶段	开始支持硬件加速
Android 4.0 阶段	默认开启硬件加速
Android 4.1 阶段	1. 引入了 VSYNC 垂直同步信号 2. Triple Buffering 三缓冲机制(为了解决 A 帧被屏幕占用, B 帧被 GPU 占用, CPU 此时无法准备下一帧的问题)
Android 4.2 阶段	开发者选项中引入了过度渲染监控工具
Android 5.0 阶段	1. 引入了 RenderNode 来保存 View 的绘制动作 DisplayList 2. 引入了 RenderThread, 所有的 GL 命令都在 RenderThread 中进行, 减轻了 UI 线程的工作量
Android 7.0 阶段	引入了 Vulkan 的硬件渲染引擎

前言

通过 Step 2 我们知道, Activity 的启动第二阶段会

先创建要启动 Activity 的进程
进程创建成功后会调用 AMS.attachApplication 通知 AMS 这个进程初始化完成了

这篇文章我们从 AMS 的 attachApplication 方法看起, 走完 Activity 创建的整个流程

前言

通过 Step 1 我们知道, Activity 的启动会

通知 Client 进程将请求的 SourceActivity 置为 Paused 状态
通知 AMS 所在进程, SourceActivity 已经 Pause 成功了
调用 ActivityStackSupervisor.resumeFocusedStackTopActivityLocked 继续执行目标 Activity 的启动
- 这个方法我们上面分析过, 它内部会回调 ActivityStack.resumeTopActivityInnerLocked 来激活当前栈顶的 Activity, 即我们的 TargetActivity

接下来就看看 resumeTopActivityInnerLocked 的实现

前言

在 SystemServer 进程启动的的学习中, 我们知道当所有的服务都准备好了之后, AMS 的 systemReady 会启动 Launcher 这个应用程序

不过 Launcher 的启动比起我们日常使用 Activity 的启动要少了一些步骤, 这里我们以最普通的 Activity 跳转进行分析

前言

之前的文章介绍了 IMS 的启动过程, 也了解了 IMS 的事件分发与窗体是息息相关的, 这里我们就来学习一下 WMS 的启动流程

前言

从 SystemServer 启动的分析中我们得知, 在其 startBootstrapServices 方法中, 启动引导服务的过程中, 会优先启动 AMS

前言

在分析 Zygote 启动的时候, 我们注意到它调用了 ZygoteInit.forkSystemServer 函数来创建系统服务进程

这里我们追踪一下系统服务进程的创建, 在此之前我们先回顾一下 SystemServer 进程的发起

主页

Android 系统架构 —— 图形渲染的准备

前言

Android 系统架构 —— 图形架构篇概览

前言

Android 系统架构 —— Activity 的启动之目标的启动

前言

Android 系统架构 —— Activity 的启动之应用进程的启动

前言

Android 系统架构 —— Activity 的启动之请求方的暂停

前言

Android 系统架构 —— WMS 的启动

前言

Android 系统架构 —— AMS 的启动

前言

Android 系统架构 —— SystemServer 进程的启动

前言