原文地址：http://blog.csdn.net/goodlixueyong/article/details/50935977
開發者選項是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()回調方法。
這個功能只是作爲調試輔助開啓比較合適，普通用戶開啓後將嚴重影響用戶體驗。