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