androidview绘制监听

1. android性能优化总结

常用的Android性能优化方法：

一、布局优化：

1）尽量减少布局文件的层级。

层级少了，绘制的工作量也就少了，性能自然提高。

2）布局重用 <include标签>

3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。

二、绘制优化：

基于onDraw会被调用多次，该方法内要避免两类操作：

1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。

2）不要做耗时操作，抢CPU时间片，造成绘制很卡不流畅。

三、内存泄漏优化：

1）静态变量导致内存泄漏   比较明显

2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。

3）属性动画导致内存泄漏  无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。

四、响应速度优化：

1）避免在主线程做耗时操作 包括四大组件，因为四大组件都是运行在主线程的。

2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。

五、ListView的优化：

1）使用convertView，走listView子View回收的一套：RecycleBin 机制

主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。

当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflater.inflate()方法了。

RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。

2）使用ViewHolder避免重复地findViewById

3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。

4）getView中避免做耗时操作，主要针对图片：ImageLoader来处理(原理：三级缓存)

5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。

六、Bitmap优化：

1）减少内存开支：图片过大，超过控件需要的大小的情况下，不要直接加载原图，而是对图片进行尺寸压缩，方式是BitmapFactroy.Options 采样，inSampleSize 转成需要的尺寸的图片。

2）减少流量开销：对图片进行质量压缩，再上传服务器。图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、线程优化：

使用线程池。为什么要用线程池？

1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”

2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销

3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。

4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。

5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。

6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel

7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。

八、一些性能优化建议：

1）避免创建过多对象，造成频繁的gc

2)不要过多使用枚举，枚举占用的空间比整型大很多

3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。

4）适当使用软引用，（弱引用就不太推荐了）

5）使用内存缓存和磁盘缓存。

2. 2022史上最全Android面试题归纳汇总（附答案解析）

我经历过这么多年的摸爬滚打，面试过也被面试过。现总结与归纳Android开发相关面试题：

1、Activity启动模式有哪些，分别有什么不同？

2、Service启动模式有哪些，对应的生命周期？IntentService呢？

3、ContentProvider的作用，是否支持多线程和多进程

4、Broadcast的注册方式，对应的生命周期是什么，有序和无序那种可以中断广播？

5、AsyncTask的作用，如何使用(包括有哪些方法，能说出同步异步，能说出不同Android版本下的区别加分）

6、有哪些异步的方式？

7、Handler机制

8、Dialog的使用及其生命周期

9、Activity的生命周期，能否改？

10、Fragment的生命周期，能否改？

11、Activity和Fragment如何通信

12、View的绘制机制

13、View的事件传递机制

14、如何监听手势

15、ImageView设置图片显示有哪几种模式，有什么区别？

16、有哪些存储方式

17、SharedPreferences是否支持多进程、多线程

别看以上常问的是入门级的，但是有两三年开发经验能回答圆满的人不多。

1、如何理解Activity的任务亲和性

2、如何让Service为单独的进程

3、IntentService的实现原理

4、LocalBroadcast的作用，实现原理，相对于Broadcast的优势在哪，劣势在哪

5、Handler的缺点，会不会造成内存泄漏，有则如何解决

6、Fragment与Activity的区别和联系

7、Fragment如何缓存布局

8、Fragment与ViewPager的搭配使用，有没有问题重叠问题，怎么解决

9、同时提供侧滑和上下滑动，如何解决事件传播问题

10、是否使用过Design包

11、嵌套滑动理解

12、behavior的原理

13、对设计模式有什么看法，经常使用的有哪些？

中级的稍微偏底层一些，这个主要考察平时是否关注而不是一味地怼业务需求

1、Activity的启动过程

2、Service创建为单独进程会有哪些问题？

3、简述AIDL的构建过程

4、IPC机制有哪些？

5、android多进程通信方式，内部原理

6、App启动的入口在哪？

7、LRU缓存算法

8、Bitmap的有哪几种压缩算法，有啥区别？

9、图片在手机本地存储大小和在内存大小是否一致，为什么，Android默认像素一般占几个字节？

10、第三方框架的熟练程度，如：

11、SharedPreference内部实现原理

12、模块化、插件话、组件化等分别有什么区别，对用有什么好处

13、说说MV * 模式，并画出做过项目的架构图

14、对跨平台方案有哪些了解，使用过哪些？ 比如RN

15、对大前端有什么看法，了解多少？使用过什么？

16、对其他语言的了解，kotlin，python、php、c++等

17、兴趣爱好是什么？对未来有什么规划？

目前是一些经常会被问到的，当然只是列举了Android 开发方向的，java的一些还没列举，比如异常、网络、多线程、JCF等等

以上问题的答案在下面都有详细解答，我们不仅整理了这些资料，而且还有一份长达"635页"的Android资料汇总：

包括：底层原理+项目实战+面试专题

虽说Android早已不像过去那般火爆，但各大厂对于中高级开发者仍旧是求贤若渴，想要获取更丰厚的薪资，打铁还得自身硬。对于框架、源码、原理、项目实操经验，都必须有足够的知识储备，才可以在面试中击败面试官。但是由于网上的资料鱼龙混杂，也不成体系，很多人在自我提升的过程中都头疼不已。 这里就给大家分享一份字节大佬整理的《Android中高级面试题汇总（2022）》，帮助大家系统的梳理中高级Android知识！里面包含了所有Android面试的知识点，刷完进大厂妥妥的 ！

(含：静态内部类和非静态内部类的比较，多态的理解与应用， java方法的多态性理解，java中接口和继承的区别，线程池的好处，详解，单例，线程池的优点及其原理，线程池的优点，为什么不推荐通过Executors直接创建线程池，创建线程或线程池时请指定有意义的线程名称，方便出错时回溯，深入理解ReentrantLock与Condition，Java多线程：线程间通信之Lock，Synchronized 关键字原理，ReentrantLock原理，HashMap中的Hash冲突解决和扩容机制， JVM常见面试题， JVM内存结构，类加载机制/双亲委托…)

（含：Activity知识点， Fragment知识点， Service知识点， Intent知识点…）

（含：屏幕适配，主要控件优化，事件分发与嵌套滚动…）

（含：MVP架构设计，组件化架构…）

（含：启动优化，内存优化，绘制优化，安装包优化…）

（含：开源库源码分析，Glide源码分析，OkHttp源码分析，Retrofit源码分析，RxJava源码分析…）

（含：开源文档，面试合集…）

3. Android ViewRootImpl

本文主要分析两个问题：
1、为什么View 的绘制流程是从 ViewRootImpl 的performTraversals()方法开始的？
2、View 的invalidate方法是怎么触发到ViewRootImpl 的performTraversals()方法的。
在阅读本文前，最好先了解window的添加过程，Android消息处理机制 和 View 的绘制流程。推荐先阅读以下文章：
Android Window和WindowManager
Android-消息机制
Android View 的绘制流程

android 源码注释的意思是：ViewRootImpl是视图层次结构的顶部，实现 View 和 WindowManager 之间所需的协议。是 WindowManager Global 的内部实现中重要的组成部分。

View 的绘制流程是从 ViewRootImpl 的performTraversals()方法开始的，那到底是哪里调用了performTraversals()方法呢，下面我们分析一下：

1.私有属性的performTraversals()方法肯定是在内部调用起来的，经过搜索找到是doTraversal()方法调用了。

2.接着找到了，调用了doTraversal() 的TraversalRunnable 类

3.内部只有一个地方实例化了TraversalRunnable 的实例mTraversalRunnable ，查到到两个方法内都调用了mTraversalRunnable ，明显 scheleTraversals 是主动触发这个 Runnable 。这就表明调用了scheleTraversals ()函数的地方都主动触发了view的刷新。

4.接着我们看一下 mChoreographer.postCallback 做了什么

可以看到，最后后走进了scheleVsyncLocked()方法内。

5.mDisplayEventReceiver 的类 是 FrameDisplayEventReceiver，继承自
DisplayEventReceiver 。

最后走到这里就没了，那么这个方法是做了什么呢，这个方法的注释是这个意思：安排在下一个显示帧开始时传送单个垂腔察直同步脉冲。意思就是，调用了这个方法可以收到系统传送过来的垂直同步脉冲信号。Android系统每隔16ms就会发送一个VSYNC信号（VSYNC：vertical synchronization 垂直同步，帧同步），触发对UI进行渲染。这个垂直同步信对于应用来说了，只有了订阅了监听，才能收到。而且是订阅一次，收到一次。

6.既然是在这个类里面订阅垂直同步信号的，那回调也应该在这里。于是找到了以下方法。

native code 调用到 onVsync，这个方法的注释解释如下：当接收到垂直同步脉冲时调用。接收者应该渲染一个帧，然后调用 {@link scheleVsync} 来安排下一个垂直同步脉冲。
这个方法的具体实现在前面分析到的FrameDisplayEventReceiver 类里面。

这里可以看到，其实mHandler就是当前主线程的handler，当接收到onVsync信号的时候，将自己封装到Message中，等到Looper处理，最后Looper处理消息基圆宽的时候就会调用run方法，这里是Handler的机制，不做解释。

7.最后，如下图调用所示，最终从mCallbackQueues取回之前添加的任务再执行run方法，也就是TraservalRunnable的run方法。

总结上面的分析，调用流程如下图所示如下：

上面我们分析到只要调用了ViewRootImpl 的scheleTraversals ()方法，最终就能调用了ViewRootImpl 的performTraversals()来开始绘制。搏亮那肯定是我们常调用的view刷新的接口，经过一系列的方法调用，最终调用了ViewRootImpl 的scheleTraversals ()方法。下面我们分析一下常用的View 的 invalidate()接口是怎么调用到了ViewRootImpl 的scheleTraversals ()方法。

可以看出，invalidate有多个重载方法，但最终都会调用invalidateInternal方法，在这个方法内部，进行了一系列的判断，判断View是否需要重绘，接着为该View设置标记位，然后把需要重绘的区域传递给父容器，即调用父容器的invalidateChild方法。
接着我们看ViewGroup#invalidateChild：

由于不断向上调用父容器的方法，到最后会调用到ViewRootImpl的invalidateChildInParent方法，我们来看看它的源码，ViewRootImpl#invalidateChildInParent:

最后调用了scheleTraversals方法，触发View的工作流程。至此，我们已经完整地分析了一次调用View 的 invalidate()方法到触发ViewRootImpl 的scheleTraversals()方法。

4. Android 如何判断一个View重绘或加载完成

1、view重绘时回调（即监听函数，当view重绘完成自动动用，需要向view的观察者添加监听器）。格式：

view.getViewTreeObserver().addOnDrawListener(new OnDrawListener() {

@Override

public void onDraw() {

// TODO Auto-generated method stub

}

});

2、view加载完成时回调（当view加载完成自动动用，需要向view的观察者添加监听器）。格式：

view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {

@Override

public void onGlobalLayout() {

// TODO Auto-generated method stub

}

});

(4)androidview绘制监听扩展阅读：

两种方式刷新：

1、主线程可以直接调用Invalidate()方法刷新

2、子线程可以直接调用postInvalidate()方法刷新。

API的描述 : Invalidatethe whole view. If the view is visible, onDraw(Canvas) will be called at somepoint in the future. This must be called from a UI thread. To call from anon-UI thread, call postInvalidate().。

API的描述译文：当Invalidate()被调用的时候，View的OnDraw()就会被调用，Invalidate()必须是在UI线程中被调用，如果在新线程中更新视图的就调用postInvalidate()。

5. Android图形渲染原理上

对于Android开发者来说，我们或多或少有了解过Android图像显示的知识点，刚刚学习Android开发的人会知道，在Actvity的onCreate方法中设置我们的View后，再经过onMeasure，onLayout，onDraw的流程，界面就显示出来了；对Android比较熟悉的开发者会知道，onDraw流程分为软件绘制和硬件绘制两种模式，软绘是通过调用Skia来操作，硬绘是通过调用Opengl ES来操作；对Android非常熟悉的开发者会知道绘制出来的图形数据最终都通过GraphiBuffer内共享内存传递给SurfaceFlinger去做图层混合，图层混合完成后将图形数据送到帧缓冲区，于是，图形就在我们的屏幕显示出来了。

但我们所知道的Activity或者是应用App界面的显示，只属于Android图形显示的一部分。同样可以在Android系统上展示图像的WebView，Flutter，或者是通过Unity开发的3D游戏，他们的界面又是如何被绘制和显现出来的呢？他们和我们所熟悉的Acitvity的界面显示又有什么异同点呢？我们可以不借助Activity的setView或者InflateView机制来实现在屏幕上显示出我们想要的界面吗？Android系统显示界面的方式又和IOS，或者Windows等系统有什么区别呢？……

去探究这些问题，比仅仅知道Acitvity的界面是如何显示出来更加的有价值，因为想要回答这些问题，就需要我们真正的掌握Android图像显示的底层原理，当我们掌握了底层的显示原理后，我们会发现WebView，Flutter或者未来会出现的各种新的图形显示技术，原来都是大同小异。

我会花三篇文章的篇幅，去深入的讲解Android图形显示的原理，OpenGL ES和Skia的绘制图像的方式，他们如何使用，以及他们在Android中的使用场景，如开机动画，Activity界面的软件绘制和硬件绘制，以及Flutter的界面绘制。那么，我们开始对Android图像显示原理的探索吧。

在讲解Android图像的显示之前，我会先讲一下屏幕图像的显示原理，毕竟我们图像，最终都是在手机屏幕上显示出来的，了解这一块的知识会让我们更容易的理解Android在图像显示上的机制。

图像显示的完整过程，分为下面几个阶段：

图像数据→CPU→显卡驱动→显卡（GPU）→显存（帧缓冲）→显示器

我详细介绍一下这几个阶段：

实际上显卡驱动，显卡和显存，包括数模转换模块都是属于显卡的模块。但为了能能详细的讲解经历的步骤，这里做了拆分。

当显存中有数据后，显示器又是怎么根据显存里面的数据来进行界面的显示的呢？这里以LCD液晶屏为例，显卡会将显存里的数据，按照从左至右，从上到下的顺序同步到屏幕上的每一个像素晶体管，一个像素晶体管就代表了一个像素。

如果我们的屏幕分辨率是1080x1920像素，就表示有1080x1920个像素像素晶体管，每个橡素点的颜色越丰富，描述这个像素的数据就越大，比如单色，每个像素只需要1bit，16色时，只需要4bit，256色时，就需要一个字节。那么1080x1920的分辨率的屏幕下，如果要以256色显示，显卡至少需要1080x1920个字节，也就是2M的大小。

刚刚说了，屏幕上的像素数据是从左到右，从上到下进行同步的，当这个过程完成了，就表示一帧绘制完成了，于是会开始下一帧的绘制，大部分的显示屏都是以60HZ的频率在屏幕上绘制完一帧，也就是16ms，并且每次绘制新的一帧时，都会发出一个垂直同步信号（VSync）。我们已经知道，图像数据都是放在帧缓冲中的，如果帧缓冲的缓冲区只有一个，那么屏幕在绘制这一帧的时候，图像数据便没法放入帧缓冲中了，只能等待这一帧绘制完成，在这种情况下，会有很大了效率问题。所以为了解决这一问题，帧缓冲引入两个缓冲区，即 双缓冲机制 。双缓冲虽然能解决效率问题，但会引入一个新的问题。当屏幕这一帧还没绘制完成时，即屏幕内容刚显示一半时，GPU 将新的一帧内容提交到帧缓冲区并把两个缓冲区进行交换后，显卡的像素同步模块就会把新的一帧数据的下半段显示到屏幕上，造成画面撕裂现象。

为了解决撕裂问题，就需要在收到垂直同步的时候才将帧缓冲中的两个缓冲区进行交换。Android4.1黄油计划中有一个优化点，就是CPU和GPU都只有收到垂直同步的信号时，才会开始进行图像的绘制操作，以及缓冲区的交换工作。

我们已经了解了屏幕图像显示的原理了，那么接着开始对Android图像显示的学习。

从上一章已经知道，计算机渲染界面必须要有GPU和帧缓冲。对于Linux系统来说，用户进程是没法直接操作帧缓冲的，但我们想要显示图像就必须要操作帧缓冲，所以Linux系统设计了一个虚拟设备文件，来作为对帧缓冲的映射，通过对该文件的I/O读写，我们就可以实现读写屏操作。帧缓冲对应的设备文件于/dev/fb* ，*表示对多个显示设备的支持， 设备号从0到31，如/dev/fb0就表示第一块显示屏，/dev/fb1就表示第二块显示屏。对于Android系统来说，默认使用/dev/fb0这一个设帧缓冲作为主屏幕，也就是我们的手机屏幕。我们Android手机屏幕上显示的图像数据，都是存储在/dev/fb0里，早期AndroidStuio中的DDMS工具实现截屏的原理就是直接读取/dev/fb0设备文件。

我们知道了手机屏幕上的图形数据都存储在帧缓冲中，所以Android手机图像界面的原理就是将我们的图像数据写入到帧缓冲内。那么，写入到帧缓冲的图像数据是怎么生成的，又是怎样加工的呢？图形数据是怎样送到帧缓冲去的，中间经历了哪些步骤和过程呢？了解了这几个问题，我们就了解了Android图形渲染的原理，那么带着这几个疑问，接着往下看。

想要知道图像数据是怎么产生的，我们需要知道 图像生产者 有哪些，他们分别是如何生成图像的，想要知道图像数据是怎么被消费的，我们需要知道 图像消费者 有哪些，他们又分别是如何消费图像的，想要知道中间经历的步骤和过程，我们需要知道 图像缓冲区 有哪些，他们是如何被创建，如何分配存储空间，又是如何将数据从生产者传递到消费者的，图像显示是一个很经典的消费者生产者的模型，只有对这个模型各个模块的击破，了解他们之间的流动关系，我们才能找到一条更容易的路径去掌握Android图形显示原理。我们看看谷歌提供的官方的架构图是怎样描述这一模型的模块及关系的。

如图， 图像的生产者 主要有MediaPlayer，CameraPrevier，NDK，OpenGl ES。MediaPlayer和Camera Previer是通过直接读取图像源来生成图像数据，NDK（Skia），OpenGL ES是通过自身的绘制能力生产的图像数据； 图像的消费者 有SurfaceFlinger，OpenGL ES Apps，以及HAL中的Hardware Composer。OpenGl ES既可以是图像的生产者，也可以是图像的消费者，所以它也放在了图像消费模块中； 图像缓冲区 主要有Surface以及前面提到帧缓冲。

Android图像显示的原理，会仅仅围绕 图像的生产者 ， 图像的消费者 ， 图像缓冲区 来展开，在这一篇文章中，我们先看看Android系统中的图像消费者。

SurfaceFlinger是Android系统中最重要的一个图像消费者，Activity绘制的界面图像，都会传递到SurfaceFlinger来，SurfaceFlinger的作用主要是接收图像缓冲区数据，然后交给HWComposer或者OpenGL做合成，合成完成后，SurfaceFlinger会把最终的数据提交给帧缓冲。

那么SurfaceFlinger是如何接收图像缓冲区的数据的呢？我们需要先了解一下Layer（层）的概念，一个Layer包含了一个Surface，一个Surface对应了一块图形缓冲区，而一个界面是由多个Surface组成的，所以他们会一一对应到SurfaceFlinger的Layer中。SurfaceFlinger通过读取Layer中的缓冲数据，就相当于读取界面上Surface的图像数据。Layer本质上是 Surface和SurfaceControl的组合 ，Surface是图形生产者和图像消费之间传递数据的缓冲区，SurfaceControl是Surface的控制类。

前面在屏幕图像显示原理中讲到，为了防止图像的撕裂，Android系统会在收到VSync垂直同步时才会开始处理图像的绘制和合成工作，而Surfaceflinger作为一个图像的消费者，同样也是遵守这一规则，所以我们通过源码来看看SurfaceFlinger是如何在这一规则下，消费图像数据的。

SurfaceFlinger专门创建了一个EventThread线程用来接收VSync。EventThread通过Socket将VSync信号同步到EventQueue中，而EventQueue又通过回调的方式，将VSync信号同步到SurfaceFlinger内。我们看一下源码实现。

上面主要是SurfaceFlinger初始化接收VSYNC垂直同步信号的操作，主要有这几个过程：

经过上面几个步骤，我们接收VSync的初始化工作都准备好了，EventThread也开始运转了，接着看一下EventThread的运转函数threadLoop做的事情。

threadLoop主要是两件事情

mConditon又是怎么接收VSync的呢？我们来看一下

可以看到，mCondition的VSync信号实际是DispSyncSource通过onVSyncEvent回调传入的，但是DispSyncSource的VSync又是怎么接收的呢？在上面讲到的SurfaceFlinger的init函数，在创建EventThread的实现中，我们可以发现答案—— mPrimaryDispSync 。

DispSyncSource的构造方法传入了mPrimaryDispSync，mPrimaryDispSync实际是一个DispSyncThread线程，我们看看这个线程的threadLoop方法

DispSyncThread的threadLoop会通过mPeriod来判断是否进行阻塞或者进行VSync回调，那么mPeriod又是哪儿被设置的呢？这里又回到SurfaceFlinger了，我们可以发现在SurfaceFlinger的 resyncToHardwareVsync 函数中有对mPeriod的赋值。

可以看到，这里最终通过HWComposer，也就是硬件层拿到了period。终于追踪到了VSync的最终来源了， 它从HWCompser产生，回调至DispSync线程，然后DispSync线程回调到DispSyncSource，DispSyncSource又回调到EventThread，EventThread再通过Socket分发到MessageQueue中 。

我们已经知道了VSync信号来自于HWCompser，但SurfaceFlinger并不会一直监听VSync信号，监听VSync的线程大部分时间都是休眠状态，只有需要做合成工作时，才会监听VSync，这样即保证图像合成的操作能和VSync保持一致，也节省了性能。SurfaceFlinger提供了一些主动注册监听VSync的操作函数。

可以看到，只有当SurfaceFlinger调用 signalTransaction 或者 signalLayerUpdate 函数时，才会注册监听VSync信号。那么signalTransaction或者signalLayerUpdate什么时候被调用呢？它可以由图像的生产者通知调用，也可以由SurfaceFlinger根据自己的逻辑来判断是否调用。

现在假设App层已经生成了我们界面的图像数据，并调用了 signalTransaction 通知SurfaceFlinger注册监听VSync，于是VSync信号便会传递到了MessageQueue中了，我们接着看看MessageQueue又是怎么处理VSync的吧。

MessageQueue收到VSync信号后，最终回调到了SurfaceFlinger的 onMessageReceived 中，当SurfaceFlinger接收到VSync后，便开始以一个图像消费者的角色来处理图像数据了。我们接着看SurfaceFlinger是以什么样的方式消费图像数据的。

VSync信号最终被SurfaceFlinger的onMessageReceived函数中的INVALIDATE模块处理。

INVALIDATE的流程如下：

handleMessageTransaction的处理比较长，处理的事情也比较多，它主要做的事情有这些

handleMessageRefresh函数，便是SurfaceFlinger真正处理图层合成的地方，它主要下面五个步骤。

我会详细介绍每一个步骤的具体操作

合成前预处理会判断Layer是否发生变化，当Layer中有新的待处理的Buffer帧（mQueuedFrames>0），或者mSidebandStreamChanged发生了变化， 都表示Layer发生了变化，如果变化了，就调用signalLayerUpdate，注册下一次的VSync信号。如果Layer没有发生变化，便只会做这一次的合成工作，不会注册下一次VSync了。

重建Layer栈会遍历Layer，计算和存储每个Layer的脏区， 然后和当前的显示设备进行比较，看Layer的脏区域是否在显示设备的显示区域内，如果在显示区域内的话说明该layer是需要绘制的，则更新到显示设备的VisibleLayersSortedByZ列表中，等待被合成

rebuildLayerStacks中最重要的一步是 computeVisibleRegions ，也就是对Layer的变化区域和非透明区域的计算，为什么要对变化区域做计算呢？我们先看看SurfaceFlinger对界面显示区域的分类：

还是以这张图做例子，可以看到我们的状态栏是半透明的，所以它是一个opaqueRegion区域，微信界面和虚拟按键是完全不透明的，他是一个visibleRegion，除了这三个Layer外，还有一个我们看不到的Layer——壁纸，它被上方visibleRegion遮挡了，所以是coveredRegion

对这几个区域的概念清楚了，我们就可以去了解computeVisibleRegions中做的事情了，它主要是这几步操作：