本文主要總結(jié)的內(nèi)容如下：

• 一、框架簡介
  1、框架
  2、Dalvik虛擬機(jī)與ART虛擬機(jī)
  3、Android應(yīng)用程序框架（APPLICATION FRAMEWORK）
  4、簡述下Android 數(shù)字簽名

系列第二篇：<查漏補(bǔ)缺_Android基礎(chǔ)系列>視圖組件

一、框架簡介

1、框架

• 總結(jié)：
  Android系統(tǒng)架構(gòu)包含四層：Linux內(nèi)核層，庫和運(yùn)行時(shí)、Framework層、應(yīng)用層。Android的體系架構(gòu)鼓勵(lì)系統(tǒng)組件重用，共享組件間的數(shù)據(jù)，并定義組件間的訪問控制權(quán)限。這些層次結(jié)構(gòu)既相互獨(dú)立，又互相關(guān)聯(lián)。

• 說明：
  1、每個(gè)Android應(yīng)用程序都運(yùn)行在它自己的Dalvik 實(shí)例的一個(gè)進(jìn)程中。
  2、Dalvik 和 Android運(yùn)行時(shí)位于一個(gè)Linux 內(nèi)核之上。
  3、Android軟件棧 是通過一個(gè)應(yīng)用程序框架提供一個(gè)Linux 內(nèi)核和一個(gè)C/C++庫集合，而該應(yīng)用程序框架為運(yùn)行時(shí)和應(yīng)用程序提供服務(wù)，并對它們進(jìn)行管理。
  

  Android體系架構(gòu)（Android軟件棧）

• Android軟件棧（體系架構(gòu)）
  1、Linux內(nèi)核（Linux KERNEL）
  Linux提供了核心服務(wù)（硬件驅(qū)動(dòng)程序、進(jìn)程和內(nèi)存管理、安全、網(wǎng)絡(luò)和電源管理），而且內(nèi)核還在硬件和軟件棧的其他部分之間提供了一個(gè)抽象層。

  2、庫（LIBRARIES）
  包含各種C/C++ 核心庫（如libc和SSL），以及：

  • 用來回放音頻和視頻媒體的媒體庫
  • 用來管理顯示的外觀管理器
  • 包含用于2D和3D圖形的SGL和OpenGL 的圖形庫
  • 用于本地?cái)?shù)據(jù)庫支持的SQLite
  • 用于集成Web瀏覽器和Internet 安全的SSL和Webkit

  3、Android運(yùn)行時(shí)（ANDROID RUNTIME）
  它是向應(yīng)用程序提供動(dòng)力的引擎，它和庫 一起形成了應(yīng)用程序框架的基礎(chǔ)。

  • 核心庫（Core Libraries）：提供了Java核心庫以及Android特定庫可用的大部分功能
  • Dalvik虛擬機(jī)（Dalvik Virtual Machine）：Dalvik是一個(gè)基于寄存器的虛擬機(jī)，它已經(jīng)被優(yōu)化從而確保一個(gè)設(shè)備可以高效地運(yùn)行多個(gè)實(shí)例。它依賴Linux內(nèi)核進(jìn)行線程和底層內(nèi)存管理。

  4、應(yīng)用程序框架（APPLICATION FRAMEWORK）
  應(yīng)用程序框架提供了用來創(chuàng)建Android應(yīng)用程序的類。它還對硬件訪問提供了一般抽象，并管理用戶界面和應(yīng)用程序資源。

  5、應(yīng)用層（APPLICATIONS）
  所有的應(yīng)用程序，包括原生的和第三方的，都在應(yīng)用層上使用相同的庫進(jìn)行構(gòu)建。
  應(yīng)用層運(yùn)行在Android運(yùn)行時(shí) 內(nèi)，并使用了應(yīng)用程序框架中可用的類和服務(wù)。

相關(guān)鏈接：android平臺(tái)原理機(jī)制

2、Dalvik虛擬機(jī)與ART虛擬機(jī)

• Dalvik虛擬機(jī)
  1、使用設(shè)備底層Linux內(nèi)核來處理基本的功能，包括安全、線程以及進(jìn)程和內(nèi)存管理。
  2、可以編寫直接運(yùn)行在底層Linux OS 上的C/C++ 應(yīng)用程序，但大部分沒必要。
  3、Dalvik虛擬機(jī)的特點(diǎn)是在運(yùn)行時(shí)才進(jìn)行編譯。
  4、每次運(yùn)行時(shí)，字節(jié)碼都需要通過即時(shí)編譯器（JIT, just in time），轉(zhuǎn)換為機(jī)器碼。這會(huì)使得應(yīng)用程序的效率降低。

• ART虛擬機(jī)（Android Runtime）
  1、從Android5.0開始，默認(rèn)采用ART虛擬機(jī)。
  2、在ART中，系統(tǒng)在安裝應(yīng)用時(shí)會(huì)進(jìn)行一次預(yù)編譯（AOT，ahead of time）,將字節(jié)碼預(yù)先編譯成機(jī)器碼并存儲(chǔ)在本地，這樣應(yīng)用每次運(yùn)行時(shí)就不需要執(zhí)行編譯了，運(yùn)行效率也大大提升。

3、Android應(yīng)用程序框架（APPLICATION FRAMEWORK）

下面的應(yīng)用程序服務(wù)是所有Android應(yīng)用程序的框架基礎(chǔ)，它們提供了常用軟件都會(huì)使用到的框架：

• Activity Manager 和Fragment Manager：
  分別控制Activity 和Fragment 的生命周期，包括對Activity 棧的管理。
• 視圖（View）：
  用來為Activity 和Fragment 構(gòu)建用戶界面。
• Notification Manager（通知管理器）：
  提供了一種一致的和非打斷性的機(jī)制來通知用戶。
• Content Provider（內(nèi)容提供者）：
  讓應(yīng)用程序可以共享數(shù)據(jù)。
• Resource Manager（資源管理器） ：
  支持像字符串和圖形這樣的非代碼資源的具體化。
• Intent：
  提供了一種在應(yīng)用程序及其組件之間傳遞數(shù)據(jù)的機(jī)制。

等等

4、簡述下Android 數(shù)字簽名

• 總結(jié)：
  在Android系統(tǒng)中，所有安裝到系統(tǒng)的應(yīng)用程序都必有一個(gè)數(shù)字證書，此數(shù)字證書用于標(biāo)識(shí)應(yīng)用程序的作者和在應(yīng)用程序之間建立信任關(guān)系。

• 1、詳細(xì)說明：
  Android系統(tǒng)要求每一個(gè)安裝進(jìn)系統(tǒng)的應(yīng)用程序都是經(jīng)過數(shù)字證書簽名的，數(shù)字證書的私鑰則保存在程序開發(fā)者的手中。Android將數(shù)字證書用來標(biāo)識(shí)應(yīng)用程序的作者和在應(yīng)用程序之間建立信任關(guān)系，不是用來決定最終用戶可以安裝哪些應(yīng)用程序。

  這個(gè)數(shù)字證書并不需要權(quán)威的數(shù)字證書簽名機(jī)構(gòu)認(rèn)證(CA)，它只是用來讓應(yīng)用程序包自我認(rèn)證的。

• 2、數(shù)字證書的好處：
  同一個(gè)開發(fā)者的多個(gè)程序盡可能使用同一個(gè)數(shù)字證書，這可以帶來以下好處。

  • 有利于程序升級(jí)，當(dāng)新版程序和舊版程序的數(shù)字證書相同時(shí)，Android系統(tǒng)才會(huì)認(rèn)為這兩個(gè)程序是同一個(gè)程序的不同版本。如果新版程序和舊版程序的數(shù)字證書不相同，則Android系統(tǒng)認(rèn)為他們是不同的程序，并產(chǎn)生沖突，會(huì)要求新程序更改包名。

  • 有利于程序的模塊化設(shè)計(jì)和開發(fā)。Android系統(tǒng)允許擁有同一個(gè)數(shù)字簽名的程序運(yùn)行在一個(gè)進(jìn)程中，Android程序會(huì)將他們視為同一個(gè)程序。所以開發(fā)者可以將自己的程序分模塊開發(fā)，而用戶只需要在需要的時(shí)候下載適當(dāng)?shù)哪K。

• 3、在簽名時(shí)，需要考慮數(shù)字證書的有效期：

  • 數(shù)字證書的有效期要包含程序的預(yù)計(jì)生命周期，一旦數(shù)字證書失效，持有改數(shù)字證書的程序?qū)⒉荒苷Ｉ?jí)。
  • 如果多個(gè)程序使用同一個(gè)數(shù)字證書，則該數(shù)字證書的有效期要包含所有程序的預(yù)計(jì)生命周期。
  • Android Market強(qiáng)制要求所有應(yīng)用程序數(shù)字證書的有效期要持續(xù)到2033年10月22日以后。

• 4、Android數(shù)字證書包含以下幾個(gè)要點(diǎn)：

  • 所有的應(yīng)用程序都必須有數(shù)字證書，Android系統(tǒng)不會(huì)安裝一個(gè)沒有數(shù)字證書的應(yīng)用程序
  • Android程序包使用的數(shù)字證書可以是自簽名的，不需要一個(gè)權(quán)威的數(shù)字證書機(jī)構(gòu)簽名認(rèn)證
  • 如果要正式發(fā)布一個(gè)Android ，必須使用一個(gè)合適的私鑰生成的數(shù)字證書來給程序簽名，而不能使用adt插件或者ant工具生成的調(diào)試證書來發(fā)布。
  • 數(shù)字證書都是有有效期的，Android只是在應(yīng)用程序安裝的時(shí)候才會(huì)檢查證書的有效期。如果程序已經(jīng)安裝在系統(tǒng)中，即使證書過期也不會(huì)影響程序的正常功能。

二、Android下的架構(gòu)模式：

• 架構(gòu)：
  現(xiàn)在比較流行的項(xiàng)目架構(gòu)基本都是基于模型（M）和視圖（V）分離來說的，一般被定義為MVX的架構(gòu)模型。
  其中最為常見和應(yīng)用最廣的有三種：MVC、MVP、MVVM。還有最新的MVI架構(gòu)
  其中MVC是最早被提出的，MVP是MVC的變種。

1、MVC：Model-View-Controller

• 組成：
  Model：模型層，負(fù)責(zé)數(shù)據(jù)獲取，包含：網(wǎng)絡(luò)請求，數(shù)據(jù)庫處理，I/O操作等
  View：視圖層，對應(yīng)于 xml 布局文件和 java 代碼動(dòng)態(tài) view 部分
  Controller：控制層，主要負(fù)責(zé)業(yè)務(wù)邏輯，Activity既要負(fù)責(zé)視圖又要加入控制邏輯

• 流程：
  通過 View 接受指令，傳遞給 Controller
  然后對模型進(jìn)行修改或者查找底層數(shù)據(jù)
  最后把改動(dòng)渲染在視圖上

  
  
  示意圖

• 問題：
  Activity 同時(shí)負(fù)責(zé) View 與 Controller 層的工作，違背了單一職責(zé)原則
  Model 層與 View 層存在耦合，存在互相依賴，違背了最小知識(shí)原則

2、MVP：Model-View-Presenter

• 組成：
  Model：模型層，負(fù)責(zé)數(shù)據(jù)獲取，包含網(wǎng)絡(luò)請求，數(shù)據(jù)庫處理等操作
  View：視圖層，對應(yīng)于 Activity 與 XML，只負(fù)責(zé)顯示 UI，只與 Presenter 層交互，與Model層沒有耦合
  Persenter：控制層，負(fù)責(zé)處理業(yè)務(wù)邏輯，通過接口回調(diào) View 層，幾乎承擔(dān)所以邏輯

• 流程：
  View接收交互指令，將指令轉(zhuǎn)交給Presenter
  Presenter操作Model進(jìn)行數(shù)據(jù)的請求更新，
  Model更新后，通知Presenter數(shù)據(jù)變化
  Presenter將更新同步到View進(jìn)行顯示

  
  
  示意圖

• 優(yōu)點(diǎn)：
  Model與View完全分離，修改互不影響
  利用高效，方便重用和變更，所有邏輯都在Presenter
  更便于測試，可脫離用戶接口來測試邏輯

• 問題：
  Presenter 層通過接口與 View 通信，實(shí)際上持有了 View 的引用
  視圖和Presenter的交互會(huì)過于頻繁，使得他們的聯(lián)系過于緊密，View接口會(huì)過于龐大

3、MVVM：Model-View-ViewModel

• 組成：
  Model：模型層，負(fù)責(zé)數(shù)據(jù)獲取，包含網(wǎng)絡(luò)請求，數(shù)據(jù)庫處理等操作
  View：視圖層，對應(yīng)于 Activity 與 XML，只負(fù)責(zé)顯示 UI，與ViewModel層交互
  ViewModel：控制層，采用雙向數(shù)據(jù)綁定，主要通過 DataBinding 來實(shí)現(xiàn)

• 特點(diǎn)：
  分離視圖（View）和模型（Model），雙向綁定，數(shù)據(jù)驅(qū)動(dòng)視圖。
  和MVP基本一致，是將Presenter改名為ViewModel，區(qū)別是采用雙向綁定，View的變動(dòng)，自動(dòng)更新到ViewModel上。

• 流程：
  View接收交互指令，并將指令轉(zhuǎn)交給ViewModel
  ViewModel操作Model進(jìn)行數(shù)據(jù)更新
  Model更新后通知ViewModel數(shù)據(jù)發(fā)生變化
  ViewModel將更新同步到View進(jìn)行顯示

  
  
  示意圖

• 優(yōu)點(diǎn)：
  低耦合（View可以獨(dú)立于Model變化和修改）
  可重用（多view重用視圖邏輯）、獨(dú)立開發(fā)互不影響

• 問題：
  為保證對外暴露的 LiveData 是不可變的，需要添加不少模板代碼并且容易遺忘
  View 層與 ViewModel 層的交互比較分散零亂，不成體系

4、MVI：Model-View-Intent

• 組成：
  Model：模型層，主要之UI狀態(tài)（UI State）如頁面加載狀態(tài)，控件位置等都是UI狀態(tài)
  View：視圖層，對應(yīng)于 Activity 與 XML，負(fù)責(zé)顯示 UI；定于Intent的變化實(shí)現(xiàn)界面刷新
  Intent：非Android中的Intent組件，用戶操作邏輯包裝成Intent發(fā)送給Model層進(jìn)行數(shù)據(jù)請求

• 特點(diǎn)：
  單向數(shù)據(jù)流
  數(shù)據(jù)永遠(yuǎn)在一個(gè)環(huán)形結(jié)構(gòu)中單向流動(dòng)，不能反向流動(dòng)

• 流程：
  用戶操作以 Intent 的形式通知 Model
  Model 基于 Intent 更新 State
  View 接收到 State 變化刷新 UI

  
  
  示意圖

5、總結(jié)：

• 問題及區(qū)別：

• MVC 架構(gòu)的主要 問題 在于 Activity 承擔(dān)了 View 與 Controller 兩層的職責(zé)，同時(shí) View 層與 Model 層存在耦合
• MVP 引入 Presenter 層，解決了 MVC 架構(gòu)的兩個(gè)問題，View只能與 Presenter 層交互，業(yè)務(wù)邏輯放在 Presenter 層
  MVP 的問題 在于隨著業(yè)務(wù)邏輯的增加，View 的接口會(huì)很龐大
• MVVM 架構(gòu)中的ViewModel 相當(dāng)于MVP的Presenter和MVC的Controller，
  View和ViewModel間沒有了MVP的界面接口，而是直接交互，通過數(shù)據(jù)綁定（可認(rèn)為是Observer 模式或者是 Publish/Subscribe 模式，原理都是為了用一種統(tǒng)一的集中的方式實(shí)現(xiàn) 頻繁 需要被實(shí)現(xiàn)的數(shù)據(jù) 更新 問題。）自動(dòng)雙向同步（自動(dòng)更新到UI上），解決MVP的問題，MVVM 更像是自動(dòng)化的 MVP
  MVVM 的雙向數(shù)據(jù)綁定主要通過 DataBinding 實(shí)現(xiàn)，但如果不用 DataBinding，而是 View 通過 LiveData 等觀察 ViewModle 的數(shù)據(jù)變化并自我更新，這其實(shí)是單一數(shù)據(jù)源而不是雙向數(shù)據(jù)綁定。
• MVI 搶到數(shù)據(jù)的 單向流動(dòng) 和 唯一數(shù)據(jù)源。和MVVM很相似
  主要是為了減少模板代碼，以及 View和ViewModel交互的分散問題。

• 個(gè)人理解：

架構(gòu)都是圍繞MV即 Model 和 View 來說的，如何更好的處理兩者的交互和通信，才出現(xiàn)的各種架構(gòu)模型，基于Android中視圖層（基本是Activity和Fragment）的生命周期在各種場景下的復(fù)雜度，處理好M和V兩者的關(guān)系，就需要根據(jù)不同的項(xiàng)目來制定不同的架構(gòu)模型了。
關(guān)注的原則就在于：
1、分離關(guān)注點(diǎn)，也可以理解為職責(zé)單一，避免和Activity或Fragment的依賴。
2、數(shù)據(jù)模型驅(qū)動(dòng)頁面，最好是持久性模型，數(shù)據(jù)應(yīng)獨(dú)立于應(yīng)用中的界面元素和組件，和生命周期無關(guān)聯(lián)。最好可以在應(yīng)用釋放資源后，數(shù)據(jù)不丟失；網(wǎng)絡(luò)不可用時(shí)，可進(jìn)行工作。

參考鏈接：
應(yīng)用架構(gòu)指南
Google 推薦使用 MVI 架構(gòu)？卷起來了~
MVVM 進(jìn)階版：MVI 架構(gòu)了解一下~
MVI 架構(gòu)封裝：快速優(yōu)雅地實(shí)現(xiàn)網(wǎng)絡(luò)請求
MVI 架構(gòu)更佳實(shí)踐：支持 LiveData 屬性監(jiān)聽