Android Camera 流程學習記錄（零）—— 碎碎念以及 Android 框架初識

碎碎念

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

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 框架。
  • 框架是應用程序的核心，也是開發者須要共同遵照的一個約定，你們能夠在這個約定的基礎之上進行一些必要的擴展，可是主體結構須要保持一致。
  • 框架層提供了大量的接口，當須要使用到某些接口的時候，能夠去看看它對應的官方文檔： 
    • Package Index

---

• 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 的大致框架好了。