開發者選項是Android為開發者提供的一個APP驗證、除錯、優化等各種功能的入口，它可以幫助我們提高除錯效率，協助發現一些bug。這個功能的入口在每個Rom上的位置不盡相同，我的小米手機顯示位置是在“其他高階設定”裡。有的Rom對開發者模式進行了隱藏，通常的開啟方法是進入到設定裡的“關於手機”，然後快速連續點選版本號多次，就會顯示出來。

今天來總結一下開發者模式中常用的功能有哪些，這些功能可以給我們提供什麼幫助，以及如何來使用它。由於工作內容原因，有些功能用的比較少，這裡只對本人常用的熟悉的功能進行講解。

USB除錯

這應該使用的最頻繁的功能，簡單講就是需要開啟它你才能通過電腦連線上手機，如果發現除錯的時候手機連線不上，關注一下是不是沒有開啟這個選項吧。

不鎖定螢幕

由於通常我們都會進行鎖屏設定，所以開發的時候一段時間不用手機就會黑屏，這個選項開啟之後，連線手機將不會鎖屏。

顯示佈局邊界

進行UI設計中時常會用到，開啟之後會顯示頁面佈局的邊界和框架，通過這個顯示結果我們可以看到沒有達到預期效果的佈局的問題在哪裡，開啟之後的效果如下。在一個論壇中偶然看到有人說，可以通過“顯示佈局邊界”來判斷這個介面或者某個部位是不是html5實現，我只想說，好機智。

視窗動畫(過渡動畫、動畫程式時長)縮放

實現動畫效果時，可以直接設定調整動畫的時長來看動畫效果。當然如果你不嫌麻煩的話，可以在程式碼裡反覆調整，每次都去重新編譯執行。

強制進行GPU渲染

這個選項的意思就是強制開啟硬體加速。對於使用者來講，開啟之後應用會變得流暢，但是由於有些Canvas方法不支援硬體加速，開啟之後可能會引起應用crash。

顯示GPU檢視更新

開啟之後可以看到頁面會不停閃爍，尤其是滑動頁面的時候閃爍更頻繁，這就表示閃爍的頁面或者View等開啟了硬體加速。如果發現某個頁面一點閃爍都沒有，那就說明這個頁面關閉了硬體加速功能。

除錯GPU過度繪製

下圖是開啟這個選項後的效果：

該功能會用幾種不同的顏色繪製螢幕，來標識overdraw發生的位置以及程度如何，各種顏色的意義如下：
沒有顏色： 意味著沒有overdraw。畫素只畫了一次。
藍色： 意味著overdraw 1倍。畫素繪製了兩次。大片的藍色還是可以接受的（若整個視窗是藍色的，可以擺脫一層）。
綠色： 意味著overdraw 2倍。畫素繪製了三次。中等大小的綠色區域是可以接受的但你應該嘗試優化、減少它們。
淺紅： 意味著overdraw 3倍。畫素繪製了四次，小範圍可以接受。
暗紅： 意味著overdraw 4倍。畫素繪製了五次或者更多。這是錯誤的，要修復它們。

GPU呈現模式分析

可以選擇使用條形圖還是線型圖顯示，選擇哪種顯示方式顯示結果都是類似的。下圖是選擇條形圖後的顯示情況：

每列資料顯示了渲染每一幀需要的時間，每一條線意味著一幀被繪製出來，而每條線中的不同顏色又代表著在繪製過程中的不同階段：
Draw (藍色) 代表著View.onDraw()方法。在這個環節會建立/重新整理DisplayList中的物件，這些物件在後面會被轉換成GPU可以明白的OpenGL命令。而這個值比較高可能是因為view比較複雜，需要更多的時間去建立他們的display list，或者是因為有太多的view在很短的時間內被建立。
Process (紅色) – 執行Display list中的內容並建立OpenGL命令。如果有過多或者過於複雜的display list需要執行的話，那麼這階段會消耗較長的時間，因為這樣的話會有很多的view被重繪。而重繪往往發生在介面的重新整理或是被移動出了被覆蓋的區域。
Execute (黃色) – 傳送OpenGL命令到GPU。這個階段是一個阻塞呼叫，因為CPU在這裡只會傳送一個含有一些OpenGL命令的緩衝區給GPU，並且等待GPU返回空的緩衝區以便再次傳遞下一幀的OpenGL命令。而這些緩衝區的總量是一定的，如果GPU太過於繁忙，那麼CPU則會去等待下一個空緩衝區。所以，如果我們看到這一階段耗時比較長，那可能是因為GPU過於繁忙的繪製UI，而造成這個的原因則可能是在短時間內繪製了過於複雜的view。

綠色的橫線表示每一幀渲染時間的閾值，值為16ms，這是因為Android流暢執行的幀率為60fps，如果每一幀的渲染時間超過16ms，幀率就降低到小於60fps，會出現丟幀的情況，直觀的感受就是頁面出現卡頓。如果發現條形圖基本上低於綠色的線，說明頁面的繪圖效率良好，但當條形線頻繁的超過綠色的線，應用的佈局應該是有問題的，通常都是由於佈局不合理或者是太過複雜。通過不同顏色的線所佔的比重，可以確定卡頓是由哪個階段引起的。

不保留活動

       開啟這個選項表示頁面切到後臺以後將會被系統銷燬，一般用來模擬裝置記憶體不足時後臺Activity被銷燬的場景。我們可以用它來測試頁面重建的穩定性。如果你的應用在開啟它時功能基本正常，說明程式碼設計得比較合理，程式碼寫的足夠健壯。這個具體怎麼理解呢？

我們知道Activity有一個回撥方法onSavedInstanceState()會在頁面被切到後臺時呼叫來儲存頁面的狀態，如果頁面重新切回前臺而且已經被系統銷燬的情況下，系統會幫我們重建頁面，這個狀態通常是很難模擬的。開啟這個功能，就可以模擬這個情況，然後進行頁面狀態恢復的除錯。也就是說，如果兩個Activity A啟動B，B啟動後系統銷燬了頁面A，從B頁面再切回來時將會白屏（或者黑屏）一下，這就是系統在重建我們的A頁面。如果我們對頁面恢復的處理不當，就有可能導致頁面的重建出現異常，因為畢竟系統沒有智慧到幫我們儲存所有必要的資料，有些還是需要我們自己手動來儲存的。我們在測試中發現，如果將B頁面的屬性設定為透明，也就是設定主題為android:theme="@android:style/Theme.Translucent"，這時候系統並不會銷燬A頁面，那是因為A頁面並沒有執行onStop()回撥方法。

這個功能只是作為除錯輔助開啟比較合適，普通使用者開啟後將嚴重影響使用者體驗。