標簽：
轉載請注明出處：http://blog.csdn.net/guolin_blog/article/details/42238627
內存(RAM)對于任何一個軟件開發(fā)環(huán)境都是種非常珍貴的資源，而對于移動操作系統(tǒng)來講的話，則會顯得更加珍貴，因為手機的硬件條件相對于PC畢竟是比較落后的。盡管Android系統(tǒng)的虛擬機擁有自動回收垃圾的機制，但這并不代表我們就可以忽視應該在什么時候分配和釋放內存。
為了使垃圾回收器可以正常釋放程序所占用的內存，在編寫代碼的時候就一定要注意盡量避免出現(xiàn)內存泄漏的情況（通常都是由于全局成員變量持有對象引用所導致的），并且在適當?shù)臅r候去釋放對象引用。對于大多數(shù)的應用程序而言，后面其它的事情就可以都交給垃圾回收器去完成了，如果一個對象的引用不再被其它對象所持有，那么系統(tǒng)就會將這個對象所分配的內存進行回收。
我們在開發(fā)軟件的時候應當自始至終都把內存的問題充分考慮進去，這樣的話才能開發(fā)出更加高性能的軟件。而內存問題也并不是無規(guī)律可行的，Android系統(tǒng)給我們提出了很多內存優(yōu)化的建議技巧，只要按照這些技巧來編寫程序，就可以讓我們的程序在內存性能發(fā)面表現(xiàn)得相當不錯，下面我們就來一一學習一下這些技巧。
如果應用程序當中需要使用Service來執(zhí)行后臺任務的話，請一定要注意只有當任務正在執(zhí)行的時候才應該讓Service運行起來。另外，當任務執(zhí)行完之后去停止Service的時候，要小心Service停止失敗導致內存泄漏的情況。
當我們啟動一個Service時，系統(tǒng)會傾向于將這個Service所依賴的進程進行保留，這樣就會導致這個進程變得非常消耗內存。并且，系統(tǒng)可以在LRU cache當中緩存的進程數(shù)量也會減少，導致切換應用程序的時候耗費更多性能。嚴重的話，甚至有可能會導致崩潰，因為系統(tǒng)在內存非常吃緊的時候可能已無法維護所有正在運行的Service所依賴的進程了。
為了能夠控制Service的生命周期，Android官方推薦的最佳解決方案就是使用IntentService，這種Service的最大特點就是當后臺任務執(zhí)行結束后會自動停止，從而極大程度上避免了Service內存泄漏的可能性。
讓一個Service在后臺一直保持運行，即使它并不執(zhí)行任何工作，這是編寫Android程序時最糟糕的做法之一。所以Android官方極度建議開發(fā)人員們不要過于貪婪，讓Service在后臺一直運行，這不僅可能會導致手機和程序的性能非常低下，而且被用戶發(fā)現(xiàn)了之后也有可能直接導致我們的軟件被卸載（我個人就會這么做）。
當用戶打開了另外一個程序，我們的程序界面已經不再可見的時候，我們應當將所有和界面相關的資源進行釋放。在這種場景下釋放資源可以讓系統(tǒng)緩存后臺進程的能力顯著增加，因此也會讓用戶體驗變得更好。
那么我們如何才能知道程序界面是不是已經不可見了呢？其實很簡單，只需要在Activity中重寫onTrimMemory()方法，然后在這個方法中監(jiān)聽TRIM_MEMORY_UI_HIDDEN這個級別，一旦觸發(fā)了之后就說明用戶已經離開了我們的程序，那么此時就可以進行資源釋放操作了，如下所示：
注意onTrimMemory()方法中的TRIM_MEMORY_UI_HIDDEN回調只有當我們程序中的所有UI組件全部不可見的時候才會觸發(fā)，這和onStop()方法還是有很大區(qū)別的，因為onStop()方法只是當一個Activity完全不可見的時候就會調用，比如說用戶打開了我們程序中的另一個Activity。因此，我們可以在onStop()方法中去釋放一些Activity相關的資源，比如說取消網(wǎng)絡連接或者注銷廣播接收器等，但是像UI相關的資源應該一直要等到onTrimMemory(TRIM_MEMORY_UI_HIDDEN)這個回調之后才去釋放，這樣可以保證如果用戶只是從我們程序的一個Activity回到了另外一個Activity，界面相關的資源都不需要重新加載，從而提升響應速度。
除了剛才講的TRIM_MEMORY_UI_HIDDEN這個回調，onTrimMemory()方法還有很多種其它類型的回調，可以在手機內存降低的時候及時通知我們。我們應該根據(jù)回調中傳入的級別來去決定如何釋放應用程序的資源：
以上是當我們的應用程序正在運行時的回調，那么如果我們的程序目前是被緩存的，則會收到以下幾種類型的回調：
當我們讀取一個Bitmap圖片的時候，有一點一定要注意，就是千萬不要去加載不需要的分辨率。在一個很小的ImageView上顯示一張高分辨率的圖片不會帶來任何視覺上的好處，但卻會占用我們相當多寶貴的內存。需要僅記的一點是，將一張圖片解析成一個Bitmap對象時所占用的內存并不是這個圖片在硬盤中的大小，可能一張圖片只有100k你覺得它并不大，但是讀取到內存當中是按照像素點來算的，比如這張圖片是1500*1000像素，使用的ARGB_8888顏色類型，那么每個像素點就會占用4個字節(jié)，總內存就是1500*1000*4字節(jié)，也就是5.7M，這個數(shù)據(jù)看起來就比較恐怖了。
Android API當中提供了一些優(yōu)化過后的數(shù)據(jù)集合工具類，如SparseArray，SparseBooleanArray，以及LongSparseArray等，使用這些API可以讓我們的程序更加高效。傳統(tǒng)Java API中提供的HashMap工具類會相對比較低效，因為它需要為每一個鍵值對都提供一個對象入口，而SparseArray就避免掉了基本數(shù)據(jù)類型轉換成對象數(shù)據(jù)類型的時間。
我們還應當清楚我們所使用語言的內存開支和消耗情況，并且在整個軟件的設計和開發(fā)當中都應該將這些信息考慮在內。可能有一些看起來無關痛癢的寫法，結果卻會導致很大一部分的內存開支，例如：
許多程序員都喜歡各種使用抽象來編程，認為這是一種很好的編程習慣。當然，這一點不可否認，因為的抽象的編程方法更加面向對象，而且在代碼的維護和可擴展性方面都會有所提高。但是，在Android上使用抽象會帶來額外的內存開支，因為抽象的編程方法需要編寫額外的代碼，雖然這些代碼根本執(zhí)行不到，但是卻也要映射到內存當中，不僅占用了更多的內存，在執(zhí)行效率方面也會有所降低。當然這里我并不是提倡大家完全不使用抽象編程，而是謹慎使用抽象編程，不要認為這是一種很酷的編程方式而去肆意使用它，只在你認為有必要的情況下才去使用。
現(xiàn)在有很多人都喜歡在Android工程當中使用依賴注入框架，比如說像Guice或者RoboGuice等，因為它們可以簡化一些復雜的編碼操作，比如可以將下面的一段代碼：
簡化成這樣的一種寫法：
看上去確實十分誘人，我們甚至可以將findViewById()這一類的繁瑣操作全部省去了。但是這些框架為了要搜尋代碼中的注解，通常都需要經歷較長的初始化過程，并且還可能將一些你用不到的對象也一并加載到內存當中。這些用不到的對象會一直占用著內存空間，可能要過很久之后才會得到釋放，相較之下，也許多敲幾行看似繁瑣的代碼才是更好的選擇。
ProGuard相信大家都不會陌生，很多人都會使用這個工具來混淆代碼，但是除了混淆之外，它還具有壓縮和優(yōu)化代碼的功能。ProGuard會對我們的代碼進行檢索，刪除一些無用的代碼，并且會對類、字段、方法等進行重命名，重命名之后的類、字段和方法名都會比原來簡短很多，這樣的話也就對內存的占用變得更少了。
這個技巧其實并不是非常建議使用，但它確實是一種可以幫助我們節(jié)省和管理內存的高級技巧。如果你要使用它的話一定要謹慎使用，因為絕大多數(shù)的應用程序都不應該在多個進程當中運行的，一旦使用不當，它甚至會增加額外的內存而不是幫我們節(jié)省內存。這個技巧比較適用于那些需要在后臺去完成一項獨立的任務，和前臺的功能是可以完全區(qū)分開的場景。
這里舉一個比較適合去使用多進程技巧的場景，比如說我們正在做一個音樂播放器軟件，其中播放音樂的功能應該是一個獨立的功能，它不需要和UI方面有任何關系，即使軟件已經關閉了也應該可以正常播放音樂。如果此時我們只使用一個進程，那么即使用戶關閉了軟件，已經完全由Service來控制音樂播放了，系統(tǒng)仍然會將許多UI方面的內存進行保留。在這種場景下就非常適合使用兩個進程，一個用于UI展示，另一個則用于在后臺持續(xù)地播放音樂。
想要實現(xiàn)多進程的功能也非常簡單，只需要在AndroidManifest文件的應用程序組件中聲明一個android:process屬性就可以了，比如說我們希望播放音樂的Service可以運行在一個單獨的進程當中，就可以這樣寫：
這里指定的進程名是background，你也可以將它改成任意你喜歡的名字。需要注意的是，進程名的前面都應該加上一個冒號，表示該進程是一個當前應用程序的私有進程。
標簽：
