Android保活方案

系統(tǒng)出于性能和體驗上的考慮，APP退到后臺后并不會真正的kill、掉進程，而是將其緩存起來。

創(chuàng)新互聯(lián)建站長期為上千家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為婺源企業(yè)提供專業(yè)的網(wǎng)站設計制作、成都網(wǎng)站制作，婺源網(wǎng)站改版等技術服務。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

打開的應用越多，緩存的應用也就越多，在系統(tǒng)進程不足的情況下，系統(tǒng)根據(jù)自己的一套進程回收機制，來判斷kill掉哪些進程，以騰出進程給需要的app，這套進程回收機制叫做low memory killer。

內(nèi)存閥值，每個手機都不一樣，當可用內(nèi)存小于該值得時候，Android就會殺死對應優(yōu)先級得進程。

進程的優(yōu)先級通過oom_adj來判斷，oom_adj取值如下：

0-3是比較安全的oom_adj一般不會被系統(tǒng)殺死的，所以我們只要保證自己的app oom_adj在0-3之間就可以了。

可以通過adb命令：cat /proc /4181/oom_adj來查看自己app的oom_adj的值

4181是進程號

原理：手機關閉屏幕的時候，偷偷創(chuàng)建一個activity，讓應用成為前臺進程，打開屏幕時關閉activity，這樣用戶就不會發(fā)現(xiàn)什么異常，我們知道前臺應用的oom_adj為0是不會被殺死的，這樣就達到看保活的目的。

缺點：activity不夠干凈，只有在息屏的時候才生效，存在局限性比較大，而且谷歌原生的系統(tǒng)息屏的時候不會清理進程，但是現(xiàn)在很多廠商會在息屏的時候清理內(nèi)存，所以本方案的可行性不高，可以作為了解。

保活原理：啟動一個前臺服務，從而拉高整個應用的優(yōu)先級。

因為一旦通知被用戶干掉那么該保活方案就不好用了，所以通知圖標存在與否是該方案是否可行的關鍵。

但是該方案是谷歌官方承認的保活方案，所以可行性還是很高的。

需要適配

API18通知圖標不會顯示

API=18API26可以啟動雙服務，綁定同樣的D,然后stop

這個方法的原理是8.0系統(tǒng)之前會根據(jù)服務的id來判斷通知，那么第二個id設置跟第一個相同，然后自殺，系統(tǒng)就會誤認為此通知已死就不會通知了，那么通知欄上面就不會顯示

API=26后暫時沒有方式能夠隱藏

8.0之后不可以創(chuàng)建同樣的id的通知，所以此隱藏通知的方法就不好用了，當然了，通知顯示與否不是該方案成功的評判標準，所以說還是可以用的。

在發(fā)生特定系統(tǒng)事件時,系統(tǒng)會發(fā)出廣播,通過在 Androidmanifest中靜

態(tài)注冊對應的廣播監(jiān)聽器,即可在發(fā)生響應事件時拉活

但是從 android7.0開始,對廣播進行了限制,而且在8.0更加嚴格該方法就不適用了。

有多個app在用戶設備上安裝,只要開啟其中一個就可以將其他的app也拉

活。比如手機里裝了手Q、QQ空間、興趣部落等等,那么打開任意一個app后,其

他的app也都會被喚醒

系統(tǒng)每隔一段時間會進行賬戶同步，當系統(tǒng)去賬戶同步的時候(不一定多長時間，跟系統(tǒng)有關)，我們就去拉活app，這個方案是非常穩(wěn)定的，當然了國內(nèi)的系統(tǒng)都是定制的，所以還是需要一定的適配的。

優(yōu)點：系統(tǒng)喚醒，比較穩(wěn)定

缺點：時間不能把控

JobScheduler允許在特定狀態(tài)與特定時間間隔周期執(zhí)行任務。可以利

用它的這個特點完成保活的功能，效果即開啟一個定時器，與普通定時器不

同的是其調度由系統(tǒng)完成。

同樣在某些ROM可能并不能達到需要的效果

Android中的保活機制

Android中的保活是一個永不過時的話題，因為每一個APP都希望能在后臺不停的運行去搜集用戶數(shù)據(jù)，在Android 系統(tǒng)處于較低版本的時候（目前最新版本為12，較低版本指的是8以下），很多APP借助于系統(tǒng)層面的漏洞研發(fā)出了各種保活的方法，但是隨著Android 版本的不斷更新，過往的保活方法漸漸失效，Android中的保活成為了一個越來越難辦到的事情，但是我認為這是一個好事，如非這樣你永遠不知道你的手機后臺到底有多少APP背著你干了多少事情。當然，系統(tǒng)的事情不是我們能掌控的了的。那么，我們先來看看以前為了保活都有哪些手段。

手段一：在Service的onStartCommand方法中返回****START_STICKY****（****親測無效****）

在Service的onStartCommand方法中返回鍵有下面幾種可供選擇：

（1）START_STICKY：如果Service所在的進程，在執(zhí)行了onStartCommand方法后，被清理了，那么這個Service會被保留在已開始的狀態(tài)，但是不保留傳入的Intent，隨后系統(tǒng)會嘗試重新創(chuàng)建此Service。

（2）START_NOT_STICKY：如果Service所在的進程，在執(zhí)行了onStartCommand方法后，被清理了，則系統(tǒng)不會重新啟動此Service。

（3）START_REDELIVER_INTENT：如果Service所在的進程，在執(zhí)行了onStartCommand方法后，被清理了，則結果和START_STICKY一樣，也會重新創(chuàng)建此Service并調用onStartCommand方法。不同之處在于，如果是返回的是START_REDELIVER_INTENT ，則重新創(chuàng)建Service時onStartCommand方法會傳入之前的intent。

手段二：在清單文件里面設置優(yōu)先級****（****親測無效****）

手段三：在Service即將銷毀的時候重新啟動****（****親測無效****）

手段四：借助AIDL使用雙進程保活****（****親測無效****）

首先創(chuàng)建一個AIDL文件

創(chuàng)建本地服務

創(chuàng)建遠程服務：

最后在清單文件聲明：

手段五：1像素的Activity讓應用在熄屏后保活****（****親測無效****）

具體怎么實現(xiàn)可以參照這篇文章

u;/u

運行一段時間后系統(tǒng)會自動殺死整個APP

手段六：****開啟前臺服務（親測有效）

在Service的onCreate方法中開啟前臺服務

當然，APP保活的方式方法遠不止這些，但是隨著Android 系統(tǒng)的不斷優(yōu)化，保活現(xiàn)在越來越不太現(xiàn)實，但是我們可以盡量提高我們APP的優(yōu)先級讓系統(tǒng)不輕易殺死我們的APP，這一點還是可以辦到的。

Android-保活

Low Memory Killer

打開的應用越多，后臺緩存的進程也越多。因為系統(tǒng)出于體驗和性能上的考慮，app在退到后臺時系統(tǒng)并不會真正的kill掉這個進程，而是將其緩存起來。于是在系統(tǒng)內(nèi)存不足的情況下，系統(tǒng)開始依據(jù)自身的一套進程回收機制來判斷要kill掉哪些進程，以騰出內(nèi)存來供給需要的app, 這套殺進程回收內(nèi)存的機制就叫 Low Memory Killer。

進程的優(yōu)先級（by:）

前臺進程

用戶正在使用的程序，一般系統(tǒng)是不會殺死前臺進程的，除非用戶強制停止應用或者系統(tǒng)內(nèi)存不足等極端情況會殺死。

可見進程

用戶正在使用，看得到，但是摸不著，沒有覆蓋到整個屏幕,只有屏幕的一部分可見進程不包含任何前臺組件，一般系統(tǒng)也是不會殺死可見進程的，除非要在資源吃緊的情況下，要保持某個或多個前臺進程存活施。

服務進程

在內(nèi)存不足以維持所有前臺進程和可見進程同時運行的情況下，服務進程會被殺死。

后臺進程

系統(tǒng)可能隨時終止它們，回收內(nèi)存。

空進程

某個進程不包含任何活躍的組件時該進程就會被置為空進程，完全沒用,殺了它只有好處沒壞處,第一個干它。

內(nèi)存閾值

內(nèi)存閾值在不同的手機上不一樣，一旦低于該值,Android便會殺死對應優(yōu)先級的進程。一旦低于該值,Android便開始按逆序關閉進程。即優(yōu)先級從最高的空進程開始，逆序關閉，直到內(nèi)存足夠。

如何判斷進程的優(yōu)先級？

通過 oom_adj 值，判斷進程的優(yōu)先級，不同手機的oom_adj 值可能不一樣。

我們了解這個有什么用呢？PS：了解這個你才能想辦法保證自己怎么不被殺掉。

網(wǎng)上的一些方案和自己認為有用的方案

1 開啟一個像素Activity（偽前臺進程）

在鎖屏的時候在本進程開啟一個Activity，為了欺騙用戶，讓這個Activity的大小是1像素，并且透明無切換動畫，在開屏幕的時候，把這個Activity關閉掉，所以這個就需要監(jiān)聽系統(tǒng)鎖屏廣播。

我們的應用就始終和前臺進程是一樣的優(yōu)先級了，為了省電，系統(tǒng)檢測到鎖屏事件后一段時間內(nèi)會殺死后臺進程，如果采取這種方案，就可以避免了這個問題，但是還是有被殺掉的可能。

Android5.0以下：

Process.killProcessQuiet(pid);

Android5.0以后：

Process.killProcessQuiet(app.pid);

Process.killProcessGroup(app.info.uid, app.pid);

應用退出后，ActivityManagerService不僅把主進程給殺死，另外把主進程所屬的進程組一并殺死，這樣一來，由于子進程和主進程在同一進程組，子進程在做的事情，也就停止了。

2 相互喚醒（廣播喚醒）

相互喚醒的意思就是，假如你手機里裝了支付寶、淘寶、天貓、UC等阿里系的app，那么你打開任意一個阿里系的app后，有可能就順便把其他阿里系的app給喚醒了。這個完全有可能的。此外，開機，網(wǎng)絡切換、拍照、拍視頻時候，利用系統(tǒng)產(chǎn)生的廣播也能喚醒app，不過Android N已經(jīng)將這三種廣播取消了。

3 JobSheduler機制保活（不推薦）

JobSheduler是作為進程死后復活的一種手段，native進程方式最大缺點是費電， Native 進程費電的原因是感知主進程是否存活有兩種實現(xiàn)方式，在 Native 進程中通過死循環(huán)或定時器，判斷主進程是否存活，當主進程不存活時進行拉活。其次5.0以上系統(tǒng)不支持。? 但是JobSheduler可以替代在Android5.0以上native進程方式，這種方式即使用戶強制關閉，部分廠商手機（如：華為）也能被拉起來，但AndroidN失效。

4 粘性服務與系統(tǒng)服務捆綁()

這個是系統(tǒng)自帶的，onStartCommand方法必須具有一個整形的返回值，這個整形的返回值用來告訴系統(tǒng)在服務啟動完畢后。Service的onStartCommand方法里返回 STATR_STICK，onDestory中start自啟（準確的將算不上進程拉活，只能算service自啟，force_stop后不能正常拉活）。

5 監(jiān)聽第三方app開放的靜態(tài)廣播（同2）

需要大量反編譯app去找開放的靜態(tài)廣播，而且不保證長期有效，可能第三方開放廣播在版本升級時改為私有廣播，如果自己公司有多個app,可廣播互相拉起。

6 NDK+Socket通過fork實現(xiàn)進程保活方案（）

實現(xiàn)進程守護實際是守護app的主要服務，當app主進程被系統(tǒng)kill時，主要服務也會殺死，守護進程將其喚醒。

實現(xiàn)原理圖：

進程保活方案調研結果

未能實現(xiàn)真正意義上的進程保活。

光從保活這一點來說，綁定一個像素activity和循環(huán)一個無聲的聲音這種方法比較好，但是對用戶來說太流氓了，不推薦。? 對于有硬性需求的，可以引導用戶加入白名單。至于推送，? 可以嘗試集成多個推送方案，小米，華為等都有推送sdk，在對應手機上可以確保收到消息，? 然后像百度這種是多app公用通道的，也就是手機中有一個使用百度推送的app被允許后臺啟動，就能讓其他app收到推送。隨著Android版本的不斷更新及國內(nèi)廠商對ROM的不斷優(yōu)化，如何最大可能的對進程保活，是Android一道需要長期學習/鉆研的學問，也是Android開發(fā)者不得不面對的問題。

引援:

Android保活系列之——雙進程守護

近期跳槽到玩加電競，加之英雄聯(lián)盟云頂之弈排位模式的推出，導致個人精力有限沒有時間和心情去寫相關的博客。

在Context中提供了bindService的方法

綁定服務是客戶端--服務器接口中的服務器。組件和服務進行綁定后，可以發(fā)送請求、接收響應、執(zhí)行進程間通信（IPC）。這里的服務器模型不同于網(wǎng)絡C-S模型而是針對于Android應用不同的功能進行進程劃分，例如提供視頻播放的進程我們可以把它當做視頻播放服務器，我們UI層屬于客戶端，客戶端想要調用視頻播放，需要用IPC方式通過bind服務的方式調用視頻播放服務。（PS:如果大家對IPC不太熟悉可以參考我的其他文章 Android跨進程通信技術的使用及原理 ）客戶端可以通過調用bindService()綁定到服務。調用時，必須提供ServiceConnection的實現(xiàn)，后者會監(jiān)控與服務的連接及銷毀。

借助bindService的機制，我們可以在主進程創(chuàng)建時創(chuàng)建一個守護進程，并監(jiān)聽守護進程的連接及銷毀，再守護進程bindService中綁定主進程，這樣即使進程因為鎖屏、內(nèi)存等問題殺掉后，也會被守護進程拉起，這就是Android中雙進程守護的概念。當然早在PC時期，網(wǎng)吧的計時系統(tǒng)就使用了雙進程守護機制，防止被惡意殺掉。

實現(xiàn)方式就不寫了，網(wǎng)絡上一搜一堆，這里給出一篇文章

Android 雙進程守護

寫的中規(guī)中矩，如果不清楚如何實現(xiàn)可以看一下。

谷歌官方8.0變更

當版本8.0時，如果需要在后臺啟動服務需要調用startForegroundService。并且在serivce中onCreate方法必須在5秒內(nèi)調用startForeground ,向通知欄發(fā)一個通知告知用戶你的App正在后臺運行，否則就會拋出異常

8.0通知適配

保活分兩種：拉活、保活

拉活和保活是相輔相成的。在6.0版本以后的機型上，系統(tǒng)殺應用是按照進程組殺的，會直接導致雙進程守護失效。那么因此就不使用雙進程了么？

1.低版本雙進程守護是依然親測好使。

2.雙進程守護可以和后面講到的 賬號同步、外部PUSH、JobScheduler

相結合，可以規(guī)避開系統(tǒng)殺進程組的問題。使雙進程守護功能可以兼容高版本。

講的有些籠統(tǒng)，我尋思的發(fā)Dome、寫例子，但這樣解決不了根本問題，只有懂得了思路，了解了什么是雙進程守護，才能在開發(fā)中隨機應變。只能說Android水太深，大家需要細心細心再細心。

Android保活——藍牙喚醒（主動kill掉也可喚醒）

項目需要后臺保活，但無論怎么保活，只要用戶主動kill掉，app依然是活不了。

發(fā)現(xiàn)了藍牙喚醒這個方式，用戶主動kill掉也可行。

Android 8.0開始提供了 startscan的方法，

public void startScan(ScanCallback callback)

public void startScan(ListScanFilter filters,ScanSettings settings,ScanCallback callback)

public int startScan(ListScanFilter filters,ScanSettings settings,PendingIntent callbackIntent)

第一個沒有過濾條件，鎖屏就停止掃描

第二個可以加過濾條件，鎖屏不影響掃描?

第三個的掃描結果由PendingIntent發(fā)送，即使app沒有在運行，系統(tǒng)也可以掃描后喚醒app，這就是我們要的方法了。

PendingIntent是對Intent的封裝，是滿足某些條件或觸發(fā)某些事件后才執(zhí)行指定的行為，主要用于鬧鐘、通知、桌面部件。Android的四大組件之間通信用Intent，跨進程通信用PendingIntent。

Android 8.0 引進了Context.startForegroundService()，在系統(tǒng)創(chuàng)建服務后，應用需要在ANR發(fā)生前調用startForeground(int ,android.app.Notification)，如果未及時調用該方法，系統(tǒng)將報ANR錯誤 。系統(tǒng)給前臺服務的ANR時間是20秒。

用startScan藍牙喚醒的原理是：app向系統(tǒng)訂閱了掃描結果（預先加了過濾條件），當藍牙連接斷開的時候，設備就會發(fā)廣播，這時系統(tǒng)就可以掃描到對應的廣播，喚醒對應的service，這時想做什么操作就根據(jù)你的項目需要了。至于系統(tǒng)會為你掃描多久，這個還沒測試。

（1）setScanMode有四個參數(shù)可以選 ：

SCAN_MODE_BALANCED：在平衡電源模式下執(zhí)行藍牙LE掃描。返回掃描結果的速度能夠很好地權衡掃描頻率和功耗。

SCAN_MODE_LOW_LATENCY：掃描使用最高占空比。建議只在應用程序在前臺運行時使用此模式。

SCAN_MODE_LOW_POWER：在低功耗模式下執(zhí)行藍牙LE掃描。這是默認的掃描模式，因為它消耗的能量最少。如果掃描應用程序不在前臺，則強制執(zhí)行此模式。

SCAN_MODE_OPPORTUNISTIC：一種特殊的藍牙LE掃描模式。使用這種掃描模式的應用程序將被動地偵聽其他掃描結果，而不啟動BLE掃描本身

（2）settingBuilder.setMatchMode有兩個參數(shù)可以選：

MATCH_MODE_AGGRESSIVE： ?信號弱也會報告?

MATCH_MODE_STICKY： ?信號比較強和掃描到的次數(shù)比較多才會報告

（3)settingBuilder.setCallbackType也有其他參數(shù)可選，但適用的就一個

(4) ?ScanFilter ?的過濾方法有幾個,如下圖，打勾的是測試了可行的，但只有第一個DeviceAddress有唯一性 ?

當前文章：android保活,Android保活方案
URL網(wǎng)址：http://chinadenli.net/article39/dsgcish.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、微信公眾號、標簽優(yōu)化、網(wǎng)站收錄、小程序開發(fā)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)