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的ｕｓｓ　內存占用大于２０Ｍ時，　就發一個ｇｃ命令．

[java]?view plain?copy

#!/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)system ui 内存优化的全部內容，希望文章能夠幫你解決所遇到的問題。

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