http://wear.techbrood.com/guide/components/processes-and-threads.html
每一個 android 應用默認會起一個進程，除非你用 android:process 實現多進程。
每一個進程里面都有一個 dalvik 虛擬機實例用來執行代碼。
進程中默認只有一個主線程（UI線程）， 4 大組件默認都運行在 UI 線程中， 所以 4 大組件中都不能直接做耗時操作，否則會 ANR。
service 和 broadcastreceiver 中要做耗時操作都必須開啟單獨的線程來做。
但按 back 鍵退出應用后，進程什么時候被回收呢？？
android 會盡可能長時間的去保留一個應用進程不被回收，這樣下次可以快速啟動，只有當內存緊張時才會回收進程，而回收哪些進程則根據進程的優先級來判斷。
默認有 5 種進程優先級， 根據進程中組件的狀態來判斷：
1 Foreground process
簡單來說就是正在前台與用戶交互的進程，優先級最高。
2 Visible process
可見但沒有與用戶交互
3 Service process
不是 1 和 2 但含有用 startService 啟動的 service 的進程。
4 Background process
非 1 2 3 不可見的進程
5 Empty process
空進程，主要做緩存。
android 推送都是在 service 中進行 socket 通信，進程優先級默認是 3 ，所以內存緊張時也是有可能被 Kill 掉的，就收不到推送了。
service 可以通過 startForground() 來設置為前台進程，這樣優先級就變為 1 了，不容易被 kill 掉。而且通過 onStartCommand 的返回值
可以控制進程在被意外 kill 掉時是否需要重啟，這樣就達到了長時間運行，應用永遠在線， 用 tcp 長連接實現推送。
看有些人用 System.exit(0) 和 Process.killProcess 來 kill 掉進程，這 2 個方法確實都能 kill 掉進程，但有些情況下會導致應用重啟，例如
當 A 啟動 B 你在 B 中調用 System.exit(0) 或 Process.killProcess 時會 kill 掉當前進程然后重啟一個新的進程。
我之前說過 90% 的情況下你是不需要手動 kill 掉一個應用的進程的，這樣第二次啟動肯定非常慢。進程是由 OS 底層進行管理的，退出應用你只需要
finish 掉所有的 activity 就行了。如果有些需求確實需要 kill 掉進程,上面的 2 個方法也可以，前提是任務站內只有一個 activity 時再調用。反正我目前
還沒有遇到過需要每次退出應用都必須殺死進程的場景，不要跟我說是為了節省內存，上面說了 5 種進程等級，系統自己會管理，不需要人為干預。
而且你自己殺死進程后第二次啟動又需要創建新的進程，應用啟動就非常慢了。