一個APP通常就是一個進程對應一個虛擬機
獲取內存大小：
GC只在Heap剩余空間不足的時候才觸發垃圾回收
GC觸發時，所有的線程都是會被暫停的
每個App分配的內存限制，隨不同設備而不同
吃內存大戶：圖片
App內存優化方法：1:數據結構優化 ? 2：對象復用
數據結構優化：
頻繁字符串拼接用StringBuillder(字符串通過+的方式拼接，會產生中間字符串內存塊，這些都是沒用的并且更耗時更低效)！
ArrayMap,SparseArray替換HashMap(ArrayMap,SparseArray效率更高，內存更小，使用方法和HashMap一樣的,HashMap一個entry需要額外占用的32B)
內存抖動（突然間生成很多對象，變量或內存空間后用了沒多久又不用了，如此反復就是內存抖動，內存像波浪形一會高一會低）
再小的class耗費0.5KB（盡量復用class）
對象復用：
復用系統自帶的資源
ListView/GridView的ConvertView復用
避免在OnDraw方法里面執行對象的創建（在OnDraw中對象的變更會重繪View）
避免內存泄漏：
內存泄漏會導致剩余可用的Heao越來越少，頻繁觸發GC
尤其Activity泄漏（如果有耗時操作為執行完，則GC無法回收還在被引用的資源）
用Application Context而不是Activity Context
注意Cursor對象是否及時關閉（數據庫操作時）
強引用和軟引用的意義：
優化OOM問題的方法：
注意臨時BitMap對象的及時回收
避免BitMap的浪費
Try catch某些大內存分配的操作
加載BitMap:縮放比例，解碼格式，局部加載
OOM絕大部分發生在圖片
