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中做的事情了，它主要是這幾步操作：