Android開發中, 假設我們的app有且僅有一個Service元件, 那麼有幾個回撥和細節是我這兩天才關注到的(我目前的戰鬥力是不是太弱了?).
這裡以android-23的模擬器作為測試裝置, 分兩種情況備註下: (前臺服務指呼叫了startForeground的服務)

1. AndroidManifest.xml中, Service聲明瞭stopWithTask=”false”或者未宣告此屬性:

   • 當通過home虛擬鍵回到桌面時, 或檢視最近app列表時, Service的onTrimMemory會得到回撥; 如果Service是前臺服務, 此時oom_adj為1, 如果不是前臺服務, oom_adj變為6;
   • 另外當從最近app列表中移除那個帶Service元件的app時有以下幾點:
     
     • 如果Service不是前臺服務, 則程序被殺死, 其後Service自動重啟, onCreate和onStartCommand被回撥, oom_adj變為8;
     • 如果Service是前臺服務, 則程序不會被殺死, onStartCommand得到回撥, oom_adj為1;

2. AndroidManifest.xml中, Service聲明瞭stopWithTask=”true”屬性時:

   • 當通過home虛擬鍵回到桌面時, 或檢視最近app列表時, Service的onTrimMemory會得到回撥; 如果Service是前臺服務, 此時oom_adj為1, 如果不是前臺服務, oom_adj變為6;
   • 另外當從最近app列表中移除那個帶Service元件的app時有以下幾點:
     
     • 當從最近app列表中移除那個帶Service元件的app時, Service的onTaskRemoved不會被回撥, app去世;
     • 不論是否是前臺服務, app去世;

這裡oom_adj的值來自於/proc/{pid}/oom_adj. 此值越大, 越容易被Android系統殺死回收(有前臺ui介面時一般值為0, 系統app或廠商合作的app可能值為負數), 殺死的時機可以是記憶體緊張, 耗電過猛, 鎖屏後若干時間, 被第三方管理軟體”偷窺”到;

(先通過adb shell ps來找到app的pid, 然後adb shell cat /proc/那個pid/oom_adj即可檢視)