轉自:http://blog.csdn.net/a396901990/article/details/38707007
寫在最前:
本文的思路主要借鑑了2014年AnDevCon開發者大會的一個演講PPT,加上把網上搜集的各種內存零散知識點進行彙總、挑選、簡化後整理而成。
所以我將本文定義爲一個工具類的文章,如果你在ANDROID開發中遇到關於內存問題,或者馬上要參加面試,或者就是單純的學習或複習一下內存相關知識,都歡迎閱讀。(本文最後我會盡量列出所參考的文章)。
OOM:
內存泄露可以引發很多的問題:
1.程序卡頓,響應速度慢(內存佔用高時JVM虛擬機會頻繁觸發GC)
2.莫名消失(當你的程序所佔內存越大,它在後臺的時候就越可能被幹掉。反之內存佔用越小,在後臺存在的時間就越長)
3.直接崩潰(OutOfMemoryError)
ANDROID內存面臨的問題:
1.有限的堆內存,原始只有16M
2.內存大小消耗等根據設備,操作系統等級,屏幕尺寸的不同而不同
3.程序不能直接控制
4.支持後臺多任務處理(multitasking)
5.運行在虛擬機之上
5R:
本文主要通過如下的5R方法來對ANDROID內存進行優化:
1.Reckon(計算)
首先需要知道你的app所消耗內存的情況,知己知彼才能百戰不殆
2.Reduce(減少)
消耗更少的資源
3.Reuse(重用)
當第一次使用完以後,儘量給其他的使用
5.Recycle(回收)
回收資源
4.Review(檢查)
回顧檢查你的程序,看看設計或代碼有什麼不合理的地方。
Reckon:
關於內存簡介,和Reckon(內存計算)的內容請看上一篇文章:ANDROID內存優化(大彙總——上)
Reduce :
Reduce的意思就是減少,直接減少內存的使用是最有效的優化方式。
下面來看看有哪些方法可以減少內存使用:
圖片顯示:
我們需要根據需求去加載圖片的大小。
例如在列表中僅用於預覽時加載縮略圖(thumbnails )。
只有當用戶點擊具體條目想看詳細信息的時候,這時另啓動一個fragment/activity/對話框等等,去顯示整個圖片
圖片大小:
直接使用ImageView顯示bitmap會佔用較多資源,特別是圖片較大的時候,可能導致崩潰。
使用BitmapFactory.Options設置inSampleSize, 這樣做可以減少對系統資源的要求。
屬性值inSampleSize表示縮略圖大小爲原始圖片大小的幾分之一,即如果這個值爲2,則取出的縮略圖的寬和高都是原始圖片的1/2,圖片大小就爲原始大小的1/4。
- BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();
- bitmapFactoryOptions.inJustDecodeBounds = true;
- bitmapFactoryOptions.inSampleSize = 2;
- // 這裏一定要將其設置回false,因爲之前我們將其設置成了true
- // 設置inJustDecodeBounds爲true後,decodeFile並不分配空間,即,BitmapFactory解碼出來的Bitmap爲Null,但可計算出原始圖片的長度和寬度
- options.inJustDecodeBounds = false;
- Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);
圖片像素:
ALPHA_8:每個像素佔用1byte內存
ARGB_4444:每個像素佔用2byte內存
ARGB_8888:每個像素佔用4byte內存 (默認)
RGB_565:每個像素佔用2byte內存
- publicstaticBitmapreadBitMap(Contextcontext, intresId) {
- BitmapFactory.Optionsopt = newBitmapFactory.Options();
- opt.inPreferredConfig = Bitmap.Config.RGB_565;
- opt.inPurgeable = true;
- opt.inInputShareable = true;
- //獲取資源圖片
- InputStreamis = context.getResources().openRawResource(resId);
- returnBitmapFactory.decodeStream(is, null, opt);
- }
圖片回收:
使用Bitmap過後,就需要及時的調用Bitmap.recycle()方法來釋放Bitmap佔用的內存空間,而不要等Android系統來進行釋放。
下面是釋放Bitmap的示例代碼片段。
- // 先判斷是否已經回收
- if(bitmap != null && !bitmap.isRecycled()){
- // 回收並且置爲null
- bitmap.recycle();
- bitmap = null;
- }
- System.gc();
捕獲異常:
經過上面這些優化後還會存在報OOM的風險,所以下面需要一道最後的關卡——捕獲OOM異常:
- Bitmap bitmap = null;
- try {
- // 實例化Bitmap
- bitmap = BitmapFactory.decodeFile(path);
- } catch (OutOfMemoryError e) {
- // 捕獲OutOfMemoryError,避免直接崩潰
- }
- if (bitmap == null) {
- // 如果實例化失敗 返回默認的Bitmap對象
- return defaultBitmapMap;
- }
修改對象引用類型:
引用類型:
引用分爲四種級別,這四種級別由高到低依次爲:強引用>軟引用>弱引用>虛引用。
強引用(strong reference)
如:Object object=new Object(),object就是一個強引用了。當內存空間不足,Java虛擬機寧願拋出OutOfMemoryError錯誤,使程序異常終止,也不會靠隨意回收具有強引用的對象來解決內存不足問題。
軟引用(SoftReference)
只有內存不夠時纔回收,常用於緩存;當內存達到一個閥值,GC就會去回收它;
弱引用(WeakReference)
弱引用的對象擁有更短暫的生命週期。在垃圾回收器線程掃描它 所管轄的內存區域的過程中,一旦發現了只具有弱引用的對象,不管當前內存空間足夠與否,都會回收它的內存。
虛引用(PhantomReference)
"虛引用"顧名思義,就是形同虛設,與其他幾種引用都不同,虛引用並不會決定對象的生命週期。如果一個對象僅持有虛引用,那麼它就和沒有任何引用一樣,在任何時候都可能被垃圾回收。
軟引用和弱引用的應用實例:
注意:對於SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案,現在已經不推薦使用了。自Android2.3版本(API Level 9)開始,垃圾回收器更着重於對軟/弱引用的回收,所以下面的內容可以選擇忽略。
在Android應用的開發中,爲了防止內存溢出,在處理一些佔用內存大而且聲明週期較長的對象時候,可以儘量應用軟引用和弱引用技術。
下面以使用軟引用爲例來詳細說明(弱引用的使用方式與軟引用是類似的):
假設我們的應用會用到大量的默認圖片,而且這些圖片很多地方會用到。如果每次都去讀取圖片,由於讀取文件需要硬件操作,速度較慢,會導致性能較低。所以我們考慮將圖片緩存起來,需要的時候直接從內存中讀取。但是,由於圖片佔用內存空間比較大,緩存很多圖片需要很多的內存,就可能比較容易發生OutOfMemory異常。這時,我們可以考慮使用軟引用技術來避免這個問題發生。
首先定義一個HashMap,保存軟引用對象。
- private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();
- public void addBitmapToCache(String path) {
- // 強引用的Bitmap對象
- Bitmap bitmap = BitmapFactory.decodeFile(path);
- // 軟引用的Bitmap對象
- SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
- // 添加該對象到Map中使其緩存
- imageCache.put(path, softBitmap);
- }
- public Bitmap getBitmapByPath(String path) {
- // 從緩存中取軟引用的Bitmap對象
- SoftReference<Bitmap> softBitmap = imageCache.get(path);
- // 判斷是否存在軟引用
- if (softBitmap == null) {
- return null;
- }
- // 取出Bitmap對象,如果由於內存不足Bitmap被回收,將取得空
- Bitmap bitmap = softBitmap.get();
- return bitmap;
- }
需要注意的是,在垃圾回收器對這個Java對象回收前,SoftReference類所提供的get方法會返回Java對象的強引用,一旦垃圾線程回收該Java對象之後,get方法將返回null。所以在獲取軟引用對象的代碼中,一定要判斷是否爲null,以免出現NullPointerException異常導致應用崩潰。
到底什麼時候使用軟引用,什麼時候使用弱引用呢?
個人認爲,如果只是想避免OutOfMemory異常的發生,則可以使用軟引用。如果對於應用的性能更在意,想盡快回收一些佔用內存比較大的對象,則可以使用弱引用。
還有就是可以根據對象是否經常使用來判斷。如果該對象可能會經常使用的,就儘量用軟引用。如果該對象不被使用的可能性更大些,就可以用弱引用。
另外,和弱引用功能類似的是WeakHashMap。WeakHashMap對於一個給定的鍵,其映射的存在並不阻止垃圾回收器對該鍵的回收,回收以後,其條目從映射中有效地移除。WeakHashMap使用ReferenceQueue實現的這種機制。
其他小tips:
對常量使用static final修飾符
讓我們來看看這兩段在類前面的聲明:
static int intVal = 42;
static String strVal = "Hello, world!";
編譯器會生成一個叫做clinit的初始化類的方法,當類第一次被使用的時候這個方法會被執行。方法會將42賦給intVal,然後把一個指向類中常量表 的引用賦給strVal。當以後要用到這些值的時候,會在成員變量表中查找到他們。 下面我們做些改進,使用“final”關鍵字:
static final int intVal = 42;
static final String strVal = "Hello, world!";
現在,類不再需要clinit方法,因爲在成員變量初始化的時候,會將常量直接保存到類文件中。用到intVal的代碼被直接替換成42,而使用strVal的會指向一個字符串常量,而不是使用成員變量。
將一個方法或類聲明爲final不會帶來性能的提升,但是會幫助編譯器優化代碼。舉例說,如果編譯器知道一個getter方法不會被重載,那麼編譯器會對其採用內聯調用。
你也可以將本地變量聲明爲final,同樣,這也不會帶來性能的提升。使用“final”只能使本地變量看起來更清晰些(但是也有些時候這是必須的,比如在使用匿名內部類的時候)。
靜態方法代替虛擬方法
如果不需要訪問某對象的字段,將方法設置爲靜態,調用會加速15%到20%。這也是一種好的做法,因爲你可以從方法聲明中看出調用該方法不需要更新此對象的狀態。
減少不必要的全局變量
儘量避免static成員變量引用資源耗費過多的實例,比如Context
避免創建不必要的對象
最常見的例子就是當你要頻繁操作一個字符串時,使用StringBuffer代替String。
對於所有所有基本類型的組合:int數組比Integer數組好,這也概括了一個基本事實,兩個平行的int數組比 (int,int)對象數組性能要好很多。
總體來說,就是避免創建短命的臨時對象。減少對象的創建就能減少垃圾收集,進而減少對用戶體驗的影響。
避免使用浮點數
通常的經驗是,在Android設備中,浮點數會比整型慢兩倍。
使用實體類比接口好
假設你有一個HashMap對象,你可以將它聲明爲HashMap或者Map:
Map map1 = new HashMap(); HashMap map2 = new HashMap();
哪個更好呢?
按照傳統的觀點Map會更好些,因爲這樣你可以改變他的具體實現類,只要這個類繼承自Map接口。傳統的觀點對於傳統的程序是正確的,但是它並不適合嵌入式系統。調用一個接口的引用會比調用實體類的引用多花費一倍的時間。如果HashMap完全適合你的程序,那麼使用Map就沒有什麼價值。如果有些地方你不能確定,先避免使用Map,剩下的交給IDE提供的重構功能好了。(當然公共API是一個例外:一個好的API常常會犧牲一些性能)
避免使用枚舉
枚舉變量非常方便,但不幸的是它會犧牲執行的速度和並大幅增加文件體積。
使用枚舉變量可以讓你的API更出色,並能提供編譯時的檢查。所以在通常的時候你毫無疑問應該爲公共API選擇枚舉變量。但是當性能方面有所限制的時候,你就應該避免這種做法了。
for循環
訪問成員變量比訪問本地變量慢得多,如下面一段代碼:
- for(int i =0; i < this.mCount; i++) {}
永遠不要在for的第二個條件中調用任何方法,如下面一段代碼:
- for(int i =0; i < this.getCount(); i++) {}
對上面兩個例子最好改爲:
- int count = this.mCount; / int count = this.getCount();
- for(int i =0; i < count; i++) {}
- for (Foo a : mArray) {
- sum += a.mSplat;
- }
瞭解並使用類庫
選擇Library中的代碼而非自己重寫,除了通常的那些原因外,考慮到系統空閒時會用匯編代碼調用來替代library方法,這可能比JIT中生成的等價的最好的Java代碼還要好。
當你在處理字串的時候,不要吝惜使用String.indexOf(),String.lastIndexOf()等特殊實現的方法。這些方法都是使用C/C++實現的,比起Java循環快10到100倍。
System.arraycopy方法在有JIT的Nexus One上,自行編碼的循環快9倍。
android.text.format包下的Formatter類,提供了IP地址轉換、文件大小轉換等方法;DateFormat類,提供了各種時間轉換,都是非常高效的方法。
TextUtils類,對於字符串處理Android爲我們提供了一個簡單實用的TextUtils類,如果處理比較簡單的內容不用去思考正則表達式不妨試試這個在android.text.TextUtils的類
高性能MemoryFile類,很多人抱怨Android處理底層I/O性能不是很理想,如果不想使用NDK則可以通過MemoryFile類實現高性能的文件讀寫操作。MemoryFile適用於哪些地方呢?對於I/O需要頻繁操作的,主要是和外部存儲相關的I/O操作,MemoryFile通過將 NAND或SD卡上的文件,分段映射到內存中進行修改處理,這樣就用高速的RAM代替了ROM或SD卡,性能自然提高不少,對於Android手機而言同時還減少了電量消耗。該類實現的功能不是很多,直接從Object上繼承,通過JNI的方式直接在C底層執行。
Reuse:
Bitmap緩存分爲兩種:
一種是內存緩存,一種是硬盤緩存。
內存緩存(LruCache):
以犧牲寶貴的應用內存爲代價,內存緩存提供了快速的Bitmap訪問方式。系統提供的LruCache類是非常適合用作緩存Bitmap任務的,它將最近被引用到的對象存儲在一個強引用的LinkedHashMap中,並且在緩存超過了指定大小之後將最近不常使用的對象釋放掉。
注意:以前有一個非常流行的內存緩存實現是SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案,然而現在已經不推薦使用了。自Android2.3版本(API
Level 9)開始,垃圾回收器更着重於對軟/弱引用的回收,這使得上述的方案相當無效。
硬盤緩存(DiskLruCache):
一個內存緩存對加速訪問最近瀏覽過的Bitmap非常有幫助,但是你不能侷限於內存中的可用圖片。GridView這樣有着更大的數據集的組件可以很輕易消耗掉內存緩存。你的應用有可能在執行其他任務(如打電話)的時候被打斷,並且在後臺的任務有可能被殺死或者緩存被釋放。一旦用戶重新聚焦(resume)到你的應用,你得再次處理每一張圖片。
在這種情況下,硬盤緩存可以用來存儲Bitmap並在圖片被內存緩存釋放後減小圖片加載的時間(次數)。當然,從硬盤加載圖片比內存要慢,並且應該在後臺線程進行,因爲硬盤讀取的時間是不可預知的。
注意:如果訪問圖片的次數非常頻繁,那麼ContentProvider可能更適合用來存儲緩存圖片,例如Image Gallery這樣的應用程序。
更多關於內存緩存和硬盤緩存的內容請看Google官方教程https://developer.android.com/develop/index.html1. Android-Universal-Image-Loader 圖片緩存
目前使用最廣泛的圖片緩存,支持主流圖片緩存的絕大多數特性。
項目地址:https://github.com/nostra13/Android-Universal-Image-Loader
2. picasso square開源的圖片緩存
項目地址:https://github.com/square/picasso
特點:(1)可以自動檢測adapter的重用並取消之前的下載
(2)圖片變換
(3)可以加載本地資源
(4)可以設置佔位資源
(5)支持debug模式
3. ImageCache 圖片緩存,包含內存和Sdcard緩存
項目地址:https://github.com/Trinea/AndroidCommon
特點:
(1)支持預取新圖片,支持等待隊列
(2)包含二級緩存,可自定義文件名保存規則
(3)可選擇多種緩存算法(FIFO、LIFO、LRU、MRU、LFU、MFU等13種)或自定義緩存算法
(4)可方便的保存及初始化恢復數據
(5)支持不同類型網絡處理
(6)可根據系統配置初始化緩存等
- @Override
- public View getView(int position, View convertView, ViewGroup parent) {
- ViewHolder vHolder = null;
- //如果convertView對象爲空則創建新對象,不爲空則複用
- if (convertView == null) {
- convertView = inflater.inflate(..., null);
- // 創建 ViewHodler 對象
- vHolder = new ViewHolder();
- vHolder.img= (ImageView) convertView.findViewById(...);
- vHolder.tv= (TextView) convertView.findViewById(...);
- // 將ViewHodler保存到Tag中(Tag可以接收Object類型對象,所以任何東西都可以保存在其中)
- convertView.setTag(vHolder);
- } else {
- //當convertView不爲空時,通過getTag()得到View
- vHolder = (ViewHolder) convertView.getTag();
- }
- // 給對象賦值,修改顯示的值
- vHolder.img.setImageBitmap(...);
- vHolder.tv.setText(...);
- return convertView;
- }
- //將顯示的View 包裝成類
- static class ViewHolder {
- TextView tv;
- ImageView img;
- }
對象池:
對象池使用的基本思路是:將用過的對象保存起來,等下一次需要這種對象的時候,再拿出來重複使用,從而在一定程度上減少頻繁創建對象所造成的開銷。 並非所有對象都適合拿來池化――因爲維護對象池也要造成一定開銷。對生成時開銷不大的對象進行池化,反而可能會出現“維護對象池的開銷”大於“生成新對象的開銷”,從而使性能降低的情況。但是對於生成時開銷可觀的對象,池化技術就是提高性能的有效策略了。
線程池的基本思想還是一種對象池的思想,開闢一塊內存空間,裏面存放了衆多(未死亡)的線程,池中線程執行調度由池管理器來處理。當有線程任務時,從池中取一個,執行完成後線程對象歸池,這樣可以避免反覆創建線程對象所帶來的性能開銷,節省了系統的資源。
比如:一個應用要和網絡打交道,有很多步驟需要訪問網絡,爲了不阻塞主線程,每個步驟都創建個線程,在線程中和網絡交互,用線程池就變的簡單,線程池是對線程的一種封裝,讓線程用起來更加簡便,只需要創一個線程池,把這些步驟像任務一樣放進線程池,在程序銷燬時只要調用線程池的銷燬函數即可。
java提供了ExecutorService和Executors類,我們可以應用它去建立線程池。
通常可以建立如下4種:
- /** 每次只執行一個任務的線程池 */
- ExecutorService singleTaskExecutor = Executors.newSingleThreadExecutor();
- /** 每次執行限定個數個任務的線程池 */
- ExecutorService limitedTaskExecutor = Executors.newFixedThreadPool(3);
- /** 所有任務都一次性開始的線程池 */
- ExecutorService allTaskExecutor = Executors.newCachedThreadPool();
- /** 創建一個可在指定時間裏執行任務的線程池,亦可重複執行 */
- ExecutorService scheduledTaskExecutor = Executors.newScheduledThreadPool(3);
要根據情況適度使用緩存,因爲內存有限。
能保存路徑地址的就不要存放圖片數據,不經常使用的儘量不要緩存,不用時就清空。
寫在最後:
我準備將文章分爲上、中、下三部分。現在已經全部完成:
內存簡介,Recoken(計算)請看:ANDROID內存優化(大彙總——上)
Reduce(減少),Reuse(重用) 請看:ANDROID內存優化(大彙總——中)
Recycle(回收), Review(檢查) 請看:ANDROID內存優化(大彙總——全)
寫這篇文章的目的就是想弄一個大彙總,將零散的內存知識點總結一下,如果有錯誤、不足或建議都希望告訴我。
參考文章:
解析Android開發優化之:軟引用與弱引用的應用(http://www.jb51.net/article/36627.htm)android內存泄露優化總結(http://blog.csdn.net/imain/article/details/8560986)
Android 內存優化(http://blog.csdn.net/awangyunke/article/details/20380719)
Android開發優化之——對Bitmap的內存優化(http://blog.csdn.net/arui319/article/details/7953690)
關於android性能,內存優化(http://www.cnblogs.com/zyw-205520/archive/2013/02/17/2914190.html)
Android研究院之應用開發線程池的經典使用(http://www.xuanyusong.com/archives/2439)