Android的記憶體分析

2021-06-26 06:35:40 字數 1554 閱讀 1946

最近在幫助客戶做gts測試遇到乙個很奇怪的現象。

在gts測試過程中,先測試media後然後測試playerstore時,會一直失敗。但是如果不放在media測試後面就不會出問題。

經過2天的檢查和log分析,終於找到問題啦。在測試playstore 時遇到呼叫launcher,在執行media測試時,由於media測試用例在記憶體占用很大,由於系統的低記憶體的機制會將停在後台的程序殺死,因此launcher此時也被kill掉啦。導致在在playerstore測試時,需要回到主頁時,

validatetop...: activity in front not resumed r=activityrecord state=destroyed

此時的主頁已經是destroyed狀態,導致返回主頁失敗。

解決方案: 1.減少系統的內建的apk,減少記憶體佔用量。2.在launcher增加防殺機制,新增android:persistent="true

在解決此問題的過程中,重點研究了activitymanagerh和activitythread **和使用一些記憶體分析的方法,現在歸納一下。

1.記憶體分析常見的引數:

一般來說記憶體占用大小有如下規律:vss >= rss >= pss >= uss

2.記憶體終端分析常用命令:

dumpsys meminfo ,cat /proc/meminfo  ,procrank, 「adb shell ps -x」

下面是procank 使用方式。

如果你想檢視所有程序的記憶體使用情況,可以使用

"adb shell procrank"命令。命令返回將如下:

pid      vss      rss      pss      uss  cmdline

188   75832k   51628k   24824k   19028k  system_server

308   50676k   26476k    9839k    6844k  system_server

265   28536k   28532k    7985k    5824k  com.android.phone

100   29052k   29048k    7299k    4984k  zygote

258   27128k   27124k    7067k    5248k  com.swype.android.inputmethod

270   25820k   25816k    6752k    5420k  com.android.kineto

1253   27004k   27000k    6489k    4880k  com.google.android.voicesearch

3157   24140k   24136k    5191k    4272k  android.process.acore

2854   23304k   23300k    4067k    2788k  com.android.vending

3604   22844k   22840k    4036k    3060k  com.wssyncmldm

各個細節使用詳細請參考:

Android記憶體分析和調優

android記憶體分析和調優 上 摘要 第一部分,如何使用adb的工具檢視記憶體占用。閱讀全文 android記憶體分析和調優 中 摘要 在前文中討論了如果使用adb shell procrank,dumpsys meminfo和showmaps分析程序的記憶體占用情況。本文將繼續細化,具體分析導...

Android應用記憶體洩露分析 改善經驗總結

通過這幾天對好幾個應用的記憶體洩露檢測和改善,效果明顯 從結果來看我分析和改善記憶體洩露的方法是對的,這個過程並不複雜,所以可以梳理總結出來作為分享。對於效能問題,分析和改善有必要遵循以下原則 下面是我在針對記憶體洩露這個效能問題上的解決步驟 首先解決常見的記憶體洩露問題,這個過程可以借助andro...

Android的記憶體優化

android應用優化主要集中在記憶體和ui流暢度上。從記憶體占用與洩露 ui流暢度的幀數和響應時間到io的堵塞式響應時間等。記憶體優化 首先。為什麼要優化記憶體?主要體如今oom out of memory 和導致ui不流暢上。對於手機來說。記憶體是乙個很稀缺的資源,即使是如今普遍擁有著很大記憶體...