Android內存泄漏_圖文

1、一、android內存機制Android的程序由Java語言編寫，所以Android的內存管理與Java的內存管理相似。程序員通過new為對象分配內存，所有對象在java堆內分配空間；然而對象的釋放是由垃圾回收器來完成的。CC+中的內存機制是“誰污染，誰治理”，java的就比較人性化了，給我們請了一個專門的清潔工（GC）。那么GC怎么能夠確認某一個對象是不是已經被廢棄了呢？Java采用了有向圖的原理。Java將引用關系考慮為圖的有向邊，有向邊從引用者指向引用對象。線程對象可以作為有向圖的起始頂點，該圖就是從起始頂點開始的一棵樹，根頂點可以到達的對象都是有效對象，GC不會回收這些對象。如果某個對

2、象 (連通子圖與這個根頂點不可達(注意，該圖為有向圖，那么我們認為這個(這些對象不再被引用，可以被GC回收。二、內存泄漏原因導致內存泄漏主要的原因是，先前申請了內存空間而忘記了釋放。如果程序中存在對無用對象的引用，那么這些對象就會駐留內存，消耗內存，因為無法讓垃圾回收器GC驗證這些對象是否不再需要。如果存在對象的引用，這個對象就被定義為有效的活動，同時不會被釋放。要確定對象所占內存將被回收，我們就要務必確認該對象不再會被使用。典型的做法就是把對象數據成員設為null或者從集合中移除該對象。但當局部變量不需要時，不需明顯的設為null，因為一個方法執(zhí)行完畢時，這些引用會自動被清理。在Java中，

3、內存泄漏就是存在一些被分配的對象，這些對象有下面兩個特點，首先，這些對象是有被引用的，即在有向樹形圖中，存在樹枝通路可以與其相連；其次，這些對象是無用的，即程序以后不會再使用這些對象。如果對象滿足這兩個條件，這些對象就可以判定為Java中的內存泄漏，這些對象不會被GC所回收，然而它卻占用內存。三、內存泄漏測試方法內存泄漏的測試方法其實也沒什么特別的，一句話就是：監(jiān)控測試場景下應用程序(進程的內存變化信息。但是測試開始之前我們還是有三件事要去做。第一，我們需要一個監(jiān)控工具(monitor，能實時(每隔一個時間片采樣應用程序的內存數據信息；第二，測試用例，開始測試前我們要分析并制定內存可能泄漏的場

4、景；第三，執(zhí)行測試自動化腳本，避免手工操作對測試數據帶來一些影響（對CPU的影響比較大）。1.準備工作測試時使用是名叫AndroidresMonitor的python腳本工具，工具的具體的介紹請參見，此處不做詳細介紹。內存泄漏的測試用例和功能測試有幾個不同點：1操作的重復性我們設計的測試場景要是重復性的。對于輕微的內存泄漏，我們可以通過操作次數的遞增來積累泄漏的內存數量，直到我們能清晰的在曲線變化上內存的泄漏問題。2操作閉環(huán)我們的測試場景必須是閉環(huán)的。這樣我們才能橫向對比不同次數的數據信息。3數據讀寫操作涉及數據讀寫的操作和功能點，是我們內存泄漏測試需要重點關注的。4圖片相關操作圖片向來是內存

5、的重災區(qū)，超級大胖子bitmap經常是內存泄漏的禍首。所以，圖片的加載、釋放、滑動查看等等都需要我們特別小心。5特別關注重復啟動退出應用，界面間跳轉，登錄-退出，多測幾次也許問題就在這里。把我們的手工操作轉化成python腳本，重復執(zhí)行多少次我們也不怕。而且，腳本化的用例也是我們測試標準化和可重復性的基礎。2.測試執(zhí)行開啟我們的監(jiān)控工具，測試用例的腳本也跑起來，喝杯咖啡等數據結果就好了。這就是我們內存泄漏測試時的場景。(1監(jiān)控工具：(2測試腳本(3測試數據3.測試數據分析測試場景下的內存數據變化曲線我們已經拿到了，那這個測試場景下是否是真的有內存泄漏？曲線只是一個表現，我們需要挖掘表象下更深層

6、次的問題。如上圖，應用啟動和退出的場測試數據，我們可以看到明顯的內存申請和釋放，good,開發(fā)同學做得不錯。但是，整體趨勢？不對，整體趨勢怎么還是持續(xù)上升的！這里我們發(fā)現了一個內存泄漏的懷疑點。畢竟曲線不能說明這個場景一定有內存泄漏。我們還利用另一個殺手锏MAT，對這個場景下應用程序內存堆棧的信息做進一步的調查。關于MAT(Eclipse Memory Analyser (MAT - Tutorial的使用，有興趣的同學可以找相關的文章來學習。我這邊常用的就是對象數量的橫向對比分析法。簡單的說就是，操作一次之后分析一次對象的數量，重復操作N次之后再分析一次對象的數量，通過兩次對象數量的橫向對比

7、，查看測試場景下有無內存泄漏?！九e例】=例子=場景三：界面間跳轉，主界面分類界面設置主界面QQ筆記：界面跳轉過程中CPU的占用率是15%左右；多次跳轉，內存數據異常，明顯呈持續(xù)增長的趨勢。結果分析：Pss：在進行界面跳轉時，內存占用持續(xù)增加，懷疑是否應用沒有釋放(可能沒有及時釋放之前的內存數據；或者重復加載相同數據?！緝却嫘孤┓治觥窟M行分析時，采樣了兩個數據場景：（1）界面跳轉，操作一次；（2）連續(xù)進行界面跳轉，操作10次。分別獲取應用的hprof文件進行對比分析。使用MAT對打開照片過程進行內存泄漏分析，分析報告如下： 使用兩個場景下的數據進行橫向對比，對象數量及占用內存大小對比數據見下表：

8、=四、內存泄漏測試報告-正文-一、關鍵測試結論：1. 在10個測試場景的測試過程中，發(fā)現QQ筆記在界面間跳轉和重復拍照加載圖片過程中內存數據異常，呈持續(xù)增長的趨勢；2. 測試意見：1）在測試界面跳轉過程中(主要是主界面-分類界面-設置界面，內存占用持續(xù)增加，懷疑是否應用沒有釋放(或者沒有及時釋放之前的內存數據；2）在重復打開圖片筆記和重復拍照-取消兩個測試場景中，測試數據有輕微的增長趨勢，懷疑操作過程中應用多有輕量的內存泄漏問題；3）在重復拍照加載照片時，用戶放棄當前圖片重新拍照選擇新的圖片時，內存占用持續(xù)增加，懷疑是否應用沒有完全釋放(或者沒有及時釋放之前的圖片數據；二、測試環(huán)境：測試對象Q

9、Q筆記測試場景1 重復啟動應用2 重復登錄3 界面間跳轉4 重復打開一條筆記5 重復播放一條錄音6 重復從相冊中加載圖片7 拍照后點擊“重拍”8 拍照后點擊“取消”9 重復拍照加載圖片10 左右滑動查看筆記內的圖片測試用例見下表。測試指標1 CPU占用率：通過監(jiān)控工具AndroidresMonitork實時獲取應用的CPU值。2 內存占用值：通過工具AndroidresMonitork實時獲取應用的內存數據(PSS、RSS、USS，測試中以PSS數據作為應用內存消耗的衡量指標。1.4 測試網絡Free-WIFI環(huán)境測試機器配置HUAWEI T9510E 配置信息: 主屏尺寸：英寸 觸摸屏：電容

10、屏，多點觸控 主屏材質：IPS 主屏分辨率：1280x720像素 主屏色彩：1600萬色 操作系統(tǒng)： 核心數：4核 CPU型號：海思K3V2 CPU頻率：1433MHz RAM容量：1G ROM容量：8G 存儲卡：MicroSD卡 擴展容量：32GB三、詳細數據及分析：場景九：通過拍照添加圖片，拍照確定后的圖片-取消-返回編輯界面QQ筆記：拍照過程中CPU的占用率是13%左右；重復多次拍照返回的操作，內存數據異常，雖然有內存資源的釋放，但是有明顯呈持續(xù)增長的趨勢。結果分析：Pss：在拍照完成-取消，返回編輯界面跳轉時，內存有相應的釋放，但是應用的內存占用持續(xù)增加，懷疑是否應用沒有完全釋放(可能

11、沒有及時釋放之前的內存數據；或者重復加載相同數據。【內存泄漏分析】進行分析時，采樣了兩個數據場景：（1）拍照-取消，操作一次；（2）連續(xù)進行拍照-取消，操作10次。分別獲取應用的hprof文件進行對比分析。使用MAT對打開照片過程進行內存泄漏分析，分析報告如下：使用兩個場景下的數據進行橫向對比，對象數量及占用內存大小對比數據見下表：五、bug修復驗證報告一、內存泄漏提單二、Bug具體描述及解決方案1、【內存泄漏】重復啟動退出應用程序，內存數據持續(xù)上升測試場景CPU及內存數據曲線圖 解決方案修復后內存數據曲線驗證結果在版本上驗證內存泄漏問題，內存的申請和釋放過程明顯，重復操作過程中內存無持續(xù)上升

12、或者積累上升趨勢。2、【內存泄漏】通過拍照添加圖片，拍照確定后的圖片-取消-返回編輯界面，重復操作過程中存在內存泄漏測試場景CPU及內存數據曲線圖解決方案修復后內存數據曲線驗證結果在版本上驗證內存泄漏問題，內存的申請和釋放過程明顯，重復操作過程中內存無持續(xù)上升或者積累上升趨勢。三、測試反饋這次專項測試發(fā)現的問題主要屬于兩個類型：1）在activity生命周期的不同階段未合理釋放內存資源；2）圖片操作相關的bitmap沒有及時釋放這里也梳理一些常見的需要關注內存操作相關問題：1. 查詢數據庫沒有關閉游標程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢Cursor后沒有關閉的情況。如果我們的

13、查詢結果集比較小，對內存的消耗不容易被發(fā)現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以后的測試和問題排查帶來困難和風險。2. 構造Adapter時，沒有使用緩存的 convertView以構造ListView的BaseAdapter為例，在BaseAdapter中提高了方法public View getView(int position, View convertView, ViewGroup parent來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據當前的屏幕布局實例化一定數量的 view對象，同時ListV

14、iew會將這些view對象緩存起來。當向上滾動ListView時，原先位于最上面的list item的view對象會被回收，然后被用來構造新出現的最下面的list item。這個構造過程就是由getView(方法完成的，getView(的第二個形參 View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null。由此可以看出，如果我們不去使用convertView，而是每次都在getView(中重新實例化一個View對象的話，即浪費資源也浪費時間，也會使得內存占用越來越大。ListView回收list item

15、的view對象的過程可以查看:android.widget.AbsListView.java - void addScrapView(View scrap 方法。3. Bitmap對象不在使用時調用recycle(釋放內存有時我們會手工的操作Bitmap對象，如果一個Bitmap對象比較占內存，當它不在被使用的時候，可以調用Bitmap.recycle(方法回收此對象的像素所占用的內存，但這不是必須的，視情況而定?？梢钥匆幌麓a中的注釋： /* Free up the memory associated with this bitmaps pixels, and mark the * bitm

16、ap as dead, meaning it will throw an exception if getPixels( or* setPixels( is called, and will draw nothing. This operation cannot be* reversed, so it should only be called if you are sure there are no* further uses for the bitmap. This is an advanced call, and normally need ; * not be called, since the normal GC process will free up this memory when* there are no more references to this bitmap.*/4. 釋放對象的引用5.