android中systemUI是作為一個設置壁紙的服務存在的．以前項目中，對systemUI做了延遲啟動的優化，可以把內存從２5M左右降到８Ｍ左右，可是最近一個項目用了同樣的方法(延遲啟動)，內存卻仍然占用２5M．

１．　procrank | busybox grep systemui

結果：　11212?? 63936K?? 44144K?? 27010K?? 25788K? com.android.systemui　　　＃　USS 占用25M

2.?? dumpsys meminfo 11212

結果：

Applications Memory Usage (kB):

Uptime: 8264904 Realtime: 8264904

** MEMINFO in pid 11212 [com.android.systemui] **

Shared? Private???? Heap???? Heap???? Heap

Pss??? Dirty??? Dirty???? Size??? Alloc???? Free

------?? ------?? ------?? ------?? ------?? ------

Native??????? 0??????? 8??????? 0???? 8580???? 1650????? 209

Dalvik??? 24528???? 5700??? 24380??? 25992??? 25734????? 258

Cursor??????? 0??????? 0??????? 0

Ashmem??????? 0??????? 0??????? 0

Other dev?????? 96?????? 56??????? 0

.so mmap???? 1203???? 2444????? 496

.jar mmap??????? 0??????? 0??????? 0

.apk mmap?????? 46??????? 0??????? 0

.ttf mmap??????? 0??????? 0??????? 0

.dex mmap????? 253??????? 0??????? 0

Other mmap?????? 28?????? 16?????? 28

Unknown????? 817????? 504????? 812

TOTAL??? 26971???? 8728??? 25716??? 34572??? 27384????? 467

3. showmap 11212

結果

virtual???????????????????? shared?? shared? private? private

size????? RSS????? PSS??? clean??? dirty??? clean??? dirty??? # object

-------- -------- -------- -------- -------- -------- -------- ---- ------------------------------

＊

＊

4096?????? 60?????? 60??????? 0??????? 0??????? 0?????? 60??? 1 /dev/ashmem/dalvik-bitmap-2 (deleted)

2052????? 212????? 212??????? 0??????? 0??????? 0????? 212??? 1 /dev/ashmem/dalvik-card-table (deleted)

262144??? 26596??? 24455??????? 0???? 2196??????? 0??? 24400??? 3 /dev/ashmem/dalvik-heap (deleted)

1024?????? 88?????? 88??????? 0??????? 0??????? 0?????? 88??? 1 /dev/ashmem/dalvik-jit-code-cache (deleted

＊

＊ -------- -------- -------- -------- -------- -------- -------- ---- ------------------------------

看到24400了嗎，　是虛擬機分配了了差不多２４Ｍ的內存，導致占用的內存過大(后面的delete　我當初以為是垃圾內存，后來據說不是)．

４．　分析到這里，還是沒有什么卵用．分析以下ｓｙｓｔｅｍ　ｕｉ的啟動ｌｏｇ吧，

發現：

4 D/Zygote? ( 9704): Process 10352 terminated by signal (15)

75 I/ActivityManager(10239): Start proc com.android.systemui for restart com.android.systemui: pid=11212 uid=10038 gids={50038, 1028, 1015, 1023,???????? 3002, 3001}

76 D/ActivityManager(10239): test resumeTopActivty

77 D/ActivityManager(10239): resumeTopActivty

78 D/ActivityManager(10239): set persist.sys.bootformui true

79 I/??????? (11212): jpeg hw mutex s_index = 319

80 I/??????? (11212): [MSOS_PRINT][003274]???? ~!~mappd sharemem? @^A

81 I/??????? (11212): [MSOS_PRINT][000640]???? pthread_mutex_init

82 I/??????? (11212): [MSOS_PRINT][000642]???? CHIP_InitISR

83 D/??????? (11212): [skia jpeg]: readbuf addr:0x1b14a000, size: 0x100000

84 D/??????? (11212):? write buff addr:0x1b34a000,? size: 0x1500000

85 D/??????? (11212):? internal buff addr:0x1b24a000,?? size: 0x100000

86 D/skia??? (11212): ---- fAsset->read(157360) returned 0

87 E/??????? (11212): jpeg goto fail 0, s16JpegDecoderErrCode = -233

88 I/??????? (11212): [MPlayerLib]:Decode jpeg fail, s16JpegDecoderErrCode = -233

89 E/??????? (11212): go sw decode!

90 D/dalvikvm(11212): GC_FOR_ALLOC freed 59K, 11% free 2318K/2592K, paused 16ms, total 16ms

91 I/dalvikvm-heap(11212): Grow heap (frag case) to 11.257MB for 9216016-byte allocation

92 D/dalvikvm(11212): GC_FOR_ALLOC freed 1K, 3% free 11317K/11596K, paused 11ms, total 11ms

93 D/dalvikvm(11212): GC_CONCURRENT freed 0K, 3% free 11317K/11596K, paused 3ms+2ms, total 16ms

94 E/bt_userial_vendor(10759): count = 39

95 E/bt_userial_vendor(10759):? /dev/btusb0 file exist

96 E/bt_userial_vendor(10759): /dev/btusb0's size????? is 0??? bytes

97 E/bt_userial_vendor(10759): /dev/btusb0's t_blksize is 4096 bytes

98 E/bt_userial_vendor(10759): /dev/btusb0's blocks??? is 0??? blocks

99 D/dalvikvm(11212): GC_FOR_ALLOC freed <1K, 3% free 11317K/11596K, paused 11ms, total 11ms

100 I/dalvikvm-heap(11212): Grow heap (frag case) to 25.319MB for 14745616-byte allocation

看到了嗎，　原因就是因為ｊｐｅｇ硬解碼失敗，使用了軟解碼，　導致內存使用暴增，而其他平臺是硬解碼成功的，所以內存占用小．

但是這還是沒用，因為硬件廠商基本上不會再為這個項目維護了，讓他們去改希望也比較渺茫了．

５．還是不死心，用ｄｄｍｓ　分析一下吧．上圖：

占用２７Ｍ，　但是當我點了一下ＧＣ后，　神奇的事情發生了，上圖：

美柚看錯，　ＨＥＡＰ占用變成了2M, 我們再用 procrank? | grep systemui　看下：

結果：　1883?? 40608K?? 20816K??? 3700K??? 2484K? com.android.systemui

的的確確是變小了．　看來system　ｕi剛啟動的時候圖片操作占用了內存，但是過后變成了垃圾內存，　我們只要用ｇｃ對其一下垃圾回收便能夠釋放內存，縮小差不多２０Ｍ的內存占用．

那么我目前的想法，我不想修改systemui 的源碼，　既然ｄｄｍｓ能夠發出ｇｃ的命令，那么我一定可以找到類似的方法　去讓system ui做ｇｃ的操作．　功夫不負有心人，

我終于找到了一條命令：　她就是　:? kill -10 ${PID} ,

感興趣的同學可以看下虛擬機的代碼，　虛擬機接收到USR1 的信號時，會做垃圾回收處理，　USER1的信號就是10.

下面　是我寫的一個簡單ｓｈｅｌｌ，放到開機時時啟動，　當systemui的ｕｓｓ　內存占用大于２０Ｍ時，　就發一個ｇｃ命令．

#!/system/bin/sh

THRESH_HOLD=20000

while true

do

SYSTEMUI_PID=`procrank 2>&1 | busybox grep systemui | busybox awk '{print $1}'`

SYSTEMUI_MEM=`procrank 2>&1 | busybox grep systemui | busybox awk '{print $5}'`

SYSTEMUI_MEM=${SYSTEMUI_MEM%%K}

#echo ----------

#echo ${SYSTEMUI_PID}

#echo ${SYSTEMUI_MEM}

#echo ----------

if [ ${SYSTEMUI_MEM} -gt ${THRESH_HOLD} ]; then

echo "gc systemui..."

kill -10 ${SYSTEMUI_PID}

fi

sleep 30

done

總結

以上是生活随笔為你收集整理的android uid systemui,(android)system ui 内存优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。