Android的性能優化（下）

應用APP內存的使用，也是評價一個應用性能高低的一個重要的指標。所以不管什麼樣的應用，都應該把內存效率，用戶體驗放在首位。
由於Android應用的沙箱機制（一種安全機制），每一個應用分的的內存大小是有限度的，內存太低就會觸發LMK(low memory killer)機制，先來簡單的說說手機的內存吧：

寄存器
寄存器擁有非常高的讀寫速度，速度最快的存儲場所，因為寄存器位於處理器內部，在程序中是無法控制的。cpu訪問快慢的速度依次為寄存器（register）-> 緩存(cache)->內存（memeory）->硬盤（disk）.

棧
一些基本類型的變量和對象的引用變量都是在函數的棧內存中分配的，當在一段代碼塊中定義一個變量時，java就在棧中為這個變量分配內存空間，當超過變量的作用域後，java會自動釋放掉為該變量分配的內存空間，該內存空間可以立刻被另作他用。但是對象本身是不存放在棧中的，而是存放在堆中的。

堆
堆內存是用來存放由new創建的對象和數組的，在堆中分配的內存，由Java虛擬機的自動垃圾回收機制來回收。在堆中產生了一個數組或者對象後，還可以在棧中定義一個特殊的變量，這個變量的取值等於數組或者對象在堆內存中的首地址，在棧中的這個特殊的變量就變成了數組或者對象的引用變量，以後就可以在程序中使用棧內存中的引用變量來訪問堆中的數組或者對象，引用變量相當於為數組或者對象起的一個別名，或者代號。
引用變量是普通變量，定義時在棧中分配內存，引用變量在程序運行到作用域外釋放。而數組＆對象本身在堆中分配，即使程序運行到使用new產生數組和對象的語句所在地代碼塊之外，數組和對象本身占用的堆內存也不會被釋放，數組和對象在沒有引用變量指向它的時候，才變成垃圾，不能再被使用，但是仍然占著內存，在隨後的一個不確定的時間被垃圾回收器釋放掉。這個也是java比較占內存的主要原因，實際上，棧中的變量指向堆內存中的變量，這就是 Java 中的指針!

靜態存儲區域
在固定的位置存放應用程序運行時一直存在的數據。內存在程序編譯的時候就已經分配好，這塊內存在程序的整個運行期間都存在。它主要存放靜態數據、全局數據和常量。

常量池
JVM虛擬機必須為每一個加載的類維護一個常量池，常量串詞就是該類型所用到常量的一個有序的集合，包括直接常量（基本類型，String）和其他類型，字段，方法的符號引用。

1.獲取Android系統的內存信息

Meminfo

Meminfo是系統上一個重要的內存監視工具，可以通過設置—>應用程序—>正在運行打開所有正在運行的APP的內存使用情況。

2.內存回收

Java對於C,C++這類語言最大的優勢就是不用手動的管理系統資源，Java創建了垃圾收集器線程來自動進行資源的管理。但是自動回收也帶來一個問題就是在何時進行垃圾回收是開發者所不能控制的，即使是調用了System.gc()方法，也只是建議系統進行GC,但是系統是否采納你的建議那就不一定了，這樣就有可能造成忘記回收的現象，這就是造成內存洩露的原因。

內存優化的實例

從Bitmap和代碼的兩個角度來對代碼進行優化。

Bitmap的優化

我們在使用bitmap的時候經常出現的一個問題就是OOM（out of memory).在使用bitmap的時候也有一些小技巧。

使用適當分辨率和大小的圖片
由於Android系統在做資源適配的時候會對不同分辨率文件夾下的圖片進行縮放來適配相應的分辨率，如果圖片分辨率與資源文件夾分辨率不匹配或者圖片的分辨率太高，就會導致系統消耗更多的內存資源。同時，在適當的時候，應該顯示合適大小的圖片，例如在圖片列表界面可以使用縮略圖thumbnails,而在顯示詳細圖片的時候再顯示原圖，或者是在對圖像要求不高的地方，盡量降低圖片的精度。

及時回收內存
一旦使用完Bitmap後，一定要及時使用bitmap.recycle()方法釋放內存資源，但是自從Android 3.0之後，由於Bitmap被放置到堆中，其內存由GC管理，就不需要進行釋放了。

使用圖片緩存
通過內存緩存（LruCache）和硬盤緩存（DiskLruCache）可以更好地使用Bitmap。

代碼的優化

對常量使用static修飾符 使用靜態方法，靜態方法會比普通方法提高15%左右的訪問速度 減少不必要的成員變量，這點在Android Lint工具上已經集成了，如果一個變量可以定義成局部變量，則會提示你不要哦定義成成員變量 減少不必要的對象，使用基礎類型比使用對象更加的節省資源，同時避免頻繁的創建短作用域的變量 盡量少使用枚舉類型，少使用迭代器 對Cursor,Receiver,Sensor,File等對象的時候，要注意該對象的創建，回收和注冊，取消注冊。 使用SurfaceView來替代View進行大量，頻繁的繪圖操作 多使用視圖緩存技術，而不是每次都執行inflate（）方法解析視圖

3.Lint工具

Android Lint工具是Android Studio中集成的一個Android代碼提示工具，它可以對我們的布局，代碼提供非常強大的幫助，它可以檢查出：xml文件中是否存在hardcode硬編碼、unused resources沒有使用到的資源、probable bug可能的bug,可能出現的冗余布局等等。

4.Android Studio的Memory Monitor工具

Memory Monitor是Android Studio自帶的一個內存監視工具，可以很好的幫我們進行內存實時的分析，Memory Monitor裡面包括了內存分析，cpu的占用比，gpu的繪制速度，以及網略請求的下載速度等分析工具：
vc/Hs8C2yau0+rHtZnJlZbXExNq05qOsye7Jq7XEsr+31rT6se21xMrHyrnTw7XExNq05rTTxNq05rHku7u1xNffysbNvKOsv8nS1MXQts/E2rTmtcTKudPDx+m/9qOswP3I57WxxNq05rPW0PjU9rjftcTKsbryv8nE3LeiyfrE2rTm0LnCtqOstbHE2rTmzbvIu7z1ydm1xMqxuvK+zdPQv8nE3LG7R0O72MrVwcuhozwvcD4NCjxoNCBpZD0="5使用traceview工具優化app性能">5.使用TraceView工具優化APP性能

TraceView是Android下的一個日志分析下工具。

5.1生成TraceView日志的兩種方法

生成TraceView日志的兩種方法，一種是利用Debug類幫助我們呢生成日志文件，另一種是利用Android Device Monitor工具輔助生成日志文件。

通過代碼生成精確范圍的生成TraceView的日志
使用Debug類的startMethodTracing()方法開啟日志的記錄，通過Debug類的stopMethodTracing()方法結束日志的監聽。將這兩個方法對某一代碼塊進行監聽，就可以記錄該代碼塊中的日志情況。比如說在onCreate()方法中調用startMethodTracing()方法，在onDestory()方法中調用stopMethodTracing（）方法結束日志的打印。TraceView的日志最終將會保存到SD卡中。也可以調用startMethodTracing(String traceName) 設置trace文件的文件名，最後使用adb pull /sdcard/test.trace /tmp 命令將trace文件復制到你的電腦中，用DDMS工具就可以打開了。
寫入SD卡中，注意要添加權限：

通過Android Device Monitor生成TraceView日志
在Android Studio的Android Device Monitor工具，選擇要調式的進程，點擊工具欄中的“start method profiling”按鈕。

6.分析TraceView日志

由於自己的Android手機沒有Root，所以此處就借用Genymotion中系統的程序（calendar）進行分析下。

時間軸區域內顯示了不同線程在不同的時間段內的執行情況，在時間軸中，每一行都代表了一個獨立的線程。在時間軸中我們可以看到不同的顏色，每種顏色代表不同的函數和步驟，同一顏色表示的區間越大，表示這個方法運行時間越長。

Profile區域顯示的是所有的調用方法，前面的是編號，展開後可以看到有Parent和Children子項，點擊Parents下的方法名，直接跳轉到調用當前的方法處。Children相反。

Profile區域主要顯示的信息：

Inclusive time - 函數本身運行花費時間 + 函數調用其他函數時間

Exclusive time - 函數本身運行花費時間

Calls + RecurCall/Total 調用 + 重復調用次數 / 函數總調用次數

Cpu Time/Call 總的Cpu時間與總的調用次數之比

每一個時間都包含兩列，一個是實際的時間，另一個是百分比，分析的時候對占用時間長的方法進行重點的分析，如果說占用的時間長且調用的次數少，那麼就是重點懷疑的對象了。