原文地址为：https://www.jianshu.com/p/9755da0f4e8f
Android 显示过程可以简单概括为：Android 应用程序把经过测量、布局、绘制后的 surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上， 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。
我们都知道在 Android 的每个 View 绘制中有三个核心步骤：Measure、Layout、Draw。具体实现是从 ViewRootImp 类的performTraversals() 方法开始执行，Measure 和 Layout都是通过递归来获取 View 的大小和位置，并且以深度作为优先级，可以看出层级越深、元素越多、耗时也就越长。
真正把需要显示的数据渲染到屏幕上，是通过系统级进程中的 SurfaceFlinger 服务来实现的，那么这个SurfaceFlinger 服务主要做了哪些工作呢？如下：
-
响应客户端事件，创建 Layer 与客户端的 Surface 建立连接。
-
接收客户端数据及属性，修改 Layer 属性，如尺寸、颜色、透明度等。
-
将创建的 Layer 内容刷新到屏幕上。
-
维持 Layer 的序列，并对 Layer 最终输出做出裁剪计算。
既然是两个不同的进程，那么肯定是需要一个跨进程的通信机制来实现数据传递，在 Android 显示系统中，使用了 Android 的匿名共享内存：SharedClient，每一个应用和 SurfaceFlinger 之间都会创建一个SharedClient ，然后在每个 SharedClient 中，最多可以创建 31 个 SharedBufferStack，每个 Surface 都对应一个 SharedBufferStack，也就是一个 Window。
一个 SharedClient 对应一个Android 应用程序，而一个 Android 应用程序可能包含多个窗口，即 Surface 。也就是说 SharedClient 包含的是 SharedBufferStack的集合，其中在显示刷新机制中用到了双缓冲和三重缓冲技术。最后总结起来显示整体流程分为三个模块：应用层绘制到缓存区，SurfaceFlinger 把缓存区数据渲染到屏幕，由于是不同的进程，所以使用 Android 的匿名共享内存 SharedClient 缓存需要显示的数据来达到目的。
除此之外，我们还需要一个名词：FPS。FPS 表示每秒传递的帧数。在理想情况下，60 FPS 就感觉不到卡，这意味着每个绘制时长应该在16 ms 以内。但是 Android 系统很有可能无法及时完成那些复杂的页面渲染操作。Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。如果某个操作花费的时间是 24ms ，系统在得到 VSYNC 信号时就无法正常进行正常渲染，这样就发生了丢帧现象。那么用户在 32ms 内看到的会是同一帧画面，这种现象在执行动画或滑动列表比较常见，还有可能是你的 Layout 太过复杂，层叠太多的绘制单元，无法在 16ms 完成渲染，最终引起刷新不及时。
卡顿根本原因
根据Android 系统显示原理可以看到，影响绘制的根本原因有以下两个方面：
-
绘制任务太重，绘制一帧内容耗时太长。
-
主线程太忙，根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧。
绘制耗时太长，有一些工具可以帮助我们定位问题。主线程太忙则需要注意了，主线程关键职责是处理用户交互，在屏幕上绘制像素，并进行加载显示相关的数据，所以特别需要避免任何主线程的事情，这样应用程序才能保持对用户操作的即时响应。总结起来，主线程主要做以下几个方面工作：
-
UI 生命周期控制
-
系统事件处理
-
消息处理
-
界面布局
-
界面绘制
-
界面刷新
除此之外，应该尽量避免将其他处理放在主线程中，特别复杂的数据计算和网络请求等。