Android 進程常駐（2）----細數利用android系統機制的保活手段

這是一個輕量級的庫，配置幾行代碼，就能夠實如今android上實現進程常駐，也就是在系統強殺下，以及360獲取root權限下，clean master獲取root權限下都沒法殺死進程

支持系統2.3到6.0

支持大部分設備，包括三星，華爲，oppo，nexus，魅族等等

能夠簡單對開機廣播進行保護

github地址：

https://github.com/Marswin/MarsDaemon

原理分析：

Android 進程常駐（0）----MarsDaemon使用說明

Android 進程常駐（1）----開篇

Android 進程常駐（2）----細數利用android系統機制的保活手段

Android 進程常駐（3）----native保活5.0如下方案推演過程以及代碼詳述

Android 進程常駐（4）----native保活5.0以上方案推演過程以及代碼詳述

Android 進程常駐（5）----開機廣播的簡單守護以及總結

正文：

年前就開篇了android進程常駐，可是一直雜事不斷，也一直沒有靜下心來整理，只是把項目傳到的github，有好多朋友會來問我其中實現原理，其實也是一點一點推演過來的。個人想法就是按照我當時的推演過程，按順序寫完這幾篇博客，也算是對那一個月努力的一個交代。

上一篇講了系統管理進程和強殺進程的過程原理，今天就開始想一下，在此基礎上，如何實現保活，固然做爲一個android開發，最早想到的確定是在framework層有沒有什麼機制能夠利用實現保活，當時整理了如下幾點（是對照本身當時寫的ppt整理的，有些細節已經忘記）：

一、將Service設置爲前臺進程

二、在service的onstart方法裏返回 STATR_STICK

三、添加Manifest文件屬性值爲android:persistent=「true」

四、覆寫Service的onDestroy方法

五、添加廣播監聽android.intent.action.USER_PRESENT事件以及其餘一些能夠容許的事件

六、服務互相綁定

七、設置鬧鐘，定時喚醒

八、帳戶同步，定時喚醒

九、native層保活






好的，而後咱們一個一個的來講

一、將Service設置爲前臺進程。

本質是修改了Service所在進程的進程優先級，詳情請參照 Android 進程常駐（1）----開篇。有了前臺進程的優先級，在android系統清理內存的時候，他被殺死的優先級僅高於前臺的activity，也就是正在和用戶交互的頁面，並且使用ddms殺進程他也能夠本身啓動起來。

可是，然，並，卵！

首先ddms殺進程和在系統設置的正在運行中殺進程自己就不具威脅，在系統設置的全部應用中選擇強行中止，仍然能夠強停掉，360，cm等軟殺更是能垂手可得殺死他。並且他還有一個缺點，在api 17以上，設置了一個前臺服務，他會以一個沒法消除的notification的樣式出如今用戶的手機狀態欄裏，大大下降了用戶體驗。看源碼

因此通常這麼用

二、在service的onstart方法裏返回 STATR_STICK

沒多大用，放在常規應用裏的service ok，但保活的話仍是差些。。。這裏很少說了直接看源碼註釋

其餘幾個返回值分別表明了

START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保證服務被kill後必定能重啓。 

START_STICKY：系統就會從新建立這個服務而且調用onStartCommand()方法，可是它不會從新傳遞最後的Intent對象，這適用於不執行命令的媒體播放器（或相似的服務），它只是無限期的運行着並等待工做的到來。

START_NOT_STICKY：直到接受到新的Intent對象，纔會被從新建立。這是最安全的，用來避免在不須要的時候運行你的服務。

START_REDELIVER_INTENT：系統就會從新建立了這個服務，而且用最後的Intent對象調。等待中的Intent對象會依次被髮送。這適用於以下載文件。

三、添加Manifest文件屬性值爲android:persistent=「true」

若是你的應用能設置這個屬性，能夠全文跳過我這個系列全部文章。由於他真的能夠殺不死，像系統的keyguard進程，media進程，且這些進程的adj都是負數，表明了前臺activity黑屏了他們也不會死。可是這個屬性須要系統shareuid，而後編譯不過，由於須要系統簽名，什麼？你用系統簽名？請忽略我所有

因此然並卵。

四、覆寫Service的onDestroy方法

你會說這麼low也行？爲了把我知道的全部方式都列舉出來，因此這裏也說一下，在設置裏面的正在運行，注意是正在運行裏面，點擊關閉，會走onDestroy回調方法，你在這裏能夠把本身啓動起來。

可是仍然然並卵，設置裏面的force close纔是真正的勁敵，還有root了的360，cm這些boos纔是咱們要解決的對象。

五、添加廣播監聽android.intent.action.USER_PRESENT事件以及其餘一些能夠容許的事件

這個有必要說一下，這個廣播相信可能有的朋友不是很清楚，這是一個android解鎖的廣播事件。

注意：

1.這不是SCREEN_ON\SCREEN_OFF廣播，,這不是SCREEN_ON\SCREEN_OFF廣播，這不是SCREEN_ON\SCREEN_OFF廣播。

2.這是一個能夠靜態註冊的廣播，這是一個能夠靜態註冊的廣播，這是一個能夠靜態註冊的廣播。

因此在manifest裏面註冊以後不須要任何前提，理論上用戶每次開屏解鎖都會觸發咱們的onReceive事件，在這裏咱們能夠檢查進程服務是否在，不在就拉起來。

可是，這個事件只有解鎖纔有，若是用戶的沒有設置鎖屏，那麼這個事件就是沒有的，並且咱們的目標是保證進程一直存活，而不是儘量多的活起來。因此這個看成一個補充的手段也不錯，另外全部那些能夠靜態註冊的廣播均可以這樣搞，前提是你不怕用戶看到你申請了好多權限，固然這個USER_PRESENT事件是不須要權限的。

如下是幾個常見能夠靜態註冊的廣播，另外android7取消了wifi的靜態廣播註冊，沒有證明

android.intent.action.USER_PRESENT
android.net.conn.CONNECTIVITY_CHANGE
android.intent.action.MEDIA_MOUNTED
android.intent.action.MEDIA_UNMOUNTED
android.net.wifi.RSSI_CHANGED
android.net.wifi.STATE_CHANGE
android.net.wifi.WIFI_STATE_CHANGED

六、服務互相綁定

這個是android裏面一個特性，跨進程bind一個service以後，若是被bind的service掛掉，bind他的service會把他拉起來。依然然並卵，具體爲何之後再說。

七、設置鬧鐘，定時喚醒

市面上瞭解到的大部分應用是用這種保活方式，使用系統鬧鐘定時發通知過來喚醒進程。

可是，

且先不說高頻的喚醒和手機廠商對於wakelock的控制上形成的耗電問題。單單保活效果上就很難過關，force close直接殺掉，沒有掙扎的機會，360、cm更是隨便殺。說下alarm的幾個參數

AlarmManager.RTC，硬件鬧鐘，不喚醒手機（也多是其它設備）休眠；當手機休眠時不發射鬧鐘。

AlarmManager.RTC_WAKEUP，硬件鬧鐘，當鬧鐘發躰時喚醒手機休眠；

AlarmManager.ELAPSED_REALTIME，真實時間流逝鬧鐘，不喚醒手機休眠；當手機休眠時不發射鬧鐘。

AlarmManager.ELAPSED_REALTIME_WAKEUP，真實時間流逝鬧鐘，當鬧鐘發躰時喚醒手機休眠；

 

嗯，RTC鬧鐘和ELAPSED_REALTIME最大的差異就是前者能夠經過修改手機時間觸發鬧鐘事件，後者要經過真實時間的流逝，即便在休眠狀態，時間也會被計算。

八、帳戶同步，定時喚醒

這個估計也是好多人不知道一點，android系統裏有一個帳戶系統，設置一個本身的帳戶，android會按期喚醒帳戶更新服務，咱們能夠本身設定同步的事件間隔。且發起更新的是系統，不會受到任何限制。看下效果，晚上下班到次日早晨，開着cm後臺自動清理

 log上來看喚醒時間一直正常，且在睡眠中是不會產生喚醒的。

使用方法也很簡單：

那麼，這就是咱們想要的？

還不行！！！

他的侷限性在於：

第一，用戶會在系統設置的帳戶列表裏面看到一個不認識的帳戶；

第二，同步的事件間隔是有限制的，最短1分鐘，見源碼，若是小雨60秒，置爲60秒。並且各類國產機怎麼改的源碼咱們未可知，是否是都能用仍然未可知；

第三，很致命，某些手機好比note3須要手動設置帳戶，你如何騙你的用戶給你手動設置帳戶完了以後不卸載你；

第四，也很致命，必須聯網！google提供這個組件是讓你同步帳戶信息，不聯網你同步個鬼，咱們要保活，能夠不聯網不作事，可是不能不聯網就死


可是，把他放在最後，仍然是一個很好的保活補充手段

九、native層保活

終於要到正文了。下一篇開啓native保活的篇章，首先上一個github上別人的native保活方案，也是絕大多數公司採用的native方案，筆者所在公司亦是北京知名互聯網公司，以前也採起的相似方案，可是，其實只是開了一個native進程按期發intent而已，缺陷是：只能簡單保活，360、cm碾壓其無壓力，但仍有可借鑑之處，下一篇分析，而後開始個人native之旅

https://github.com/Coolerfall/Android-AppDaemon