在沒有JIT(Just In Time Compiler)時鹃栽，直接訪問變量的速度是調用getter的3倍。有JIT時旨涝，直接訪問變量的速度是通過getter訪問的7倍。
使用ArrayList時缚态，for-i循環(huán)會快3倍（不管有沒有JIT），但是對于其他collection堤瘤，增強的for-each循環(huán)寫法會和迭代器寫法的效率一樣玫芦。
Android系統(tǒng)中float類型的數據存取速度是int類型的一半，盡量優(yōu)先采用int類型本辐。
就速度而言桥帆，現代硬件上，float 和 double 的速度是一樣的慎皱±铣妫空間而言，double 是兩倍float的大小茫多。在空間不是問題的情況下祈匙，你應該使用 double 。
同樣，對于整型夺欲，有些處理器實現了硬件幾倍的乘法跪帝，但是沒有除法。這時些阅，整型的除法和取余是在軟件內部實現的伞剑，這在你使用哈希表或大量計算操作時要考慮到。
為了能夠接收到用戶離開你的UI時的通知市埋，你需要實現Activtiy類里面的onTrimMemory()回調方法黎泣。你應該使用這個方法來監(jiān)聽到TRIM_MEMORY_UI_HIDDEN級別的回調，此時意味著你的UI已經隱藏腰素，你應該釋放那些僅僅被你的UI使用的資源聘裁。
- 當內存緊張時釋放部分內存
在你的app生命周期的任何階段，onTrimMemory的回調方法同樣可以告訴你整個設備的內存資源已經開始緊張弓千。你應該根據onTrimMemory回調中的內存級別來進一步決定釋放哪些資源。
TRIM_MEMORY_RUNNING_MODERATE：你的app正在運行并且不會被列為可殺死的献起。但是設備此時正運行于低內存狀態(tài)下洋访，系統(tǒng)開始觸發(fā)殺死LRU Cache中的Process的機制。
TRIM_MEMORY_RUNNING_LOW：你的app正在運行且沒有被列為可殺死的谴餐。但是設備正運行于更低內存的狀態(tài)下姻政，你應該釋放不用的資源用來提升系統(tǒng)性能（但是這也會直接影響到你的app的性能）。
TRIM_MEMORY_RUNNING_CRITICAL：你的app仍在運行岂嗓，但是系統(tǒng)已經把LRU Cache中的大多數進程都已經殺死汁展，因此你應該立即釋放所有非必須的資源。如果系統(tǒng)不能回收到足夠的RAM數量厌殉，系統(tǒng)將會清除所有的LRU緩存中的進程食绿，并且開始殺死那些之前被認為不應該殺死的進程，例如那個包含了一個運行態(tài)Service的進程公罕。
同樣器紧，當你的app進程正在被cached時，你可能會接受到從onTrimMemory()中返回的下面的值之一:
TRIM_MEMORY_BACKGROUND: 系統(tǒng)正運行于低內存狀態(tài)并且你的進程正處于LRU緩存名單中最不容易殺掉的位置楼眷。盡管你的app進程并不是處于被殺掉的高危險狀態(tài)铲汪，系統(tǒng)可能已經開始殺掉LRU緩存中的其他進程了。你應該釋放那些容易恢復的資源罐柳，以便于你的進程可以保留下來掌腰，這樣當用戶回退到你的app的時候才能夠迅速恢復。
TRIM_MEMORY_MODERATE: 系統(tǒng)正運行于低內存狀態(tài)并且你的進程已經已經接近LRU名單的中部位置张吉。如果系統(tǒng)開始變得更加內存緊張齿梁，你的進程是有可能被殺死的。
TRIM_MEMORY_COMPLETE: 系統(tǒng)正運行與低內存的狀態(tài)并且你的進程正處于LRU名單中最容易被殺掉的位置芦拿。你應該釋放任何不影響你的app恢復狀態(tài)的資源士飒。
因為onTrimMemory()的回調是在API 14才被加進來的查邢，對于老的版本，你可以使用onLowMemory)回調來進行兼容酵幕。onLowMemory相當與TRIM_MEMORY_COMPLETE扰藕。
Note: 當系統(tǒng)開始清除LRU緩存中的進程時，盡管它首先按照LRU的順序來操作芳撒，但是它同樣會考慮進程的內存使用量邓深。因此消耗越少的進程則越容易被留下來。
檢查你應該使用多少的內存
正如前面提到的笔刹，每一個Android設備都會有不同的RAM總大小與可用空間芥备，因此不同設備為app提供了不同大小的heap限制。你可以通過調用getMemoryClass())來獲取你的app的可用heap大小舌菜。如果你的app嘗試申請更多的內存萌壳，會出現OutOfMemory的錯誤。
