android殺不死

⑴ 進程保活

一 、問：什麼是進程保活？

答：進程保活就是進程永遠存在內存中，是殺不死的，就算殺死了也會有辦法重新啟動起來，其實這些並不是流氓手段，很多情況下，如果你想給你的用戶提供服務，就必須有一個進程常駐著，便於在特定的時候做一些特定的事情，比如廣播接受者，他就不支持靜態注冊，也就是說如果我們想接受屏幕開關啟動的廣播，必須要在進程中動態注冊，這個時候如果沒有一個常駐的進程，鎖屏業務就無法正常的為用戶展開服務。

二、問：進程是怎麼死掉的呢？

答：其實進程被殺死的原因，一方面是人為的，二、可能被第三方應用殺死，如殺敵軟體等。

三、問：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被殺死後，廣播接收器也會被殺死。下面我已極光推送為例。

⑶ android 微信為什麼清理內存的時候，殺不死

因為它服務有留駐後台，然後會把程序喚醒
所以你要把它的後台服務也要kill掉才行