Android零基礎入門第2節：Android 系統架構和應用組件那些事

 繼上一期淺談了Android的前世此生，這一期一塊兒來大體回顧一下Android 系統架構和應用組件。

 

1、Android 系統架構

Android系統的底層創建在Linux系統之上，該平臺由操做系統、中間件、用戶界面和應用軟件4層組成，它採用一種被稱爲軟件疊層（Software Stack）的方式進行構建。這種軟件疊層結構使得層與層之間相互分離，明確各層的分工。這種分工保證了層與層之間的低耦合，當下層的層內或層下發生改變時，上層應用程序無須任何改變。

Android的系統架構和其餘操做系統同樣，採用了分層的架構。從架構圖看，Android分爲四個層，從高層到低層分別是應用程序層（Applications）、應用程序框架層（Application Framework ）、系統運行庫層（Libraries和Android Runtime）和Linux內核層（Linux Kernel），以下圖所示：

01 應用程序層

應用程序層是一個核心應用程序的集合，全部安裝在手機上的應用程序都屬於這一層。該層不只包括系統內置的應用也包括用戶本身安裝的應用，例如email 客戶端，SMS 短消息程序，日曆，地圖，瀏覽器，聯繫人管理程序，QQ，微信，淘寶，美團等。

該層全部的應用程序都是使用Java 語言編寫的，這也是本次主要總結整理的內容。

02 應用程序框架層

開發人員也能夠徹底訪問核心應用程序所使用的API框架。該應用程序的架構設計簡化了組件的重用，任何一個應用程序均可以發佈它的功能塊而且任何其它的應用程序均可以使用其所發佈的功能塊（不過得遵循框架的安全性）。一樣，該應用程序重用機制也使用戶能夠方便的替換程序組件。

隱藏在每一個應用後面的是一系列的服務和系統，其中包括：

1)豐富而又可擴展的視圖（Views），能夠用來構建應用程序， 它包括列表（List）、網格（Grid）、文本框（Text）、按鈕（Button)， 甚至可嵌入web瀏覽器。

2)內容提供者（Content Providers），使得應用程序能夠訪問另外一個應用程序的數據（如聯繫人數據庫），或者共享它們本身的數據。

3)資源管理器（Resource Manager），提供非代碼資源的訪問，如本地字符串、圖形、和佈局文件（Layout files ）。

4)通知管理器 （Notification Manager），使得應用程序能夠在狀態欄中顯示自定義的提示信息。

5)活動管理器（Activity Manager），用來管理應用程序生命週期並提供經常使用的導航回退功能。

應用程序框架除了可做爲應用程序開發的基礎以外，也是軟件複用的重要手段，任何一個應用程序均可發佈它的功能模塊——只要發佈時遵照了框架的約定，那麼其餘應用程序就可以使用這個功能模塊。

03 系統運行庫層

系統運行庫層包含了系統庫及Android運行時。

系統庫

Android包含一套被不一樣組件所使用的C/C++庫的集合。通常來講，Android應用開發者不能直接調用這套C/C++庫集，但能夠經過它上面的應用程序框架來調用這些庫。

下面列出一些核心庫：

1)系統C庫：一個從BSD系統派生出來的標準C系統庫（libc），而且專門爲嵌入式 Linux設備調整過。

2)媒體庫：基於PacketVideo的OpenCORE，這套媒體庫支持播放和錄製許多流行的音 頻和視頻格式，以及查看靜態圖片。主要包括MPEG四、H.26四、MP三、AAC、AMR、JPG、PNG等多媒體格式。

3)Surface Manager：管理對顯示子系統的訪問，並能夠對多個應用程序的2D和3D圖 層提供無縫整合。

4)LibWebCore：一個全新的Web瀏覽器引擎，該引擎爲Android瀏覽器提供支持，也爲WebView提供支持，WebView徹底能夠嵌入開發者本身的應用程序中。

5)SQLite：供全部應用程序使用的功能強大的輕量級關係數據庫。

6)OpenGL ES：該庫可使用硬件3D加速(若是可用)或者使用高度優化的3D軟加速。

7)FreeType：位圖（Bitmap）和矢量（Vector）字體顯示。

8)SGL：底層的2D 圖形引擎。

Android運行時（Android Runtime）

Android運行時由兩部分組成：Android核心庫集和ART。其中核心庫集提供了Java語言核心庫所能使用的絕大部分功能，而虛擬機則負責運行Android應用程序。

Android 5.0之前的Android運行時由Dalvik虛擬機和Android核心庫集組成，但因爲Dalvik 虛擬機採用了一種被稱爲JIT （Just-in-time）的解釋器進行動態編譯並執行，所以致使Android App運行時比較慢;而ART模式則是在用戶安裝App時進行預編譯（Ahead-of-time，簡稱AOT）的，將本來在程序運行時的編譯動做提早到應用安裝時，這樣使得程序在運行時能夠減小動態 編譯的開銷，從而提高Android App的運行效率。

反過來，因爲ART須要在安裝App時進行AOT處理，所以ART須要佔用更多的存儲空 間，應用安裝和系統啓動時間會延長很多。

除此以外，ART還支持ARM、x86和MIPS架構，而且能徹底兼容64位系統，Android必然會帶來更好的用戶體驗。

04 Linux內核層

Android系統主要基於Linux2.6內核開發，Linux內核層爲Android設備的各類硬件提供了底層的驅動，如顯示驅動、音頻驅動、照相機驅動、藍牙驅動、電源管理驅動等。

Linux 內核也同時做爲硬件和軟件棧之間的抽象層。

 

2、Dalvik虛擬機和ART模式

01 Dalvik虛擬機

經過JavaSE部分的學習，咱們知道JavaSE 程序使用的虛擬機叫Java Virtual Machine，簡稱JVM。而Android 應用雖然使用Java 語言開發，可是使用的虛擬就是Dalvik Virtual Machine，簡稱DVM。

Dalvik是Google公司本身設計的用於Android平臺的虛擬機，它能夠簡單地完成進程隔離和線程管理，而且能夠提升內存的使用效率。每個Android應用程序在底層都會對應一個獨立的Dalvik虛擬機實例，其代碼在虛擬機的解析下得以執行。Dalvik 通過優化，容許在有限的內存中同時運行多個虛擬機的實例，而且每個Dalvik 應用做爲一個獨立的Linux 進程執行。

不少人都認爲Dalvik虛擬機是一個Java虛擬機，由於Android開發的編程語言偏偏是 Java語目，可是這種說法並不許確。Dalvlk虛擬機並非按照Java虛擬機的規範來實現的，二者不兼容，並且也有不少不一樣之處。下面經過一個圖來進行對比說明，以下圖所示。

從上圖能夠看出，Java虛擬機和Dalvik虛擬機主要有兩大區別：一是它們編譯後的文件不一樣；二是它們基於的架構不一樣。具體以下：

 編譯後的文件不一樣

Java虛擬機運行的是.class字節碼文件，而Dalvik虛擬機運行的則是其專有的.dex文件。 在Java程序中Java類會被翻譯成一個或者多個字節碼文件（.class ）而後打包到.jar文件，以後Java虛擬機會從相應的.class文件和.jar文件中獲取相應的字節碼。Android程序雖然也是使用Java語言進行編程，可是在翻譯成.class文件後，還會經過工具將全部的.class文件轉換成一個.dex文件，而後Dalvik虛擬機從其中讀取指令和數據，最後的.odex是爲了在運行過程當中進一步提升性能而對.dex文件進行的進一步優化，能加快軟件的加載速度和開啓速度。

 基於的架構不一樣

Java虛擬機是基於棧的架構，你們知道，棧是一個連續的內存空間，取出和存人的速度比較慢；而Dalvik基於寄存器的架構，寄存器是CPU上的一塊緩存，寄存器的存取速度要比從內存中存取的速度快不少，這樣就能夠根據硬件最大限度地優化設備，更適合移動設備的使用。

須要說明的是，Android系統下的Dalvik虛擬機默認給每個應用程序最多分配16 MB 內存，若是Android加載的資源超過這個值，就會報出OutOfMemoryError異常，所以必定要注意這個問題。

02 ART模式

ART模式英文全稱爲Android Runtime，是谷歌Android 4.4系統新增的一種用運行模式。與傳統的Dalvik模式不一樣，ART模式能夠實現更爲流暢的安卓系統體驗，只有在Android 4.4以上系統中採用此模式。

在4.4 系統以前，Android 系統在Linux 的底層下構築Dalvik 一層的虛擬機，經過其能夠更好適應多樣的硬件架構，開發者只須要按一套規則進行應用即可，無需由於不一樣的硬件架構而處理與底層的驅動關係，從而大大提升開發的效率，但由於應用均是運行在Dalvik 虛擬機中，所以應用程序每次運行的時候，一部分代碼都須要從新進行編譯，這過程須要消耗必定的時間和下降應用的執行效率，最明顯的即是拖延了應用的啓動時間和下降了運行速度。

ART 模式最大的做用就是提高了Android 系統流暢度，相比Dalvik 模式中出現的耗電快、佔用內存大、即便是旗艦機用久了也會卡頓嚴重等現象，ART 模式中這種問題獲得了很好的解決，經過在安裝應用程序時，自動對程序進行代碼預讀取編譯，讓程序直接編譯成機器語言，免去了Dalvik 模式要時時轉換代碼，實現高效率、省電、佔用更低的系統內存、手機運行流暢。

 

3、Android應用組件

Android四大組件分別是：

活動（Activity）： 用於表現功能。

服務（Service）： 後臺運行服務，不提供界面呈現。

廣播接收器（BroadcastReceiver）：用於接收廣播。

內容提供者（Content Provider）： 支持在多個應用中存儲和讀取數據，至關於數據庫。

01 Activity

Android中，Activity是全部程序的根本，全部程序的流程都運行在Activity之中，Activity能夠算是開發者遇到的最頻繁，也是Android 當中最基本的模塊之一。在Android的程序當中，Activity 通常表明手機屏幕的一屏。若是把手機比做一個瀏覽器，那麼Activity就至關於一個網頁。在Activity當中能夠添加一些Button、Check box等控件。能夠看到Activity概念和網頁的概念至關相似。

通常一個Android 應用是由多個Activity 組成的。這多個Activity之間能夠進行相互跳轉，例如，按下一個Button按鈕後，可能會跳轉到其餘的Activity。和網頁跳轉稍微有些不同的是，Activity 之間的跳轉有可能返回值，例如，從Activity A 跳轉到Activity B，那麼當Activity B運行結束的時候，有可能會給Activity A一個返回值。這樣作在不少時候是至關方便的。

當打開一個新的屏幕時，以前一個屏幕會被置爲暫停狀態，而且壓入歷史堆棧中。用戶能夠經過回退操做返回到之前打開過的屏幕。能夠選擇性的移除一些沒有必要保留的屏幕，由於Android會把每一個應用的開始到當前的每一個屏幕保存在堆棧中。

02 Service

Service 是android 系統中的一種組件，它跟Activity 的級別差很少，可是他不能本身運行，只能後臺運行，而且能夠和其餘組件進行交互。Service 是沒有界面的長生命週期的代碼。Service是一種程序，它能夠運行很長時間，可是它卻沒有用戶界面。

這麼說有點枯燥，來看個例子。打開一個音樂播放器的程序，這個時候若想上網了，那麼，打開Android瀏覽器，這個時候雖然已經進入了瀏覽器這個程序，可是，歌曲播放並無中止，而是在後臺繼續一首接着一首的播放。其實這個播放就是由播放音樂的Service進行控制。固然這個播放音樂的Service也能夠中止，例如，當播放列表裏邊的歌曲都結束，或者用戶按下了中止音樂播放的快捷鍵等。

Service 能夠在和多場合的應用中使用，好比播放多媒體的時候用戶啓動了其餘Activity這個時候程序要在後臺繼續播放，好比檢測SD 卡上文件的變化，再或者在後臺記錄地理信息位置的改變等等，總之服務嘛，老是藏在後頭的。

03 BroadcastReceiver

在Android 中，Broadcast是一種普遍運用的在應用程序之間傳輸信息的機制。而BroadcastReceiver 是對發送出來的Broadcast進行過濾接受並響應的一類組件。可使用BroadcastReceiver 來讓應用對一個外部的事件作出響應。

這是很是有意思的，例如，當電話呼入這個外部事件到來的時候，能夠利用BroadcastReceiver 進行處理。例如，當下載一個程序成功完成的時候，仍然能夠利用BroadcastReceiver 進行處理。BroadcastReceiver不能生成UI，也就是說對於用戶來講不是透明的，用戶是看不到的。BroadcastReceiver經過NotificationManager 來通知用戶這些事情發生了。BroadcastReceiver 既能夠在AndroidManifest.xml 中註冊，也能夠在運行時的代碼中使用Context.registerReceiver（）進行註冊。只要是註冊了，當事件來臨的時候，即便程序沒有啓動，系統也在須要的時候啓動程序。各類應用還能夠經過使用Context.sendBroadcast（） 將它們本身的Intent Broadcasts廣播給其餘應用程序。

04 Content Provider

Content Provider 是Android提供的第三方應用數據的訪問方案。

在Android中，對數據的保護是很嚴密的，除了放在SD卡中的數據，一個應用所持有的數據庫、文件等內容，都是不容許其餘直接訪問的。Android固然不會真的把每一個應用都作成一座孤島，它爲全部應用都準備了一扇窗，這就是Content Provider。應用想對外提供的數據，能夠經過派生Content Provider類， 封裝成一枚Content Provider，每一個Content Provider都用一個uri做爲獨立的標識，形如：content://com.xxxxx。全部東西看着像REST的樣子，但實際上，它比REST 更爲靈活。和REST相似，uri也能夠有兩種類型，一種是帶id的，另外一種是列表的，但實現者不須要按照這個模式來作，給id的uri也能夠返回列表類型的數據，只要調用者明白，就無妨，不用苛求所謂的REST。

 

今天就先到這裏，下一期將初步總結分享Android環境搭建，若是有問題歡迎留言一塊兒探討，共同成長！

此文章版權爲微信公衆號分享達人秀全部，若轉載請備註出處，特此聲明！