碎碎念

到公司入職了快兩個月了。前一個月全是在公共培訓，其中有半個月還到某個子公司（手機生產工廠）去實習，體驗了生產最前線人民的日常生活……

8 月開始才正式分配到軟體中心的工位上，然後又開始了新一輪的內部培訓，培訓的內容大概就是一些 Git 的使用，軟體測試那邊的一些知識，還有缺陷跟蹤系統比如 JIRA 的使用規範等等。這裡值得吐槽一下的就是這些操作性的東西居然還要背下來考試……考試完了以後，我們新來的又被放養了幾天，然後才分到了具體的小組來。

而我分到了影像部，就是專門做 Android Camera 這方面專案的部門，具體的組是其中的框架組。於是從未接觸 Android 方面知識的我便開始了漫長的 Android 開發學習之旅……

根據導師所介紹，小組的主要業務關注的是 Android Camera 架構中的 Frameworks 層。其實當時我是蒙比的，因為沒看過 Android 系統的結構。於是導師讓我先花點時間把 Android System 架構瞭解瞭解，然後再去熟悉 Camera 的整個流程。

花了大概一個多星期的時間，我才對 Camera 的整個控制流以及資料流有了一個比較清晰的瞭解。由於業務上的需要，我現在所瞭解的主要是 Camera API 1 的主要流程，而 API 2 最近也開始擴大使用的範圍了，所以在整理好 API 1 的內容後，我還會繼續跟進學習並整理 API 2 的內容。

Android 基本框架

在學習 Camera 框架之前，最基本的知識點應該就是 Android 的基本框架了。

這方面的內容我主要參考學習了這些文章：
Android 系統四層體系結構詳解
Android 平臺架構
以及參考了《Android 系統原始碼情景分析（修訂版）》的內容。
當然還有其它零零散散的一些文章，不過內容大同小異。

首先有一個很經典的架構圖：

在我看的每一篇關於 Android 系統架構介紹的文章中，都少不了這張圖，或者這張圖的變種。

從圖中可以很清楚得看出，整個架構可以分為五大層次：

1. System Apps：即系統應用層，這一層中都是我們使用手機時都會直接接觸到的各種應用。
2. Java API Framework：即 Java 介面框架層，這一層是為了上層應用提供各種介面。
3. Native C/C++ Libraries && Android Runtime：分別是原生 C/C++ 庫，安卓執行時環境。這一層中，C/C++ 庫集成了許多諸如 OpenGL ES 這樣的開源庫，提供了很多封裝好的方法。而執行時環境則是與一些核心庫、Dalvik Virtual Machine 相關的東西，這方面暫時還沒多少了解。
4. HAL（Hardware Abstract Layer）：這是一個硬體抽象層，它主要是在 Framework 層和 Linux Kernel 層之間起到一個連結作用。
5. Linux Kernel：即 Linux 核心層，整個 Android 系統實際上是基於 Linux 的核心搭建起來的。

• 系統應用層
  
  • 它包含了一系列使用 Java 編寫的核心程式包（Home，Phone，Browser...）。
  • 應用程式通過呼叫框架層的介面，或者 JNI （Java 原生介面）來完成自己的業務邏輯。
  • 值得注意的是，要使用 JNI 開發原生應用程式，需要與 Android NDK 配合，NDK 使得 Java 可以與 C/C++ 進行互動。

• Java 介面框架層
  
  • 也有人稱為應用程式框架層，實際上這一層主要是提供給上層應用一些訪問核心功能的 API 框架。
  • 框架是應用程式的核心，也是開發者需要共同遵守的一個約定，大家可以在這個約定的基礎之上進行一些必要的擴充套件，但是主體結構需要保持一致。
  • 框架層提供了大量的介面，當需要使用到某些介面的時候，可以去看看它對應的官方文件：
    

• C/C++ 庫 && Android 執行時環境
  
  • 官方 API 不是萬能的，開發者常常需要自己一些 API 以實現自己的業務邏輯，這時候我們就可以通過呼叫 C/C++ 本地庫的介面來進行個性化設計。
  • 需要注意的是，這些 C/C++ 庫（第三方庫）是獨立於 Android 系統架構實現的，但是它與系統架構處於相同的地位：
    
    • 他們都使用 Linux 核心層提供服務，實現、封裝模組，以供應用層呼叫。
  • 執行時環境提供了一些核心連結庫。
  • 以及 Dalvik 虛擬機器：
    
    • DVM 代替了 JVM，“.java”檔案編譯為“.class”檔案後，再編譯得到“.dex”程式，最後又打包成為 Android 可執行檔案“.apk”。
    • 每個應用都執行在自己的程序上（一個應用程式對應一個虛擬機器，一一對應關係），而 DVM 為它分配自有例項。
    • Dalvik 的好處是，使得一臺裝置可以執行多個虛擬機器程式，並且消耗比較少的資源。

• 硬體抽象層
  
  • 向下遮蔽了硬體驅動模組的實現細節，並向上提供硬體訪問服務。
  • 這一層的存在，實際上主要是為了保護移動裝置廠商的商業利益：
    
    • Linux 核心原始碼遵循 GPL 協議，基於它所修改的原始碼需要完全公開，如果裝置廠商通過修改核心原始碼來提供服務，就需要公開對應的程式碼，這就暴露了很多硬體相關的引數和實現的細節。
    • 為了保證商業利益，在 Android 架構中提供一個硬體抽象層給裝置廠商對硬體做出具體實現，而 Linux 核心僅提供簡單的硬體訪問通道。由於 Android 原始碼遵循商業友好的Apache License 協議，這樣裝置廠商的利益就得到了保障。

• Linux 核心層
  
  • Android 是基於 Linux 核心開發的（官方給出的例子是，Android Runtime (ART) 依靠 Linux 核心來執行底層功能，例如執行緒和底層記憶體管理）。
  • 一個很重要的部分是 Linux 核心驅動部分，在 Camera 流程中，我們的控制指令最終要通過核心驅動傳送給 Camera 裝置，同時也要通過它對裝置返回的資料向上傳輸。
  • 在 Android 中，增加了 YAFFS2（Yet Another Flash File System, 2nd edition）檔案系統。（這個系統沒有去深入瞭解）
  • 增加了一個程序間通訊的機制 IPC Binder，通過 Binder ，可以使不同程序可以訪問同一塊共享記憶體。Binder 機制在整個 Camera 流程中起到了十分重要的作用，它主要使用在 CameraClient 與 CameraServer 的互動中（Camera 架構中，採用了一個 C/S 互動的流程，在之後的學習中會有比較深入的瞭解）。

小結

到這裡，我對 Android 框架就有了一個基本的認識。

從下到上，實際上是一個逐層封裝的過程。在以往的開發中，我所接觸到的往往都是上層的介面，實際上它們的內部有許多複雜的實現機制我並沒有去探究過，正所謂“知其然，而不知其所以然”，這也許是我的實際開發能力總是無法有突破性的進步的原因之一。

通過一個多星期對原始碼的追溯學習，我開始嘗試去探索學習從上層到底層的實現機制。當然這個過程還是挺痛苦的，Android 的原始碼雖然有大量清楚的註釋，但是突然去閱讀大量具有關聯性的程式碼，時常還是會迷失方向，特別是在 C/C++ 的部分，各種函式指標經常不知道指到哪裡去了，找了半天找不到，還把之前的一部分內容跟丟了……

廢話說得有點多了…下一篇就先整理一下 Camera 的大體框架好了。