引言

一次針對系統全應用跑Monkey 腳本測驗時導致設備系統例外重啟…

adb shell monkey -v -v -v -s 100 --throttle 500 --pct-motion 30 --pct-touch 60 --pct-syskeys 10 --ignore-timeouts --ignore-crashes --ignore-security-exceptions --ignore-native-crashes 90000000 > d:\monkey_log_1106.txt

原始碼基于 Android7.1.2，僅供參考，

一、分析定位

在分析了aplog、klog、tombstone、dropbox等一堆日志之后，終于在aplog里定位到關鍵資訊：

首先是兩個重要的TAG：lowmemorykiller 和 Zygote，

1、Low Memory Killer機制

在Android中，當用戶退出應用程式之后，對應的行程也還是存在于系統中，這是為了方便程式的再次啟動，隨著打開的程式數量的增加，系統的記憶體會變得不足，此時就需要殺掉一部分行程以釋放記憶體空間，而至于是否需要殺死一些行程和哪些行程需要被殺死，是通過Low Memory Killer機制來進行判定的，詳情請參見下篇文章，

2、Zygote 概述

Android應用的行程都是從一個叫做Zygote的行程fork出來的，Android 會對每個應用進行記憶體限制（通過ActivityManager實體的getMemoryClass()查看），也可以查看/system/build.prop中的對應欄位來查看App的最大允許申請記憶體，

3、分析日志

首先定位到Zygote 第一條日志的列印處frameworks\base\core\jni\com_android_internal_os_Zygote.cpp

// This signal handler is for zygote mode, since the zygote must reap its children
static void SigChldHandler(int /*signal_number*/) {
  pid_t pid;
  int status;

  // It's necessary to save and restore the errno during this function. Since errno is stored per thread, changing //it here modifies the errno on the thread on which this signal handler executes. If a signal occurs
  // between a call and an errno check, it's possible to get the errno set here.
  int saved_errno = errno;
	//Zygote 監聽了所有行程的死亡
  while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
    if (WIFEXITED(status)) {//行程正常結束
      if (WEXITSTATUS(status)) {
        ALOGI("Process %d exited cleanly (%d)", pid, WEXITSTATUS(status));
      }
    } else if (WIFSIGNALED(status)) {//行程例外死亡
      if (WTERMSIG(status) != SIGKILL) {
        ALOGI("Process %d exited due to signal (%d)", pid, WTERMSIG(status));
      }
      if (WCOREDUMP(status)) {
        ALOGI("Process %d dumped core.", pid);
      }
    }

    // If the just-crashed process is the system_server, bring down zygote
    // so that it is restarted by init and system server will be restarted from there.
    if (pid == gSystemServerPid) {//system_server 行程例外終止
      ALOGE("Exit zygote because system server (%d) has terminated", pid);
      kill(getpid(), SIGKILL);//通知內核殺掉Zygote行程
    }
  }

	...
  errno = saved_errno;
}

繼續分析lowmemorykiller 猜想可能是由于記憶體不足導致核心行程被殺，很可能是因為記憶體泄漏（我們的設備系統可用記憶體為2G），而從日志中發現原生Setting 占用了540M，極其不正常

初步結論：由于原生Settings 記憶體泄漏導致系統可用記憶體不足，進而通過lowmemorykiller 機制強殺system_server ，Zygote行程也隨之被殺最終導致系統重啟，

二、案情重現

為了驗證結論和猜想，在Monkey 測驗程序，實時檢測系統記憶體分配情況，引入阿里開源的性能測驗開發工具mobileperf，并單獨對Settings 應用進行Monkey 測驗，腳本如下：

adb shell monkey -p com.android.settings -v -v -v -s 100 --throttle 500 --pct-motion 30 --pct-touch 60 --pct-syskeys 10 --ignore-timeouts --ignore-crashes --ignore-security-exceptions --ignore-native-crashes 90000000 > d:\monkey_settings_log_1106.txt

mobileperf輸出的產物：

Settings 行程實時記憶體分配情況：

從上圖統計中來看，原生Settings 的記憶體一直在往上增加即使GC后也沒有下降，這就是典型的記憶體泄漏現象，

再結合MAT（Memory Analyzer Tool）分析.hprof檔案：

結果如下：

這些原生物件的實體數目明顯例外，原來是因為原生Settings 里的子界面——應用詳情界面里的選單（形如通知、權限、存盤、流量使用情況等），這些二級界面跳回到應用詳情界面時會頻繁創建這些物件，卻沒有及時回收舊物件，分析到這基本石錘了原生Settings 存在記憶體泄漏的隱患，

三、優化修改

由于我們是定制性的系統，修改方案可能沒有共性，就不詳述具體細節，總之修改完畢之后的結果例外令人滿意，再次針對系統全應用執行Monkey 測驗時，原生Settings 的記憶體分配情況

單獨針對Settings 執行Monkey測驗時，Setting 的記憶體分配情況

四、小結

在Android 移動設備上尤其是低端的設備上，記憶體很容易出現不足的情況，一旦出現記憶體泄漏等問題，很可能導致不可預知的崩潰，所以在編碼時需要注意盡量避免記憶體泄漏的隱患，以下有幾條建議（不僅限于）：

• 合理使用一些輕量級的資料結構，在Android中很多情況下，我們可以優先考慮使用SparseArray或者ArrayMap替代HashMap等傳統Java的資料結構，相比起這些Android特意開發的ArrayMap、SparseArray的容器，傳統容器消耗更多的資源和相對低效些，因為HashMap自身需要一個額外的實體物件來記錄Mapping操作導致更加消耗記憶體，同時SparseArray避免了key和value的自動裝箱，從而避免了自動拆箱，
• 合理使用Bitmap，盡量減小BitMap的記憶體占用，在把圖片加載到記憶體之前，可以根據需求對原始圖片進行縮放處理，避免加載過大的圖片，另外解碼時使用合適的編碼格式，
• 盡量復用Bitmap物件、ViewHolder等物件
• 在使用背景關系的時候，盡量優先使用Appcation的Context，而非Activity的Context，當然區域的Dialog必須使用Activity的Context，
• 使用軟參考來避免Handler的泄漏
• 謹慎使用static和單例物件，因為兩者的生命周期都是與App的生命周期一樣，如果不是需要全生命周期存在就盡量避免過度使用單例和static，
• 注意原始WebView的泄漏（Android系統中一個失敗的控制元件，不僅僅兼容性存在問題，泄漏也是一大敗筆），如果一定使用原始WebView，最好在單獨的行程中運行

更多記憶體優化文章可參見性能優化系列