Android性能優化典範

    Android性能優化典範
    咱們能夠經過前面介紹的MonitorGPURendering來查看渲染的表現性能如何，另外也能夠經過開發者選項裏面的ShowGPUviewupdates來查看視圖更新的操做，最後咱們還能夠經過HierarchyViewer這個工具來查看佈局，使得佈局儘可能扁平化，移除非必需的UI組件，這些操做可以減小Measure，Layout的計算時間。
    8)Overdraw,Cliprect,QuickReject
    引發性能問題的一個很重要的方面是由於過多複雜的繪製操做。咱們能夠經過工具來檢測並修復標準UI組件的Overdraw問題，可是針對高度自定義的UI組件則顯得有些力不從心。
    有一個竅門是咱們能夠經過執行幾個APIs方法來顯著提高繪製操做的性能。前面有提到過，非可見的UI組件進行繪製更新會致使Overdraw。例如NavDrawer從前置可見的Activity滑出以後，若是還繼續繪製那些在NavDrawer裏面不可見的UI組件，這就致使了Overdraw。爲了解決這個問題，Android系統會經過避免繪製那些徹底不可見的組件來儘可能減小Overdraw。那些NavDrawer裏面不可見的View就不會被執行浪費資源。
    可是不幸的是，對於那些過於複雜的自定義的View(重寫了onDraw方法)，Android系統沒法檢測具體在onDraw裏面會執行什麼操做，系統沒法監控並自動優化，也就沒法避免Overdraw了。可是咱們能夠經過canvas.clipRect()來幫助系統識別那些可見的區域。這個方法能夠指定一塊矩形區域，只有在這個區域內纔會被繪製，其餘的區域會被忽視。這個API能夠很好的幫助那些有多組重疊組件的自定義View來控制顯示的區域。同時clipRect方法還能夠幫助節約CPU與GPU資源，在clipRect區域以外的繪製指令都不會被執行，那些部份內容在矩形區域內的組件，仍然會獲得繪製。
    除了clipRect方法以外，咱們還可使用canvas.quickreject()來判斷是否沒和某個矩形相交，從而跳過那些非矩形區域內的繪製操做。作了那些優化以後，咱們能夠經過上面介紹的ShowGPUOverdraw來查看效果。
    9)MemoryChurnandperformance
    雖然Android有自動管理內存的機制，可是對內存的不恰當使用仍然容易引發嚴重的性能問題。在同一幀裏面建立過多的對象是件須要特別引發注意的事情。
    Android系統裏面有一個GenerationalHeapMemory的模型，系統會根據內存中不一樣的內存數據類型分別執行不一樣的GC操做。例如，最近剛分配的對象會放在YoungGeneration區域，這個區域的對象一般都是會快速被建立而且很快被銷燬回收的，同時這個區域的GC操做速度也是比OldGeneration區域的GC操做速度更快的。
    除了速度差別以外，執行GC操做的時候，任何線程的任何操做都會須要暫停，等待GC操做完成以後，其餘操做纔可以繼續運行。
    一般來講，單個的GC並不會佔用太多時間，可是大量不停的GC操做則會顯著佔用幀間隔時間(16ms)。若是在幀間隔時間裏面作了過多的GC操做，那麼天然其餘相似計算，渲染等操做的可用時間就變得少了。
    致使GC頻繁執行有兩個緣由：
    MemoryChurn內存抖動，內存抖動是由於大量的對象被建立又在短期內立刻被釋放。
    瞬間產生大量的對象會嚴重佔用YoungGeneration的內存區域，當達到閥值，剩餘空間不夠的時候，也會觸發GC。即便每次分配的對象佔用了不多的內存，可是他們疊加在一塊兒會增長Heap的壓力，從而觸發更多其餘類型的GC。這個操做有可能會影響到幀率，並使得用戶感知到性能問題。
    解決上面的問題有簡潔直觀方法，若是你在MemoryMonitor裏面查看到短期發生了屢次內存的漲跌，這意味着頗有可能發生了內存抖動。
    同時咱們還能夠經過AllocationTracker來查看在短期內，同一個棧中不斷進出的相同對象。這是內存抖動的典型信號之一。
    當你大體定位問題以後，接下去的問題修復也就顯得相對直接簡單了。例如，你須要避免在for循環裏面分配對象佔用內存，須要嘗試把對象的建立移到循環體以外，自定義View中的onDraw方法也須要引發注意，每次屏幕發生繪製以及動畫執行過程當中，onDraw方法都會被調用到，避免在onDraw方法裏面執行復雜的操做，避免建立對象。對於那些沒法避免須要建立對象的狀況，咱們能夠考慮對象池模型，經過對象池來解決頻繁建立與銷燬的問題，可是這裏須要注意結束使用以後，須要手動釋放對象池中的對象。
    10)GarbageCollectioninAndroid
    JVM的回收機制給開發人員帶來很大的好處，不用時刻處理對象的分配與回收，能夠更加專一於更加高級的代碼實現。相比起Java，C與C++等語言具有更高的執行效率，他們須要開發人員本身關注對象的分配與回收，可是在一個龐大的系統當中，仍是免不了常常發生部分對象忘記回收的狀況，這就是內存泄漏。
    原始JVM中的GC機制在Android中獲得了很大程度上的優化。Android裏面是一個三級Generation的內存模型，最近分配的對象會存放在YoungGeneration區域，當這個對象在這個區域停留的時間達到必定程度，它會被移動到OldGeneration，最後到PermanentGeneration區域。
    每個級別的內存區域都有固定的大小，此後不斷有新的對象被分配到此區域，當這些對象總的大小快達到這一級別內存區域的閥值時，會觸發GC的操做，以便騰出空間來存放其餘新的對象。
    前面提到過每次GC發生的時候，全部的線程都是暫停狀態的。GC所佔用的時間和它是哪個Generation也有關係，YoungGeneration的每次GC操做時間是最短的，OldGeneration其次，PermanentGeneration最長。執行時間的長短也和當前Generation中的對象數量有關，遍歷查找20000個對象比起遍歷50個對象天然是要慢不少的。
    雖然Google的工程師在儘可能縮短每次GC所花費的時間，可是特別注意GC引發的性能問題仍是頗有必要。若是不當心在最小的for循環單元裏面執行了建立對象的操做，這將很容易引發GC並致使性能問題。經過MemoryMonitor咱們能夠查看到內存的佔用狀況，每一次瞬間的內存下降都是由於此時發生了GC操做，若是在短期內發生大量的內存上漲與下降的事件，這說明頗有可能這裏有性能問題。咱們還能夠經過HeapandAllocationTracker工具來查看此時內存中分配的到底有哪些對象。
    11)PerformanceCostofMemoryLeaks
    雖然Java有自動回收的機制，但是這不意味着Java中不存在內存泄漏的問題，而內存泄漏會很容易致使嚴重的性能問題。
    內存泄漏指的是那些程序再也不使用的對象沒法被GC識別，這樣就致使這個對象一直留在內存當中，佔用了寶貴的內存空間。顯然，這還使得每級Generation的內存區域可用空間變小，GC就會更容易被觸發，從而引發性能問題。
    尋找內存泄漏並修復這個漏洞是件很棘手的事情，你須要對執行的代碼很熟悉，清楚的知道在特定環境下是如何運行的，而後仔細排查。例如，你想知道程序中的某個activity退出的時候，它以前所佔用的內存是否有完整的釋放乾淨了？首先你須要在activity處於前臺的時候使用HeapTool獲取一份當前狀態的內存快照，而後你須要建立一個幾乎不這麼佔用內存的空白activity用來給前一個Activity進行跳轉，其次在跳轉到這個空白的activity的時候主動調用System.gc()方法來確保觸發一個GC操做。最後，若是前面這個activity的內存都有所有正確釋放，那麼在空白activity被啓動以後的內存快照中應該不會有前面那個activity中的任何對象了。
    若是你發如今空白activity的內存快照中有一些可疑的沒有被釋放的對象存在，那麼接下去就應該使用AlocationTrackTool來仔細查找具體的可疑對象。咱們能夠從空白activity開始監聽，啓動到觀察activity，而後再回到空白activity結束監聽。這樣操做之後，咱們能夠仔細觀察那些對象，找出內存泄漏的真兇。
    12)MemoryPerformance
    一般來講，Android對GC作了大量的優化操做，雖然執行GC操做的時候會暫停其餘任務，但是大多數狀況下，GC操做仍是相對很安靜而且高效的。可是若是咱們對內存的使用不恰當，致使GC頻繁執行，這樣就會引發不小的性能問題。
    爲了尋找內存的性能問題，AndroidStudio提供了工具來幫助開發者。
    MemoryMonitor：查看整個app所佔用的內存，以及發生GC的時刻，短期內發生大量的GC操做是一個危險的信號。
    AllocationTracker：使用此工具來追蹤內存的分配，前面有提到過。
    HeapTool：查看當前內存快照，便於對比分析哪些對象有多是泄漏了的，請參考前面的Case。
    13)Tool-MemoryMonitor
    AndroidStudio中的MemoryMonitor能夠很好的幫組咱們查看程序的內存使用狀況。
    14)BatteryPerformance
    電量實際上是目前手持設備最寶貴的資源之一，大多數設備都須要不斷的充電來維持繼續使用。不幸的是，對於開發者來講，電量優化是他們最後纔會考慮的的事情。可是能夠肯定的是，千萬不能讓你的應用成爲消耗電量的大戶。
    PurdueUniversity研究了最受歡迎的一些應用的電量消耗，平均只有30%左右的電量是被程序最核心的方法例如繪製圖片，擺放佈局等等所使用掉的，剩下的70%左右的電量是被上報數據，檢查位置信息，定時檢索後臺廣告信息所使用掉的。如何平衡這二者的電量消耗，就顯得很是重要了。
    有下面一些措施可以顯著減小電量的消耗：
    咱們應該儘可能減小喚醒屏幕的次數與持續的時間，使用WakeLock來處理喚醒的問題，可以正確執行喚醒操做並根據設定及時關閉操做進入睡眠狀態。
    某些非必須立刻執行的操做，例如上傳歌曲，圖片處理等，能夠等到設備處於充電狀態或者電量充足的時候才進行。
    觸發網絡請求的操做，每次都會保持無線信號持續一段時間，咱們能夠把零散的網絡請求打包進行一次操做，避免過多的無線信號引發的電量消耗。關於網絡請求引發無線信號的電量消耗，還能夠參考這裏。
    咱們能夠經過手機設置選項找到對應App的電量消耗統計數據。咱們還能夠經過BatteryHistorianTool來查看詳細的電量消耗。
    若是發現咱們的App有電量消耗過多的問題，咱們可使用JobSchedulerAPI來對一些任務進行定時處理，例如咱們能夠把那些任務重的操做等到手機處於充電狀態，或者是鏈接到WiFi的時候來處理。
    15)UnderstandingBatteryDrainonAndroid
    電量消耗的計算與統計是一件麻煩並且矛盾的事情，記錄電量消耗自己也是一個費電量的事情。惟一可行的方案是使用第三方監測電量的設備，這樣纔可以獲取到真實的電量消耗。
    當設備處於待機狀態時消耗的電量是極少的，以N5爲例，打開飛行模式，能夠待機接近1個月。但是點亮屏幕，硬件各個模塊就須要開始工做，這會須要消耗不少電量。
    使用WakeLock或者JobScheduler喚醒設備處理定時的任務以後，必定要及時讓設備回到初始狀態。每次喚醒無線信號進行數據傳遞，都會消耗不少電量，它比WiFi等操做更加的耗電。修復電量的消耗是另一個很大的課題，這裏就不展開繼續了。
    16)BatteryDrainandWakeLocks
    高效的保留更多的電量與不斷促使用戶使用你的App來消耗電量，這是矛盾的選擇題。不過咱們可使用一些更好的辦法來平衡二者。
    假設你的手機裏面裝了大量的社交類應用，即便手機處於待機狀態，也會常常被這些應用喚醒用來檢查同步新的數據信息。Android會不斷關閉各類硬件來延長手機的待機時間，首先屏幕會逐漸變暗直相當閉，而後CPU進入睡眠，這一切操做都是爲了節約寶貴的電量資源。可是即便在這種睡眠狀態下，大多數應用仍是會嘗試進行工做，他們將不斷的喚醒手機。一個最簡單的喚醒手機的方法是使用PowerManager.WakeLock的API來保持CPU工做並防止屏幕變暗關閉。這使得手機能夠被喚醒，執行工做，而後回到睡眠狀態。知道如何獲取WakeLock是簡單的，但是及時釋放WakeLock也是很是重要的，不恰當的使用WakeLock會致使嚴重錯誤。例如網絡請求的數據返回時間不肯定，致使原本只須要10s的事情一直等待了1個小時，這樣會使得電量白白浪費了。這也是爲什麼使用帶超時參數的wakelock.acquice()方法是很關鍵的。可是僅僅設置超時並不足夠解決問題，例如設置多長的超時比較合適？何時進行重試等等？
    解決上面的問題，正確的方式多是使用非精準定時器。一般狀況下，咱們會設定一個時間進行某個操做，可是動態修改這個時間也許會更好。例如，若是有另一個程序須要比你設定的時間晚5分鐘喚醒，最好可以等到那個時候，兩個任務捆綁一塊兒同時進行，這就是非精肯定時器的核心工做原理。咱們能夠定製計劃的任務，但是系統若是檢測到一個更好的時間，它能夠推遲你的任務，以節省電量消耗。
    這正是JobSchedulerAPI所作的事情。它會根據當前的狀況與任務，組合出理想的喚醒時間，例如等到正在充電或者鏈接到WiFi的時候，或者集中任務一塊兒執行。咱們能夠經過這個API實現不少免費的調度算法。
    從Android5.0開始發佈了BatteryHistoryTool，它能夠查看程序被喚醒的頻率，又誰喚醒的，持續了多長的時間，這些信息均可以獲取到。
    請關注程序的電量消耗，用戶能夠經過手機的設置選項觀察到那些耗電量大戶，並可能決定卸載他們。因此儘可能減小程序的電量消耗是很是有必要的。
    更多：黑帽技術 http://www.heimaoxuexi.com