1、概述
本篇文章不会从源码的角度去分析Android系统显示的实现细节，而是从理论的角度去讲解，参考的资料是一些博客和书籍，如有错误的地方，欢迎指正。写博客的目的是加深自己的理解，同时也是将自己的所学分享给大家，共同进步，只有我们首先知道了大致的原理，然后参考具体代码实现，相信更加容易看懂代码。
2、显示原理
2.1 显示原理概述
Android 的显示过程可以简单概括为：应用程序把经过测量、布局、绘制后的surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上，通过 Android 的刷新机制来刷新数据。
应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕。
如果从源码的角度分析，Android 的图形显示系统采用的是Client/Server 架构。SurfaceFlinger（Server）由 C++代码编写。Client 端代码分为两部分，一部分是由 Java 提供给应用使用的 API，另一部分则是由 C++写成的底层具体实现。
2.2 应用层View的绘制流程
有过Android开发经验的都知道，View的整个绘制流程中会回调三个重要的方法，分别是测量（onMeasure）、布局（onLayout）和绘制（onDraw），这三个方法各司其职。
- 测量（onMeasure）
主要用来控制当前View或ViewGroup的大小，如果是ViewGroup会递归获取子View，先去测量子View的大小。
- 布局（onLayout）
这个方法有点特殊，他其实并不是控制当前View在父View的显示位置，而是控制当前View中的子View显示位置。如果我们自定义了一个MyView 继承至View，即便我们修改onLayout中的left、right、top、buttom的值，并不能改变MyView在父ViewGroup中的显示位置。如果我们自定义一个MyViewGroup 继承至 ViewGroup，则必须要复写onLayout，如果需要控制子View的显示位置，则可以在onLayout中获取子View， 然后调用子View的layout方法即可。
- 绘制（onDraw）
目前 Android 支持了两种绘制方式：软件绘制（CPU）和硬件加速（GPU），其中硬件加速在 Android 3.0 开始已经全面支持。
2.3 系统层的渲染原理
真正把需要显示的数据渲染到屏幕上，是通过系统级进程中的 SurfaceFlinger 服务来实现的。系统层server端主要工作如下：
两个不同进程，那么肯定需要一个跨进程的通信机制来实现数据传输，在 Android的显示系统，使用了 Android 的匿名共享内存：SharedClient，每一个应用和 SurfaceFlinger之间都会创建一个 SharedClient，SharedClient 包含的是 SharedBufferStack 的集合。因为最多可以创建 31 个 SharedBufferStack，这也意味着一个 Android 应用程序最多可以包含 31 个窗口。
总结
显示整体流程分为三个模块：应用层绘制到缓存区，SurfaceFlinger 把缓存区数据渲染到屏幕，由于是两个不同的进程，所以使用 Android 的匿名共享内存 SharedClient，缓存需要显示的数据来达到目的。
3、系统的刷新机制
首先需要了解一个名词：FPS。FPS（Frames Per Second）表示每秒传递的帧数。在理想情况下，60 FPS 就感觉不到卡，这意味着每个绘制时长应该在 16ms 以内。
Android 系统每隔16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。
如果某个操作花费的时间是 24ms，系统在得到 VSYNC 信号时就无法进行正常渲染，这样就发生了丢帧现象。那么用户在 32ms 内看到的会是同一帧画面，从而感觉卡顿。
参考链接
《Android应用性能优化最佳实践》
https://www.jianshu.com/p/8df89e9dd67d
https://blog.csdn.net/qq_43666827/article/details/87353184
