android啟動機制

⑴ 為什麼在 android 上啟動知乎 app 時會喚醒微信

知乎調用微信sdk中分享的相關介面，微信sdk的相關介面裡面，給微信發送了一個廣播，微信app就被喚醒了，這不是頌盯知乎的主觀行為，而是微信的（而且結合實型櫻圓際的分析來看，這個應該也算是正常的功能）。
1首先說一下app的被喚醒（自啟動）機制。

app自啟動，基本上都是依靠Android的廣播來實現的，而且是靜態注冊的廣播（在AndroidManifest.xml文件中進行配置的廣播），發送廣播的方法在一般情況下是sendBroadcast。
2按照慣例，反編譯一下微信apk，然後搜索卜塌一下它能夠由哪些靜態廣播進行喚醒，同時抓取廣播相關的log。
結合微信的AndroidManifest.xml文件以及抓取的log，可以知道相關的BroadcastReceiver是EntryReceiver，相關的action為

com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER
com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_UNREGISTER

從其名稱上看，是和注冊/注銷相關,具體接收到廣播之後做了哪些處理，這些就不贅述了。
3接下來分析知乎的代碼,搜索一下知乎反編譯之後的smali文件(sendBroadcast),其中只有一條是和微信相關的

⑵ Android 系統運行機制 【Looper】【Choreographer】篇

目錄：
1 MessageQueue next()
2 Vsync
3 Choreographer doFrame
4 input

系統是一個無限循環的模型， Android也不例外，進程被創建後就陷入了無限循環的狀態

系統運行最重要的兩個概念：輸入，輸出。

Android 中輸入 輸出 的往復循環都是在 looper 中消息機制驅動下完成的

looper 的循環中， messageQueue next 取消息進行處理， 處理輸入事件， 進行輸出， 完成和用戶交互

應用生命周期內會不斷 產生 message 到 messageQueue 中， 有： java層 也有 native層

其中最核心的方法就是 messageQueue 的 next 方法， 其中會先處理 java 層消息， 當 java 層沒有消息時候， 會執行 nativePollOnce 來處理 native 的消息 以及監聽 fd 各種事件

從硬體來看， 屏幕不會一直刷新， 屏幕的刷新只需要符合人眼的視覺停留機制

24Hz ， 連續刷新每一幀， 人眼就會認為畫面是流暢的

所以我們只需要配合上這個頻率， 在需要更新 UI 的時候執行繪制操作

如何以這個頻率進行繪制每一幀： Android 的方案是 Vsync 信號驅動。

Vsync 信號的頻率就是 24Hz ， 也就是每隔 16.6667 ms 發送一次 Vsync 信號提示系統合成一幀。

監聽屏幕刷新來發送 Vsync 信號的能力，應用層 是做不到的， 系統是通過 jni 回調到 Choreographer 中的 Vsync 監聽， 將這個重要信號從 native 傳遞到 java 層。

總體來說 輸入事件獲取 Vsync信號獲取 都是先由 native 捕獲事件 然後 jni 到 java 層實現業務邏輯

執行的是 messageQueue 中的關鍵方法： next

next 主要的邏輯分為： java 部分 和 native 部分

java 上主要是取java層的 messageQueue msg 執行， 無 msg 就 idleHandler

java層 無 msg 會執行 native 的 pollOnce@Looper

native looper 中 fd 監聽封裝為 requestQueue， epoll_wait 將 fd 中的事件和對應 request 封裝為 response 處理， 處理的時候會調用 fd 對應的 callback 的 handleEvent

native 層 pollOnce 主要做的事情是：

vsync 信號，輸入事件， 都是通過這樣的機制完成的。

epoll_wait 機制 拿到的 event ， 都在 response pollOnce pollInner 處理了

這里的 dispatchVsync 從 native 回到 java 層

native：

java：

收到 Vsync 信號後， Choreographer 執行 doFrame

應用層重要的工作幾乎都在 doFrame 中

首先看下 doFrame 執行了什麼：

UI 線程的核心工作就在這幾個方法中：

上述執行 callback 的過程就對應了圖片中 依次處理 input animation traversal 這幾個關鍵過程

執行的周期是 16.6ms， 實際可能因為一些 delay 造成一些延遲、丟幀

input 事件的整體邏輯和 vsync 類似

native handleEvent ，在 NativeInputEventReceiver 中處理事件， 區分不同事件會通過 JNI

走到 java 層，WindowInputEventReceiver 然後進行分發消費

native :

java:

input事件的處理流程：

輸入event deliverInputEvent

deliver的 input 事件會來到 InputStage

InputStage 是一個責任鏈， 會分發消費這些 InputEvent

下面以滑動一下 recyclerView 為例子， 整體邏輯如下：

vsync 信號到來， 執行 doFrame，執行到 input 階段

touchEvent 消費， recyclerView layout 一些 ViewHolder

scroll 中 fill 結束，會執行 一個 recyclerView viewProperty 變化， 觸發了invalidate

invalidate 會走硬體加速， 一直到達 ViewRootImpl ， 從而將 Traversal 的 callback post choreographer執行到 traversal 階段就會執行

ViewRootImpl 執行 performTraversal ， 會根據目前是否需要重新layout ， 然後執行layout， draw 等流程

整個 input 到 traversal 結束，硬體繪制後， sync 任務到 GPU ， 然後合成一幀。

交給 SurfaceFlinger 來顯示。

SurfaceFlinger 是系統進程， 每一個應用進程是一個 client 端， 通過 IPC 機制，client 將圖像顯示工作交給 SurfaceFlinger

launch 一個 app：

⑶ Android的handler機制的原理

Android的handler機制的原理分為非同步通信准備，消息發送，消息循環，消息處理。

1、非同步通信准備

在主線程中創建處理器對象(Looper)、消息隊列對象(Message Queue)和Handler對象。

2、消息入隊

工作線程通過Handler發送消息(Message) 到消息隊列(Message Queue)中。

3、消息循環

消息出隊: Looper循環取出消息隊列(Message Queue) 中的的消息(Message)。

消息分發: Looper將取出的消息 (Message) 發送給創建該消息的處理者(Handler)。

4、消息處理

處理者(Handler) 接收處理器(Looper) 發送過來的消息(Message)，根據消息(Message) 進行U操作。

handler的作用

handler是android線程之間的消息機制，主要的作用是將一個任務切換到指定的線程中去執行，（准確的說是切換到構成handler的looper所在的線程中去出處理）android系統中的一個例子就是主線程中的所有操作都是通過主線程中的handler去處理的。

Handler的運行需要底層的 messagequeue和 looper做支撐。

⑷ 安卓運行機制是什麼 安卓手機的工作原理是什麼

android基於Linux內核，很多系統也都基於Linux內核。但是android的特別之處除了開發上的特點以外，還有一個就是程序在運行時的行為和以往我接觸到的程序運行機制有很大不同。在傳統PC機或者其他一些手機上，用戶對應用程序有絕對的掌控權，在應用程序的系統菜單上選擇「退出」或者「關閉」之類的選項會直接殺死進程，而在android系統中不是這樣的。在android中，應用程序的生命周期並不是由應用程序自身直接控制的，而是由系統，當系統需要釋放內存來運行新進程或者保證某些後台進程和前端進程順利執行的時候才會釋放相應應用程序的資源，這個釋放過程有一個重要性的層次。
android中進程的層次如下（重要性由高到低）：

1、前端進程。顧名思義，前端進程就是目前顯示在屏幕上和用戶交互的進程，在系統中前端進程數量很少，而這種進程是對用戶體驗的影響最大，只有系統的內存稀少到不足以維持和用戶的基本交互時才會銷毀前端進程。因此這種進程重要性是最高的。

2、可見進程。可見進程也擁有一個可視化的界面，只是目前不是最上層界面（最上層界面在前端進程裡面），可見進程一般調用了OnPause()，可見進程比前端進程重要性低，但是在交互方面影響還是很大，因為用戶可能隨時切換過去，所以系統不會輕易銷毀它。

3、服務進程。一個服務進程就是一個Service，它調用了startService，就是UNIX中說的守護進程，對用戶不可見，但是保證了一些重要的事件被監聽或者維持著某些狀態，比如網路數據傳輸、後台音樂播放，這類進程在內存不足且為了保證前端交互的順利進行的時候被銷毀。

4、後台進程。這里叫後台進程可能會和一般意義上的後台進程混淆，要說明的是，android里的後台進程是調用了OnStop()的，可以理解成用戶暫時沒有和這個進程交互的願望，所以這里後台進程有點「待銷毀」的意思。

5、空進程。這是一種系統緩存機制，其實就是個進程的外殼，當有新進程創建的時候，這個空進程可以加快進程創建速度，當系統內存不足的時候，首先銷毀空進程。
android中進程重要性層次

⑸ Android應用自啟動機制

一般應用自啟動是通過差襲開機廣播實現。 1.系統開機後，系統產生並發送開機廣播，同時設置開機廣播的Flag為FLAG_excluds_stopped_packages,即對虛檔兄於之前未啟動過的應用不發送開機廣播。 2.系統剛開機時，檢查應用之前是否啟動是通過讀取存儲中的配置文件(package-restriction.xml)中應用的stopped屬性來判斷的。 3.當上一次打開應用，10秒後，系統會將蠢橘應用的stopped屬性設置為false，寫入配置文件。 當上一次關閉應用，10秒後，系統會將應用的stopped屬性設置為true，寫入配置文件。 總結:在應用打開或關閉後，系統刷新應用狀態到配置文件中會有10秒的延時。

⑹ Android 性能優化 05---App啟動優化

其實啟動框架就是一個任務調度系統，是手淘啟動的「大管家」。
管家要做的事情就是把它們的關系梳理得明明白白，有條不紊，合理安排位置、調度時間，襲嘩同時提升硬體資源的利用率。

總結下來無非就是兩點：

有向無環圖[拓撲排序]

可用方案
APT，位元組碼插樁，利用ContentProvider
面試題LeakCanary 為什麼不需要在Application中手動初始化？

①點擊桌面App圖標，Launcher進程採用Binder IPC向system_server進程發起 startActivity請求；
②system_server進程接收到請求後，向zygote進程發送創建進程的請求；
③Zygote進程fork出新的子進程，即App進程；
④App進程，通過Binder IPC向sytem_server進程發起attachApplication請求；
⑤system_server進程在收到請求後，進皮禪頃行一系列准備工作後，再通過binder IPC 向App進程發送scheleLaunchActivity請求；
⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主 線程發送LAUNCH_ACTIVITY消息；
⑦主線程在收到Message後，通過反射機制創建目標Activity，並回調 Activity.onCreate()等方法。
⑧到此，App便正式啟動，開始進入Activity生命周期，執行完 onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

應用有三種啟動狀態，每種狀態都會影響應用向用戶顯示所需的時間：冷啟動、溫啟動與熱啟動。

adb命令啟動應用，一般會輸入三個值：ThisTime、TotalTime與WaitTime。
1.WaitTime：包括前一個應用Activitypause的時間和新應用啟動的時間；
2.ThisTime：表示一連串啟動Activity的最後一個Activity的啟動耗時；
3.TotalTime：表示新應用啟動的耗時，包括新進程的啟動和Activity的啟動，但不包括前一個應用Activitypause
的耗時。

StrictMode是一個開發人員工具，它可以檢測出我們可能無意中做的事情，並將它們提請我們注意，以便我 們能夠修復它們。 StrictMode最常用於捕獲應用程序主線程上的意外磁碟或網路訪問。幫助我們讓磁碟和網路操作遠離主線程， 可以使應用程序更加平滑、響應更快

當系統載入並啟動 App 時，需要耗費相應的時間，這樣會造成用戶會感覺到當點擊 App 圖標時會有 「延遲」 現象，
為了解決這一問題，Google 的做法是燃陸在 App 創建的過程中，先展示一個空白頁面，讓用戶體會到點擊圖標之後立
馬就有響應。
如果你的application或activity啟動的過程太慢，導致系統的BackgroundWindow沒有及時被替換，就會出現啟動
時白屏或黑屏的情況（取決於Theme主題是Dark還是Light）。

消除啟動時的黑/白屏問題，大部分App都採用自己在Theme中設置背景圖的方式來解決。

然後在Activity的onCreate方法，把Activity設置回原來的主題。

這么做，只是提高啟動的用戶體驗。並不能做到真正的加快啟動速度。

⑺ 人人都應該了解的 Android 進程管理機制

打開設置--應用與服務（不同機型進入方式可能不同），你就會看到當前正在運行的進程和服務，也就是目前正在「後台運行」的任務。列表中有你剛剛使用過的 APP ，也有一兩小時前打開過的 APP。還有一些軟體你甚至不知道自己什麼時候打開過（其實根本就不是自己打開的），或者記得自己已經「關閉」了，但它們也在列表中，消耗著你的手機資源。列表中有一些條目名字很奇怪，一般人看不懂，但還是覺得「它很重要」，不敢輕易強悔培制關閉。這個列表展示的內容和普通的後台管理界面不太一樣，感覺稍稍有些神秘，然而這又是我們日常使用所迴避不了的一部分。

作為一名資深的手機用戶（我相信人人都是），是時候該解決這類疑問了。這一切都要從人與宇宙的關系。。。咳咳。。手機進程的概念開始說起。

在開發文檔中是這么說的：當一個應用程序啟動時（僅僅只是「啟動時」，並不一定有組件運行），就會產生一個進程。在這個進程中同時會創建一個主線程，使應用內的任務開始執行。Android系統總是盡可能地保留進程。舉個例子，當你打開qq時，進程創建（同時創建主線程），隨後各種內容載入（首先是活動，然後是各種控制項什麼的）。當你完成操作時，一般都會按後退鍵（back），直至退出程序。

這里需要注意，一般情況下我們一直按後退是希望應用程序關閉的。然而事實上這樣做只是關閉了界面（活動），大多數app的「進程」仍會保留（少數良心app可以設置在退出時「完全關閉」），佔用內存以進行後台任務。進程隨應用啟動而產生，但往往並不隨著應用的「關閉」而關閉

所以很多時候我們看上去關閉了程序，但其實它仍在後台運行！（此處請自行回憶那些困擾你的流氓軟體們）。不過不必擔心，Android 系統自有一套進程管理機制來幫你管理後台任務。系統會根據應用的重要程度把所有進程劃歸為幾個等級，最不重要的進程將會被優先關閉，相對重要的進程將獲得資源來保留。

那麼問題來了----到底如何分辨哪些進程重要而哪些不重要呢？

系統當然要保證用戶體驗，所以重要等級的劃分原則就是要首先滿足用戶當前的需求：用戶正在使用的當然不能關閉，而用戶暫時不需要的，相對的就沒那麼重要了。

1.Foreground process 前台進程：也就是用戶正在進行操作的進程。這樣的進程優先順序（優先保留）最高，最不容易銷毀，因為它表現在屏幕上，直接同用戶進行交互，所以只有當內存資源極度緊張等一些其他極端情猛迅況才會關閉，表現為「閃退」。我用的第一台 Android 手機運行內存（RAM）只有 290M，多任務時經常內存不足導致程序「閃退」。這手機我竟然用了兩年，現在想想都佩服我自己hhhh。

不只是界面交互，如果應用程序中的服務（service）組件正在進行一些操作或者廣播接收者（BroadcastReceiver）在執行接收廣播的操作（onReceive）時，該進程仍被視為前台進程。

2.Visible process 可視進程：顧名思義，就是仍然在屏幕上有顯示，但用戶不再能直接與它交互的程序。比如當在應用中打開下滑菜單時（有些下滑菜單是透明的），用戶能「看得到」，但是「摸不著」。優先順序僅次於前台進程。

3.Service process 服務進程：該進程中開啟了一個服務（通過startService方法）。注意這里強調的是服務的「開啟」，區別於第一類中的「服務正在執行一些操作」。大多數音樂軟體都是通過這種方法來保留其播放音樂的進程。

4.Background process 後台進程：當你按下 HOME 鍵或 BACK 鍵時，手機退回主界面，此時應用程序不再可見，轉入後台運行。如果如果不滿足前幾類的條件，這個進程就會被判定為後台進程。

5.Empty process 空進程：A process that doesn't hold any active application components.沒有任何組件在運行，包括活動界面（Activity）。事實上用戶已經不再需要這個進程了，但出於 Android 系統「盡可能保留進程」的原則，這樣的進程出現後不會被立即銷毀。保留進程的唯一理由，就是為了下次開啟這個應用時能快一些。其實現在的手機硬體性能足夠好，這樣的緩存對於用戶體驗的提升效果不怎麼明顯。這樣的進程最不重要，將首先被銷毀。枝前此

也許你已經注意到了，在屏幕上正在顯示的或者正在服務於用戶的進程的重要等級是比較高的，這是出於對用戶體驗的考慮-----誰會接受在自己打王者榮耀的時候游戲突然閃退呢？大多數情況下，一個應用程序的組件成分都會比較復雜，這個進程可能同時滿足多個級別的劃分條件。在這種情況下，它會被盡可能地劃為能夠達到的最重要等級。

如果你的手機上安裝了好幾個同一家公司推出的 APP（比如企鵝系、頭條系等），那麼當你啟動其中之一時，剩下的幾款 APP 大概率也會被喚醒（視軟體的流氓程度而定）。聯動開啟的 APP 會大大佔用內存，讓手機變得卡頓。並且它們許多都需要聯網服務，佔用網速，有些還會在你不知情（因為你並沒有直接開啟或使用它們）的情況下監控你的數據並上傳。

不過，你以為這就完了？

事實上，如果不手動清除，這樣的進程很難被系統關閉，它們會一直長期運行。這些進程大多屬於第三或第四等級，然而如果不同 APP 中的組件構成「相互依賴」的關系，它們所屬進程的保留優先順序就會提高，也就越不容易被關閉。（我等流氓軟體可不是浪得虛名的ε=ε=ε=( _￣▽￣) ）

盡管 Android 想要盡可能的保存所有的進程，但是並非所有的內存都會被用於維持進程。比如系統運行會佔用相當的內存，系統也需要留出一部分閑置內存用以處理新事件。Android 的管理讓內存的分配處於一種「動態平衡」中，以保障各項任務都能盡可能的穩定、高效地執行。

好了，關於進程的管理就暫時說到這了。眾所周知，Android 系統是一個復雜的機體，它管理著手機硬體和軟體，讓它們盡可能的配合，提供給用戶最好的服務。這次只是簡單介紹了進程管理機制，今後我也會盡量用通俗的語言從系統上去解釋那些平常看上去似是而非的問題，期待你的關注！

⑻ android進程管理機制

Android系統與其他操作系統有個很不一樣的地方，就是其他操作系統盡可能移除不再活動的進程，從而盡可能保證多的內存空間，而Android系統卻是反其道而行之，盡可能保留進程。Android這樣設計有什麼優勢呢？又是通過怎樣的方法來管理這些被保留的進程的呢？Android用戶又該如何正確使用手機從而更好發揮Android系統所特有的優勢呢？本文將一一為您解開這些謎團。

      本文的主要內容如下：

一、Android進程管理的特殊設計

       Linux系統對進程的管理方式是一旦進程活動停止，系統就會結束該進程。盡管Android基於Linux Kernel，但在進程管理上，卻採取了另外一種獨特的設計：當進程活動停止時，系統並不會立刻結束它，而是會盡可能地將該進程保存在內存中，在以後的某個時間，一旦需要該進程，系統就會立即打開它，而不用再做一些初始化操作。只有當剩餘內存不夠用了，為了維持新開啟的進程或者比較重要的進程的正常運行，系統才會選擇性地殺掉一些不重要的內存，騰出內存空間來，所以Android系統永遠不會有內存不足的提示。

二、Android獨特進程管理設計的好處

      Android這種獨特的設計，也正是Android標榜的優勢之一，這有兩個好處：

  1、最大限度地提高內存的使用率。

       比如，你的內存是8G，如果每次使用完某個進程就殺掉，那麼被使用的內存基本上會始終保持在某個值，比如4G以內，那麼內存的使用率就總是保存在50%以內，剩餘的4G內存形同虛設，發揮用處的機會非常少。而Android的這種設計，就可以做到有多少內存就用多少內存，盡可能大地提高內存使用率。同樣比如有8G內存，使用完的進程仍保留在內存中，累積下來，被使用的內存就盡可能地會接近8G。

  2、提高再次啟動時的啟動速度

       被駐留在內存中不再活動的進程（後台進程或空進程，後面會再講到），很多是經常需要使用的，當再次使用該進程的時候，系統立即打開它，而不需要再重新初始化。例如，我們常用的瀏覽器，當暫時不再使用時，按下Home鍵或Back鍵，瀏覽器進程就變成了不再活動的進程。如果下次又要使用了，點擊多任務鍵，在最近使用應用列表中點擊瀏覽器即可，瀏覽器界面仍然保持著退出前的界面。但如果退出時把該進程移除了，那麼再次使用時，就需要重新初始化，然後進入該應用，這往往會花費不少的時間。

三、Android進程的五個等級

        Android系統將盡量長時間地保持應用進程，但為了新建進程或運行更重要的進程，最終需要移除舊進程來回收內存。為了確定保留或終止哪些進程，系統會根據進程中正在運行的組件以及這些組件的狀態，將每個進程放入「重要性層次結構」中。必要時，系統會首先消除重要性最低的進程，然後是重要性略遜的進程，以此類推，以回收系統資源。該「重要性層級結構」將進程分為了五個等級：

  1、前台進程（foreground）

       前台進程是指那些有組件正和用戶進行交互的應用程序的進程，也稱為Active進程。這些都是Android嘗試通過回收其他應用程序來使其保持相應的進程。這些進程的數量非常少，只有等到最後關頭才會終止這些進程，是用戶最不希望終止的進程。例如：而當你運行瀏覽器這類應用時，它們的界面就會顯示在前台，它們就屬於前台進程，當你按home鍵回到主界面，他們就變成了後台程序。

       如果一個進程滿足以下任一條件，即視為前台進程：

     （1）託管處於活動狀態的Activity，也就是說，它們位於前台並對用戶事件進行響應，此時的情形為響應了Activity中的onResume()生命周期方法，但沒有響應onPause()。

     （2）託管正在執行onReceive()方法處理事件程序的BroadcastReceiver。

     （3）託管正在執行onStart()、onCreate()或onDestroy()事件處理程序的Service。

     （4）託管正在運行且被標記為在前台運行的Service，即調用了該Service的startForeground()方法。

     （5）託管某個Service，且該Service正綁定在用戶正在交互的Activity的Service，即該Activity正處於活動狀態。

  2、可見進程（visible）

        沒有任何前台組件、但仍然會影響用戶在屏幕上所見內容的進程。如果一個進程滿足以下任一條件，即視為可見進程：

    （1）託管不在前台、但仍對用戶可見的Activity（已調用其onPause（）方法）。例如：如果前台Acitivty啟動了一個對話框，或者啟動了一個非全屏，亦或是一個透明的Activity，允許在其後顯示上一個Activity，則可能會發生這種情況，這類Activity不在前台運行，也不能對用戶事件作出反應。

    （2）託管綁定到可見Activity的Service。（官網上說是綁定到可見或前台Activity，但筆者有一點疑問，這個和「前台進程」中第（5）點相矛盾嗎，綁定到前台Activity，那就是前台進程了）

        可見進程被視為是極其重要的進程，這類進程的數量也很少，只有在資源極度匱乏的環境下，為保證前台進程繼續執行時才會終止。

  3、服務進程（Service）

        正在運行已使用startService（）方法啟動的Serice且不屬於上述兩個更高類別進程的進程。盡管服務進程與用戶所見內容沒有直接關聯，但是它們通常在執行一些用戶關心的操作。因此，除非內存不足以維持所有前台進程和可見進程同時運行，否則系統會讓服務進程保持運行狀態。

       有些資料上面也稱這種進程為次要服務（Secondary Service），而屬於上述兩個更高類別的進程則被稱為主要服務，主要服務往往屬於系統進程，如撥號進程等，不可能被進程管理輕易終止。這里我們以Android開發者官網的稱呼為標准，稱為服務進程。

  4、後台進程（hidden）

       包含目前對用戶不可見的Activity，即該Activity調用了onStop()方法。這些進程對用戶體驗沒有直接影響，系統可能隨時終止它們，以回收內存供上述三個更高級別的進程使用。通常會有很多後台進程在運行，它們會保存在LRU（Least Recently Used，最近最少使用）列表中，以確保包含用戶最近查看的Activity的進程最後一個被終止。如果某個Activity正確實現了生命周期方法，並保存了其當前狀態，則終止其進程不會對用戶體驗產生明顯影響，因為當用戶導航回該Activity時，Activity會恢復其所有可見狀態。

       這里讀者可以做個試驗，先開啟微信，進入到朋友圈界面， 然後點擊手機屏幕下方的導航欄中的Home按鍵進入到後台，再點擊最近使用應用列表顯示按鈕（不同的手機位置不一樣，有的在Home鍵左邊，有的則在Home鍵右邊），在顯示的最近使用應用的列表中清理掉微信應用，最後再點擊桌面的微信圖標啟動微信，會發現顯示的界面仍然是朋友圈界面。

       後台進程，我們可以簡單理解為，應用（只考慮只有Activity組件的情況）啟動後按Home鍵後被切換到後台的進程。如瀏覽器、閱讀器等，當程序顯示在屏幕上時，它們所運行的進程即為前台進程（foreground），一旦按home鍵（注意不是back鍵）返回到桌面，程序就停留在後台，成為後台進程。

  5、空進程（empty）

       不含任何活動應用組件的進程。保留這種進程的唯一目的是用作緩存，以縮短下次再其中運行組件所需要的啟動時間。一般來說，當應用按back按鍵退出後應用後，就變成了一個空進程。比如BTE，在程序退出後，依然會在進程中駐留一個空進程，這個進程里沒有任何數據在運行，作用往往是提高該程序下次的啟動速度或者記錄程序的一些歷史信息。當系統內存不夠用時，無疑，該進程是應該最先終止的。在最近使用應用列表中，可以看到按back鍵退出的應用。

       根據進程中當前活動組件的重要程度，Android會將進程評定為它可能達到的最高級別。通俗地說，就是如果一個進程同時擁有多個對應上述不同等級進程的組件時，會以最高的那個等級作為該進程的等級。例如，如果某進程託管著服務和可見Activity，則會將此進程評定為可見進程，而不是服務進程。

       此外，一個進程的級別可能會因為其他進程對它的依賴而有所提高，即服務於另一進程的進程其級別永遠不會低於其所服務的進程。例如，如果進程A中的內容提供程序為進程B中的客戶端提供服務，或者如果進程A中的服務綁定到進程B中的組件，則進程A始終被視為至少與進程B同樣重要。

       由於運行服務的進程其級別高於託管後台Activity的進程，因此啟動長時間運行操作的Activity最好為該操作啟動Service，而不是簡單地創建工作線程，當操作有可能比Activity更加持久時更應該如此。例如，正在將圖片上傳到網站的Activity應該啟動服務來執行上傳，這樣一來，即使用戶退出Activity，仍可在後台繼續執行上傳操作。使用服務可以保證，無論Activity發生什麼情況，該操作至少具備「服務進程」優先順序。如果某個Activity開啟了線程執行耗時操作，當Activity退出時，該Activity的實例將不會釋放內存資源，直到線程執行完，這樣容易導致內存泄漏。同理，廣播接收器也應該使用服務，而不是簡單地將耗時冗長的操作放入線程中。

四、進程移除順序的依據——閾（yu，第四聲）值

        前面講到，內存不夠用時，會根據進程的等級來決定優先回收哪類進程。那麼系統是根據什麼來判斷需要移除這些進程的時機的呢？答案是閾值。

  1、查看閾值

        我們可以採用如下方法查看手機中各個等級進程的閾值（需要root許可權），如第二排數據所示（其單位為頁）：

       以第一個數據44032為例，計算方法為：

       1page=4KB=4*1024B=4096B

       44032page* 4048B/page =  180355072B

       180355072B/1024/1024 = 172M

       即第一個等級的進程的閾值為172M。依次類推，閾值依次為：172M，190M，208M，226M，316M，415M。

       有必要說明一下，在Android開發者官方文檔中，是將Android應用進程分為了5個等級，但很多資料卻是分的6個等級，在後台進程和空進程之間還有一個「內容提供節點（content provider）進程」。內容提供節點，沒有實體程序，僅提供內容供別的程序去用 ，比如日歷供應節點，郵件供應節點等，在終止進程時，這類進程有比較高的優先權。手機中應該是採用的6個等級的方式，如上六個數據，正好對應著六個等級的進程，等級越高，閾值越低，即前台進程閾值為172M，空進程為415M。當系統的剩餘內存只剩餘不到415M的時候，系統首先會回收空進程，依次類推，只有剩餘內存不到172M了，才會去回收前台進程，這樣就起到了優化保護重要進程的作用。

五、Home鍵、Back鍵和多任務鍵

       Home鍵、Back鍵和多任務鍵，在手機屏幕的下方，這三個按鍵一般稱為導航欄，中間的按鈕為Home鍵，多任務鍵和Back鍵分別在其左右，一般根據手機品牌不同，左右位置也有所差異。

       在運行App的時候，如果按一下Home鍵或者Back鍵，都可以退到桌面，那麼這兩者有什麼區別呢？

Home鍵。按Home鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個後台進程；如果有前台service運行，就仍然是前台進程，比如QQ音樂播放器等；如果是只有普通service運行，那麼就轉變為服務進程（參照前文中講的Android進程的5個級別）。

Back鍵。按Back鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個空進程；對於有Service運行的情況，和按Home鍵一樣。

        後台進程和空進程，都是駐留在後台，處於暫停狀態，也都是除了佔用一部分內存外，不佔用其他如cpu等資源的，那麼問題來了，為什麼要設計後台進程和空進程這兩種空進程呢？它們的區別到底在哪裡呢？我們在前文講Android進程的5個等級的時候講到過，當剩餘內存不足的時候，系統會按照等級順序，優先移除不太重要進程，以收回內存供更重要的進程運行。那麼，它們的區別就是，在剩餘內存不足時，會優先移除空進程，再不足，才會移除空進程。所以，如果確實要退出某個應用一段時間內不大使用了，如果這款應用有退出按鈕，就用應用自帶的退出功能；如果沒有，則最好按系統的Back鍵，這樣可以變成空進程，當系統要回收內存時，就會優先被回收，從而釋放的所佔的資源。如果只是暫時退出去做點別的，過一會還要切換回來，或者對這款應用使用比較頻繁，那就使用Home鍵，因為相比於按Back鍵，這樣可以盡可能保住後台進程，方便下次使用的時候快速啟動。

       當然，按Home鍵或Back鍵，對用戶來說，其實感覺不到差異，使用起來沒什麼兩樣，但是，對於Android開發者來說，卻有必要作為常識來了解其中的道理和差異。無論是按Home鍵還是按Back鍵，在按多任務鍵的時候，都可以看到這些進程，如下圖所示。最下面的按鍵為清理按鍵，點擊後可以清除掉這些進程，回收內存了，當然，前面也講了很多遍了，不建議這樣做。

  2、修改閾值。

       可以採用命令：echo "44032,48640,53248,57856,80896,106241" > /sys/mole/lowmemorykiller/parameters/minfree來修改閾值，如下所示：

       重啟後，會恢復為原來的值。至於如何永久性修改該閾值，這里不深入探討，有興趣的童鞋可以自行研究，一般來說，就按照系統給定的默認值使用就可以了，沒特殊用途的話，沒必要修改。

       對於這一節閾值的內容，暫時先講到這里，如果要更深入，可以自行多研究研究。筆者也沒有看到比較好的更深入的文章，所以也不好推薦，如果讀者看到比較好的，可以推薦給筆者，感激不盡。

六、開發者選項中的進程管理功能

        Android手機都帶有開發者選項，隱藏了很多功能，顧名思義，這些功能主要用於輔助開發者調試程序用的。其中有一些就是關於進程管理功能的，筆者這里簡單介紹一下其中兩款，如下圖紅框部分所示：

不保留活動。用戶離開以後即銷毀每個活動（Activity），這樣做使得後台進程都被銷毀了。筆者試驗過幾款app，比如微信，瀏覽器，開啟/關閉「不保留活動」前後，按Home鍵後，再打開應用，有明顯的差別。當然，也試用了簡訊，DD打車，就沒看出起了什麼作用。讀者若是感興趣可以深入研究研究，到時候在指導指導筆者！

後台進程限制。如下圖所示，給出了後台進程個數限制的選項。

七、進程管理軟體的使用

       Windows操作系統用戶往往總想著保留更多的內存，在使用Android手機的時候，喜歡經常清理後台進程或空進程，而且清理完後，心裡有一種特別爽的感覺，就像給家裡做了一次大掃除一樣，筆者最初使用Android手機的時候也是這樣的心態-_-！基於這樣的心態，一些進程清理軟體，很受普通用戶的青睞。其實這樣做卻正好抹殺了Android系統所標榜的優勢，如前文所講到的。

       那麼進程管理軟體有無必要呢？當然有的，只是需要注意使用場合。當需要運行大型程序的時候，可以手動關閉掉一些進程，騰出足夠的空間供大型程序使用，這樣就可以有效避免系統調用進程調度策略而引起的卡頓，這一點，第八大點第3小節中會有說明。而且由於開發者的原因，可能是程序寫得太爛，或程序容易出錯，或做不該做的動作，或是惡意程序，對於這類程序進程，手動移除也是有好處的。

       但如果是運行一些小程序，就完全沒有必要去預先殺進程了，完全可以交給系統自己管理。讀者可能會疑惑，因為小程序啟動的時候，也有可能會因為內存不足而導致需要移除部分進程的情況。筆者認為，即便是內存不足，小程序運行引起的調用進程調度策略測的次數非常少，要移除的進程也非常少，產生的影響不大。同時，我們也要意識到另外一點就是，無論是手動殺死進程還是自動殺進程，都需要cpu去執行這些任務，所以也會拖慢手機和消耗電量。所以從這一點看，頻繁殺進程，也是一個不好的習慣。

八、答疑解惑

        在以前沒有專門去了解Android進程管理機制的時候，甚至是在研究的過程中，筆者心裡都經常存在很多疑惑，以下整理了其中5個，不知道讀者您是否有也類似的困惑呢？

  1、這么多駐留在內存的進程，不會耗電嗎？

       大多數用慣了Windows操作系統的童鞋，看到Android系統盡可能保留不在活動的進程的設計，可能第一反應就是質疑，難道這樣不會增加耗電量嗎？其實，但一個程序按home鍵變成後台進程或者按back鍵退出變成空進程後，其實已經被暫停了，只保留了運行狀態，不會消耗cpu，一個程序會耗電，是因為它需要調用cpu來運算，現在不消耗cpu了，當然就不會耗電了。當然，開了service的應用就另當別論了，比如QQ音樂播放器，當按home鍵或back鍵後，音樂仍然播放，是因為它開啟了服務，而且是一個前台服務，在後面我們會繼續講到，此時它是一個前台進程，而不是後台進程或空進程。

  2、為什麼一個不太app，運行時會佔用很大的內存呢？

我們經常會碰到這樣一種現象，一個只有20M的App，運行起來的時候，卻會耗掉100M以上的內存。一方面是，程序運行時為對象分配內存，另一方面，是Android虛擬機的原因。Android中的應用啟動的時候，系統都會給它開啟一個獨立的虛擬機，這樣做的好處是可以避免虛擬機崩潰導致整個系統崩潰，代價就是耗用更多的內存。

  3、為什麼內存少的時候，運行大型程序會卡頓呢？

        當剩餘內存不多時，打開大型程序，系統會觸發自身的進程調度策略，去移除一些等級比較低的進程來回收內存，以供大型程序運行。而這個進程調度策略在決定哪些進程需要被移除的過程，是一個十分消耗資源的操作，特別是一個程序頻繁像系統申內存的時候，這樣就導致了系統的卡頓。

 4、應用開得太多了，手機變慢，是因為內存被佔用太多嗎？

        其實手機變慢的根本原因是cpu被耗用太多，而不是內存佔用太多，因為真正執行程序所要完成的任務的最終執行者是CPU，而不是內存（RAM）。在內存足夠的情況下，如果系統中佔用cpu的進程太多，那無疑cpu總有忙不過來的時候，那肯定就會變慢了。這就好比，在一條道路上駕車，道路就像內存，車的引擎就像cpu，如果車的引擎的動力不夠，或者承載的貨物太多，車都跑不快，即便是道路上一路暢通無阻，也無濟於事。所以，內存佔用多少並不重要，只要道路提供給車輛前行的空間是足夠的，手機變慢的責任，就和內存無關了。這個比喻用來解釋第三點也很恰當，道路提供的車輛前進的空間無法滿足車輛所必需的空間時，就需要交通機制花時間來調節交通，給這輛車提供足夠的空間，而在此期間，這輛車只能乖乖候著。

  5、Android手機越用越慢，是什麼原因呢？

Android手機常常是越用越慢，即使是恢復出廠設置，也無法改變這個現象。手機越用越慢，主要由如下幾個原因：（1）虛擬機機制問題。這一點在上一個問題中也提到了，在Android4.4以前的系統，使用的是Dalvik虛擬機，它的設計機制有缺陷，就是越用越慢；在Android4.4系統中有切換按鈕，可以在Art虛擬機和Dalvik虛擬機之間切換；在Android4.4以後的系統就徹底拋棄了Dalvik而全面使用Art。（2）開啟了太多的服務，導致耗用太多的CPU。隨著手機開機使用時間的增長，應用使用越來越多，很多應用看似退出了，而其實後台可能開了不少的服務，而他們可能還沒有關閉。這些服務正在執行一些操作，會消耗CPU，而CPU才是手機變慢的根本原因。 而且Android app比較開放的，有很多不良應用充斥其中，可能對服務處理不當，濫用服務等，增加系統中的服務。（3）系統頻繁調用自身的進程調度演算法。這一點在前面已經說明了，這里不再贅述。（4）手機硬體的自然老化

⑼ android管理開機自啟動的代碼

Android開機自啟動是通過BroadcastReceiver 注冊開機廣播來實現的
Android接收開機廣播,需要用到播廣播接收者BroadcastReceiver組件。
具體代碼:
1.在配置文件AndroidManifest.xml中向系統注冊receiver
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>

2.需要添加相應許可權
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

3.在Receiver中就可以添加開機需要進行的操作
public class BootCompletedReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
// 開機後執行的代碼
}
}

⑽ Android的Activity代碼是怎麼一個運行機制。

在Android中每個界面都是一個Activity，切換界面操作其實是多個不同Activity之間的實例化操作。在Android中Activity的啟動模式決定了Activity的啟動運行方式。
Android總Activity的啟動模式分為四種：

Activity啟動模式設置：

<activity android:name=".MainActivity" android:launchMode="standard" />

Activity的四種啟動模式：

1. standard

模式啟動模式，每次激活Activity時都會創建Activity，並放入任務棧中。

2. singleTop

如果在任務的棧頂正好存在該Activity的實例， 就重用該實例，否者就會創建新的實例並放入棧頂(即使棧中已經存在該Activity實例，只要不在棧頂，都會創建實例)。

3. singleTask

如果在棧中已經有該Activity的實例，就重用該實例(會調用實例的onNewIntent())。重用時，會讓該實例回到棧頂，因此在它上面的實例將會被移除棧。如果棧中不存在該實例，將會創建新的實例放入棧中。

4. singleInstance

在一個新棧中創建該Activity實例，並讓多個應用共享改棧中的該Activity實例。一旦改模式的Activity的實例存在於某個棧中，任何應用再激活改Activity時都會重用該棧中的實例，其效果相當於多個應用程序共享一個應用，不管誰激活該Activity都會進入同一個應用中。

其中standard是系統默認的啟動模式。

下面通過實例來演示standard的運行機制：

1 private TextView text_show;
2 private Button btn_mode;
3
4 @Override
5 public void onCreate(Bundle savedInstanceState) {
6 super.onCreate(savedInstanceState);
7 setContentView(R.layout.activity_main);
8
9 text_show = (TextView) this.findViewById(R.id.text_show);
10
11 text_show.setText(this.toString());
12
13 btn_mode = (Button) this.findViewById(R.id.btn_mode);
14
15 }
16
//按鈕單擊事件
17 public void LaunchStandard(View v){
18 startActivity(new Intent(this,MainActivity.class));
19
20 text_show.setText(this.toString());
21 }