### 參考文章:
[官方文檔介紹:平臺架構](https://developer.android.google.cn/guide/platform#art)
[Android 操作系統架構開篇](http://gityuan.com/android/)
### Android系統的體系結構
**早期的Android架構**如下圖所示

**官方網站最新的Android平臺架構圖**
:-: 
圖1 Android系統架構圖
#### **1、應用程序層**
Android會同一系列核心應用程序包一起發布,該應用程序包包括email客戶端,SMS短消息程序,日歷,地圖,瀏覽器,聯系人管理程序等。所有的應用程序通常都是使用JAVA語言編寫的。
#### **2、應用程序框架**
開發Android應用程序就是面向底層的應用程序框架進行的,從此角度而言,Android上的應用程序完全是平等的。Android應用程序框架提供了大量的API供開發者使用,該應用程序的架構設計簡化了組件的重用;任何一個應用程序都可以發布它的功能塊并且任何其它的應用程序都可以使用其所發布的功能塊(不過得遵循框架的安全性限制)。同樣,該應用程序重用機制也使用戶可以方便的替換程序組件。
- **豐富而又可擴展的視圖(Views)**:可以用來構建應用程序, 它包括列表(lists),網格(grids),文本框(text boxes),按鈕(buttons), 甚至可嵌入的web瀏覽器。
- **內容提供器(Content Providers)**:使得應用程序可以訪問另一個應用程序的數據(如聯系人數據庫), 或者共享它們自己的數據
- **資源管理器(Resource Manager)**:提供 非代碼資源的訪問,如本地字符串,圖形,和布局文件(layout files)。
- **通知管理器 (Notification Manager)**: 使得應用程序可以在狀態欄中顯示自定義的提示信息。
- **活動管理器( Activity Manager)**: 用來管理應用程序生命周期并提供常用的導航回退功能。
#### **3. 函數庫(原生 C/C++ 庫)**
Android 包含一些被不同組件所使用的C/C++庫的集合,一般不能直接調用這套C/C++庫集,但是可以通過 Android 應用程序框架來調用這些庫。
- **Bionic系統 C 庫** : 一個從 BSD 繼承來的標準 C 系統函數庫( libc ), 它是專門為基于 embedded(嵌入式) linux 的設備定制的。
- **媒體庫**:基于 PacketVideo OpenCORE;該庫支持多種常用的音頻、視頻格式回放和錄制,同時支持靜態圖像文件。編碼格式包括MPEG4, H.264, MP3, AAC, AMR, JPG, PNG 。
- **Surface Manager** - 對顯示子系統的管理,并且為多個應用程序提 供了2D和3D圖層的無縫融合。
- **Webkit,LibWebCore** - 一個全新的web瀏覽器引擎用,支持Android瀏覽器和一個可嵌入的web視圖。webview完全可以嵌入到開發者自己的應用程序中
- **SGL** - 底層的2D圖形引擎
- **3D libraries** - 基于OpenGL ES 1.0 APIs實現;該庫可以使用硬件 3D加速(如果可用)或者使用高度優化的3D軟加速。
- **FreeType** -位圖(bitmap)和矢量(vector)字體顯示。
- **SQLite** - 一個對于所有應用程序可用,功能強勁的輕型關系型數據庫引擎。
參考:[淺談 Google Skia 圖形處理引擎](https://www.cnblogs.com/delphidoc/archive/2009/04/26/1443839.html)
#### **4. Android運行時**
Android運行時由兩部分組成:Android核心庫和[ART](https://source.android.google.cn/devices/tech/dalvik)(Android RunTime),其中核心庫集提供了Java語言核心庫所使用的絕大部分功能,而虛擬機則負責運行Android應用程序。
**Android5.0以前,Android運行時由Dalvik虛擬機和Android核心庫集組成,但是由于Dalvik采用一種被稱為JIT(Just-In-Time)的解釋器進行動態編譯并執行,應用每次運行的時候,字節碼都需要通過JIT轉換為機器碼,這會拖慢應用的運行效率,因此導致AndroidAPP運行比較緩慢;而ART模式是在用戶安裝APP時進行預編譯(ahead of time,簡稱為AOT),將原本在程序運行時的編譯動作提前到應用安裝時,這樣使得運行時可以減少動態編譯的開銷,從而提升Android APP的運行效率**。但是,由于ART需要在安裝APP時進行AOT處理,因此ART需要占用更多的存儲空間,應用安裝和系統啟動時間會延長不少,除此之外,ART還支持ARM、X86和MIPS架構,且完全兼容64位系統,必然會帶來更好的用戶體驗。
**ART 的部分主要功能**包括:
* 預先 (AOT) 和即時 (JIT) 編譯
* 優化的垃圾回收 (GC)
* 在 Android 9(API 級別 28)及更高版本的系統中,支持將應用軟件包中的[Dalvik Executable 格式 (DEX) 文件轉換為更緊湊的機器代碼](https://developer.android.google.cn/about/versions/pie/android-9.0#art-aot-dex)。
* 更好的調試支持,包括專用采樣分析器、詳細的診斷異常和崩潰報告,并且能夠設置觀察點以監控特定字段
**ART優點**:
1、系統性能的顯著提升。
2、應用啟動更快、運行更快、體驗更流暢、觸感反饋更及時。
3、更長的電池續航能力。
4、支持更低的硬件。
**ART缺點**:
1、更大的存儲空間占用,可能會增加10%-20%。
2、更長的應用安裝時間。
?
總的來說**ART的功效就是“空間換時間”**。
對于運行 Android 5.0(API 級別 21)或更高版本的設備,每個應用都在其自己的進程中運行,并且都有其自己的[Android Runtime (ART)](http://source.android.google.cn/devices/tech/dalvik/index.html)實例。ART 編寫為通過執行 DEX 文件在低內存設備上運行多個虛擬機,DEX 文件是一種專為 Android 設計的字節碼格式,經過優化,使用的內存很少。編譯工具鏈(例如[Jack](https://source.android.google.cn/source/jack.html))將 Java 源代碼編譯為 DEX 字節碼,使其可在 Android 平臺上運行。
*****
----------
**PS**:2014年的Google I/O大會,ART才正式取代Dalvik,ART的發布之所以引起大家的關注,是因為Andoid與iOS相比,一直被人詬病它的流暢性。Android的流暢性問題,有一部分原因就歸結于它的應用程序和部分系統服務是運行虛擬機之上的,也就是運行在Dalvik虛擬機之上,而IOS的應用程序和系統服務都是直接執行本地機器指令的。除了使用ART替換Dalvik之外,我們也應當看到,Android從3.0開始,就不遺余力地改進系統的流暢性。例如,3.0增加了對應用程序2D UI的硬件加速渲染,也就是GPU渲染。在此之前,應用程序的2D UI一直都是使用軟件渲染,也就是CPU渲染。又如4.1通過Project Butter,在UI架構中引入了VSYNC、Triple Buffer和HWComposer等技術,極大地提高UI的流暢性。
**ART之所以會比Dalvik快,是因為ART執行的是本地機器指令,而Dalvik執行的是Dex字節碼,通過通過解釋器執行**。盡管Dalvik也會對頻繁執行的代碼進行JIT生成本地機器指令來執行,但畢竟在應用程序運行的過程中將Dex字節碼翻譯成本地機器機器指令也會影響到應用程序本身的執行,因此即使Dalvik使用了JIT,也在一定程度上也比不上直接就可以執行本地機器指令的運行時。下圖是Dalvik、ART和Java VM的關系
:-: 
圖2 Dalvik、ART和Java VM的關系
ART像Dalvik一樣,都實現Java虛擬機接口,除此之外,其內部還有垃圾收集機制(GC),同時還有Java核心類庫調用,具體關于ART的分析可以參考[老羅的一些列博客](http://blog.csdn.net/luoshengyang/article/details/39256813),具體有[ART執行類方法的過程分析 ](http://blog.csdn.net/luoshengyang/article/details/40289405)和[ART運行時無縫替換Dalvik虛擬機的過程分析 ](http://blog.csdn.net/luoshengyang/article/details/18006645)等等。
#### **5.硬件抽象層 (HAL)**
[硬件抽象層 (HAL)](https://source.android.google.cn/devices/architecture/hal-types)**提供標準界面**,向更高級別的[Java API 框架](https://developer.android.google.cn/guide/platform#api-framework)顯示設備硬件功能。**HAL 包含多個庫模塊,其中每個模塊都為特定類型的硬件組件實現一個界面,例如[相機](https://source.android.google.cn/devices/camera/index.html)或[藍牙](https://source.android.google.cn/devices/bluetooth.html)模塊**。當框架 API 要求訪問設備硬件時,Android 系統將為該硬件組件加載庫模塊。
關于HAL,你需要記住以下幾點:
在 Android 8.0 及更高版本中,較低級別的層已重新編寫以采用更加模塊化的新架構。運行 Android 8.0 或更高版本的設備必須支持使用 HIDL 語言編寫的 HAL,下面列出了一些例外情況。這些 HAL 可以是綁定式 HAL 也可以是直通式 HAL:
* **綁定式 HAL**:以 [HAL 接口定義語言 (HIDL)](https://source.android.google.cn/devices/architecture/hidl) 表示的 HAL。這些 HAL 取代了早期 Android 版本中使用的傳統 HAL 和舊版 HAL。在綁定式 HAL 中,Android 框架和 HAL 之間通過 Binder 進程間通信 (IPC) 調用進行通信。所有在推出時即搭載了 Android 8.0 或更高版本的設備都必須只支持綁定式 HAL。
* **直通式 HAL**:以 HIDL 封裝的傳統 HAL 或舊版 HAL。這些 HAL 封裝了現有的 HAL,可在綁定模式和 Same-Process(直通)模式下使用。升級到 Android 8.0 的設備可以使用直通式 HAL。
[Android HIDL HAL 接口定義語言詳解](https://blog.csdn.net/qq_19923217/article/details/88398660):在 Andoird 8.0 版本框架代碼中,加入了 HIDL(HAL 接口定義語言),HIDL 的出現是為了將用戶層和 HAL 層分割開,它指定了 HAL 和用戶之間的接口,讓用戶能夠替換 Android 框架,而無需重新編譯 HAL,以便讓廠商能夠以更低的成本、更快速地將設備更新到新版 Android 版本中。
**通俗的來說,HIDL 設計了一套通過的框架接口,將 HAL 層實現與 Android 操作系統框架分離開來,設備廠商只需要構建一次 HAL,并將其放置在` /vendor` 分區中,便能適應大部分 Android 操作系統框架版本的升級。**
:-: 
圖:HIDL 設計下的升級方式
#### **6. [Linux內核](https://source.android.google.cn/devices/architecture/kernel)**
Android系統建立在Linux 2.6之上,如安全性,內存管理,進程管理, 網絡協議棧和驅動模型。 Linux 內核也同時作為硬件和軟件棧之間的抽象層。其外還對其做了部分修改,主要涉及兩部分修改:
1. Binder (IPC):提供有效的進程間通信,雖然linux內核本身已經提供了這些功能,但Android系統很多服務都需要用到該功能,為了某種原因其實現了自己的一套。
2. 電源管理:主要是為了省電,畢竟是手持設備嘛,低耗電才是我們的追求。
:-: 
圖3 AndroidLinux內核
#### **cpu**:
* **intel x86結構** 主要運用在pc機 筆記本 k800 k880
* **AMD x86結構**
* **arm** 主要運用在移動平臺 賣標準 絕大多數android手機處理器
#### **一些重要的Android組件**
一個Android程序由下面這些部分組成。
* Activity:代表了Android程序的展現層,比如用戶看到的界面。一個Android程序會有一些個Activities,在程序運行過程中也會切換。
* Views:一個Activities的用戶界面是繼承自android.view.View。views的布局通過android.view.ViewGroups來管理。
* Services:不需要UI展現的后臺任務。可以通過android的提醒框架給用戶提示。
* Content Provider:為程序提供數據,通過Content Provider你的程序可以與別的程序共享數據。Android的SQLite數據庫可以看做一個Content Provider。
* Intents:是一個異步的消息系統,可以從別的系統或服務獲取數據。程序可以直接調用一個服務或者activity,也可以請求android系統。
* Broadcast Receiver:接受系統消息或者隱含的intent,可以根據系統的改變做出反應。一個程序可以注冊成為某些事件的Broadcast Receiver,當事件發生時,程序就執行。
**android應用程序的四個核心的組件:**
* **activity** ui界面的展現,不適合做耗時操作
* **content provider** 內容提供者 暴露自己應用私有的數據給別的應用程序
* **broadcast receiver** 廣播接受者.
* **service** 后臺服務. 長期在后臺運行, 都沒用戶界面的一個組件.
- 前言
- Android系統的體系結構
- Dalvik VM 和 JVM 的比較
- Android 打包應用程序并安裝的過程
- Android ADB工具
- Android應用開發
- Android UI相關知識總結
- Android 中window 、view、 Activity的關系
- Android應用界面
- Android中的drawable和bitmap
- AndroidUI組件adapterView及其子類和Adapter的關系
- Android四大組件
- Android 數據存儲
- SharedPreference
- Android應用的資源
- 數組資源
- 使用Drawable資源
- Material Design
- Android 進程和線程
- 進程
- 線程
- Android Application類的介紹
- 意圖(Intent)
- Intent 和 Intent 過濾器(Google官網介紹)
- Android中關于任務棧的總結
- 任務和返回棧(官網譯文)
- 總結
- Android應用安全現狀與解決方案
- Android 安全開發
- HTTPS
- 安卓 代碼混淆與打包
- 動態注入技術(hook技術)
- 一、什么是hook技術
- 二、常用的Hook 工具
- Xposed源碼剖析——概述
- Xposed源碼剖析——app_process作用詳解
- Xposed源碼剖析——Xposed初始化
- Xposed源碼剖析——hook具體實現
- 無需Root也能Hook?——Depoxsed框架演示
- 三、HookAndroid應用
- 四、Hook原生應用程序
- 五、Hook 檢測/修復
- Android 應用的逆向與加固保護技術
- OpenCV在Android中的開發
- Android高級開發進階
- 高級UI
- UI繪制流程及原理
- Android新布局ConstraintLayout約束布局
- 關鍵幀動畫
- 幀動畫共享元素變換
- Android異步消息處理機制完全解析,帶你從源碼的角度徹底理解
- Android中為什么主線程不會因為Looper.loop()里的死循環卡死?
- 為什么 Android 要采用 Binder 作為 IPC 機制?
- JVM 中一個線程的 Java 棧和寄存器中分別放的是什么?
- Android源碼的Binder權限是如何控制?
- 如何詳解 Activity 的生命周期?
- 為什么Android的Handler采用管道而不使用Binder?
- ThreadLocal,你真的懂了嗎?
- Android屏幕刷新機制