Android 進程被殺時函數執行行為解析

核心問題

當 Android 系統因記憶體不足或其他原因殺死應用進程時，正在執行的函數是否會被允許完成？

直接回答

不會等待函數返回，直接殺死進程。 系統呼叫 Process.killProcess() 或類似機制終止進程時，所有執行緒會瞬間停止，後續代碼完全不會執行，包括 finally 區塊、onDestroy()、onStop() 等生命週期方法。

詳細機制說明

進程優先級與殺死順序

Android 根據進程類型分配 oom_adj 分數，分數越高越優先被殺：

被殺時的具體表現

• 主執行緒：正在執行的方法直接中斷，堆疊框架直接丟棄
• 子執行緒：同樣瞬間終止，無拋出異常、無執行 finally
• 靜態變數/單例：隨進程消失，重新啟動時重新初始化
• 檔案/資料庫：若未 flush()/close() 可能導致資料損壞
• SharedPreferences apply()：非同步寫入可能丟失

開發者應對策略

1. 關鍵資料即時持久化

// 壞例：依賴 onDestroy 寫入
@Override
protected void onDestroy() {
    saveUserData(); // 進程被殺時不會執行！
}

// 好例：資料變更即寫入
private void updateUserName(String name) {
    user.setName(name);
    // 同步寫入關鍵資料
    SharedPreferences.Editor editor = prefs.edit();
    editor.putString("name", name);
    editor.commit(); // 同步寫入，較 apply() 可靠
}

2. 使用 Service + Foreground 降低被殺機率

// 前台服務顯示持續通知，優先級接近前台進程
Notification notification = new NotificationCompat.Builder(this, CHANNEL_ID)
    .setContentTitle("服務運行中")
    .setSmallIcon(R.drawable.ic_service)
    .build();
startForeground(SERVICE_ID, notification);

3. 實作 onTrimMemory 釋放非必要資源

@Override
public void onTrimMemory(int level) {
    super.onTrimMemory(level);
    if (level >= TRIM_MEMORY_RUNNING_LOW) {
        // 清理圖片快取、釋放大型物件
        imageCache.clear();
    }
}

4. 利用 WorkManager / JobScheduler 執行可延遲任務

系統會在適當時機（充電、Wi-Fi、閒置）執行，即使進程被殺也會重新排程：

WorkRequest uploadWork = new OneTimeWorkRequest.Builder(UploadWorker.class).build();
WorkManager.getInstance(context).enqueue(uploadWork);

常見誤區

總結

Android 進程被殺是暴力、即時、不可攔截的。開發者不應依賴任何「臨終代碼」，而應採用即時持久化、前台服務、系統排程任務等機制保障資料安全與任務完成。