android不死service
❶ ios系統和Android區別
1、兩者運行機制不同：IOS採用的是沙盒運行機制，安卓採用的是虛擬機運行機制。
2、兩者後台制度不同：IOS中任何第三方程序都不能在後台運行；安卓中任何程序都能在後台運行，直到沒有內存才會關閉。
3、IOS中用於UI指令許可權最高，安卓中數據處理指令許可權最高。
(1)android不死service擴展閱讀
Android是一種基於Linux的自由及開放源代碼的操作系統，主要使用於移動設備，如智能手機和平板電腦，由Google公司和開放手機聯盟領導及開發。尚未有統一中文名稱，中國大陸地區較多人使用「安卓」或「安致」。Android操作系統最初由Andy Rubin開發，主要支持手機。2005年8月由Google收購注資。
2007年11月，Google與84家硬體製造商、軟體開發商及電信營運商組建開放手機聯盟共同研發改良Android系統。隨後Google以Apache開源許可證的授權方式，發布了Android的源代碼。第一部Android智能手機發布於2008年10月。Android逐漸擴展到平板電腦及其他領域上，如電視、數碼相機、游戲機等。
❷ 如何讓一個應用程序一直在後台運行
1、保活手段
1 業界保活手段：黑色保活，灰色保活，白色保活
2 黑色保活：
1 不同的APP進程，用廣播相互喚醒，包括利用系統廣播進行喚醒
2 常見手段：
1 開機，網路切換，拍照，拍視頻等利用系統廣播喚醒APP
此場景Google已經意識到，在Android N 取消了 拍照，視頻，網路切換的廣播
2 接入第三方的SDK也會喚醒相應的APP進程
3 假如你手機里裝了支付寶，淘寶，UC等阿里系的APP，那麼你打開任何一個，都有可能喚醒其他的阿里系的APP
3 白色保活：
就是調用系統的API啟動一個前台Service進程，這樣會在通知欄生成一個Notification，用戶知道哪些進程正在運行
4 灰色保活
1 保活領域應用最為廣泛，利用系統的漏洞來啟動一個前台的Service進程，與「白色保活」不同的是，它不會在通知欄生成一個Notification,用戶無法察覺，但是優先順序要高於普通的後台進程。
2 實現思路
思路一：當API<18，啟動前台的Service直接傳入new Notification()；
思路二：當API >= 18,同時啟動兩個id相同的前台Service，然後再將後啟動的Service做stop處理
代碼這樣寫：
[java]view plain
importandroid.app.Notification;
importandroid.app.Service;
importandroid.content.Intent;
importandroid.os.Build;
importandroid.os.IBinder;
/**
*APP灰色保活
*Createdbyfflinon2016/4/23.
*/
{
privatefinalstaticintGRAY_SERVICE_ID=1001;
@Override
publicIBinderonBind(Intentintent){
returnnull;
}
@Override
publicintonStartCommand(Intentintent,intflags,intstartId){
//API<18,此方法能有效地隱藏notification的圖標
if(Build.VERSION.SDK_INT<18){
startForeground(GRAY_SERVICE_ID,newNotification());
}else{
Intentintent1=newIntent(this,GrayInnerService.class);
startService(intent1);
startForeground(GRAY_SERVICE_ID,newNotification());
}
returnsuper.onStartCommand(intent,flags,startId);
}
//給API>=18的平台上做灰色保護手段
{
@Override
publicIBinderonBind(Intentintent){
returnnull;
}
@Override
publicintonStartCommand(Intentintent,intflags,intstartId){
startForeground(GRAY_SERVICE_ID,newNotification());
stopForeground(true);
stopSelf();
returnsuper.onStartCommand(intent,flags,startId);
}
}
}
3 檢驗方法：
首先看系統通知欄有沒有Notification，如果沒有，就進入手機adb shell模式，輸入命令mpsys activity services PackageName
列印出指定包名的所有進程中的service信息，看下有沒有isForground=true的信息，如果有，就說明了該APP使用了灰色保活
4 使用灰色保活手段並不意味著你的應用就能永生不死，只能說提高了進程的優先順序，如果應用佔用了很大的內存，還是會被回收的
2、進一步理解保活
1 進程回收機制
系統出於體驗和性能上的考慮，APP在退出後台時系統並不會真正的kill掉這個進程，而是將其緩存起來，打開的應用越多，後台緩存的進程也就越多。在系統內存不足的情況下，系統開始根據自身的一套進程回收機制來判斷要回收掉哪些進程，這套殺死進程回收內存的機制叫 Low Memory Killer，它是基於Linux內核的OOM killer機制誕生的，該機制為每個系統分配了一個值，叫做oom_adj，代表了進程的優先順序，oom_adj越大，代表優先順序越低，越容易被回收，普通APP進程的oom_adj >=0,系統的可能會小於0.
2 查看oom_adj的值，需要用到兩個shell命令
ps | grep 包名
$cat /proc/進程id/oom_adj
3 結果發現，APP推到後台，UI進程的值降低最為明顯，因為它佔用的內存資源最多，因此，為了避免後台UI進程被殺，需要盡可能的釋放一些不用的圖片，音頻資源
❸ 進程保活
一 、問：什麼是進程保活？
答：進程保活就是進程永遠存在內存中，是殺不死的，就算殺死了也會有辦法重新啟動起來，其實這些並不是流氓手段，很多情況下，如果你想給你的用戶提供服務，就必須有一個進程常駐著，便於在特定的時候做一些特定的事情，比如廣播接受者，他就不支持靜態注冊，也就是說如果我們想接受屏幕開關啟動的廣播，必須要在進程中動態注冊，這個時候如果沒有一個常駐的進程，鎖屏業務就無法正常的為用戶展開服務。
二、問：進程是怎麼死掉的呢？
答：其實進程被殺死的原因，一方面是人為的，二、可能被第三方應用殺死，如殺敵軟體等。
三、問：Android進程的優先順序？
答：
1、前台進程 （Foreground process）：用戶當前操作所在的進程，當內存不足以承擔前台進程的使用，才有可能回收
2、可見進程（Visible process）:沒有任何前台組件，但是仍然會影響屏幕上所見內容，他是一種極為重要的進程，除非為了維持前台進程，因內存不足，有可能會回收掉可見進程，否則系統是不會回收可見進程。
3、服務進程（Service process）:他與用戶所見的內容是沒有直接關聯，但是他們通常執行一些用戶關心的操作，比如說在後台獲取網路數據，後台播放音樂，後台進行一些數據計算等。被殺死的原因：也是為了
支持前台進程和可見進程，因內存不足情況下才會被回收。
4、後台進程（BaclGround process）:對用戶的體驗沒有直接的影響，用戶可以隨時終止他們，這個進程是為了供給上面三個進程來使用的，通常在後台進程運行著很多操作，他們保存在一個列表當中，為了確保用戶最近查看Activit的進程最後一個被終止，他是一個LRU演算法，
5、空進程（Empty process） :保存這個進程的唯一目的就是用來做緩存，以縮短下次在運行組件所需的啟動時間，為了使系統總體的資源在進程緩存和內存底層之間保持平衡。它是不包括任何組件的進程.
四、問：Android進程的回收策略？
答：Android進程的回收策略主要是通過Low memory killer機制來完成的。
Low memory killer：通過一些比較復雜的評分機制，對進程進行打分，然後講分數的進程判定為bad進程，殺死並釋放內存。Low memory killer是定時進行檢查的，它主要是通過進程的OOM_ODJ來判斷進程的優先順序。當OOM_ODJ的值越小，進程的優先順序越高，而OOM_ODJ越不會去回收。反之就會被回收。
注意：Low memory killer和out memory不一樣的地方：out memory機制只有當系統內存不足的時候才會啟動檢查，而Low memory killer是定時進行檢查的，它主要是通過進程的OOM_ODJ來判斷進程的優先順序。
五、問：進程保活方案？
答：Android進程的回收策略主要是通過Low memory killer機制來完成的。
1、利用系統廣播拉活，在發生系統事件的時候，系統會發出相應的廣播，
詳情查看：http://blog.csdn.NET/sunshinetan/article/details/53126857
2、利用系統Service機制拉活，在Service有一個onStartCommand
推薦博客：http://blog.csdn.net/wulianghuan/article/details/8596467
Android開發的過程中，每次調用startService(Intent)的時候，都會調用該Service對象的onStartCommand(Intent,int,int)方法，然後在onStartCommand方法中做一些處理。然後我們注意到這個函數有一個int的返回值，這篇文章就是簡單地講講int返回值的作用。從Android官方文檔中，我們知道onStartCommand有4種返回值：
START_STICKY：如果service進程被kill掉，保留service的狀態為開始狀態，但不保留遞送的intent對象。隨後系統會嘗試重新創建service，由於服務狀態為開始狀態，所以創建服務後一定會調用onStartCommand
(Intent,int,int)方法。如果在此期間沒有任何啟動命令被傳遞到service，那麼參數Intent將為null。（service因內存不足的情況下，殺死的進程才可以拉活，這里要特別注意，不是所有情況都可以拉活。第一次server被殺死後，會在5秒後拉活，第二次會在10秒後，第三次會在20秒後。之後就不會在拉活。第二種情況是獲得root許可權通過stop停止的，也是無法通過server拉活）
START_NOT_STICKY：「非粘性的」。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統將會把它置為started狀態，系統不會自動重啟該服務，直到startService(Intent intent)方法再次被用;。
START_REDELIVER_INTENT：重傳Intent。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務，並將Intent的值傳入。
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保證服務被kill後一定能重啟。
3、利用Native進程拉活，
4、利用JobScheler機制拉活：Android5.0之後提供的一個機制，他會監聽主進程的存活，如果死掉就會激活拉活進程。
5、利用賬號同步機制拉活：android系統有一個賬戶系統，設置一個自己的賬戶，android會定期喚醒賬戶更新服務。我們可以自己設定同步的事件間隔，且發起更新的是系統，不會受到任何限制。需要在 AndroidManifest 中定義賬號授權與同步服務。
Android 版本（Android N）中系統對賬戶同步這里做了變動，該方法不再有效。
缺點：
a.用戶會在系統設置的賬戶列表裡面看到一個不認識的賬戶；
b.同步的事件間隔是有限制的，最短1分鍾，見源碼，如果小雨60秒，置為60秒；
c.用戶可以卸載賬戶；
d.必須聯網！google提供這個組件是讓你同步賬戶信息，不聯網就不能保活！
❹ 關於APP進程被殺死，極光推送收不到消息的解決辦法
推送是每一個APP必不可少的一部分，這幾天正好在做這一塊，所以總結一下遇到的一些問題。在APP被殺死的情況下，對應的推送service也一起被殺死了，這個時候我們怎麼能夠收到後台的推送呢？
解決辦法很簡單，但是也特別粗暴，在mainfest中給application設置這個屬性android:persistent="true"，看意思我們就知道，持續的，一直的，這樣的話，app是殺不死的，推送肯定有可以收到了。但是強烈建議不要這樣做，因為這樣就像某些流氓軟體一樣了，畢竟我們做個應用出來，也不想讓別人以為我們的是流氓軟體吧。好了，重頭戲來了，最後一種方法，也是我比較推薦的一種。用Broadcast Receivers。我們都知道，推送實際上應用的就是廣播，這里我們自定義一個廣播接收器，讓它繼承系統的Broadcast Receivers，然後復寫它的onReceive方法，在onReceive裡面開啟推送的服務。最後在mainfest中去注冊我們自定義的廣播接收器。這里一定要用靜態注冊的廣播接收器。如果是動態注冊的，APP被殺死後，廣播接收器也會被殺死。下面我已極光推送為例。