由此可见，通常情况下，一个 Activity 的 UI 渲染本质是 系统提供一块内存，并创建一个图形缓冲区进行维护；这块内存就是 Surface，最终页面所有 View 的 UI 状态数据，都会被填充到同一个 Surface 中。
截至目前一切正常，但需要指出的是，现有图形系统的架构设计中还藏了一个线程相关的 隐患 。
二、设计起源
1.线程问题
问题点在于：我们还需保证 Surface 内部 Buffer 缓冲区的 线程安全。
这样的描述，对于读者似乎太过飘渺，但从结论来说，最终，一条 Android开发者 耳熟能详 的规则因此而诞生：
主线程不能执行耗时操作。
我们知道， UI 的所有操作，一定会涉及到视图（View 树) 内部大量状态的维护，而 Surface 内部的缓冲区也会不断地被读写，并交给系统渲染。因此，如果 UI 相关的操作，放在不同的线程中执行，而多线程对这一块内存区域的读写，势必会引发内部状态的混乱。
为了避免这个问题，设计者就需要通过某种手段保证线程同步（比如加锁），而这种同步所带来的巨大开销，对于开发者而言，是不可接受的。
因此，最合理的方案就是保证所有UI相关操作都在同一个线程，而这个线程也被称作 主线程 或 UI 线程。
现在，我们将UI操作限制到主线程去执行，以解决了本小节开始时提到的线程问题，但开发者仍需小心—— 众所周知，主线程除了执行UI相关的操作之外，还负责接收各种各样的 输入事件（比如触摸、按键等），因此，为了保证用户的输入事件能够及时得到响应，我们就要保证 UI 操作的 稳定高效，尽可能避免耗时的 UI 操作。
2.动机
挑战随之而来。
当渲染的缓冲数据来自外部的其它系统服务或API时——比如系统媒体解码器的音视频数据，或者 Camera API 的相机数据等，这时 UI 渲染的效率要求会变得非常高。
开发者有了新的诉求：能否有这样一种特殊的视图，它拥有独立的 Surface ，这样就可以脱离现有 Activity 宿主的限制，在一个独立的线程中进行绘制。
由于该视图不会占用主线程资源，一方面可以实现复杂而高效的 UI 渲染，另一方面可以及时响应用户其它输入事件。
因此，SurfaceView 应运而生：与常规视图控件不同，SurfaceView 拥有独立的 Surface，如果我们将一个 Surface 理解为一个层级 （Layer)，最终 SurfaceFlinger 会将前后两者的2个 Layer 进行 合成 和 渲染 ：
————————————————
