Android系統架構、基礎元件、JVM&DVM&ART、安全機制、SP
Android 系統架構
Android 是一個完整的作業系統，包含中介軟體和一些關建的應用程式
Android 有四層架構，五塊區域. 其中架構層自上至下依次為
應用層 Application
應用框架層 Application Framework
函式庫 Library
Linux 核心
下面依次簡介各層及區域
層級/區域 簡介 Linux Kernel Android 系統是基於 Linux2.6 核心修改而來，此層大多都是操作相關的硬體驅動 Libraries 由 C/C++ 編寫的完成 Android 核心功能的相關類庫 Application Framework 由 Java 語言編寫，包含供開發人員呼叫的各種 API Applications 日常安裝的所有應用程式都屬於該層 Android Runtime 安卓執行時環境 Core Libraries 核心類庫 Dalvik Virtual Machine Android 底層都是 Linux 系統，使用 C、C++ 語言編寫的，所以 Android 程式要在 Linux 上執行就需要虛擬機器，即 DVM，其針對手機記憶體、CPU 效能有限等情況做了優化處理 一個小例子介紹 Android 工作流程
- 鬧鐘應用實際上就是定時播放音樂
- 鬧鐘應用呼叫 Application Framework 層的 MediaPlayer
- MediaPlayer 訪問 Libraries 層中的 Media Framework
- Media Framework 再使用C語言操作 Linux Kernel 層的 Audio Drivers 去播放音樂
Android 提供了哪些東西
四大元件
Activity - 介面
Service - 服務
BroadcastReceiver - 廣播接收者
ContentProvider - 內容提供者
豐富的系統控制元件
RelativeLayout - 相對佈局
LinearLayout - 線性佈局
EditText - 編輯文字框
WebView - 網頁控制元件
……
SQLite 資料庫
定位：GPS(Android 自帶)、LBS(基於位置服務-網路)……
多媒體：視訊、音訊、錄音、拍照、鬧鈴……
感測器：光線、重力、陀螺儀、指紋、3D TOUCH……
簡單基本元件介紹
View：所有 UI 控制元件、容器控制元件的基類，View 元件就是 Android 應用中使用者實實在在看到的部分
Activity：負責顯示介面並與使用者互動
Service：通常位於後臺執行，一般不需要與使用者互動，因此 Service 元件沒有圖形使用者介面
BroadcastReceiver：監聽器，其監聽的事件源是 Android 應用中的其他元件
ContentProvider：一個應用使用 ContentProvider 暴露自己的資料，另一個應用程式通過 ContentResolver 來訪問資料
Intent 和 IntentFilter：Activity、Service、BroadcastReceiver 三種元件之間的通訊載體
Eclipse-ADT 的專案結構
JVM 和 DVM 的區別[->ART-Android Runtime(4.4引進，5.0取代 DVM)]
JVM(Java Virtual Machine) DVM(Dalvik Virtual Machine) JVM 基於堆疊 DVM 基於暫存器 通過 Zygote 預載入類完成虛擬機器的啟動 執行 java 位元組碼 執行 dex 位元組碼(減少了 class 檔案中的冗餘資訊，DX 工具整合所有 class 檔案到一個檔案以提高效能，最後將資原始檔和 dex 檔案等打包成 apk 安裝包) 每個 class 檔案都有一個 Header(儲存了 class 檔案的初始資訊) apk 檔案中的 dex 檔案只有一個 Header，所有 class 檔案的初始化資訊都儲存在其中，效率更高 有218個機器指令 有200個機器指令(使用等長的指令，提高解析速度) 每個類中都有一個常量池 只有一個統一的常量池(打包慢，讀取快) Dalvik 虛擬機器主要是完成物件生命週期、堆疊、執行緒、安全和異常的管理，以及垃圾回收等重要功能
Dalvik 虛擬機器適用於記憶體容量和資料處理能力較小的機器(移動終端)
Dalvik 虛擬機器一般包含暫存器地址，所以指令比 java 更長
Dalvik 虛擬機器負責程序隔離和執行緒管理，每一個 Android 應用在底層都會對應一個獨立的 Dalvik 虛擬機器例項，其程式碼在虛擬機器的解釋下得以執行
不同於 Java 虛擬機器執行 java 位元組碼，Dalvik 虛擬機器執行的是其專有的檔案格式 Dex
dex 檔案格式可以減少整體檔案尺寸，提高 I/O 操作的類查詢速度
odex 是為了在執行過程中進一步提高效能，對 dex 檔案的進一步優化
所有的 Android 應用的執行緒都對應一個 Linux 執行緒，虛擬機器因而可以更多的依賴作業系統的執行緒排程和管理機制
有一個特殊的虛擬機器程序 Zygote，他是虛擬機器例項的孵化器.它在系統啟動的時候就會產生，它會完成虛擬機器的初始化，庫的載入，預製類庫和初始化的操作.如果系統需要一個新的虛擬機器例項，它會迅速複製自身，以最快的資料提供給系統.對於一些只讀的系統庫，所有虛擬機器例項都和 Zygote 共享一塊記憶體區域
DVM 和 ART 虛擬機器的區別
DVM：應用程式每次執行，位元組碼都需通過即時編譯器轉換為機器碼(C 指令)，拖慢速度
ART(Android runtime)：應用程式第一次安裝時，位元組碼預先編譯成機器碼(Java 語言翻譯成 C 指令)，使其成為真正的本地應用，其啟動、執行速度明顯提升. 弊端即 ART 需要儲存 Java 和 C 兩份指令，消耗記憶體
Android 的安全機制
Android 是基於 Linux 核心的，因此 Linux 對檔案許可權的控制同樣適用於 Android. 在 Android 中每個應用都有自己的 /data/data/包名資料夾，該資料夾只能該應用訪問，而其他應用則無權訪問
Android 的許可權機制保護了使用者的合法權益. 如果我們的程式碼想撥打電話、傳送簡訊、訪問通訊錄、定位、訪問 sdcard 等所有可能侵犯用於權益的行為都是必須要在 AndroidManifest.xml 中進行宣告的，這樣就給了使用者一個知情權
Android 的程式碼混淆保護了開發者的勞動成果
Android 的四大元件都需要在清單檔案中註冊嗎
Activity 、Service 、ContentProvider 如果要使用則必須在 AndroidManifest.xml 中進行註冊，而 BroadcastReceiver 則有兩種註冊方式，靜態註冊和動態註冊. 其中靜態註冊就是指在 AndroidManifest.xml 中進行註冊，而動態註冊時通過程式碼註冊
在Android 中程序的級別
- Foreground process - 前臺程序
- Visible process - 可見程序
- Service process - 服務程序
- Background process - 後臺程序
- Empty process - 空程序
sp 頻繁操作有什麼後果？sp 能存多少資料？
sp 的底層是由 xml 來實現的，操作 sp 的過程就是xml 的序列化和解析的過程. xml 是儲存在磁碟上的，因此考慮到需要 I/O 速度問題，sp 不適宜頻繁操作. 同時序列化 xml 是就是將記憶體中的資料寫到xml 檔案中，由於 dvm 的記憶體是很有限的，因此單個 sp 檔案不建議太大，具體多大是沒有具體要求，但是 DVM 堆記憶體也就 16M，因此資料大小肯定不能超過這個數字.
其實 sp 設定的目的就是為了儲存使用者的偏好和配置資訊的，因此不要儲存太多的資料