❶ 為什麼說android主線程是線程不安全的，既然不安全為什麼要在主線程中更新UI，有點暈 求大師解答
UI線程及Android的單線程模型原則當應用啟動，系統會創建一個主線程（main thread）。這個主線程負責向UI組件分發事件（包括繪制事件），也是在這個主線程里，應用和Android的UI組件（components from the Android UI toolkit (components from the android.widget and android.view packages)）發生交互。
當App做一些比較重（intensive）的工作的時候，除非合理地實現，否則單線程模型的performance會很poor。特別的是，如果所有的工作都在UI線程，做一些比較耗時的工作比如訪問網路或者資料庫查詢，都會阻塞UI線程，導致事件停止分發（包括繪制事件）。對於用戶來說，應用看起來像是卡住了，更壞的情況是，如果UI線程blocked的時間太長（大約超過5秒），用戶就會看到ANR（application not responding）的對話框。
另外，Andoid UI toolkit並不是線程安全的，所以不能從非UI線程來操縱UI組件。必須把所有的UI操作放在UI線程里，所以Android的單線程模型有兩條原則：
1.不要阻塞UI線程。
2.不要在UI線程之外訪問Android UI toolkit（主要是這兩個包中的組件：android.widget and android.view）。
❷ Android線程池ThreadPoolExecutor詳解
傳統的多線程是通過繼承Thread類及實現Runnable介面來實現的，每次創建及銷毀線程都會消耗資源、響應速度慢，且線程缺乏統一管理，容易出現阻塞的情況，針對以上缺點，線程池就出現了。
線程池是一個創建使用線程並能保存使用過的線程以達到復用的對象，簡單的說就是一塊緩存了一定數量線程的區域。
1.復用線程：線程執行完不會立刻退出，繼續執行其他線程；
2.管理線程：統一分配、管理、控制最大並發數；
1.降低因頻繁創建&銷毀線程帶來的性能開銷，復用緩存在線程池中的線程；
2.提高線程執行效率&響應速度，復用線程：響應速度；管理線程：優化線程執行順序，避免大量線程搶占資源導致阻塞現象；
3.提高對線程的管理度；
線程池的使用也比較簡單，流程如下：
接下來通過源碼來介紹一下ThreadPoolExecutor內部實現及工作原理。
線程池的最終實現類是ThreadPoolExecutor，通過實現可以一步一步的看到，父介面為Executor:
其他的繼承及實現關系就不一一列舉了，直接通過以下圖來看一下：
從構造方法開始看：
通過以上可以看到，在創建ThreadPoolExecutor時，對傳入的參數是有要求的：corePoolSize不能小於0；maximumPoolSize需要大於0，且需要大於等於corePoolSize；keepAliveTime大於0；workQueue、threadFactory都不能為null。
在創建完後就需要執行Runnable了，看以下execute()方法：
在execute()內部主要執行的邏輯如下：
分析點1：如果當前線程數未超過核心線程數，則將runnable作為參數執行addWorker()，true表示核心線程，false表示非核心線程；
分析點2：核心線程滿了，如果線程池處於運行狀態則往workQueue隊列中添加任務，接下來判斷是否需要拒絕或者執行addWorker()；
分析點3：以上都不滿足時 [corePoolSize=0且沒有運行的線程，或workQueue已經滿了] ，執行addWorker()添加runnable，失敗則執行拒絕策略；
總結一下：線程池對線程創建的管理，流程圖如下：
在執行addWorker時，主要做了以下兩件事：
分析點1：將runnable作為參數創建Worker對象w，然後獲取w內部的變數thread；
分析點2：調用start()來啟動thread；
在addWorker()內部會將runnable作為參數傳給Worker，然後從Worker內部讀取變數thread，看一下Worker類的實現：
Worker實現了Runnable介面，在Worker內部，進行了賦值及創建操作，先將execute()時傳入的runnable賦值給內部變數firstTask，然後通過ThreadFactory.newThread(this)創建Thread，上面講到在addWorker內部執行t.start()後，會執行到Worker內部的run()方法，接著會執行runWorker(this)，一起看一下：
前面可以看到，runWorker是執行在子線程內部，主要執行了三件事：
分析1：獲取當前線程，當執行shutdown()時需要將線程interrupt()，接下來從Worker內部取到firstTask，即execute傳入的runnable，接下來會執行；
分析2：while循環，task不空直接執行；否則執行getTask()去獲取，不為空直接執行；
分析3：對有效的task執行run()，由於是在子線程中執行，因此直接run()即可，不需要start()；
前面看到，在while內部有執行getTask()，一起看一下：
getTask()是從workQueue內部獲取接下來需要執行的runnable，內部主要做了兩件事：
分析1：先獲取到當前正在執行工作的線程數量wc，通過判斷allowCoreThreadTimeOut[在創建ThreadPoolExecutor時可以進行設置]及wc > corePoolSize來確定timed值；
分析2：通過timed值來決定執行poll()或者take()，如果WorkQueue中有未執行的線程時，兩者作用是相同的，立刻返回線程；如果WorkQueue中沒有線程時，poll()有超時返回，take()會一直阻塞；如果allowCoreThreadTimeOut為true，則核心線程在超時時間沒有使用的話，是需要退出的；wc > corePoolSize時，非核心線程在超時時間沒有使用的話，是需要退出的；
allowCoreThreadTimeOut是可以通過以下方式進行設置的：
如果沒有進行設置，那麼corePoolSize數量的核心線程會一直存在。
總結一下：ThreadPoolExecutor內部的核心線程如何確保一直存在，不退出？
上面分析已經回答了這個問題，每個線程在執行時會執行runWorker()，而在runWorker()內部有while()循環會判斷getTask()，在getTask()內部會對當前執行的線程數量及allowCoreThreadTimeOut進行實時判斷，如果工作數量大於corePoolSize且workQueue中沒有未執行的線程時，會執行poll()超時退出；如果工作數量不大於corePoolSize且workQueue中沒有未執行的線程時，會執行take()進行阻塞，確保有corePoolSize數量的線程阻塞在runWorker()內部的while()循環不退出。
如果需要關閉線程池，需要如何操作呢，看一下shutdown()方法：
以上可以看到，關閉線程池的原理：a. 遍歷線程池中的所有工作線程；b. 逐個調用線程的interrupt()中斷線程（註：無法響應中斷的任務可能永遠無法終止）
也可調用shutdownNow()來關閉線程池，二者區別：
shutdown()：設置線程池的狀態為SHUTDOWN，然後中斷所有沒有正在執行任務的線程；
shutdownNow()：設置線程池的狀態為STOP，然後嘗試停止所有的正在執行或暫停任務的線程，並返回等待執行任務的列表；
使用建議：一般調用shutdown()關閉線程池；若任務不一定要執行完，則調用shutdownNow()；
總結一下：ThreadPoolExecutor在執行execute()及shutdown()時的調用關系，流程圖如下：
線程池可以通過Executors來進行不同類型的創建，具體分為四種不同的類型，如下：
可緩存線程池：不固定線程數量，且支持最大為Integer.MAX_VALUE的線程數量：
1、線程數無限制
2、有空閑線程則復用空閑線程，若無空閑線程則新建線程
3、一定程度上減少頻繁創建/銷毀線程，減少系統開銷
固定線程數量的線程池：定長線程池
1、可控制線程最大並發數(同時執行的線程數)
2、超出的線程會在隊列中等待。
單線程化的線程池：可以理解為線程數量為1的FixedThreadPool
1、有且僅有一個工作線程執行任務
2、所有任務按照指定順序執行，即遵循隊列的入隊出隊規則
定時以指定周期循環執行任務
一般來說，等待隊列 BlockingQueue 有: ArrayBlockingQueue 、 LinkedBlockingQueue 與 SynchronousQueue 。
假設向線程池提交任務時，核心線程都被佔用的情況下:
ArrayBlockingQueue ：基於數組的阻塞隊列，初始化需要指定固定大小。
當使用此隊列時，向線程池提交任務，會首先加入到等待隊列中，當等待隊列滿了之後，再次提交任務，嘗試加入隊列就會失敗，這時就會檢查如果當前線程池中的線程數未達到最大線程，則會新建線程執行新提交的任務。所以最終可能出現後提交的任務先執行，而先提交的任務一直在等待。
LinkedBlockingQueue ：基於鏈表實現的阻塞隊列，初始化可以指定大小，也可以不指定。
當指定大小後，行為就和 ArrayBlockingQueue一致。而如果未指定大小，則會使用默認的 Integer.MAX_VALUE 作為隊列大小。這時候就會出現線程池的最大線程數參數無用，因為無論如何，向線程池提交任務加入等待隊列都會成功。最終意味著所有任務都是在核心線程執行。如果核心線程一直被占，那就一直等待。
SynchronousQueue ：無容量的隊列。
使用此隊列意味著希望獲得最大並發量。因為無論如何，向線程池提交任務，往隊列提交任務都會失敗。而失敗後如果沒有空閑的非核心線程，就會檢查如果當前線程池中的線程數未達到最大線程，則會新建線程執行新提交的任務。完全沒有任何等待，唯一制約它的就是最大線程數的個數。因此一般配合Integer.MAX_VALUE就實現了真正的無等待。
但是需要注意的是， 進程的內存是存在限制的，而每一個線程都需要分配一定的內存。所以線程並不能無限個。
❸ 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 的 UI 框架使用單線程模型，比多線程模型有什麼優點
·如果有大量的線程,會影響性能,因為操作系統需要在它們之間切換。·的線程需要的內存空間。·線程可能會給程序帶來「bug」，因此要小心使用。·線程的中止需要考慮其對程序運行的影響。·通常塊模型數據是在多個線程間共享的，需要防止線程死鎖情況的發生。一些線程模型的背景可以重點討論一下在Win32環境中常用的一些模型。·單線程模型在這種線程模型中，一個進程中只能有一個線程，剩下的進程必須等待當前的線程執行完。這種模型的缺點在於系統完成一個很小的任務都必須佔用很長的時間。·塊線程模型（單線程多塊模型STA）這種模型里，一個程序里可能會包含多個執行的線程。在這里，每個線程被分為進程里一個單獨的塊。每個進程可以含有多個塊，可以共享多個塊中的數據。程序規定了每個塊中線程的執行時間。所有的請求通過Windows消息隊列進行串列化，這樣保證了每個時刻只能訪問一個塊，因而只有一個單獨的進程可以在某一個時刻得到執行。這種模型比單線程模型的好處在於，可以響應同一時刻的多個用戶請求的任務而不只是單個用戶請求。但它的性能還不是很好，因為它使用了串列化的線程模型，任務是一個接一個得到執行的。·多線程塊模型（自由線程塊模型）多線程塊模型（MTA）在每個進程里只有一個塊而不是多個塊。這單個塊控制著多個線程而不是單個線程。這里不需要消息隊列，因為所有的線程都是相同的塊的一個部分，並且可以共享。這樣的程序比單線程模型和STA的執行速度都要快，因為降低了系統的負載，因而可以優化來減少系統idle的時間。這些應用程序一般比較復雜，因為程序員必須提供線程同步以保證線程不會並發的請求相同的資源，因而導致競爭情況的發生。這里有必要提供一個鎖機制。但是這樣也許會導致系統死鎖的發生。進程和線程都是操作系統的概念。進程是應用程序的執行實例，每個進程是由私有的虛擬地址空間、代碼、數據和其它各種系統資源組成，進程在運行過程中創建的資源隨著進程的終止而被銷毀，所使用的系統資源在進程終止時被釋放或關閉。線程是進程內部的一個執行單元。系統創建好進程後，實際上就啟動執行了該進程的主執行線程，主執行線程以函數地址形式，比如說main或WinMain函數，將程序的啟動點提供給Windows系統。主執行線程終止了，進程也就隨之終止。每一個進程至少有一個主執行線程，它無需由用戶去主動創建，是由系統自動創建的。用戶根據需要在應用程序中創建其它線程，多個線程並發地運行於同一個進程中。一個進程中的所有線程都在該進程的虛擬地址空間中，共同使用這些虛擬地址空間、全局變數和系統資源，所以線程間的通訊非常方便，多線程技術的應用也較為廣泛。多線程可以實現並行處理，避免了某項任務長時間佔用CPU時間。要說明的一點是，到2015年為止，大多數的計算機都是單處理器（CPU）的，為了運行所有這些線程，操作系統為每個獨立線程安排一些CPU時間，操作系統以輪換方式向線程提供時間片，這就給人一種假象，好象這些線程都在同時運行。由此可見，如果兩個非常活躍的線程為了搶奪對CPU的控制權，在線程切換時會消耗很多的CPU資源，反而會降低系統的性能。這一點在多線程編程時應該注意。C++11標准中，STL類庫也實現了多線程的類std::thread，使得多線程編程更加方便。