其實有點不想寫這篇文章的，但是又想寫，有些沖突。不想寫的原因是随便上網一搜一堆關于性能的建議，感覺大家你一總結、我一總結的都說到了很多優化注意事項，但是看過這些文章後大多數存在一個問題就是隻給出啥啥啥不能用，啥啥啥該咋用等，卻很少有較為系統的進行真正性能案例分析的，大多數都是嘴上喊喊或者死記住規則而已（當然了，這話我自己聽着都有些刺耳，實在不好意思，其實關于性能優化的優質博文網上也還是有很多的，譬如google官方都已經推出了優化專題，我這裡隻是總結下自的感悟而已，若有得罪歡迎拍磚，我願挨打，因為我之前工作的一半時間都是負責性能優化）。
android應用的性能問題其實可以劃分為幾個大的子產品的，而且都具有相對不錯的優化調試技巧，下面我們就會依據一個項目正常開發的大類型來進行一些分析講解。
ps：之前呆過一家初創醫療網際網路公司，别提性能優化了，老闆立完新項目後一個月就要求見到上線成品，這種壓迫下談何性能優化，純屬扯蛋，是以不到三個月時間我主動選擇撤了，這種現象後來我一打聽發現在很多初創公司都很嚴重，都想速成卻忽略了體驗。
ppps：本文隻是達到抛磚引玉的作用，很多東西細究下去都是值得深入研究的，再加上性能優化本來就是一個需要綜合考量的任務，不是說會了本文哪一點就能做性能分析了，需要面面俱到才可高效定位問題原因。
ui可謂是一個應用的臉，是以每一款應用在開發階段我們的互動、視覺、動畫工程師都拼命的想讓它變得自然大方美麗，可是現實總是不盡人意，動畫和互動總會覺得開發做出來的應用用上去感覺不自然，沒有達到他們心目中的自然流暢細節；這種情況之下就更别提釋出給終端使用者使用了，使用者要是能夠感覺出來，少則影響心情，多則解除安裝應用；是以一個應用的ui顯示性能問題就不得不被開發人員重視。
人類大腦與眼睛對一個畫面的連貫性感覺其實是有一個界限的，譬如我們看電影會覺得畫面很自然連貫（幀率為24fps），用手機當然也需要感覺螢幕操作的連貫性（尤其是動畫過度），是以android索性就把達到這種流暢的幀率規定為60fps。
有了上面的背景，我們開發app的幀率性能目标就是保持在60fps，也就是說我們在進行app性能優化時心中要有如下準則：
從上面可以看出來，所謂的卡頓其實是可以量化的，每次是否能夠成功渲染是非常重要的問題，16ms能否完整的做完一次操作直接決定了卡頓性能問題。
當然了，針對android系統的設計我們還需要知道另一個常識；虛拟機在執行gc垃圾回收操作時所有線程（包括ui線程）都需要暫停，當gc垃圾回收完成之後所有線程才能夠繼續執行（這個細節下面小節會有詳細介紹）。也就是說當在16ms内進行渲染等操作時如果剛好遇上大量gc操作則會導緻渲染時間明顯不足，也就進而導緻了丢幀卡頓問題。
有了上面這兩個簡單的理論基礎之後我們下面就會探讨一些ui卡頓的原因分析及解決方案。
我們在使用app時會發現有些界面啟動卡頓、動畫不流暢、清單等滑動時也會卡頓，究其原因，很多都是丢幀導緻的；通過上面卡頓原理的簡單說明我們從應用開發的角度往回推理可以得出常見卡頓原因，如下：
人為在ui線程中做輕微耗時操作，導緻ui線程卡頓；
布局layout過于複雜，無法在16ms内完成渲染；
同一時間動畫執行的次數過多，導緻cpu或gpu負載過重；
view過度繪制，導緻某些像素在同一幀時間内被繪制多次，進而使cpu或gpu負載過重；
view頻繁的觸發measure、layout，導緻measure、layout累計耗時過多及整個view頻繁的重新渲染；
記憶體頻繁觸發gc過多（同一幀中頻繁建立記憶體），導緻暫時阻塞渲染操作；
備援資源及邏輯等導緻加載和執行緩慢；
臭名昭著的anr；
可以看見，上面這些導緻卡頓的原因都是我們平時開發中非常常見的。有些人可能會覺得自己的應用用着還蠻ok的，其實那是因為你沒進行一些瞬時測試和壓力測試，一旦在這種環境下運作你的app你就會發現很多性能問題。
分析ui卡頓我們一般都借助工具，通過工具一般都可以直覺的分析出問題原因，進而反推尋求優化方案，具體如下細說各種強大的工具。
我們可以通過sdk提供的工具hierarchyviewer來進行ui布局複雜程度及備援等分析，如下：
選中一個window界面item，然後點選右上方hierarchy window或者pixel perfect window（這裡不介紹，主要用來檢查像素屬性的）即可操作。
先看下hierarchy window，如下：
一個activity的view樹，通過這個樹可以分析出view嵌套的備援層級，左下角可以輸入view的id直接自動跳轉到中間顯示；save as png用來把左側樹儲存為一張圖檔；capture layers用來儲存psd的photoshop分層素材；右側劇中顯示選中view的目前屬性狀态；右下角顯示目前view在activity中的位置等；左下角三個進行切換；load view hierarchy用來手動重新整理變化（不會自動重新整理的）。當我們選擇一個view後會如下圖所示：
類似上圖可以很友善的檢視到目前view的許多資訊；上圖最底那三個彩色原點代表了目前view的性能名額，從左到右依次代表測量、布局、繪制的渲染時間，紅色和黃色的點代表速度渲染較慢的view（當然了，有些時候較慢不代表有問題，譬如viewgroup子節點越多、結構越複雜，性能就越差）。
當然了，在自定義view的性能調試時，hierarchyviewer上面的invalidate layout和requestlayout按鈕的功能更加強大，它可以幫助我們debug自定義view執行invalidate()和requestlayout()過程，我們隻需要在代碼的相關地方打上斷點就行了，接下來通過它觀察繪制即可。
可以發現，有了hierarchyviewer調試工具，我們的ui性能分析變得十分容易，這個工具也是我們開發中調試ui的利器，在平時寫代碼時會時常伴随我們左右。
我們對于ui性能的優化還可以通過開發者選項中的gpu過度繪制工具來進行分析。在設定->開發者選項->調試gpu過度繪制（不同裝置可能位置或者叫法不同）中打開調試後可以看見如下圖（對settings目前界面過度繪制進行分析）：
可以發現，開啟後在我們想要調試的應用界面中可以看到各種顔色的區域，具體含義如下：
顔色
含義
無色
webview等的渲染區域
藍色
1x過度繪制
綠色
2x過度繪制
淡紅色
3x過度繪制
紅色
4x(+)過度繪制
由于過度繪制指在螢幕的一個像素上繪制多次（譬如一個設定了背景色的textview就會被繪制兩次，一次背景一次文本；這裡需要強調的是activity設定的theme主題的背景不被算在過度繪制層級中），是以最理想的就是繪制一次，也就是藍色（當然這在很多絢麗的界面是不現實的，是以大家有個度即可，我們的開發性能優化标準要求最極端界面下紅色區域不能長期持續超過螢幕三分之一，可見還是比較寬松的規定），是以我們需要依據此顔色分布進行代碼優化，譬如優化布局層級、減少沒必要的背景、暫時不顯示的view設定為gone而不是invisible、自定義view的ondraw方法設定canvas.cliprect()指定繪制區域或通過canvas.quickreject()減少繪制區域等。
android界面流暢度除過視覺感覺以外是可以考核的（測試妹子專用），常見的方法就是通過gpu呈現模式圖或者實時fps顯示進行考核，這裡我們主要針對gpu呈現模式圖進行下說明，因為fps考核測試方法有很多（譬如自己寫代碼實作、第三方app測試、固件支援等），是以不做統一說明。
通過開發者選項中gpu呈現模式圖工具來進行流暢度考量的流程是（注意：如果是在開啟應用後才開啟此功能，記得先把應用結束後重新啟動）在設定->開發者選項->gpu呈現模式（不同裝置可能位置或者叫法不同）中打開調試後可以看見如下圖（對settings目前界面上下滑動清單後的圖表）：
當然，也可以在執行完ui滑動操作後在指令行輸入如下指令檢視指令行列印的gpu渲染資料（分析依據：draw + process + execute = 完整的顯示一幀時間 < 16ms）：
打開上圖可視化工具後，我們可以在手機畫面上看到豐富的gpu繪制圖形資訊，分别展示了statusbar、navgationbar、activity區域等的gpu渲染時間資訊，随着界面的重新整理，界面上會以實時柱狀圖來顯示每幀的渲染時間，柱狀圖越高表示渲染時間越長，每個柱狀圖偏上都有一根代表16ms基準的綠色橫線，每一條豎着的柱狀線都包含三部分（藍色代表測量繪制display list的時間，紅色代表opengl渲染display list所需要的時間，黃色代表cpu等待gpu處理的時間），隻要我們每一幀的總時間低于基準線就不會發生ui卡頓問題（個别超出基準線其實也不算啥問題的）。
可以發現，這個工具是有局限性的，他雖然能夠看出來有幀耗時超過基準線導緻了丢幀卡頓，但卻分析不到造成丢幀的具體原因。是以說為了配合解決分析ui丢幀卡頓問題我們還需要借助traceview和systrace來進行原因追蹤，下面我們會介紹這兩種工具的。
上面說了，備援資源及邏輯等也可能會導緻加載和執行緩慢，是以我們就來看看lint這個工具是如何發現優化這些問題的（當然了，lint實際的功能是非常強大的，我們開發中也是經常使用它來發現一些問題的，這裡主要有點針對ui性能的說明了，其他的雷同）。
在android studio 1.4版本中使用lint最簡單的辦法就是将滑鼠放在代碼區點選右鍵->analyze->inspect code–>界面選擇你要檢測的子產品->點選确認開始檢測，等待一下後會發現如下結果：
可以看見，lint檢測完後給了我們很多建議的，我們重點看一個關于ui性能的檢測結果；上圖中高亮的那一行明确說明了存在備援的ui層級嵌套，是以我們是可以點選跳進去進行優化處理掉的。
當然了，lint還有很多功能，大家可以自行探索發揮，這裡隻是達到抛磚引玉的作用。
關于android的記憶體管理機制下面的一節會詳細介紹，這裡我們主要針對gc導緻的ui卡頓問題進行詳細說明。
android系統會依據記憶體中不同的記憶體資料類型分别執行不同的gc操作，常見應用開發中導緻gc頻繁執行的原因主要可能是因為短時間内有大量頻繁的對象建立與釋放操作，也就是俗稱的記憶體抖動現象，或者短時間内已經存在大量記憶體暫用介于門檻值邊緣，接着每當有新對象建立時都會導緻超越門檻值觸發gc操作。
如下是我工作中一個項目的一次經曆（我将代碼回退特意抓取的），出現這個問題的場景是一次壓力測試導緻整個系統卡頓，瞬間殺掉應用就ok了，究其原因最終查到是一個api的調運位置寫錯了方式，導緻一直被狂調，當普通使用時不會有問題，壓力測試必現卡頓。具體記憶體參考圖如下：
與此抖動圖對應的logcat抓取如下：
我們知道，類似上面logcat列印一樣，觸發垃圾回收的主要原因有以下幾種：
gc_malloc——記憶體配置設定失敗時觸發；
gc_concurrent——當配置設定的對象大小超過一個限定值（不同系統）時觸發；
gc_explicit——對垃圾收集的顯式調用(system.gc()) ；
gc_external_alloc——外部記憶體配置設定失敗時觸發；
可以看見，這種不停的大面積列印gc導緻所有線程暫停的操作必定會導緻ui視覺的卡頓，是以我們要避免此類問題的出現，具體的常見優化方式如下：
檢查代碼，盡量避免有些頻繁觸發的邏輯方法中存在大量對象配置設定；
盡量避免在多次for循環中頻繁配置設定對象；
避免在自定義view的ondraw()方法中執行複雜的操作及建立對象（譬如paint的執行個體化操作不要寫在ondraw()方法中等）；
對于并發下載下傳等類似邏輯的實作盡量避免多次建立線程對象，而是交給線程池處理。
當然了，有了上面說明gc導緻的性能後我們就該定位分析問題了，可以通過運作ddms->allocation tracker标簽打開一個新視窗，然後點選start tracing按鈕，接着運作你想分析的代碼，運作完畢後點選get allocations按鈕就能夠看見一個已配置設定對象的清單，如下：
點選上面第一個表格中的任何一項就能夠在第二個表格中看見導緻該記憶體配置設定的棧資訊，通過這個工具我們可以很友善的知道代碼配置設定了哪類對象、在哪個線程、哪個類、哪個檔案的哪一行。譬如我們可以通過allocation tracker分别做一次paint對象執行個體化在ondraw與構造方法的一個自定義view的記憶體跟蹤，然後你就明白這個工具的強大了。
ps一句，android studio新版本除過ddms以外在memory視圖的左側已經內建了allocation tracker功能，隻是用起來還是沒有ddms的友善實用，如下圖：
關于ui卡頓問題我們還可以通過運作traceview工具進行分析，他是一個分析器，記錄了應用程式中每個函數的執行時間；我們可以打開ddms然後選擇一個程序，接着點選上面的“start method profiling”按鈕（紅色小點變為黑色即開始運作），然後操作我們的卡頓ui（小範圍測試，是以操作最好不要超過5s），完事再點一下剛才按的那個按鈕，稍等片刻即可出現下圖，如下：
花花綠綠的一幅圖我們怎麼分析呢？下面我們解釋下如何通過該工具定位問題：
整個界面包括上下兩部分，上面是你測試的程序中每個線程運作的時間線，下面是每個方法（包含parent及child）執行的各個名額的值。通過上圖的時間面闆可以直覺發現，整個trace時間段main線程做的事情特别多，其他的做的相對較少。當我們選擇上面的一個線程後可以發現下面的性能面闆很複雜，其實這才是traceview的核心圖表，它主要展示了線程中各個方法的調用資訊（cpu使用時間、調用次數等），這些資訊就是我們分析ui性能卡頓的核心關注點，是以我們先看幾個重要的屬性說明，如下：
屬性名
name
線程中調運的方法名；
incl cpu time
目前方法（包含内部調運的子方法）執行占用的cpu時間；
excl cpu time
目前方法（不包含内部調運的子方法）執行占用的cpu時間；
incl real time
目前方法（包含内部調運的子方法）執行的真實時間，ms機關；
excl real time
目前方法（不包含内部調運的子方法）執行的真實時間，ms機關；
calls+recur calls/total
目前方法被調運的次數及遞歸調運占總調運次數百分比；
cpu time/call
目前方法調運cpu時間與調運次數比，即目前方法平均執行cpu耗時時間；
real time/call
目前方法調運真實時間與調運次數比，即目前方法平均執行真實耗時時間；（重點關注）
有了對上面traceview圖表的一個認識之後我們就來看看具體導緻ui性能後該如何切入分析，一般traceview可以定位兩類性能問題：
方法調運一次需要耗費很長時間導緻卡頓；
方法調運一次耗時不長，但被頻繁調運導緻累計時長卡頓。
譬如我們來舉個執行個體，有時候我們寫完app在使用時不覺得有啥大的影響，但是當我們啟動完app後靜止在那卻十分費電或者導緻裝置發熱，這種情況我們就可以打開traceview然後按照cpu time/call或者real time/call進行降序排列，然後打開可疑的方法及其child進行分析檢視，然後再回到代碼定位檢查邏輯優化即可；當然了，我們也可以通過該工具來trace我們自定義view的一些方法來權衡性能問題，這裡不再一一列舉喽。
可以看見，traceview能夠幫助我們分析程式性能，已經很友善了，然而traceview家族還有一個更加直覺強大的小工具，那就是可以通過dmtracedump生成方法調用圖。具體做法如下：
通過這個生成的方法調運圖我們可以更加直覺的發現一些方法的調運異常現象。不過本人優化到現在還沒怎麼用到它，每次用到traceview分析就已經搞定問題了，是以說dmtracedump自己酌情使用吧。
systrace其實有些類似traceview，它是對整個系統進行分析（同一時間軸包含應用及surfaceflinger、windowmanagerservice等子產品、服務運作資訊），不過這個工具需要你的裝置核心支援trace（指令行檢查/sys/kernel/debug/tracing）且裝置是eng或userdebug版本才可以，是以使用前麻煩自己确認一下。
我們在分析ui性能時一般隻關注圖形性能（是以必須選擇graphics和view，其他随意），同時一般對于卡頓的抓取都是5s，最多10s。啟動systrace進行資料抓取可以通過兩種方式，指令行方式如下：
圖形模式：
打開ddms->capture system wide trace using android systrace->設定時間與選項點選ok就開始了抓取，接着操作app，完事生成一個trace.html檔案，用chrome打開即可如下圖：
在chrome中浏覽分析該檔案我們可以通過鍵盤的w-a-s-d鍵來搞定，由于上面我們在進行trace時選擇了一些選項，是以上圖生成了左上方相關的cpu頻率、負載、狀态等資訊，其中的cpu n代表了cpu核數，每個cpu行的柱狀圖表代表了目前時間段目前核上的運作資訊；下面我們再來看看surfaceflinger的解釋，如下：
可以看見上面左邊欄的surfaceflinger其實就是負責繪制android程式ui的服務，是以surfaceflinger能反應出整體繪制情況，可以關注上圖vsync-app一行可以發現前5s多基本都能夠達到16ms重新整理間隔，5s多開始到7s多大于了15ms，說明此時存在繪制丢幀卡頓；同時可以發現surfaceflinger一行明顯存在類似不規律間隔，這是因為有的地方是不需要重新渲染ui，是以有大範圍不規律，有的是因為阻塞導緻不規律，明顯可以發現0到4s間大多是不需要渲染，而5s以後大多是阻塞導緻；對應這個時間點我們放大可以看到每個部分所使用的時間和正在執行的任務，具體如下：
可以發現具體的執行明顯存在逾時性能卡頓（原點不是綠色的基本都代表存在一定問題，下面和右側都會提示你選擇的幀相關詳細資訊或者alert資訊），但是遺憾的是通過systrace隻能大體上發現是否存在性能問題，具體問題還需要通過traceview或者代碼中嵌入trace工具類等去繼續詳細分析，總之很蛋疼。
ps：如果你想使用systrace很輕松的分析定位所有問題，看明白所有的行含義，你還需要具備非常紮實的android系統架構的原理才可以将該工具使用的得心應手。
anr（application not responding）是android中ams與wms監測應用響應逾時的表現；之是以把臭名昭著的anr單獨作為ui性能卡頓的分析來說明是因為anr是直接卡死ui不動且必須要解掉的bug，我們必須盡量在開發時避免他的出現，當然了，萬一出現了那就用下面介紹的方法來分析吧。
我們應用開發中常見的anr主要有如下幾類：
按鍵觸摸事件派發逾時anr，一般門檻值為5s（設定中開啟anr彈窗，預設有事件派發才會觸發彈框anr）；
廣播阻塞anr，一般門檻值為10s（設定中開啟anr彈窗，預設不彈框，隻有log提示）；
服務逾時anr，一般門檻值為20s（設定中開啟anr彈窗，預設不彈框，隻有log提示）；
當anr發生時除過logcat可以看見的log以外我們還可以在系統指定目錄下找到traces檔案或dropbox檔案進行分析，發生anr後我們可以通過如下指令得到anr trace檔案：
然後我們用txt編輯器打開可以發現如下結構分析：
至此常見的應用開發中anr分析定位就可以解決了。
可以看見，關于android ui卡頓的性能分析還是有很多工具的，上面隻是介紹了應用開發中我們經常使用的一些而已，還有一些其他的，譬如oprofile等工具不怎麼常用，這裡就不再詳細介紹。
布局優化；盡量使用include、merge、viewstub标簽，盡量不存在備援嵌套及過于複雜布局（譬如10層就會直接異常），盡量使用gone替換invisible，使用weight後盡量将width和heigh設定為0dp減少運算，item存在非常複雜的嵌套時考慮使用自定義item view來取代，減少measure與layout次數等。
清單及adapter優化；盡量複用getview方法中的相關view，不重複擷取執行個體導緻卡頓，清單盡量在滑動過程中不進行ui元素重新整理等。
背景和圖檔等記憶體配置設定優化；盡量減少不必要的背景設定，圖檔盡量壓縮處理顯示，盡量避免頻繁記憶體抖動等問題出現。
自定義view等繪圖與布局優化；盡量避免在draw、measure、layout中做過于耗時及耗記憶體操作，尤其是draw方法中，盡量減少draw、measure、layout等執行次數。
當然了，上面隻是列出了我們項目中常見的一些ui性能注意事項而已，相信還有很多其他的情況這裡沒有說到，歡迎補充。還有一點就是我們上面所謂的ui性能優化分析總結等都是建議性的，因為性能這個問題是一個涉及面很廣很泛的問題，有些優化不是必需的，有些優化是必需的，有些優化掉以後又是得不償失的，是以我們一般着手解決那些必須的就可以了。
系統級記憶體管理：
android系統核心是基于linux，是以說android的記憶體管理其實也是linux的更新版而已。linux在程序停止後就結束該程序，而android把這些停止的程序都保留在記憶體中，直到系統需要更多記憶體時才選擇性的釋放一些，保留在記憶體中的程序預設（不包含背景service與thread等單獨ui線程的程序）不會影響整體系統的性能（速度與電量等）且當再次啟動這些保留在記憶體的程序時可以明顯提高啟動速度，不需要再去加載。
可以看見，所謂的我們的service在背景跑着跑着挂了，或者盒子上有些大型遊戲啟動起來就挂（之前我在上家公司做盒子時遇見過），有一個直接的原因就是這個門檻值定義的太大，導緻系統一直認為已經達到門檻值，是以進行優先清除了符合類型的程序。是以說，該門檻值的設定是有一些講究的，額，扯多了，我們主要是針對應用層記憶體分析的，系統級記憶體回收了解這些就基本夠解釋我們應用在裝置上的一些表現特征了。
應用級記憶體管理：
在說應用級别記憶體管理原理時大家先想一個問題，假設有一個記憶體為1g的android裝置，上面運作了一個非常非常吃記憶體的應用，如果沒有任何機制的情況下是不是用着用着整個裝置會因為我們這個應用把1g記憶體吃光然後整個系統運作癱瘓呢？
哈哈，其實google的工程師才不會這麼傻的把系統設計這麼差勁。為了使系統不存在我們上面假想情況且能安全快速的運作，android的架構使得每個應用程式都運作在單獨的程序中（這些應用程序都是由zygote程序孵化出來的，每個應用程序都對應自己唯一的虛拟機執行個體）；如果應用在運作時再存在上面假想的情況，那麼癱瘓的隻會是自己的程序，不會直接影響系統運作及其他程序運作。
既然每個android應用程式都執行在自己的虛拟機中，那了解java的一定明白，每個虛拟機必定會有堆記憶體門檻值限制（值得一提的是這個門檻值一般都由廠商依據硬體配置及裝置特性自己設定，沒有統一标準，可以為64m，也可以為128m等；它的配置是在android的屬性系統的/system/build.prop中配置dalvik.vm.heapsize=128m即可，若存在dalvik.vm.heapstartsize則表示初始申請大小），也即一個應用程序同時存在的對象必須小于門檻值規定的記憶體大小才可以正常運作。
接着我們運作的app在自己的虛拟機中記憶體管理基本就是遵循java的記憶體管理機制了，系統在特定的情況下主動進行垃圾回收。但是要注意的一點就是在android系統中執行垃圾回收（gc）操作時所有線程（包含ui線程）都必須暫停，等垃圾回收操作完成之後其他線程才能繼續運作。這些gc垃圾回收一般都會有明顯的log列印出回收類型，常見的如下：
通過上面這幾點的分析可以發現，應用的記憶體管理其實就是一個蘿蔔一個坑，坑都一般大，你在開發應用時要保證的是記憶體使用同一時刻不能超過坑的大小，否則就裝不下了。
有了關于android的一些記憶體認識，接着我們來看看關于android應用開發中常出現的一種記憶體問題—-記憶體洩露。
衆所周知，在java中有些對象的生命周期是有限的，當它們完成了特定的邏輯後将會被垃圾回收；但是，如果在對象的生命周期本來該被垃圾回收時這個對象還被别的對象所持有引用，那就會導緻記憶體洩漏；這樣的後果就是随着我們的應用被長時間使用，他所占用的記憶體越來越大。如下就是一個最常見簡單的洩露例子（其它的洩露不再一一列舉了）：
可以看見，上面例子中我們讓一個單例模式的對象持有了目前activity的強引用，那在目前acvitivy執行完ondestroy()後，這個activity就無法得到垃圾回收，也就造成了記憶體洩露。
記憶體洩露可以引發很多的問題，常見的記憶體洩露導緻問題如下：
應用卡頓，響應速度慢（記憶體占用高時jvm虛拟機會頻繁觸發gc）;
應用被從背景程序幹為空程序（上面系統記憶體原理有介紹，也就是超過了門檻值）；
應用莫名的崩潰（上面應用記憶體原理有介紹，也就是超過了門檻值oom）；
造成記憶體洩露洩露的最核心原理就是一個對象持有了超過自己生命周期以外的對象強引用導緻該對象無法被正常垃圾回收；可以發現，應用記憶體洩露是個相當棘手重要的問題，我們必須重視。
知道了記憶體洩露的概念之後肯定就是想辦法來确認自己的項目是否存在記憶體洩露了，那該如何察覺自己項目是否存在記憶體洩露呢？如下提供了幾種常用的方式：
察覺方式
場景
as的memory視窗
平時用來直覺了解自己應用的全局記憶體情況，大的洩露才能有感覺。
ddms-heap記憶體監測工具
同上，大的洩露才能有感覺。
dumpsys meminfo指令
常用方式，可以很直覺的察覺一些洩露，但不全面且正常足夠用。
leakcanary神器
比較強大，可以感覺洩露且定位洩露；實質是mat原理，隻是更加自動化了，當現有代碼量已經龐大成型，且無法很快察覺掌控全局代碼時極力推薦；或者是偶現洩露的情況下極力推薦。
as的memory視窗如下，詳細的說明這裡就不解釋了，很簡單很直覺（使用頻率高）：
ddms-heap記憶體監測工具視窗如下，詳細的說明這裡就不解釋了，很簡單（使用頻率不高）：
dumpsys meminfo指令如下（使用頻率非常高，非常高效，我的最愛之一，平時一般關注幾個重要的object個數即可判斷一般的洩露；當然了，adb shell dumpsys meminfo不跟參數直接展示系統所有記憶體狀态）：
leakcanary神器使用這裡先不說，下文會專題介紹，你會震撼的一b。有了這些工具的定位我們就能很友善的察覺我們app的記憶體洩露問題，察覺到以後該怎麼定位分析呢，繼續往下看。
leakcanary是一個開源項目，一個記憶體洩露自動檢測工具，是著名的github開源組織square貢獻的，它的主要優勢就在于自動化過早的發覺記憶體洩露、配置簡單、抓取貼心，缺點在于還存在一些bug，不過正常使用百分之九十情況是ok的，其核心原理與mat工具類似。
ps：之前在優化性能時發現我們有一個應用有兩個界面退出後activity沒有被回收（dumpsys meminfo發現一直在加），是以就懷疑可能存在記憶體洩露。但是問題來了，這兩個activity的邏輯十分複雜，代碼也不是我寫的，相關聯的代碼量也十分龐大，更加郁悶的是很難判斷是哪個版本修改導緻的，這時候隻知道有洩露，卻無法定位具體原因，使用mat分析解決掉了一個可疑洩露後發現洩露又變成了機率性的。可以發現，對于這種機率性的洩露用mat去主動抓取肯定是很耗時耗力的，是以決定直接引入leakcanary神器來檢測項目，後來很快就徹底解決了項目中所有必現的、偶現的記憶體洩露。
總之一點，工具再強大也隻是幫我們定位可能的洩露點，而最核心的gc root洩露資訊推導出洩露問題及如何解決還是需要你把住代碼邏輯及洩露核心概念去推了解決。
ps：這是開發中使用頻率非常高的一個工具之一，麻煩務必掌握其核心使用技巧，雖然android studio已經實作了部分功能，但是真的很難用，遇到問題目前還是使用eclipse memory analysis tools吧。
原諒我該小節的放蕩不羁！！！！（其實我是困了，嗚嗚！）
有了上面的原理及案例處理其實還不夠，因為上面這些處理辦法是補救的措施，我們正确的做法應該是在開發過程中就養成良好的習慣和敏銳的嗅覺才對，是以下面給出一些應用開發中常見的規避記憶體洩露建議：
context使用不當造成記憶體洩露；不要對一個activity context保持長生命周期的引用（譬如上面概念部分給出的示例）。盡量在一切可以使用應用applicationcontext代替context的地方進行替換（原理我前面有一篇關于context的文章有解釋）。
非靜态内部類的靜态執行個體容易造成記憶體洩漏；即一個類中如果你不能夠控制它其中内部類的生命周期（譬如activity中的一些特殊handler等），則盡量使用靜态類和弱引用來處理（譬如viewroot的實作）。
警惕線程未終止造成的記憶體洩露；譬如在activity中關聯了一個生命周期超過activity的thread，在退出activity時切記結束線程。一個典型的例子就是handlerthread的run方法是一個死循環，它不會自己結束，線程的生命周期超過了activity生命周期，我們必須手動在activity的銷毀方法中中調運thread.getlooper().quit();才不會洩露。
對象的注冊與反注冊沒有成對出現造成的記憶體洩露；譬如注冊廣播接收器、注冊觀察者（典型的譬如資料庫的監聽）等。
建立與關閉沒有成對出現造成的洩露；譬如cursor資源必須手動關閉，webview必須手動銷毀，流等對象必須手動關閉等。
不要在執行頻率很高的方法或者循環中建立對象，可以使用hashtable等建立一組對象容器從容器中取那些對象，而不用每次new與釋放。
避免代碼設計模式的錯誤造成記憶體洩露；譬如循環引用，a持有b，b持有c，c持有a，這樣的設計誰都得不到釋放。
關于規避記憶體洩露上面我隻是列出了我在項目中經常遇見的一些情況而已，肯定不全面，歡迎拍磚！當然了，隻有我們做到好的規避加上強有力的判斷嗅覺洩露才能讓我們的應用駕馭好自己的一畝三分地。
上面談論了android應用開發的記憶體洩露，下面談談記憶體溢出（oom）；其實可以認為記憶體溢出與記憶體洩露是交集關系，具體如下圖：
下面我們就來看看記憶體溢出（oom）相關的東東吧。
上面我們探讨了android記憶體管理和應用開發中的記憶體洩露問題，可以知道記憶體洩露一般影響就是導緻應用卡頓，但是極端的影響是使應用挂掉。前面也提到過應用的記憶體配置設定是有一個門檻值的，超過門檻值就會出問題，這裡我們就來看看這個問題—–記憶體溢出（oom–outofmemoryerror）。
記憶體溢出的主要導緻原因有如下幾類：
應用代碼存在記憶體洩露，長時間積累無法釋放導緻oom；
應用的某些邏輯操作瘋狂的消耗掉大量記憶體（譬如加載一張不經過處理的超大超高清圖檔等）導緻超過門檻值oom；
可以發現，無論哪種類型，導緻記憶體溢出（outofmemoryerror）的核心原因就是應用的記憶體超過門檻值了。
通過上面的oom概念和那幅交集圖可以發現，要想分析oom原因和避免oom需要分兩種情況考慮，洩露導緻的oom，申請過大導緻的oom。
記憶體洩露導緻的oom分析：
這種oom一旦發生後會在logcat中列印相關outofmemoryerror的異常棧資訊，不過你别高興太早，這種情況下導緻的oom列印異常資訊是沒有太大作用，因為這種oom的導緻一般都如下圖情況（圖示為了說明問題資料和場景有誇張，請忽略）：
從圖檔可以看見，這種oom我們有時也遇到，第一反應是去分析oom異常列印棧，可是後來發現列印棧列印的地方沒有啥問題，沒有可優化的餘地了，于是就郁悶了。其實這時候你留心觀察幾個現象即可，如下：
留意你執行觸發oom操作前的界面是否有卡頓或者比較密集的gc列印；
使用指令檢視下目前應用占用記憶體情況；
确認了以上這些現象你基本可以斷定該oom的log真的沒用，真正導緻問題的原因是記憶體洩露，是以我們應該按照上節介紹的方式去着手排查記憶體洩露問題，解決掉記憶體洩露後紅色空間都能得到釋放，再去顯示一張0.8m的優化圖檔就不會再報oom異常了。
不珍惜記憶體導緻的oom分析：
上面說了記憶體洩露導緻的oom異常，下面我們再來看一幅圖（資料和場景描述有誇張，請忽略），如下：
可見，這種類型的oom就很好定位原因了，一般都可以從oom後的log中得出分析定位。
如下例子，我們在activity中的imageview放置一張未優化的特大的（30多m）高清圖檔，運作直接崩潰如下：
通過上面的log可以很友善的看出來問題原因所在地，那接下來的做法就是優化呗，降低圖檔的相關規格即可（譬如使用bitmapfactory的option類操作等）。
ps：提醒一句的是記得應用所屬的記憶體是區分java堆和native堆的！
還是那句話，等待oom發生是為時已晚的事，我們應該将其扼殺于萌芽之中，至于如何在開發中規避oom，如下給出一些我們應用開發中的常用的政策建議：
優化界面互動過程中頻繁的記憶體使用；譬如在清單等操作中隻加載可見區域的bitmap、滑動時不加載、停止滑動後再開始加載。
有些地方避免使用強引用，替換為弱引用等操作。
避免各種記憶體洩露的存在導緻oom。
對批量加載等操作進行緩存設計，譬如清單圖檔顯示，adapter的convertview緩存等。
盡可能的複用資源；譬如系統本身有很多字元串、顔色、圖檔、動畫、樣式以及簡單布局等資源可供我們直接使用，我們自己也要盡量複用style等資源達到節約記憶體。
對于有緩存等存在的應用盡量實作onlowmemory()和ontrimmemory()方法。
盡量使用線程池替代多線程操作，這樣可以節約記憶體及cpu占用率。
盡量管理好自己的service、thread等背景的生命周期，不要浪費記憶體占用。
盡可能的不要使用依賴注入，中看不中用。
盡量在做一些大記憶體配置設定等可疑記憶體操作時進行try catch操作，避免不必要的應用閃退。
盡量的優化自己的代碼，減少備援，進行編譯打包等優化對齊處理，避免類加載時浪費記憶體。
可以發現，上面隻是列出了我們開發中常見的導緻oom異常的一些規避原則，還有很多相信還沒有列出來，大家可以自行追加參考即可。
無論是什麼電子裝置的開發，記憶體問題永遠都是一個很深奧、無底洞的話題，上面的這些記憶體分析建議也單單隻是android應用開發中一些常見的場景而已，真正的達到合理的優化還是需要很多知識和功底的。
合理的應用架構設計、設計風格選擇、開源lib選擇、代碼邏輯規範等都會決定到應用的記憶體性能，我們必須時刻頭腦清醒的意識到這些問題潛在的風險與優劣，因為記憶體優化必須要有一個度，不能一味的優化，亦不能置之不理。
在我們開發中除過正常的那些經典ui、記憶體性能問題外其實還存在很多潛在的性能優化、這種優化不是十分明顯，但是在某些場景下卻是非常有必要的，是以我們簡單列舉一些常見的其他潛在性能優化技巧，具體如下探讨。
字元串操作在android應用開發中是十分常見的操作，也就是這個最簡單的字元串操作卻也暗藏很多潛在的性能問題，下面我們執行個體來說說。
先看下面這個關于string和stringbuffer的對比例子：
通過這個例子可以看出來，string對象（記得是對象，不是常量）和stringbuffer對象的主要性能差別在于string對象是不可變的，是以每次對string對象做改變操作（譬如“+”操作）時其實都生成了新的string對象執行個體，是以會導緻記憶體消耗性能問題；而stringbuffer對象做改變操作每次都會對自己進行操作，是以不需要消耗額外的記憶體空間。
我們再看一個關于string和stringbuffer的對比例子：
在這種情況下你會發現stringbuffer的性能反而沒有string的好，原因是在jvm解釋時認為
<code>string str = "name:" + "gjrs";</code>就是<code>string str = "name:gjrs";</code>，是以自然比stringbuffer快了。
可以發現，如果我們拼接的是字元串常量則string效率比stringbuffer高，如果拼接的是字元串對象，則stringbuffer比string效率高，我們在開發中要酌情選擇。當然，除過注意stringbuffer和string的效率問題，我們還應該注意另一個問題，那就是stringbuffer和stringbuilder的差別，其實stringbuffer和stringbuilder都繼承自同一個父類，隻是stringbuffer是線程安全的，也就是說在不考慮多線程情況下stringbuilder的性能又比stringbuffer高。
ps：如果想追究清楚他們之間具體細節差異，麻煩自己檢視實作源碼即可。
ontrimmemory是android 4.0之後加入的一個回調方法，作用是通知應用在不同的情況下進行自身的記憶體釋放，以避免被系統直接殺掉，提高應用程式的使用者體驗（冷啟動速度是熱啟動的2~3倍）。系統會根據目前不同等級的記憶體使用情況調用這個方法，并且傳入目前記憶體等級，這個等級有很多種，我們可以依據情況實作不同的等級，這裡不詳細介紹，但是要說的是我們應用應該至少實作如下等級：
trim_memory_background
記憶體已經很低了，系統準備開始根據lru緩存來清理程序。這時候如果我們手動釋放一些不重要的緩存資源，則當使用者傳回我們應用時會感覺到很順暢，而不是重新啟動應用。
可以實作ontrimmemory方法的系統元件有application、activity、fragement、
service、contentprovider；關于ontrimmemory釋放哪些記憶體其實在架構階段就要考慮清楚哪些對象是要常駐記憶體的，哪些是伴随元件周期存在的，一般需要釋放的都是緩存。
如下給出一個我們項目中常用的例子：
通常在我們代碼實作了ontrimmemory後很難複顯這種記憶體消耗場景，但是你又怕引入新bug，想想辦法測試。好在我們有一個快捷的方式來模拟觸發該水準記憶體釋放，如下指令：
packagename為包名或者程序id，value為componentcallbacks2.java裡面定義的值，可以為80、60、40、20、5等，我們模拟觸發其中的等級即可。
在android開發中涉及到資料邏輯部分大部分用的都是java的api（譬如hashmap），但是對于android裝置來說有些java的api并不适合，可能會導緻系統性能下降，好在google團隊已經意識到這些問題，是以他們針對android裝置對java的一些api進行了優化，優化最多就是使用了arraymap及sparsearray替代hashmap來獲得性能提升。
hashmap：
hashmap内部使用一個預設容量為16的數組來存儲資料，數組中每一個元素存放一個連結清單的頭結點，其實整個hashmap内部結構就是一個哈希表的拉鍊結構。hashmap預設實作的擴容是以2倍增加，且擷取一個節點采用了周遊法，是以相對來說無論從記憶體消耗還是節點查找上都是十分昂貴的。
sparsearray：
sparsearray比hashmap省記憶體是因為它避免了對key進行自動裝箱（int轉integer），它内部是用兩個數組來進行資料存儲的（一個存key，一個存value），它内部對資料采用了壓縮方式來表示稀疏數組資料，進而節約記憶體空間，而且其查找節點的實作采用了二分法，很明顯可以看見性能的提升。
arraymap：
arraymap内部使用兩個數組進行資料存儲，一個記錄key的hash值，一個記錄value值，它和sparsearray類似，也會在查找時對key采用二分法。
有了上面的基本了解我們可以得出結論供開發時參考，當資料量不大（千位級内）且key為int類型時使用sparsearray替換hashmap效率高；當資料量不大（千位級内）且資料類型為map類型時使用arraymap替換hashmap效率高；其他情況下hashmap效率相對高于二者。
contentprovider是android應用開發的核心元件之一，有時候在開發中需要使用contentprovider對多行資料進行操作，我們的做法一般是多次調運相關操作方法，殊不知這種實作方式是非常低性能的，取而代之的做法應該是使用批量操作，具體為了使批量更新、插入、删除資料操作更加友善官方提供了contentprovideroperation工具類。是以在我們開發中遇到類似情景時請務必使用批量操作，具體的優勢如下：
所有的操作都在一個事務中執行，可以保證資料的完整性。
批量操作在一個事務中執行，是以隻用打開、關閉一個事務。
減輕應用程式與contentprovider間的多次頻繁互動，提升性能。
可以看見，這對于資料庫操作來說是一個非常有用的優化措施，煩請務必重視（我們項目優化過，的确有很大提升）。
關于api及邏輯性能優化其實有多知識點的，這裡無法一一列出，隻能給出一些重要的知識點，下面再給出一些常見的優化建議：
避免在android中使用java的枚舉類型，因為編譯後不但占空間，加載也費時，完全沒有static final的變量好用、高效。
handler發送消息時盡量使用obtain去擷取已經存在的message對象進行複用，而不是新new message對象，這樣可以減輕記憶體壓力。
在使用背景service時盡量将能夠替換為intentservice的地方替換為此，這樣可以減輕系統壓力、省電、省記憶體、省cpu占用率。
在目前類内部盡量不要通過自己的getxxx、setxxx對自己内部成員進行操作，而是直接使用，這樣可以提高代碼執行效率。
不要一味的為了設計模式而過分的抽象代碼，因為代碼抽象系數與代碼加載執行時間成正比。
盡量減少鎖個數、減小鎖範圍，避免造成性能問題。
合理的選擇使用for循環與增強型for循環，譬如不要在arraylist上使用增強型for循環等。
哎呀，類似的小優化技巧有很多，這裡不一一列舉了，自行發揮留意即可。
有了ui性能優化、記憶體性能優化、代碼編寫優化之後我們在來說說應用開發中很重要的一個優化子產品—–電量優化。
在盒子等開發時可能電量優化不是特别重視（視盒子待機真假待機模式而定），但是在移動裝置開發中耗電量是一個非常重要的名額，如果使用者一旦發現我們的應用非常耗電，不好意思，他們大多會選擇解除安裝來解決此類問題，是以耗電量是一個十分重要的問題。
其實我們一款應用耗電量最大的部分不是ui繪制顯示等，常見耗電量最大原因基本都是因為網絡資料互動、gps定位、大量記憶體性能問題、備援的背景線程和service等造成。
優化電量使用情況我們不僅可以使用系統提供的一些api去處理，還可以在平時編寫代碼時就養成好的習慣。具體的一些建議如下：
在需要網絡的應用中，執行某些操作前盡量先進行網絡狀态判斷。
在網絡應用傳輸中使用高效率的資料格式和解析方法，譬如json等。
在傳輸使用者回報或者下載下傳ota更新包等不是十分緊急的操作時盡量采用壓縮資料進行傳輸且延遲到裝置充電和wifi狀态時進行。
在有必要的情況下盡量通過powermanager.wakelock和jobscheduler來控制一些邏輯操作達到省電優化。
對定位要求不太高的場景盡量使用網絡定位，而不是gps定位。
對于定時任務盡量使用alarmmanager，而不是sleep或者timer進行管理。
盡可能的減少網絡請求次數和減小網絡請求時間間隔。
背景任務要盡可能少的喚醒cpu，譬如im通信的長連接配接心跳時間間隔、一些應用的背景定時喚醒時間間隔等要設計合理。
特殊耗電業務情況可以進行彈窗等友好的互動設計提醒使用者該操作會耗用過多電量。
可以看見，上面隻是一些常見的電量消耗優化建議。總之，作為應用開發者的我們要意識到電量損耗對于使用者來說是非常敏感的，隻有我們做到合理的電量優化才能赢得使用者的芳心。
性能優化是一個很大的話題，上面我們談到的隻是應用開發中常見的性能問題，也是應用開發中性能問題的冰山一角，更多的性能優化技巧和能力不是靠看出來，而是靠經驗和實戰結果總結出來的，是以說性能優化是一個涉及面非常廣的話題，如果你想對你的應用進行性能你必須對你應用的整個架構有一個非常清晰的認識。
當然了，如果在我們開發中隻是一味的追求各種極緻的優化也是不對的。因為優化本來就是存在風險的，甚至有些過度的優化會直接導緻項目的臃腫，是以不要因為極緻的性能優化而破壞掉了你項目的合理架構。
總之一句話，性能優化适可而止，請酌情優化。