android獨立進程

1. android 推送服務為什麼要獨立進程

「進程」？你應該是指在android中的「線程」吧，主線程是UI線程，不能阻塞。所以不建議放到主線程。既然不是主線程，那就要另啟獨立線程咯。如果不是，請勿噴～

2. android中線程,進程都是什麼意思（通俗易懂的）

android中的進程就是一個個獨立的APP應用。線程可以理解為進程中的時間片斷：從代碼執行的角度來看，主線程就是APP從開始一句一句代碼從上往下執行，而子線程的執行時間片斷與主線程的執行時間片斷是分開的，執行時間不會影響到主線程的執行時間。

3. Android中的線程與進程之間的關系簡單解釋

一、Android中的進程
當一個程序第一次啟動的時候，Android會啟動一個LINUX進程和一個主線程。默認的情況下，所有該程序的組件都將在該進程和線程中運行。 同時，Android會為每個應用程序分配一個單獨的LINUX用戶。Android會盡量保留一個正在運行進程，只在內存資源出現不足時，Android會嘗試停止一些進程從而釋放足夠的資源給其他新的進程使用， 也能保證用戶正在訪問的當前進程有足夠的資源去及時地響應用戶的事件。
我們可以將一些組件運行在其他進程中，並且可以為任意的進程添加線程。組件運行在哪個進程中是在manifest文件里設置的，其中<Activity>，<Service>，<receiver>和<provider>都有一個process屬性來指定該組件運行在哪個進程之中。我們可以設置這個屬性，使得每個組件運行在它們自己的進程中，或是幾個組件共同享用一個進程，或是不共同享用。<application>元素也有一個process屬性，用來指定所有的組件的默認屬性。
Android中的所有組件都在指定的進程中的主線程中實例化的，對組件的系統調用也是由主線程發出的。每個實例不會建立新的線程。對系統調用進行響應的方法——例如負責執行用戶動作的View.onKeyDown()和組件的生命周期函數——都是運行在這個主線程中的。這意味著當系統調用這個組件時，這個組件不能長時間的阻塞主線程。例如進行網路操作時或是更新UI時，如果運行時間較長，就不能直接在主線程中運行，因為這樣會阻塞這個進程中其他的組件，我們可以將這樣的組件分配到新建的線程中或是其他的線程中運行。
二、Android中的線程
線程在代碼是使用標準的java Thread對象來建立，那麼在Android系統中提供了一系列方便的類來管理線程——Looper用來在一個線程中執行消息循環，Handler用來處理消息，HandlerThread創建帶有消息循環的線程。
三、進程與線程的關系
它們之間的區別：

1、線程是進程的一部分，所以線程有的時候被稱為是輕權進程或者輕量級進程。
2、一個沒有線程的進程是可以被看作單線程的，如果一個進程內擁有多個進程，進程的執行過程不是一條線（線程）的，而是多條線（線程）共同完成的。
3、系統在運行的時候會為每個進程分配不同的內存區域，但是不會為線程分配內存（線程所使用的資源是它所屬的進程的資源），線程組只能共享資源。那就是說，出了CPU之外（線程在運行的時候要佔用CPU資源），計算機內部的軟硬體資源的分配與線程無關，線程只能共享它所屬進程的資源。
4、與進程的控製表PCB相似，線程也有自己的控製表TCB，但是TCB中所保存的線程狀態比PCB表中少多了。
5、進程是系統所有資源分配時候的一個基本單位，擁有一個完整的虛擬空間地址，並不依賴線程而獨立存在。
它們之間的聯系：
簡單的說就是：一個程序包含進程，進程又包含線程，線程是進程的一個組成部分，進程是操作系統分配資源的基本單位，線程是不會分配資源的，一個進程可以包含多個線程，然後這些線程共享進程的資源。
分開來說就是：
線程是進程的一個實體，是CPU 調度和分配的基本單位，其本身不擁有系統資源，只含有程序計數器、寄存器和棧等一些運行時必不可少的基本資源。同屬一個進程的線程共享進程中的全部資源。
進程是系統資源分配時的一個基本單位，擁有一個完整的虛擬空間地址。
系統在運行的時候會為每個進程分配不同的內存區域。
線程組只能共享資源，即除了CPU外，計算機內部的軟硬體資源的分配與線程無關，線程只能共享它所屬進程的資源。

4. android broadreceiver 運行在哪個進程

廣播接收器是運行在UI線程。

下面介紹來自於android學習手冊，android學習手冊包含9個章節，108個例子，源碼文檔隨便看，例子都是可交互，可運行，源碼採用android studio目錄結構，高亮顯示代碼，文檔都採用文檔結構圖顯示，可以快速定位。360手機助手中下載,圖標上有貝殼

1.Android廣播機制概述

Android廣播分為兩個方面：廣播發送者和廣播接收者，通常情況下，BroadcastReceiver指的就是廣播接收者（廣播接收器）。廣播作為Android組件間的通信方式，可以使用的場景如下：
1.同一app內部的同一組件內的消息通信（單個或多個線程之間）；

2.同一app內部的不同組件之間的消息通信（單個進程）；

3.同一app具有多個進程的不同組件之間的消息通信；

4.不同app之間的組件之間消息通信；

5.Android系統在特定情況下與App之間的消息通信。

從實現原理看上，Android中的廣播使用了觀察者模式，基於消息的發布/訂閱事件模型。因此，從實現的角度來看，Android中的廣播將廣播的發送者和接受者極大程度上解耦，使得系統能夠方便集成，更易擴展。具體實現流程要點粗略概括如下：

1.廣播接收者BroadcastReceiver通過Binder機制向AMS(Activity Manager Service)進行注冊；

2.廣播發送者通過binder機制向AMS發送廣播；

3.AMS查找符合相應條件（IntentFilter/Permission等）的BroadcastReceiver，將廣播發送到BroadcastReceiver（一般情況下是Activity）相應的消息循環隊列中；

4.消息循環執行拿到此廣播，回調BroadcastReceiver中的onReceive()方法。

對於不同的廣播類型，以及不同的BroadcastReceiver注冊方式，具體實現上會有不同。但總體流程大致如上。

由此看來，廣播發送者和廣播接收者分別屬於觀察者模式中的消息發布和訂閱兩端，AMS屬於中間的處理中心。廣播發送者和廣播接收者的執行是非同步的，發出去的廣播不會關心有無接收者接收，也不確定接收者到底是何時才能接收到。顯然，整體流程與EventBus非常類似。

在上文說列舉的廣播機制具體可以使用的場景中，現分析實際應用中的適用性：

第一種情形：同一app內部的同一組件內的消息通信（單個或多個線程之間），實際應用中肯定是不會用到廣播機制的（雖然可以用），無論是使用擴展變數作用域、基於介面的回調還是Handler-post/Handler-Message等方式，都可以直接處理此類問題，若適用廣播機制，顯然有些「殺雞牛刀」的感覺，會顯太「重」；

第二種情形：同一app內部的不同組件之間的消息通信（單個進程），對於此類需求，在有些教復雜的情況下單純的依靠基於介面的回調等方式不好處理，此時可以直接使用EventBus等，相對而言，EventBus由於是針對統一進程，用於處理此類需求非常適合，且輕松解耦。可以參見文件《Android各組件/控制項間通信利器之EventBus》。

第三、四、五情形：由於涉及不同進程間的消息通信，此時根據實際業務使用廣播機制會顯得非常適宜。下面主要針對Android廣播中的具體知識點進行總結。

2.BroadcastReceiver

自定義BroadcastReceiver

自定義廣播接收器需要繼承基類BroadcastReceivre，並實現抽象方法onReceive(context, intent)方法。廣播接收器接收到相應廣播後，會自動回到onReceive(..)方法。默認情況下，廣播接收器也是運行在UI線程，因此，onReceive方法中不能執行太耗時的操作。否則將因此ANR。一般情況下，根據實際業務需求，onReceive方法中都會涉及到與其他組件之間的交互，如發送Notification、啟動service等。
下面代碼片段是一個簡單的廣播接收器的自定義：

1 public class MyBroadcastReceiver extends BroadcastReceiver {
2 public static final String TAG = "MyBroadcastReceiver";
3 public static int m = 1;
4
5 @Override
6 public void onReceive(Context context, Intent intent) {
7 Log.w(TAG, "intent:" + intent);
8 String name = intent.getStringExtra("name");
9 Log.w(TAG, "name:" + name + " m=" + m);
10 m++;
11
12 Bundle bundle = intent.getExtras();
13
14 }
15 }

BroadcastReceiver注冊類型

BroadcastReceiver總體上可以分為兩種注冊類型：靜態注冊和動態注冊。

1).靜態注冊：
直接在AndroidManifest.xml文件中進行注冊。規則如下：

<receiver android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permission="string"
android:process="string" >
. . .
</receiver>

其中，需要注意的屬性
android:exported ——此broadcastReceiver能否接收其他App的發出的廣播，這個屬性默認值有點意思，其默認值是由receiver中有無intent-filter決定的，如果有intent-filter，默認值為true，否則為false。（同樣的，activity/service中的此屬性默認值一樣遵循此規則）同時，需要注意的是，這個值的設定是以application或者application user id為界的，而非進程為界（一個應用中可能含有多個進程）；
android:name —— 此broadcastReceiver類名；
android:permission ——如果設置，具有相應許可權的廣播發送方發送的廣播才能被此broadcastReceiver所接收；
android:process ——broadcastReceiver運行所處的進程。默認為app的進程。可以指定獨立的進程（Android四大基本組件都可以通過此屬性指定自己的獨立進程）

常見的注冊形式有：

<receiver android:name=".MyBroadcastReceiver" >
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>

其中，intent-filter由於指定此廣播接收器將用於接收特定的廣播類型。本示例中給出的是用於接收網路狀態改變或開啟啟動時系統自身所發出的廣播。當此App首次啟動時，系統會自動實例化MyBroadcastReceiver，並注冊到系統中。

之前常說：靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立，具體分析詳見本文後面部分。

2).動態注冊：
動態注冊時，無須在AndroidManifest中注冊<receiver/>組件。直接在代碼中通過調用Context的registerReceiver函數，可以在程序中動態注冊BroadcastReceiver。registerReceiver的定義形式如下：

1 registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
2 registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheler)

典型的寫法示例如下：

1 public class MainActivity extends Activity {
2 public static final String BROADCAST_ACTION = "com.example.corn";
3 private BroadcastReceiver mBroadcastReceiver;
4
5 @Override
6 protected void onCreate(Bundle savedInstanceState) {
7 super.onCreate(savedInstanceState);
8 setContentView(R.layout.activity_main);
9
10 mBroadcastReceiver = new MyBroadcastReceiver();
11 IntentFilter intentFilter = new IntentFilter();
12 intentFilter.addAction(BROADCAST_ACTION);
13 registerReceiver(mBroadcastReceiver, intentFilter);
14 }
15
16 @Override
17 protected void onDestroy() {
18 super.onDestroy();
19 unregisterReceiver(mBroadcastReceiver);
20 }
21
22 }

註：Android中所有與觀察者模式有關的設計中，一旦涉及到register，必定在相應的時機需要unregister。因此，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)。

當此Activity實例化時，會動態將MyBroadcastReceiver注冊到系統中。當此Activity銷毀時，動態注冊的MyBroadcastReceiver將不再接收到相應的廣播。

3.廣播發送及廣播類型

經常說」發送廣播「和」接收「，表面上看廣播作為Android廣播機制中的實體，實際上這一實體本身是並不是以所謂的」廣播「對象存在的，而是以」意圖「（Intent）去表示。定義廣播的定義過程，實際就是相應廣播」意圖「的定義過程，然後通過廣播發送者將此」意圖「發送出去。被相應的BroadcastReceiver接收後將會回調onReceive()函數。

下段代碼片段顯示的是一個普通廣播的定義過程，並發送出去。其中setAction(..)對應於BroadcastReceiver中的intentFilter中的action。

1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.putExtra("name", "qqyumidi");
4 sendBroadcast(intent);

根據廣播的發送方式，可以將其分為以下幾種類型：
1.Normal Broadcast：普通廣播

2.System Broadcast: 系統廣播

3.Ordered broadcast：有序廣播

4.Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)

5.Local Broadcast：App應用內廣播

下面分別總結下各種類型的發送方式及其特點。

1).Normal Broadcast：普通廣播

此處將普通廣播界定為：開發者自己定義的intent，以context.sendBroadcast_"AsUser"(intent, ...)形式。具體可以使用的方法有：
sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)。
普通廣播會被注冊了的相應的感興趣（intent-filter匹配）接收，且順序是無序的。如果發送廣播時有相應的許可權要求，BroadCastReceiver如果想要接收此廣播，也需要有相應的許可權。

2).System Broadcast: 系統廣播

Android系統中內置了多個系統廣播，只要涉及到手機的基本操作，基本上都會發出相應的系統廣播。如：開啟啟動，網路狀態改變，拍照，屏幕關閉與開啟，點亮不足等等。每個系統廣播都具有特定的intent-filter，其中主要包括具體的action，系統廣播發出後，將被相應的BroadcastReceiver接收。系統廣播在系統內部當特定事件發生時，有系統自動發出。

3)Ordered broadcast：有序廣播

有序廣播的有序廣播中的「有序」是針對廣播接收者而言的，指的是發送出去的廣播被BroadcastReceiver按照先後循序接收。有序廣播的定義過程與普通廣播無異，只是其的主要發送方式變為：sendOrderedBroadcast(intent, receiverPermission, ...)。

對於有序廣播，其主要特點總結如下：

1>多個具當前已經注冊且有效的BroadcastReceiver接收有序廣播時，是按照先後順序接收的，先後順序判定標准遵循為：將當前系統中所有有效的動態注冊和靜態注冊的BroadcastReceiver按照priority屬性值從大到小排序，對於具有相同的priority的動態廣播和靜態廣播，動態廣播會排在前面。

2>先接收的BroadcastReceiver可以對此有序廣播進行截斷，使後面的BroadcastReceiver不再接收到此廣播，也可以對廣播進行修改，使後面的BroadcastReceiver接收到廣播後解析得到錯誤的參數值。當然，一般情況下，不建議對有序廣播進行此類操作，尤其是針對系統中的有序廣播。

4)Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)。

既然已經deprecated，此處不再多做總結。

5)Local Broadcast：App應用內廣播（此處的App應用以App應用進程為界）

由前文闡述可知，Android中的廣播可以跨進程甚至跨App直接通信，且注冊是exported對於有intent-filter的情況下默認值是true，由此將可能出現安全隱患如下：

1.其他App可能會針對性的發出與當前App intent-filter相匹配的廣播，由此導致當前App不斷接收到廣播並處理；

2.其他App可以注冊與當前App一致的intent-filter用於接收廣播，獲取廣播具體信息。

無論哪種情形，這些安全隱患都確實是存在的。由此，最常見的增加安全性的方案是：

1.對於同一App內部發送和接收廣播，將exported屬性人為設置成false，使得非本App內部發出的此廣播不被接收；

2.在廣播發送和接收時，都增加上相應的permission，用於許可權驗證；

3.發送廣播時，指定特定廣播接收器所在的包名，具體是通過intent.setPackage(packageName)指定在，這樣此廣播將只會發送到此包中的App內與之相匹配的有效廣播接收器中。

App應用內廣播可以理解成一種局部廣播的形式，廣播的發送者和接收者都同屬於一個App。實際的業務需求中，App應用內廣播確實可能需要用到。同時，之所以使用應用內廣播時，而不是使用全局廣播的形式，更多的考慮到的是Android廣播機制中的安全性問題。

相比於全局廣播，App應用內廣播優勢體現在：

1.安全性更高；

2.更加高效。

為此，Android v4兼容包中給出了封裝好的LocalBroadcastManager類，用於統一處理App應用內的廣播問題，使用方式上與通常的全局廣播幾乎相同，只是注冊/取消注冊廣播接收器和發送廣播時將主調context變成了LocalBroadcastManager的單一實例。

代碼片段如下：

1 //registerReceiver(mBroadcastReceiver, intentFilter);
2 //注冊應用內廣播接收器
3 localBroadcastManager = LocalBroadcastManager.getInstance(this);
4 localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
5
6 //unregisterReceiver(mBroadcastReceiver);
7 //取消注冊應用內廣播接收器
8 localBroadcastManager.unregisterReceiver(mBroadcastReceiver);
9
10 Intent intent = new Intent();
11 intent.setAction(BROADCAST_ACTION);
12 intent.putExtra("name", "qqyumidi");
13 //sendBroadcast(intent);
14 //發送應用內廣播
15 localBroadcastManager.sendBroadcast(intent);

4.不同注冊方式的廣播接收器回調onReceive(context, intent)中的context具體類型

1).對於靜態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext；

2).對於全局廣播的動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Activity Context；

3).對於通過LocalBroadcastManager動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Application Context。

註：對於LocalBroadcastManager方式發送的應用內廣播，只能通過LocalBroadcastManager動態注冊的ContextReceiver才有可能接收到（靜態注冊或其他方式動態注冊的ContextReceiver是接收不到的）。

5.不同Android API版本中廣播機制相關API重要變遷

1).Android5.0/API level 21開始粘滯廣播和有序粘滯廣播過期，以後不再建議使用；

2).」靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立「

Android 3.1開始系統在Intent與廣播相關的flag增加了參數，分別是FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES。

FLAG_INCLUDE_STOPPED_PACKAGES：包含已經停止的包（停止：即包所在的進程已經退出）

FLAG_EXCLUDE_STOPPED_PACKAGES：不包含已經停止的包

主要原因如下：

自Android3.1開始，系統本身則增加了對所有app當前是否處於運行狀態的跟蹤。在發送廣播時，不管是什麼廣播類型，系統默認直接增加了值為FLAG_EXCLUDE_STOPPED_PACKAGES的flag，導致即使是靜態注冊的廣播接收器，對於其所在進程已經退出的app，同樣無法接收到廣播。

詳情參加Android官方文檔：http://developer.android.com/about/versions/android-3.1.html#launchcontrols

由此，對於系統廣播，由於是系統內部直接發出，無法更改此intent flag值，因此，3.1開始對於靜態注冊的接收系統廣播的BroadcastReceiver，如果App進程已經退出，將不能接收到廣播。

但是對於自定義的廣播，可以通過復寫此flag為FLAG_INCLUDE_STOPPED_PACKAGES，使得靜態注冊的BroadcastReceiver，即使所在App進程已經退出，也能能接收到廣播，並會啟動應用進程，但此時的BroadcastReceiver是重新新建的。

1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES);
4 intent.putExtra("name", "qqyumidi");
5 sendBroadcast(intent);

注1：對於動態注冊類型的BroadcastReceiver，由於此注冊和取消注冊實在其他組件（如Activity）中進行，因此，不受此改變影響。

注2：在3.1以前，相信不少app可能通過靜態注冊方式監聽各種系統廣播，以此進行一些業務上的處理（如即時app已經退出，仍然能接收到，可以啟動service等..）,3.1後，靜態注冊接受廣播方式的改變，將直接導致此類方案不再可行。於是，通過將Service與App本身設置成不同的進程已經成為實現此類需求的可行替代方案。

5. android 關屏 如何保持程序繼續運行

主要看第二個方法：（A,Bservice在兩個進程中，所以要用到AIDL來跨進程）

在原本只有一個serviceA的情況下再聲明一個serviceB，並為之新開啟一個進程；

serviceA被殺死的時候，serviceB立刻重啟serviceA；（在serviceB中重寫ServiceConnection中的Connect和Disconnect方法，在disconnect中start和bindserviceA）；

如下：在主服務StepService中的Disconnect方法中start和bindservice GuardService；

serviceB被殺死的時候，serviceA立刻重啟serviceB；（在serviceA中重寫ServiceConnection中的Connect和Disconnect方法，在disconnect中start和bindserviceB）

兩個進程互相守護

6. android服務和進程的區別

他們之間的區別：Service很大程度上充當了應用程序後台線程管理器的角色。（如果Activity中新開啟一個線程，當該Acitivyt關閉後，該線程依然在工作，但是與開啟它的Activity失去聯系。也就是說此時的這個線程處於失去管理的狀態。但是使用Service，則可以對後台運行的線程有效地管理。）
一個服務不是一個單獨的進程。服務對象本身並不意味著它是在自己的進程中運行，除非另有規定，否則它與運行程序是同在一個進程中。
一個服務不是一個單獨的線程。Service和其他組件一樣，默認情況下，Service中的所有代碼都是運行在主線程中。
在android中，為什麼不使用後台線程而使用Service？ 有3大要點：
1、Service可以放在獨立的進程中，所以更安全；

2、使用Service可以依賴現有的binder機制，不需要在應用層面上處理線程同步的繁雜工作；

3、系統可以重新啟動異常死去的Service。

說明：進程是由若干線程組成。（線程是進程中的一部分，進程包含多個線程在運行。）

7. Android進程與線程區別

所以下來特地去查了以下資料，先說說線程：
（1）在Android APP中，只允許有一個主線程，進行UI的渲染等等，但是不能進行耗時操作（網路交互等等），否則會造成ANR，就是線程阻塞卡死，未響應。
（2）除了主線程之外，耗時操作都應該規范到子線程中,線程之間會有相應的通信方式，但相互獨立。
（3）然後看了一下所查資料：
線程是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位。線程比進程更小，基本上不擁有系統資源，故對它的調度所用資源小，能更高效的提高系統內多個程序間並發執行的。 嗯，從大的說就是這樣。
在平時的Android開發過程中，基本上都會用到線程handler，thread等等，具體的實現方法我就不在這里寫了。

進程：
根據所查資料：是一個具有獨立功能的程序關於某個數據集合的一次運行活動。進程是系統進行資源分配和調度的一個獨立單位。可以申請和擁有系統資源，是一個動態的概念，是一個活動的實體，是一個「執行中的程序」。不只是程序的代碼，還包括當前的活動。
這應該是一個比較大的概念，存在於一個系統中，與線程的區別是：

1、子進程和父進程有不同的代碼和數據空間，而多個線程則共享數據空間，每個線程有自己的執行堆棧和程序計數器為其執行上下文。
2、進程間相互獨立，同一進程的各線程間共享。某進程內的線程在其它進程不可見。

3、進程間通信IPC，線程間可以直接讀寫進程數據段（如全局變數）來進行通信——需要進程同步和互斥手段的輔助，以保證數據的一致性。

4、線程上下文切換比進程上下文切換要快得多。

8. 在android里Service不是一個單獨的進程也不是一個單獨的線程,那麼為什麼用戶可以在

根據API的描述：
service是運行在主線程上的，而不是運行在另一個線程中，如果你想在service中處理很占時間的操作，你必須在service中開線程，這樣可以降低activity沒有響應的風險。

9. android 應用進程是怎麼創建的

程序關閉後確實也會有數據就在內存里，如果不使用強行停止就不會清理，你不信可以打開瀏覽器然後打開一個網站，然後使用任務管理器關掉(不要用設置里的強行停止，會清空數據的)，再打開瀏覽器，會發現你打開的網頁還在 安卓啟動進程時需要先優化和解釋應用程序的源碼，然後復制一個虛擬機，將虛擬機內容換成應用程序的 最開始的虛擬機是安卓開機時創建的，所有的進程都由這個母進程復制過來的。所以你知道為什麼應用程序開機啟動可以加速了，開機時就把這個進程的虛擬機准備好 並且解釋程序代碼的過程實際上把程序緩存了一下 內存比存儲快，啟動就快。可以理解為類似於windows7上的superfetch當然原理完全不同。也可以給應用程序做odex，就是一個事先優化和解釋好的文件 你看你手機自帶程序都有odex，就是為了起到加速作用。 安卓的apk與windows完全不同，它實際上是個zip，而且所有的資源都在這個包裡面，不像windows還會有什麼dll在外面。所謂應用程序安裝，實際上是把apk復制到了手機內存里(路徑 /data/app)，然後在data/data里為應用程序創建獨立的存儲空間(實際上是個ext文件系統的文件夾)，然而運行的過程就像java一樣，還要打開壓縮包什麼的。

10. Android應用程序啟動流程總結

AMS主要功能：
AMS是Android中最核心的服務，主要負責系統中四大組件的啟動、切換、調度及應用進程的管理和調度等工作。還負責啟動或殺死應用程序的進程。

WMS主要功能：
為所有窗口分配Surface。
管理Surface的顯示順序、尺寸、位置。
管理窗口動畫。
輸入系統相關：WMS是派發系統按鍵和觸摸消息的最佳人選，當接收到一個觸摸事件，它需要尋找一個最合適的窗口來處理消息。

PWS主要功能：
PMS 用來管理跟蹤所有應用APK，包括安裝，卸載，解析，控制許可權等。

SystemServer也是一個進程，包括AMS、PMS、WMS等等。

zygote意為「受精卵「。Android是基於Linux系統的，而在Linux中，所有的進程都是由init進程直接或者是間接fork出來的，zygote進程也不例外。

App進程是用戶點擊桌面icon時，通過Launcher進程請求SystemServer，再調用Zygote孵化的。

①點擊啟動一個App，Launcher進程採用Binder IPC向ActivityManagerService發起startActivity請求；

②ActivityManagerService接收到請求後，向zygote進程發送創建進程的請求；

③Zygote進程fork出新的子進程，即App進程；

④App進程通過Binder IPC向sytem_server進程發起綁定Application請求；

⑤system_server進程在收到請求後，進行一系列准備工作後，再通過binder IPC向App進程發送scheleLaunchActivity請求；

⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主線程發送LAUNCH_ACTIVITY消息；

⑦主線程在收到Message後，通過發射機制創建目標Activity，並回調Activity.onCreate()等方法。

⑧到此，App便正式啟動，開始進入Activity生命周期，執行完onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

備註：
Launcher，PMS，Zygote，App進程是三個獨立的進程，相互通信就需要使用進程間通信機制。與Zygote通信是使用的socket通信，Launcher，PMS，App進程間使用的是Binder機制。