前言

金九銀十面試季，相信大家肯定急需一套Android面試寶典，今天小編就給大家準(zhǔn)備了我珍藏已久的Android高階面試寶典，一份超級詳細(xì)的Android面試必備知識點，供大家學(xué)習(xí) ！

想必每一個安卓程序員都有追求大廠的決心，但是想要進(jìn)入大廠，我們需要掌握哪些知識點呢？這里，我為大家梳理了一個整體的知識架構(gòu)。整體包括Java、Android、算法、網(wǎng)絡(luò)等。希望大家閱讀之后，能幫助大家完善與整理自己的知識體系。祝大家面試順利~~

文末還有給大家分享我整理的Android面試專題及答案可以拿去參考下~

注意，整篇文章是知識點的概括，不包含答案，需要大家多看源碼，知識只有自己去探索與發(fā)現(xiàn)，才會彌足珍貴！

二、顯示系統(tǒng)基礎(chǔ)知識

在一個典型的顯示系統(tǒng)中，一般包括CPU、GPU、Display三個部分， CPU負(fù)責(zé)計算幀數(shù)據(jù)，把計算好的數(shù)據(jù)交給GPU，GPU會對圖形數(shù)據(jù)進(jìn)行渲染，渲染好后放到buffer(圖像緩沖區(qū))里存起來，然后Display（屏幕或顯示器）負(fù)責(zé)把buffer里的數(shù)據(jù)呈現(xiàn)到屏幕上。如下圖：

2.1 基礎(chǔ)概念

• 屏幕刷新頻率 一秒內(nèi)屏幕刷新的次數(shù)（一秒內(nèi)顯示了多少幀的圖像），單位 Hz（赫茲），如常見的 60 Hz。刷新頻率取決于硬件的固定參數(shù)（不會變的）。

• 逐行掃描 顯示器并不是一次性將畫面顯示到屏幕上，而是從左到右邊，從上到下逐行掃描，順序顯示整屏的一個個像素點，不過這一過程快到人眼無法察覺到變化。以 60 Hz 刷新率的屏幕為例，這一過程即 1000 / 60 ≈ 16ms。

• 幀率 （Frame Rate） 表示 GPU 在一秒內(nèi)繪制操作的幀數(shù)，單位 fps。例如在電影界采用 24 幀的速度足夠使畫面運行的非常流暢。而 Android 系統(tǒng)則采用更加流程的 60 fps，即每秒鐘GPU最多繪制 60 幀畫面。幀率是動態(tài)變化的，例如當(dāng)畫面靜止時，GPU 是沒有繪制操作的，屏幕刷新的還是buffer中的數(shù)據(jù)，即GPU最后操作的幀數(shù)據(jù)。

• 畫面撕裂（tearing） 一個屏幕內(nèi)的數(shù)據(jù)來自2個不同的幀，畫面會出現(xiàn)撕裂感，如下圖

2.2 雙緩存

2.2.1 畫面撕裂 原因

屏幕刷新頻是固定的，比如每16.6ms從buffer取數(shù)據(jù)顯示完一幀，理想情況下幀率和刷新頻率保持一致，即每繪制完成一幀，顯示器顯示一幀。但是CPU/GPU寫數(shù)據(jù)是不可控的，所以會出現(xiàn)buffer里有些數(shù)據(jù)根本沒顯示出來就被重寫了，即buffer里的數(shù)據(jù)可能是來自不同的幀的， 當(dāng)屏幕刷新時，此時它并不知道buffer的狀態(tài)，因此從buffer抓取的幀并不是完整的一幀畫面，即出現(xiàn)畫面撕裂。

簡單說就是Display在顯示的過程中，buffer內(nèi)數(shù)據(jù)被CPU/GPU修改，導(dǎo)致畫面撕裂。

2.2.2 雙緩存

那咋解決畫面撕裂呢？ 答案是使用 雙緩存。

由于圖像繪制和屏幕讀取 使用的是同個buffer，所以屏幕刷新時可能讀取到的是不完整的一幀畫面。

雙緩存，讓繪制和顯示器擁有各自的buffer：GPU 始終將完成的一幀圖像數(shù)據(jù)寫入到 Back Buffer，而顯示器使用 Frame Buffer，當(dāng)屏幕刷新時，Frame Buffer 并不會發(fā)生變化，當(dāng)Back buffer準(zhǔn)備就緒后，它們才進(jìn)行交換。如下圖：

2.2.3 VSync

問題又來了：什么時候進(jìn)行兩個buffer的交換呢？

假如是 Back buffer準(zhǔn)備完成一幀數(shù)據(jù)以后就進(jìn)行，那么如果此時屏幕還沒有完整顯示上一幀內(nèi)容的話，肯定是會出問題的?？磥碇荒苁堑鹊狡聊惶幚硗暌粠瑪?shù)據(jù)后，才可以執(zhí)行這一操作了。

當(dāng)掃描完一個屏幕后，設(shè)備需要重新回到第一行以進(jìn)入下一次的循環(huán)，此時有一段時間空隙，稱為VerticalBlanking Interval(VBI)。那，這個時間點就是我們進(jìn)行緩沖區(qū)交換的最佳時間。因為此時屏幕沒有在刷新，也就避免了交換過程中出現(xiàn) screen tearing的狀況。

VSync(垂直同步)是VerticalSynchronization的簡寫，它利用VBI時期出現(xiàn)的vertical sync pulse（垂直同步脈沖）來保證雙緩沖在最佳時間點才進(jìn)行交換。另外，交換是指各自的內(nèi)存地址，可以認(rèn)為該操作是瞬間完成。

所以說V-sync這個概念并不是Google首創(chuàng)的，它在早年的PC機(jī)領(lǐng)域就已經(jīng)出現(xiàn)了。

三、Android屏幕刷新機(jī)制

3.1 Android4.1之前的問題

具體到Android中，在Android4.1之前，屏幕刷新也遵循 上面介紹的 雙緩存+VSync 機(jī)制。如下圖：

以時間的順序來看下將會發(fā)生的過程：

Display顯示第0幀數(shù)據(jù)，此時CPU和GPU渲染第1幀畫面，且在Display顯示下一幀前完成

因為渲染及時，Display在第0幀顯示完成后，也就是第1個VSync后，緩存進(jìn)行交換，然后正常顯示第1幀

接著第2幀開始處理，是直到第2個VSync快來前才開始處理的。

第2個VSync來時，由于第2幀數(shù)據(jù)還沒有準(zhǔn)備就緒，緩存沒有交換，顯示的還是第1幀。這種情況被Android開發(fā)組命名為“Jank”，即發(fā)生了丟幀。

當(dāng)?shù)?幀數(shù)據(jù)準(zhǔn)備完成后，它并不會馬上被顯示，而是要等待下一個VSync 進(jìn)行緩存交換再顯示。

所以總的來說，就是屏幕平白無故地多顯示了一次第1幀。

原因是 第2幀的CPU/GPU計算 沒能在VSync信號到來前完成 。

我們知道，雙緩存的交換 是在Vsyn到來時進(jìn)行，交換后屏幕會取Frame buffer內(nèi)的新數(shù)據(jù)，而實際 此時的Back buffer 就可以供GPU準(zhǔn)備下一幀數(shù)據(jù)了。 如果 Vsyn到來時 CPU/GPU就開始操作的話，是有完整的16.6ms的，這樣應(yīng)該會基本避免jank的出現(xiàn)了（除非CPU/GPU計算超過了16.6ms）。 那如何讓 CPU/GPU計算在 Vsyn到來時進(jìn)行呢？

3.2 drawing with VSync

為了優(yōu)化顯示性能，Google在Android 4.1系統(tǒng)中對Android Display系統(tǒng)進(jìn)行了重構(gòu)，實現(xiàn)了Project Butter（黃油工程）：系統(tǒng)在收到VSync pulse后，將馬上開始下一幀的渲染。即一旦收到VSync通知（16ms觸發(fā)一次），CPU和GPU 才立刻開始計算然后把數(shù)據(jù)寫入buffer。如下圖：

CPU/GPU根據(jù)VSYNC信號同步處理數(shù)據(jù)，可以讓CPU/GPU有完整的16ms時間來處理數(shù)據(jù)，減少了jank。

一句話總結(jié)，VSync同步使得CPU/GPU充分利用了16.6ms時間，減少jank。

問題又來了，如果界面比較復(fù)雜，CPU/GPU的處理時間較長 超過了16.6ms呢？如下圖：

在第二個時間段內(nèi)，但卻因 GPU 還在處理 B 幀，緩存沒能交換，導(dǎo)致 A 幀被重復(fù)顯示。

而B完成后，又因為缺乏VSync pulse信號，它只能等待下一個signal的來臨。于是在這一過程中，有一大段時間是被浪費的。

當(dāng)下一個VSync出現(xiàn)時，CPU/GPU馬上執(zhí)行操作（A幀），且緩存交換，相應(yīng)的顯示屏對應(yīng)的就是B。這時看起來就是正常的。只不過由于執(zhí)行時間仍然超過16ms，導(dǎo)致下一次應(yīng)該執(zhí)行的緩沖區(qū)交換又被推遲了——如此循環(huán)反復(fù)，便出現(xiàn)了越來越多的“Jank”。

為什么 CPU 不能在第二個 16ms 處理繪制工作呢？

原因是只有兩個 buffer，Back buffer正在被GPU用來處理B幀的數(shù)據(jù)， Frame buffer的內(nèi)容用于Display的顯示，這樣兩個buffer都被占用，CPU 則無法準(zhǔn)備下一幀的數(shù)據(jù)。 那么，如果再提供一個buffer，CPU、GPU 和顯示設(shè)備都能使用各自的buffer工作，互不影響。

3.3 三緩存

三緩存就是在雙緩沖機(jī)制基礎(chǔ)上增加了一個 Graphic Buffer 緩沖區(qū)，這樣可以最大限度的利用空閑時間，帶來的壞處是多使用的一個 Graphic Buffer 所占用的內(nèi)存。

第一個Jank，是不可避免的。但是在第二個 16ms 時間段，CPU/GPU 使用 第三個 Buffer 完成C幀的計算，雖然還是會多顯示一次 A 幀，但后續(xù)顯示就比較順暢了，有效避免 Jank 的進(jìn)一步加劇。

注意在第3段中，A幀的計算已完成，但是在第4個vsync來的時候才顯示，如果是雙緩沖，那在第三個vynsc就可以顯示了。

三緩沖有效利用了等待vysnc的時間，減少了jank，但是帶來了延遲。 所以，是不是 Buffer 越多越好呢？這個是否定的，Buffer 正常還是兩個，當(dāng)出現(xiàn) Jank 后三個足以。

以上就是Android屏幕刷新的原理了。

最后

簡歷首選內(nèi)推方式，速度快，效率高啊！然后可以在拉鉤，boss，脈脈，大街上看看。簡歷上寫道熟悉什么技術(shù)就一定要去熟悉它，不然被問到不會很尷尬！做過什么項目，即使項目體量不大，但也一定要熟悉實現(xiàn)原理！不是你負(fù)責(zé)的部分，也可以看看同事是怎么實現(xiàn)的，換你來做你會怎么做？做過什么，會什么是廣度問題，取決于項目內(nèi)容。但做過什么，達(dá)到怎樣一個境界，這是深度問題，和個人學(xué)習(xí)能力和解決問題的態(tài)度有關(guān)了。大公司看深度，小公司看廣度。大公司面試你會的，小公司面試他們用到的你會不會，也就是崗位匹配度。

面試過程一定要有禮貌！即使你覺得面試官不尊重你，經(jīng)常打斷你的講解，或者你覺得他不如你，問的問題缺乏專業(yè)水平，你也一定要尊重他，誰叫現(xiàn)在是他選擇你，等你拿到offer后就是你選擇他了。

另外，描述問題一定要慢！不要一下子講一大堆，慢顯得你沉穩(wěn)、自信，而且你還有時間反應(yīng)思路接下來怎么講更好?，F(xiàn)在開發(fā)過多依賴ide，所以會有個弊端，當(dāng)我們在面試講解很容易不知道某個方法怎么讀，這是一個硬傷…所以一定要對常見的關(guān)鍵性的類名、方法名、關(guān)鍵字讀準(zhǔn)，有些面試官不耐煩會說“你到底說的是哪個？”這時我們會容易亂了陣腳。正確的發(fā)音+沉穩(wěn)的描述+好聽的嗓音決對是一個加分項！

最重要的是心態(tài)！心態(tài)！心態(tài)！重要事情說三遍！面試時間很短，在短時間內(nèi)對方要摸清你的底子還是比較不現(xiàn)實的，所以，有時也是看眼緣，這還是個看臉的時代。

希望大家都能找到合適自己滿意的工作！
如果需要PDF版本可以在GitHub中自行領(lǐng)取！

• 或者點擊這里自行下載，直達(dá)領(lǐng)取鏈接

進(jìn)階學(xué)習(xí)視頻

附上：我們之前因為秋招收集的二十套一二線互聯(lián)網(wǎng)公司Android面試真題?（含BAT、小米、華為、美團(tuán)、滴滴）和我自己整理Android復(fù)習(xí)筆記（包含Android基礎(chǔ)知識點、Android擴(kuò)展知識點、Android源碼解析、設(shè)計模式匯總、Gradle知識點、常見算法題匯總。）

題**?（含BAT、小米、華為、美團(tuán)、滴滴）和我自己整理Android復(fù)習(xí)筆記（包含Android基礎(chǔ)知識點、Android擴(kuò)展知識點、Android源碼解析、設(shè)計模式匯總、Gradle知識點、常見算法題匯總。）

[外鏈圖片轉(zhuǎn)存中…(img-pZ8o97qN-1619769952918)]

總結(jié)

以上是生活随笔為你收集整理的小程序FMP优化实录，大厂面试题汇总的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。