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