Native 层数据结构之间的关系

2016-7-31 chenhui Surface

在阅读本文前,请先阅读:Java 层数据结构之间的关系


之前说过,一个 Surface 和一个显示层(Layer)一一对应,也和 Activity 一一对应。所以,在 Activity 和 WMS 建立起连接后,WMS 就会开始在 Native 层创建 Surface 对象,


WMS 创建的 Surface 对象,其实实际上最终服务的,还是 Activity 的 Surface 对象。他在 Native 层有一个 SurfaceControl 对象,WMS 的 Surface 通过这个对象和 Activity 的 Surface 对象进行通信。WMS 还有一个 SurfaceComposerClient 对象,这个对象十分重要。他和 SF 有两个通道,其中 BpSurfaceFlingerClient 就是通知 SF 混合显示层的。


SurfaceComposerClient 有一个 Client 对象,这个对象下面有一个 MemoryHeadBase MemoryHeadBase 是一片共享内存,在这片共享内存中,又包含了一个 SharedClient 对象,他有一个 SharedbufferStack[31] 数组。


这个数组是干嘛用的?很简单,就是控制显示层的读写的,每一个元素可以控制一个显示层,总共能控制 31 个。那么,怎么控制?


之前说过,Activity 把数据写到显示层,而 SF 从显示层中读取数据,显示层有两个内存可供读写。那么,他们怎么知道自己该读哪个内存?又怎么知道该写哪个内存?这就是通过他来实现的。对于 Activity 而言,他要通过 SharedBufferClient 来写一个显示层;对于 SF 而言,他要通过 SharedBufferServer 来读一个显示层。其中的调度,就通过 SharedBufferStack 来做。


我们可以发现,Activity 的 Surface 对象和显示层都有一个 GriphicBuffer[2] 这个数组,这两个数组中的 GriphicBuffer 对象就是控制显示层的缓存的,实际上,这两个数组中的 GriphicBuffer 对象映射的是同一片内存,这样 Activity 和 SF 才能快速有效地读写显示层。


基本上就这么一回事吧,要说详细的话,太复杂了,但若要了解大致流程,可阅读:Surface 总结:绘制流程总图




发表评论:

Copyright ©2015-2016 freehui All rights reserved