android進程服務

A. 請問android系統中的進程，任務，服務三者的區別和聯系

進程是總稱，包括第三方應用和系統應用以及系統底層模塊。任務是你安裝的第三方應用進程。而服務是系統模塊進程。

B. Android提升服務進程優先順序

在android應用開發時，我們經常會在後台開一個service，來處理一些業務操作。最近公司的一個項目就是，通過service不斷地和硬體設備交互，獲取數據，在頁面長時間停留在一個頁面時，手機的屏幕會出項鎖屏的狀況，這時，我們的應用的優先順序就會下降，很多次，等打開屏幕的瞬間，我發現原來的原來的進程被殺死了，應用又回到了首頁，尤其是在Android高版本的系統中尤為突出。所以下面我們通過提成優先順序的方式，來進行進程保活

2.在程序開始的地方注冊這個廣播接收者

4.定義這個activity的style屬性 value - style.xml 文件

5.Androidmanifest文件中注冊這個activity

大功告成！
經過測試，本人的華為榮耀9i，原來存在的問題被解決了，希望大家能互相交流經驗。

C. 安卓開發線程和進程講解

本教程為大家介紹安卓開發中的線程和進程，安卓平台中當首次啟動運行一個組件的時候，Android會相應的啟動了一個進程。默認的，所有的組件和程序運行在這個進程和線程中，也可以安排組件在其他的進程或者線程中運行。
進程：組件運行的進程由manifest file控制。組件的節點activity, service, receiver, 和 provider 都包含一個 process 屬性。這個屬性可以設置組件運行的進程：可以配置組件在一個獨立進程運行，或者多個組件在同一個進程運行。甚至可以多個程序在一個進程中運行——如果這些程序共享一個User ID並給定同樣的許可權。 節點也包含 process 屬性，用來設置程序中所有組件的默認進程。
所有的組件在此進程的主線程中實例化，系統對這些組件的調用從主線程中分離。並非每個對象都會從主線程中分離。一般來說，響應例如View.onKeyDown()用戶操作的方法和通知的方法也在主線程中運行。這就表示，組件被系統調用的時候不應該長時間運行或者阻塞操作(如網路操作或者計算大量數據)，因為這樣會阻塞進程中的其他組件。可以把這類操作從主線程中分離。
當更加常用的進程無法獲取足夠內存,Android可能會關閉不常用的進程。下次啟動程序的時候會重新啟動進程。
當決定哪個進程需要被關閉的時候， Android會考慮哪個對用戶更加有用。如Android會傾向於關閉一個長期不顯示在界面的旦頌殲進程來支持一個經常顯示在界面的進程。
線程：即使為組件分配了不同的進程，有時候也需要再分配線程。比如用戶界面需要很快對用戶進行響應，因此某些費時的操作，如網路連接、下載或者非常佔用伺服器時間的操作應該放到其他線程。
線程通過java的標准對象Thread 創建. Android 提供了很多方便的管理線程的方法：— Looper 在線程中運行一個消息循環; Handler 傳遞一個消息; HandlerThread 創建一個帶有消息循環的線程。
遠程調用Remote procere calls
Android有一個遠程調用(RPCs) 的輕量級機制— 通過這個機制，方法可以在本地調用，在遠程執行(在其他進程執行)，還可以返回一個值。要實現這個需求，必須分解方法調用，並且所有要傳遞的數據必須是操作系統可以訪問的級別。從本地的進程和內存地址傳送到遠程的進程和內存地櫻正址並在遠程處理和返回。返回值必須向相反的方向傳遞。Android提供了做以上操作的代碼，所以開發者可以專注於實現RPC的介面。
一個RPC介面只能包含方法。所有的方法都是同步執行的(直到遠程方法返回，本地方法才結束阻塞)，沒有返回值的時候也是如此。
簡單來說，這個機制是這樣的：使用IDL (interface definition language)定義你想要實現的介面， aidl 工具可以生成用於java的介面定義，本地和遠程都要使用這個定義。它包含2個類，
inner類包含了所有的管理遠程程序(符合IDL描述的介面)所需要的代碼。所有的inner類實現了IBinder 介面.其中一個在本地使用，可以不管它的代碼;另外一個叫做Stub繼承了 Binder 類。為了實現遠程調用，這個類包含RPC介面。開發者可以繼承Stub類來實現需要的方法。
一般來說，遠程進程會被一個service管理(因為service可以通知操作系統這個進程的信息並和其他進程通信)，它也會包含aidl 工具產生的介面文件，Stub類實現了遠處那個方法。服務的客戶端只需要aidl 工具產生的介面文件。
以下是如何連接服務和客戶端調用：
·服務的客戶端(本地)會實現onServiceConnected() 和onServiceDisconnected() 方法，這樣，當客戶端連接或者斷開連接的時候可以獲取到通知。通過 bindService() 獲取到服務的連接。
· 服務的 onBind() 方法中可以接收或者拒絕連接，取決它收到的intent (intent通過 bindService()方法連接到服務). 如果服務接收了連接，會返回一個Stub類的實例.
· 如果服務接受了連接，Android會調用客戶端的onServiceConnected() 方法，模沖並傳遞一個Ibinder對象(系統管理的Stub類的代理)，通過這個代理，客戶端可以連接遠程的服務。
以上的描述省略很多RPC的機制。請參見Designing a Remote Interface Using AIDL 和 IBinder 類。
線程安全的方法
在某些情況下，方法可能調用不止一個的線程，因此需要注意方法的線程安全。
對於可以遠程調用的方法，也要注意這點。當一個調用在Ibinder對象中的方法的程序啟動了和Ibinder對象相同的進程，方法就在Ibinder的進程中執行。但是，如果調用者發起另外一個進程，方法在另外一個線程中運行，這個線程在和IBinder對象在一個線程池中;它不會在進程的主線程中運行。例如，一個service從主線程被調用onBind() 方法，onBind() 返回的對象(如實現了RPC的Stub子類)中的方法會被從線程池中調用。因為一個服務可能有多個客戶端請求，不止一個線程池會在同一時間調用IBinder的方法。因此IBinder必須線程安全。
簡單來說，這個機制是這樣的：使用IDL (interface definition language)定義你想要實現的介面， aidl 工具可以生成用於java的介面定義，本地和遠程都要使用這個定義。它包含2個類，
inner類包含了所有的管理遠程程序(符合IDL描述的介面)所需要的代碼。所有的inner類實現了IBinder 介面.其中一個在本地使用，可以不管它的代碼;另外一個叫做Stub繼承了 Binder 類。為了實現遠程調用，這個類包含RPC介面。開發者可以繼承Stub類來實現需要的方法。
一般來說，遠程進程會被一個service管理(因為service可以通知操作系統這個進程的信息並和其他進程通信)，它也會包含aidl 工具產生的介面文件，Stub類實現了遠處那個方法。服務的客戶端只需要aidl 工具產生的介面文件。
以下是如何連接服務和客戶端調用：
·服務的客戶端(本地)會實現onServiceConnected() 和onServiceDisconnected() 方法，這樣，當客戶端連接或者斷開連接的時候可以獲取到通知。通過 bindService() 獲取到服務的連接。
· 服務的 onBind() 方法中可以接收或者拒絕連接，取決它收到的intent (intent通過 bindService()方法連接到服務). 如果服務接收了連接，會返回一個Stub類的實例.
· 如果服務接受了連接，Android會調用客戶端的onServiceConnected() 方法，並傳遞一個Ibinder對象(系統管理的Stub類的代理)，通過這個代理，客戶端可以連接遠程的服務。
線程安全的方法
在某些情況下，方法可能調用不止一個的線程，因此需要注意方法的線程安全。
對於可以遠程調用的方法，也要注意這點。當一個調用在Ibinder對象中的方法的程序啟動了和Ibinder對象相同的進程，方法就在Ibinder的進程中執行。但是，如果調用者發起另外一個進程，方法在另外一個線程中運行，這個線程在和IBinder對象在一個線程池中;它不會在進程的主線程中運行。例如，一個service從主線程被調用onBind() 方法，onBind() 返回的對象(如實現了RPC的Stub子類)中的方法會被從線程池中調用。因為一個服務可能有多個客戶端請求，不止一個線程池會在同一時間調用IBinder的方法。因此IBinder必須線程安全。
簡單來說，一個content provider 可以接收其他進程的數據請求。即使ContentResolver和ContentProvider類沒有隱藏了管理交互的細節，ContentProvider中響應這些請求的方法(query(), insert(), delete(), update(), and getType() )— 是在content provider的線程池中被調用的，而不是ContentProvider的本身進程。因為這些方法可能是同時從很多線程池運行的，所以這些方法必須要線程安全。

D. Android 守護進程的實現方式

在我們進行應用開發時，會遇到上級的各種需求，其中有一條 剛需： 後台保活 ，更有甚者：

我要我們的應用永遠活在用戶的手機後台不被殺死 —— 這都 TM 的扯淡

除了系統級別的應用能持續運行，所有三方程序都有被殺死的那一天！當然 QQ/微信/陌陌 等會好一些，因為他們已經深入設備的 心 ；
我們能做的只是通過各種手段盡量讓我們的程序在後台運行的時間長一些，或者在被幹掉的時候，能夠重新站起來，而且這個也不是每次都有效的，也是不能在所有的設備的上都有效的；要做到後台進程保活，我們需要做到兩方便：

要實現實現上邊所說，通過下邊幾點來實現，首先我們需要了解下進程的優先順序劃分：

Process Importance 記錄在 ActivityManager.java 類中:

了解進程優先順序之後，我們還需要知道一個進程回收機制的東西；這里參考 AngelDevil 在博客園上的一篇文章:

Android 的 Low Memory Killer 基於 Linux 的 OOM 機制，在 Linux 中，內存是以頁面為單位分配的，當申請頁面分配時如果內存不足會通過以下流程選擇bad進程來殺掉從而釋放內存：

在 Low Memory Killer 中通過進程的 oom_adj 與佔用內存的大小決定要殺死的進程， oom_adj 越小越不容易被殺死；
Low Memory Killer Driver 在用戶空間指定了一組內存臨界值及與之一一對應的一組 oom_adj 值，當系統剩餘內存位於內存臨界值中的一個范圍內時，如果一個進程的 oom_adj 值大於或等於這個臨界值對應的 oom_adj 值就會被殺掉。

下邊是表示 Process State (即老版本里的 OOM_ADJ )數值對照表，數值越大，重要性越低，在新版SDK中已經在 android 層去除了小於0的進程狀態

Process State （即老版本的 OOM_ADJ ）與 Process Importance 對應關系，這個方法也是在 ActivityManager.java 類中，有了這個關系，就知道可以知道我們的應用處於哪個級別，對於我們後邊優化有個很好地參考

一般情況下，設備端進程被幹掉有一下幾種情況

由以上分析，我們可以可以總結出，如果想提高我們應用後台運行時間，就需要提高當前應用進程優先順序，來減少被殺死的概率

分析了那麼多，現在對Android自身後台進程管理，以及進程的回收也有了一個大致的了解，後邊我們要做的就是想盡一切辦法去提高應用進程優先順序，降低進程被殺的概率；或者是在被殺死後能夠重新啟動後台守護進程

第一種方式就是利用系統漏洞，使用 startForeground() 將當前進程偽裝成前台進程，將進程優先順序提高到最高(這里所說的最高是服務所能達到的最高，即1);

這種方式在 7.x 之前都是很好用的，QQ、微信、IReader、Keep 等好多應用都是用的這種方式實現；因為在7.x 以後的設備上，這種偽裝前台進程的方式也會顯示出來通知欄提醒，這個是取消不掉的，雖然 Google 現在還沒有對這種方式加以限制，不過這個已經能夠被用戶感知到了，這種方式估計也用不了多久了

下邊看下實現方式，這邊這個 VMDaemonService 就是一個守護進程服務，其中在服務的 onStartCommand() 方法中調用 startForeground() 將服務進程設置為前台進程，當運行在 API18 以下的設備是可以直接設置，API18 以上需要實現一個內部的 Service ，這個內部類實現和外部類同樣的操作，然後結束自己；當這個服務啟動後就會創建一個定時器去發送廣播，當我們的核心服務被幹掉後，就由另外的廣播接收器去接收我們守護進程發出的廣播，然後喚醒我們的核心服務；

當我們啟動這個守護進程的時候，就可以使用以下 adb 命令查看當前程序的進程情況（需要 adb shell 進去設備），
為了等下區分進程優先順序，我啟動了一個普通的後台進程，兩外兩個一個是我們啟動的守護進程，一個是當前程序的核心進程，可以看到除了後台進程外，另外兩個進程都帶有 isForeground=true 的屬性：

然後我們可以用下邊的命令查看 ProcessID

有了 ProcessID 之後，我們可以根據這個 ProcessID 獲取到當前進程的優先順序狀態 Process State ，對應 Linux 層的 oom_adj
可以看到當前核心進程的級別為 0 ，因為這個表示當前程序運行在前台 UI 界面，守護進程級別為 1 ，因為我們利用漏洞設置成了前台進程，雖然不可見，但是他的級別也是比較高的，僅次於前台 UI 進程，然後普通後台進程級別為 4 ；當我們退到後台時，可以看到核心進程的級別變為 1 了，這就是因為我們利用 startForeground() 將進程設置成前台進程的原因，這樣就降低了進程被系統回收的概率了；

可以看到這種方式確實能夠提高進程優先順序，但是在一些國產的設備上還是會被殺死的，比我我測試的時候小米點擊清空最近運行的應用進程就別幹掉了；當把應用加入到設備白名單里就不會被殺死了，微信就是這樣，人家直接裝上之後就已經在白名單里了，我們要做的就是在用戶使用中引導他們將我們的程序設置進白名單，將守護進程和白名單結合起來，這樣才能保證我們的應用持續或者

Android系統在5.x以上版本提供了一個 JobSchele 介面，系統會根據自己實現定時去調用改介面傳遞的進程去實現一些操作，而且這個介面在被強制停止後依然能夠正常的啟動；不過在一些國產設備上可能無效，比如小米；
下邊是 JobServcie 的實現：

我們要做的就是在需要的時候調用 JobSchele 的 schele 來啟動任務；剩下的就不需要關心了， JobSchele 會幫我們做好，下邊就是我這邊實現的啟動任務的方法：

在實現 Service 類時，將 onStartCommand() 返回值設置為 START_STICKY ，利用系統機制在 Service 掛掉後自動拉活；不過這種方式只適合比較原生一些的系統，像小米，華為等這些定製化比較高的第三方廠商，他們都已經把這些給限制掉了；

這種方式在以下兩種情況無效：

事事沒有絕對，萬物總有一些漏洞，就算上邊的那些方式不可用了，後邊肯定還會出現其他的方式；我們不能保證我們的應用不死，但我們可以提高存活率；

其實最好的方式還是把程序做好，讓程序本身深入人心，別人喜歡你了，就算你被幹掉了，他們也會主動的把你拉起來，然後把你加入他們的白名單，然後我們的目的就實現了不是 😁 ~

E. 深入理解Android：SystemServer進程的作用

看了一段時間關於SystemServer進程的博客，有點小理解，寫一篇關於SystemServer的小筆記，然後走一遍過程。

ZygoteInit通過startSystemServer方法fork了一個SS進程。這個進程有啥作用呢。

handlerSystemServerProcess()方法只要是以下三個方法：

其中 applicationInit() 很有意思很重要。該方法中有一個，invokeStaticMain方法通過反射調用main方法：

run方法最終通過反射調用SystemServer的main方法，作用是：
通過以上分析其實main方法的主要作用是：
1、調整系統時間
2、設置屬性persist.sys.dalvik.vm.lib.2的值為當前虛擬機的運行庫路徑
3、裝載libandroid_servers.so庫，初始化native層service
4、初始化系統Context
5、創建SystemServiceManager對象
6、調用startBootstrapServices()，startCoreServices()，startOtherServices()啟動所有的Java服務

另外也可以看到為什麼說handler默認是主線程，以及android 應用本身就是基於handler/Looper/Message的
startBootstrapServices()：啟動java層的各種服務。framwork層的服務。例如AMS

startCoreServices：啟動核心服務：

startOtherServices也與上面一樣啟動各種服務。

總結下：SystemServer進程最終會執行到SystemServer類中的main方法中，初始化各種伺服器，其中第一個初始化的就是ActivityManagerService。當我們點擊啟動app的時候。Zygote會對這個消息進行處理，最終執行到applicationInit。那麼是在哪裡調用方法啟動應用的呢？