最近在幫助客戶做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不流暢上。對於手機來說。記憶體是乙個很稀缺的資源，即使是如今普遍擁有著很大記憶體...