android運行環境一覽
android基于linux內核，面向移動終端的操作系統。主要包括以下幾個方面：

application framework：
這一層為應用開發者提供了豐富的應用編程接口，如 activity manager，content provider，notification manager，以及各種窗口 widget 資源等。所有的app都是運行在這一層之上。
dalvik 虛擬機：
dalvik vm采用寄存器架構，而不是jvm的棧架構，更適于移動設備。java源代碼經過編譯成為.class字節碼文件，然后由谷歌提供的 dx工具將其轉化為dalvik可識別的.dex文件。
linux kernel：
每個app應用程序由一個獨立的dalvik vm來解釋執行，而一個dalvik vm實例對應一個linux內核進程。
所以說，每個app之間完全隔離，資源獨立。使得每個app更加安全，但也不利于進程間通信

android官方介紹

**android 系統架構

application framework
大部分開發者十分關心這一層。你必須要了解開發者會接觸到的所有api接口，大部分接口都與硬件抽象層(hal層)接口一一對應，而且它們會告訴你如何實現你自己的驅動。

binder ipc
binder進程間通信機制幫助application framework層能夠跨進程并且調用系統級服務。從根本上講，它幫助高級別的framework的api接口與android系統服務進行交互。

系統服務
大部分application framework api具備的功能都要依靠與某種系統服務進行通信從而操作底層硬件。系統服務根據不同的功能分成了若干模塊組件，例如window manager, search service, or notification manager。系統服務主要包含兩大塊：系統和媒體。前者對應的服務包含如window manager 或 notification manager，后者對應的服務都與播放或記錄媒體有關。
硬件抽象層hardware abstraction layer (hal)
硬件抽象層可以作為一個標準接口讓android系統調用設備驅動層而不用管這些驅動和硬件時如何實現的。
![硬件驅動層相關組件]
linux kernel
大多數情況下，你自己開發設備驅動和開發linux設備驅動時一樣的。android挑選了一個特定的linux內核版本，這個版本包含了如wakelocks(一個內存管理系統)，binder ipc驅動和其他一些特征，這些特征對于像android一樣的移動嵌入式平臺都非常重要。你也可以根據自己的需求選擇合適的kernel版本，只要它能支持一些必要的屬性如binder ipc驅動等。但是，我們仍然推薦你使用最新版本的android內核。具體可參考內核編譯
相關知識點：
應用程序進程間隔離機制：
android系統包括四層架構：從底層往上依次是linux kernel層、c/c++函數庫與android運行時環境(dalvik vm等)層、android framwork框架層、應用程序層。其中，android運行時環境層類似java里的jre層，主要用來運行java程序，不過此處的虛擬機是dalvik虛擬機。每一個android應用程序都運行在單獨的davlik進程里，dalvik虛擬機針對同時高效運行多個虛擬機而優化，在這一層實現了應用程序的進程間隔離。

dalvik虛擬機與jvm區別：

jvm直接從.class或jar包中加載字節碼解釋運行，dalvik通過dx工具將.class文件編譯為.dex文件（dalvik executable）來運行。
jvm采用棧結構，而dalvik采用寄存器結構，更適于移動設備。
為何android要采用dalvik虛擬機而不是jvm呢？

大多數虛擬機（包括jvm）都是基于棧的，而dalvik虛擬機則是基于寄存器的，性能更好，不過也導致硬件通用性略差；
運行專有.dex文件。dx工具對.class文件編譯時，去除里面的冗余信息，并把所有.class文件整合到一個文件中，提高了性能。同時dx工具還會對.dex文件進行性能優化。

內存管理及優化
一、android內存基礎
物理內存與進程內存
物理內存即移動設備上的ram，當啟動一個android程序時，會啟動一個dalvik vm進程，系統會給它分配固定的內存空間（16m,32m不定），這塊內存空間會映射到ram上某個區域。然后這個android程序就會運行在這塊空間上。java里會將這塊空間分成stack棧內存和heap堆內存。stack里存放對象的引用，heap里存放實際對象數據。
在程序運行中會創建對象，如果未合理管理內存，比如不及時回收無效空間就會造成內存泄露，嚴重的話可能導致使用內存超過系統分配內存，即內存溢出oom，導致程序卡頓甚至直接退出。

內存泄露（memory leak）
java內存泄漏指的是進程中某些對象（垃圾對象）已經沒有使用價值了，但是它們卻可以直接或間接地引用到gc roots導致無法被gc回收。dalvik vm具備的gc機制（垃圾回收機制）會在內存占用過多時自動回收，嚴重時會造成內存溢出oom。

內存溢出oom
當應用程序申請的java heap空間超過dalvik vm heapgrowthlimit時，溢出。
注意：oom并不代表內存不足，只要申請的heap超過dalvik vm heapgrowthlimit時，即使內存充足也會溢出。效果是能讓較多進程常駐內存。

如果ram不足時系統會做什么？
android的memory killer會殺死優先級較低的進程，讓高優先級進程獲取更多內存。

android系統默認內存回收機制

進程優先級：foreground進程、visible進程、service進程、background進程、empty進程;
如果用戶按home鍵返回桌面，那么該app成為background進程；如果按back返回，則成為empty進程
activitymanagerservice直接管理所有進程的內存資源分配。所有進程要申請或釋放內存都需要通過activitymanagerservice對象。
垃圾回收不定期執行。當內存不夠時就會遍歷heap空間，把垃圾對象刪除。
堆內存越大，則gc的時間更長

二、優化
bitmap優化
bitmap非常消耗內存，而且在android中，讀取bitmap時， 一般分配給虛擬機的圖片堆棧只有8m，所以經常造成oom問題。所以有必要針對bitmap的使用作出優化：

• 圖片顯示：加載合適尺寸的圖片，比如顯示縮略圖的地方不要加載大圖。
• 圖片回收：使用完bitmap，及時使用bitmap.recycle()回收。
• 問題：android不是自身具備垃圾回收機制嗎？此處為何要手動回收。
• bitmap對象不是new生成的，而是通過bitmapfactory生產的。而且通過源碼可發現是通過調用jni生成bitmap對象（nativedecodestream()等方法）。所以，加載bitmap到內存里包括兩部分，dalvik內存和linux kernel內存。前者會被虛擬機自動回收。而后者必須通過recycle()方法，內部調用nativerecycle()讓linux kernel回收。
• 捕獲oom異常：程序中設定如果發生oom的應急處理方式。
• 圖片緩存：內存緩存、硬盤緩存等
• 圖片壓縮：直接使用imageview顯示bitmap時會占很多資源，尤其當圖片較大時容易發生oom?？梢允褂胋itmapfactory.options對圖片進行壓縮。
• 圖片像素：android默認顏色模式為argb_8888，顯示質量最高，占用內存最大。若要求不高時可采用rgb_565等模式。圖片大?。簣D片長度*寬度*單位像素所占據字節數
• argb_4444：每個像素占用2byte內存
• argb_8888：每個像素占用4byte內存 （默認）
• rgb_565：每個像素占用2byte內存

對象引用類型

強引用 strong：object object=new object()。當內存不足時，java虛擬機寧愿拋出oom內存溢出異常，也不會輕易回收強引用對象來解決內存不足問題；
軟引用 soft：只有當內存達到某個閾值時才會去回收，常用于緩存；
弱引用 weak ：只要被gc線程掃描到了就進行回收；
虛引用
如果想要避免oom發生，則使用軟引用對象，即當內存快不足時進行回收；如果想盡快回收某些占用內存較大的對象，例如bitmap，可以使用弱引用，能被快速回收。不過如果要對bitmap作緩存就不要使用弱引用，因為很快就會被gc回收，導致緩存失敗。
池 pool

對象池：如果某個對象在創建時，需要較大的資源開銷，那么可以將其放入對象池，即將對象保存起來，下次需要時直接取出使用，而不用再次創建對象。當然，維護對象池也需要一定開銷，故要衡量。
線程池：與對象池差不多，將線程對象放在池中供反復使用，減少反復創建線程的開銷。