根据当前的设想，我们针对 SurfaceView 设计思路进行细化。
首先，我们需对现有的视图树结构进行改造。为了便于使用，我们允许开发者将 SurfaceView 直接加入到现有的视图树中（即作为控件，它受限于宿主 View Hierachy的结构关系），但在系统服务端中，对于 SurfaceFlinger 而言，SurfaceView 又是完全与宿主完全分离开的：
在上图中，我们可以看到，在 z 轴上，SurfaceView 默认是低于 DecorView 的，也就是说，SurfaceView 通常总是处于当前页面的最下方。
这似乎有些违反直觉，但仔细考虑 SurfaceView 的应用场景，无论是 Camera 相机应用、音视频播放页，亦或者是渲染游戏画面等，SurfaceView 承载的画面似乎总应该在页面的最下面。
实际设计中也是如此，用来描述 SurfaceView 的 Layer 或者 LayerBuffer 的 z 轴位置默认是低于宿主窗口的。与此同时，为了便于最底层的视图可见， SurfaceView 在宿主 Activity 的窗口上设置了一块透明区域（挖了一个洞）。
最终，SurfaceFlinger 把所有的 Layer 通过用统一流程来绘制和合成对应的 UI。
在整个过程中，我们需更进一步深入研究几个细节：
SurfaceView 与宿主视图树结构的关系，以及 挖洞 过程的实现；
SurfaceView 与系统服务的通信创建 Surface的实现；
SurfaceView 具体绘制流程的实现。
三、施工
- 视图树与挖洞
一句话总结 SurfaceView 与视图树的关系： 在视图树内部，但又没完全在内部 。
首先，SurfaceView 的设计依然遵循 Android 的 View 体系，继承了 View，这意味着使用时，它可以声明在 xml 布局文件中：
————————————————
