Android与IOS渲染流程对比

た入场券 2024-02-20 03:46 16阅读 0赞

**目录**

Android

CPU计算图元信息

GPU干预 几何阶段等后处理

--------------------

#### Android ####

APP通过WindowManager统一提供所有Surface的缓冲区【不管是SurfaceView还是普通的布局流程都会将数据提交到Surface的BufferQuene中】 Java中的Surface是null，最终都是由Native层的Surface处理。

> Native中的Surface持有的一个接口用于和bufferQuene交互，渲染到Surface上，其实是渲染到了BufferQuene中的GraphicBuffer，通过接口将GraphicBuffer提交到BufferQuene中

> 通过canvas的操作之前的版本渲染是在主线程执行会耗时卡死主线程，后续通过RenderThrad（FM层）单独处理渲染，主线程耗时操作不影响渲染处理，渲染过程中**会使用到OPENGl 系统进程接收到BufferQuene之后SurfaceFlinger统一合成多个Surface也就是Layer**。

SurfaceFliger通过OpenGl生成图层放到缓冲区frameBuffer中，hwcomposer取出frameBuffer进行再次处理并放置到frameBuffer中。

Graph Core用于分配图形缓冲区，Display用于取出缓冲区数据进行展示

#### CPU计算图元信息 ####

> **IOS的UIView对应一个CaLayer，Android的一个Window对应一个Surface（Surface也可由SurfaceView申请创建）**

IOS的CALayer中有content属性存储要显示的bitmap数据（可由纹理2D图片直接使用），数据来源是由视图树的测量布局，渲染提交后将数据打包发送给RenderServer进程处理，RenderServer进程解析包，将其提交到缓冲区中，GPU进行读取进行几何阶段后面的处理

#### GPU干预 几何阶段等后处理 ####

Android的是WindowManager将计算出所有的Window（Surface），也是通过CPU计算图元信息【测量布局绘制】，Surface中有一个BufferQuene类似于CALayer的content属性。

> CPU计算图元信息的时侯只记录操作指令，具体的渲染操作由FM层维护的RenderServer线程去渲染通过openGl比较耗时 。

WindwoManager将所有信息给到SurfaceFlnger后，SurfaceFlinger先自己通过opengl操作一部分数据放到frameBuffer中，再通过hwComposer具体的合成策略去合成图层（本质也是几何阶段后面的处理），GraphCore用于分配图形缓冲区 Andrid和ios原理大致一样 都是CPU计算图元信息，IOS通过RenderServer进程去处理渲染，Android是FM层的RenderServer线程去处理渲染操作。 图元计算完成后都是GPU去取数据进行几何阶段后面的处理 。 Android除了用canvas设置Surface内容也可以使用OPENGL设置Surface。