版權聲明：本文章原創於 RamboPan ，未經允許，請勿轉載。
記錄一次使用 Android Profiler 分析內存
最近一個老項目需要更新，就想着把之前蒐集的一些小問題一起修復了，然後測試了下，發現了一個情況，就是在查看歷史數據模塊的時候，進入比進入其他模塊時間稍微長一點，想着優化下。
點擊可能有點暗，gif 上看不出來，我點擊的時候水波觸發暫停，還是能感覺間隔有點長。
看代碼前懷疑是不是讀數據庫時有點緩慢，在代碼中加入日誌觀察，發現讀數據庫並不緩慢，在大量代碼中如何快速查找可能耗時的部分呢，想到了之前 AS 中 Profiler 可以查看內存的情況，當時也有一些其他參數，甚至在 8.0 上的系統也支持電量查看，那麼此時我們就可以試試這個好用不。
一般會自動出現在常用的工具欄附近，可以看到是一個類似儀表指針的圖標，沒有的話，可以在上方菜單欄中查找。
點擊之後將程序跑起來，下方菜單欄會出現 Profier 對話框，依次是 CPU 、Memory、Network、Energy，顯示需要查看的幾個選項，這裏我們選擇 CPU。
這裏會顯示線程有關的，但是我們重點不是觀察線程，是查看點擊之後進行了哪些操作導致時間花費比較高，所以等程序進入主界面一會後，CPU 慢慢穩定之後，點擊 Record ，再點擊我們要測試的模塊，進入模塊之後再點擊一次 Record 位置（此時顯示爲 Stop），那麼就會得出一段分析的區間。
可以看到這種時間段，從上到下依次是調用的方法以及層級關係。
- 橙色部分是 Android 系統的方法。
- 藍色部分是 Java 的方法。
- 綠色部分是我們的代碼。
比如沿着左邊的分支可以看到顯示 Android 的方法調用，觸發了 java.lang.reflect.Method.invoke，再回到 Android 的代碼調用最後走到我們的代碼，因爲 getLocalDate 中涉及一些數據處理，實現部分也是 Android ，Java 的代碼，所以最後末端變成橙色和藍色的時間小塊。
我們重點觀察是圖中綠色部分，特別是整塊的綠色。圖中能看到的有我們類的 onCreate 方法，中間一整塊部分下方也有我們的方法，只是此處沒有截取到。
圖中的包名部分因爲顯示區間太小，所以沒有完全顯示出來，這裏可以滑動滾輪將時間精度放大，也可以把鼠標移上去可以看到顯示的，那我們先來找一找這個方法有沒有。
可以看到確實是能找到我們對應的方法，但是檢查了下這裏面代碼，裏面時間優化的空間不大，那我們看有沒有其他大的耗時部分，我們把界面往下拉一下。
可以看到這裏有幾個詞語反覆出現，感覺真相可能在這，我們放大來看一看。
移到對應的時間塊上可以顯示出時間，此時的縮放比例，我標出了一個圖中方塊的單位是 50ms ，可以發現中間有很多重複的調用，每個都是 50ms 左右或者更長，我看大概算了這幾個綠色部分花了 1 .1 秒（流下了心痛的淚水），看來就是真兇沒錯，那我們按着這些方法來看一下問題出在哪了。
按着上圖的指示，我們來查找這五個方法。首先是 instantiateItem ，再是 applyDataToView。
接下來找剩下三個方法。
查看三處的代碼。
可以看到一個共同的特點，都是在實現獲得一個時間戳的字符串形式或者其中的部分。
先不說是否耗時，就邏輯上來說：如果需要反覆用，在類裏面加一個字符串的時間戳變量就行了，在保存 long 類型時間時，同時解出一個 String 類型的時間戳保存下來。
這還不是最氣的，打開 DateUtils.dateToString() 這個方法。
這 …… 既然做成了靜態的工具類，直接存一個靜態的變量呀 …… 前人挖坑，後人踩坑。🙃
更詳細的使用可以參考以下的鏈接 (需要科學上網)。