上一篇文章，在解析初始化GraphicBuffer中，遇到一個ion驅動，對圖元進行管理。首先看看ion是怎麼使用的：
我們按照這個流程分析ion的源碼。
如果對ion使用感興趣，可以去這篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744
本文基於Android的linux內核版本3.1.8
遇到什麼問題歡迎來本文討論 https://www.jianshu.com/p/5fe57566691f
什麼是ion？如果是音視頻，Camera的工程師會對這個驅動比較熟悉。最早的GPU和其他驅動協作申請一塊內存進行繪制是使用比較粗暴的共享內存。在Android系統中使用的是匿名內存。最早由三星實現了一個Display和Camera共享內存的問題，曾經在Linux社區掀起過一段時間。之後各路大牛不斷的改進之下，就成為了dma_buf驅動。並在 Linux-3.3 主線版本合入主線。現在已經廣泛的運用到各大多媒體開發中。
首先介紹dma_buf的2個角色，importer和exporter。importer是dma_buf驅動中的圖元消費者，exporter是dma_buf驅動中的圖元生產者。
這里借用大佬的圖片：
ion是基於dma_buf設計完成的。經過閱讀源碼，其實不少思路和Android的匿名內存有點相似。閱讀本文之前就算不知道dma_buf的設計思想也沒關系，我不會仔細到每一行，我會注重其在gralloc服務中的申請流程，看看ion是如何管理共享內存，為什麼要拋棄ashmem。
我們先來看看ion的file_operation:
只有一個open和ioctl函數。但是沒有mmap映射。因此mmap映射的時候一定其他對象在工作。
我們關注顯卡英偉達的初始化模塊。
文件：/ drivers / staging / android / ion / tegra / tegra_ion.c
mole_platform_driver實際上就是我之前經常提到過的mole_init的一個宏,多了一個register注冊到對應名字的平台中的步驟。在這裡面注冊了一個probe方法指針，probe指向的tegra_ion_probe是載入內核模塊注冊的時候調用。
先來看看對應的結構體：
再來看看對應ion內的堆結構體：
完成的事情如下幾個步驟：
我們不關注debug模式。其實整個就是我們分析了很多次的方法。把這個對象注冊miscdevice中。等到insmod就會把整個整個內核模塊從dev_t的map中關聯出來。
我們來看看這個驅動結構體：
文件：/ drivers / staging / android / ion / ion_heap.c
這里有四個不同堆會申請出來，我們主要來看看默認的ION_HEAP_TYPE_SYSTEM對應的heap流程。
其實真正象徵ion的內存堆是下面這個結構體
不管原來的那個heap，會新建3個ion_system_heap，分別order為8，4，0,大於4為大內存。意思就是這個heap中持有一個ion_page_pool 頁資源池子，裡面只有對應order的2的次冪，內存塊。其實就和夥伴系統有點相似。
還會設置flag為ION_HEAP_FLAG_DEFER_FREE，這個標志位後面會用到。
文件：/ drivers / staging / android / ion / ion_page_pool.c
在pool中分為2個鏈表一個是high_items，另一個是low_items。他們之間的區分在此時就是以2為底4的次冪為分界線。
文件：/ drivers / staging / android / ion / ion.c
因為打開了標志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此會初始化兩個回收函數。
文件：/ drivers / staging / android / ion / ion_heap.c
此時會創建一個內核線程，調用ion_heap_deferred_free內核不斷的循環處理。不過由於這個線程設置的是SCHED_IDLE，這是最低等級的時間片輪轉搶占。和Handler那個adle一樣的處理規則，就是閑時處理。
在這個循環中，不斷的循環銷毀處理heap的free_list裡面已經沒有用的ion_buffer緩沖對象。
文件：/ drivers / staging / android / ion / ion_system_heap.c
注冊了heap的銷毀內存的方法。當系統需要銷毀頁的時候，就會調用通過register_shrinker注冊進來的函數。
文件：/ drivers / staging / android / ion / ion_page_pool.c
整個流程很簡單，其實就是遍歷循環需要銷毀的頁面數量，接著如果是8的次冪就是移除high_items中的page緩存。4和0則銷毀low_items中的page緩存。至於為什麼是2的次冪其實很簡單，為了銷毀和申請簡單。__free_pages能夠整頁的銷毀。
文件：/ drivers / staging / android / ion / ion.c
主要就是初始化ion_client各個參數，最後把ion_client插入到ion_device的clients。來看看ion_client結構體：
核心還是調用ion_alloc申請一個ion緩沖區的句柄。最後把數據拷貝會用戶空間。
這個實際上就是找到最小能承載的大小，去申請內存。如果8kb申請內存，就會拆分積分在0-4kb，4kb-16kb，16kb-128kb區間找。剛好dma也是在128kb之內才能申請。超過這個數字就禁止申請。8kb就會拆成2個4kb保存在第一個pool中。
最後所有的申請的page都添加到pages集合中。
文件：/ drivers / staging / android / ion / ion_page_pool.c
能看到此時會從 ion_page_pool沖取出對應大小區域的空閑頁返回上層，如果最早的時候沒有則會調用ion_page_pool_alloc_pages申請一個新的page。由於引用最終來自ion_page_pool中，因此之後申請之後還是在ion_page_pool中。
這里的處理就是為了避免DMA直接內存造成的緩存差異(一般的申請，默認會帶一個DMA標志位)。換句話說，是否打開cache其實就是，關閉了則使用pool的cache，打開了則不使用pool緩存，只依賴DMA的緩存。
我們可以看另一個dma的heap，它是怎麼做到dma內存的一致性.
文件： drivers / staging / android / ion / ion_cma_heap.c
能看到它為了能辦到dma緩存的一致性，使用了dma_alloc_coherent創建了一個所有強制同步的地址，也就是沒有DMA緩存的地址。
這里出現了幾個新的結構體，sg_table和scatterlist
文件：/ lib / scatterlist.c
這裡面實際上做的事情就是一件：初始化sg_table.
sg_table中有一個核心的對象scatterlist鏈表。如果pages申請的對象數量<PAGE_SIZE/sizeof(scatterlist),每一項sg_table只有一個scatterlist。但是超出這個數字就會增加一個scatterlist。
用公式來說：
換句話說，每一次生成scatterlist的鏈表就會直接盡可能占滿一頁，讓內存更好管理。
返回了sg_table。
初始化ion_handle，並且記錄對應的ion_client是當前打開文件的進程，並且設置ion_buffer到handle中。使得句柄能夠和buffer關聯起來。
每當ion_buffer需要銷毀，
㈡ Android跨進程通信-mmap函數
通過mmap或者內存共享的Linux IPC機制
直接世猛將同一段內存映射到數據發送進程和數據接收進程的用戶空間，這樣數據發送進程只需要將數據拷貝到共享的內存區域，數據接收進程就可以直接使用數據了。
mmap是一個很重要的函數，它可以實現共享內存，但並不像SystemV和Posix的共享內存存粹的只用於共享內存，橋返飢mmap()的設計，主要是用來做文件的映射的，它提供了我們一種新的訪問文件的方案。
mmap函數的使用非常簡單，我們來看一下
常規文件操作為了提高讀寫效率和保護磁碟，使用了 頁緩存機制 ，這種機制會造成讀文件時需要先將文件頁從磁碟拷貝到頁緩存中，由於 頁緩存處在內核空間 ，不能被用戶進程直接定址，所以還需要 將頁緩存中數據頁再次拷貝到內存 對應的用戶空間中。
常規文件操作為了提高讀寫效率和保護磁碟，使用了頁緩存機制，這種機制會造成讀文件時需要先將文件頁從磁碟拷貝到頁緩存中，由於頁緩存處在內核空間，不能被用戶進程直接定址，所以還需要將頁緩存中數據頁再次拷貝到內存對應的用戶空間中。
而 使用mmap操作文件中，由於不需要經過內核空間的數據緩存，只使用一次數據拷貝，就從磁碟中將數據傳入內存的用戶空間中，供進程使用 。
mmap的關鍵點是實現了用戶空間和內核空間的數據直接交互而省去了空間不同數據不通的繁瑣過程，因此mmap效率很高。
mmap()使用非常頻繁，看過Android系統源碼的人，肯定看到過大量的地方使用mmap()函數，比如上面提到的 匿名共享內存的使用就使用到了mmap來映射/dev/ashmem里的文件 。
這里我再介紹一種mmap()在Android系統上的使用場景， mmap的設計目的就是為了讓文件的訪問更有效率 ，所以當APK進行安裝時，為了更高效的讀取APK包裡面的文件，同樣也用到了mmap函數。
Dalvik在安裝應敏返用時，需要載入dex文件，然後進行odex優化處理，優化函數為dvmContinueOptimization，我們看一下他的大致實現。
可以看到，dvmContinueOptimization函數中對dex文件的載入便用了mmap內存映射函數。
㈢ android匿名共享內存兩個進程間必須知道文件描述符嗎
在Android 匿名共享內存驅動源鏈渣配碼分析中詳細分析了匿名共享內存在Linux內核空間的實現，雖然內核空間實現了匿名共享內存，但仍然需要在用戶空間為用戶使用匿名共享內存提供訪問介面。Android系統在用戶空間，C++應用程序框架層，java層分別提供了訪問介面
本文首先介紹匿名共享內存在用戶空間提供的C語言介面，在後續文章中在介紹Android匿名共享內存的C++及Java介面，從而全面理解並掌握Android匿名共享內存的使用。
1）匿名共享內存的創建
system\core\libcutils\ashmem-dev.c
Java代碼 收藏代碼
int ashmem_create_region(const char *name, size_t size)
{
int fd, ret;
//打開"/dev/ashmem"設備文件
fd = open(ASHMEM_DEVICE, O_RDWR);
if (fd < 0)
return fd;
//根據Java空間傳過來的名稱修改設備文件名
if (name) {
char buf[ASHMEM_NAME_LEN];
strlcpy(buf, name, sizeof(buf));
//進入匿名共享內存驅梁判動修改匿名共享內存名稱
ret = ioctl(fd, ASHMEM_SET_NAME, buf);
if (ret < 0)
goto error;
}
////進入匿名共享內存驅動修改匿名共享內存大小
ret = ioctl(fd, ASHMEM_SET_SIZE, size);
if (ret < 0)
goto error;
return fd;
error:
close(fd);
return ret;
}
ASHMEM_DEVICE的宏定義如下：
Java代碼 收藏代碼
#define ASHMEM_DEVICE "/dev/ashmem"
函數ashmem_create_region首先通過open函數進入匿名共享內存驅動打開/dev/ashmem設備文件，打開過程在Android 匿名共享內存驅動源碼分析中已經詳細分析了，就是在匿名共享內棚指存初始化過程創建的slab緩沖區ashmem_area_cachep中創建並初始化一個ashmem_area結構體了，接著通過IO命令來修改該ashmem_area結構體的成員name和size，具體設置過程請查看Android 匿名共享內存驅動源碼分析。匿名共享內存的創建過程可以歸納為以下三個步驟：
1.打開/dev/ashmem設備文件;
2. 修改匿名共享內存名稱
3. 修改匿名共享內存大小
2）設置匿名共享內存屬性
通過Ioctl命令控制系統調用進入內核空間的匿名共享內存驅動來設置匿名共享內存塊的屬性值，比如設置匿名共享內存塊的鎖定與解鎖，設置匿名共享內存塊的大小，名稱，保護位等屬性信息。Android對匿名共享內存的這些屬性訪問也提供了相應的C語言介面：
1. 設置匿名共享內存的保護位
Java代碼 收藏代碼
int ashmem_set_prot_region(int fd, int prot)
{
return ioctl(fd, ASHMEM_SET_PROT_MASK, prot);
}
2.鎖定匿名共享內存塊
Java代碼 收藏代碼
int ashmem_pin_region(int fd, size_t offset, size_t len)
{
struct ashmem_pin pin = { offset, len };
return ioctl(fd, ASHMEM_PIN, &pin);
}
3.解鎖指定匿名共享內存塊
Java代碼 收藏代碼
int ashmem_unpin_region(int fd, size_t offset, size_t len)
{
struct ashmem_pin pin = { offset, len };
return ioctl(fd, ASHMEM_UNPIN, &pin);
}
4.獲取創建的匿名共享內存大小
Java代碼 收藏代碼
int ashmem_get_size_region(int fd)
{
return ioctl(fd, ASHMEM_GET_SIZE, NULL);
}
無論是匿名共享內存的屬性設置還是獲取，都是直接使用ioctl系統調用進入匿名共享內存驅動中實現的，關於匿名共享內存驅動是如何實現這些功能的，在Android 匿名共享內存驅動源碼分析中有詳細的介紹，這里就不重復介紹了。這里我們知道Android提供的匿名共享內存C語言介面比較簡單。了解了匿名共享內存的C語言介面之後也為以後學習匿名共享內存的C++介面提供基礎。
㈣ 如何寫一個Android USB介面驅動
說到 android 驅動是離不開 Linux 驅動的。Android 內核採用的是 Linux2.6 內核 （最近Linux 3.3 已經包含了一些 Android 代碼）。但 Android 並沒有完全照搬 Linux 系統內核，除了對Linux 進行部分修正，還增加了不少內容。android 驅動 主要分兩種類型：Android 專用驅動 和 Android 使用的設備驅動（linux）。
Android 專有驅動程序：
1）Android Ashmem 匿名共享內存； 為用戶空間程序提供分配內存的機制，為進程間提供大塊共享內存，同時為內核提供回收和管理這個內存。
2）Android Logger 輕量級的LOG（日誌） 驅動；
3）Android Binder 基於 OpenBinder 框架的一個驅動；
4）Android Power Management 電源管理模塊；
5）Low Memory Killer 低內存管理器；
6）Android PMEM 物理內存驅動；
7）USB Gadget USB 驅動（基於 gaeget 框架）；
8）Ram Console 用於調試寫入日誌信息的設備；
9）Time Device 定時控制設備；
10）Android Alarm 硬體時鍾；
Android 上的設備驅動：
1）Framebuff 顯示驅動；
2）Event 輸入設備驅動；
3）ALSA 音頻驅動；
4）OSS 音頻驅動；
5）v412攝像頭：視頻驅動；
6）MTD 驅動；
7）藍牙驅動；
8）WLAN 設備驅動；
Android 專有驅動程序
1.Android Ashmem
為用戶空間程序提供分配內存的機制，為進程間提供大塊共享內存，同時為內核提供回收和管理這個內存。
設備節點：/dev/ashmen .主設備號 10.
源碼位置： include/linux/ashmen.h Kernel /mm/ashmen.c
相比於 malloc 和 anonymous/named mmap 等傳統的內存分配機制，其優勢是通過內核驅動提供了輔助內核的內存回收演算法機制（pin/unoin）
2.Android Logger
無論是底層的源代碼還上層的應用，我們都可以使用 logger 這個日誌設備看、來進行調試。
設備節點： /dev/log/main /dev/log/event /dev/log/radio
源碼位置：include/linux/logger.h include/linux/logger.c
3.Android Binder
IPC Binder 一種進程間通信機制。他的進程能夠為其它進程提供服務 ----- 通過標準的 Linux 系統調用 API。
設備節點 ：/dev/binder
源碼位置：Kernel/include/linux/binder.h Kernel/drivers/misc/binder.c
4.Android Power Management
一個基於標准 linux 電源管理的輕量級 Android 電源管理系統，在 drivers/android/power.c kernel/power/
5.Low Memory Killer
它在用戶空間中指定了一組內存臨界值，當其中某個值與進程描述中的 oom_adj 值在同一范圍時，該進程將被Kill掉（在parameters/adj中指定oome_adj 的最小值）。它與標準的Linux OOM機制類似，只是實現方法不同
源碼位置：drivers/misc/lowmemorykiller.c
6.Android PMEM
PMEM 主要作用就是向用戶空間提供連續的物理內存區域。
1.讓 GPU 或 VPU 緩沖區共享 CPU 核心。
2.用於 Android service 堆。
源碼位置：include/linux/android_pmem.h drivers/android/pmem.c
7.USB Gadget
基於標准 Linux USB gaeget 驅動框架的設備驅動。
源碼位置：drivers/usb/gadet/
8.Ram Console
為了提供調試功能，android 允許將調試日誌信息寫入這個設備，它是基於 RAM 的 buffer.
源碼位置： drivers/staging/android/ram_console.c
9.Time Device
定時控制,提供了對設備進行定時控制的功能。
源碼位置：drivers/staging/android/timed_output.c(timed_gpio.c)
10.Android Alarm
提供一個定時器，用於把設備從睡眠狀態喚醒，同時它還提供了一個即使在設備睡眠時也會運行的時鍾基準。
設備節點：/dev/alarm
源碼位置：drivers/trc/alarm.c
Android 設備驅動
1. Framebuffer 幀緩存設備
Framebuffer 驅動在 Linux 中是標準的顯示設備的驅動。對於 PC 系統，它是顯卡的驅動 ； 對於嵌入式 SOC 處理器系統，它是 LCD 控制器或者其他顯示控制器的驅動。它是一個字元設備，在文件系統中設備節點通常是 /dev/fbx 。 每個系統可以有多個顯示設備 ， 依次用 /dev/fbO 、 /dev/fb l
等來表示。在 Android 系統中主設備號為 29 ，次設備號遞增生成。
Android 對 Framebuffer 驅動的使用方式是標準的 ， 在 / dev / graphie / 中的 Framebuffer 設備節點由 init 進程自動創建 ， 被 libui 庫調用 。 Android 的 GUI 系統中 ， 通過調用 Framebuffer 驅動的標准介面，實現顯示設備的抽象。
Framebuff的結構框架和實現 ：
linux LCD驅動（二）--FrameBuffer
Linux LCD驅動(四）--驅動的實現
2.Event輸入設備驅動
Input 驅動程序是 Linux 輸入設備的驅動程序 ， 分為游戲桿 (joystick) 、 滑鼠 (mouse 和 mice)和事件設備 (Event queue)3 種驅動程序。其中事件驅動程序是目前通用的程序，可支持鍵盤 、 滑鼠、觸摸屏等多種輸入設備。 Input 驅動程序的主設備號是 l3 ，每一種 Input 設備從設備號占 用5 位 ， 3 種從設備號分配是 ： 游戲桿 0 ～ 61 ； Mouse 滑鼠 33 ～ 62 ； Mice 滑鼠 63 ； 事件設備 64 ～ 95 ，各個具體的設備在 misc 、 touchscreen 、 keyboard 等目錄中。
Event 設備在用戶空問使用 read 、 ioctl 、 poll 等文件系統的介面操作， read 用於讀取輸入信息， ioctl 用於獲取和設置信息， poll 用於用戶空間的阻塞，當內核有按鍵等中斷時，通過在中斷中喚醒內核的 poll 實現。
Event 輸入驅動的架構和實現：
Linux設備驅動之——input子系統
3.ALSA音頻驅動
高級 Linux 聲音體系 ALSA(Advanced Linux Sound Architecture ) 是為音頻系統提供驅動 的Linux 內核組件，以替代原先的開發聲音系統 OSS 。它是一個完全開放源代碼的音頻驅動程序集 ，除了像 OSS 那樣提供一組內核驅動程序模塊之外 ， ALSA 還專門為簡化應用程序的編寫提供相應的函數庫，與 OSS 提供的基於 ioctl 等原始編程介面相比， ALSA 函數庫使用起來要更加方便一些
利用該函數庫，開發人員可以方便、快捷地開發出自己的應用程序，細節則留給函數庫進行內部處理 。 所以雖然 ALSA 也提供了類似於 OSS 的系統介面 ， 但建議應用程序開發者使用音頻函數庫，而不是直接調用驅動函數。
ALSA 驅動的主設備號為 116 ，次設備號由各個設備單獨定義，主要的設備節點如下：
/ dev / snd / contmlCX —— 主控制 ；
/ dev / snd / pcmXXXc —— PCM 數據通道 ；
/ dev / snd / seq —— 順序器；
/ dev / snd / timer —— 定義器。
在用戶空問中 ， ALSA 驅動通常配合 ALsA 庫使用 ， 庫通過 ioctl 等介面調用 ALSA 驅動程序的設備節點。對於 AIJSA 驅動的調用，調用的是用戶空間的 ALsA 庫的介面，而不是直接調用 ALSA 驅動程序。
ALSA 驅動程序的主要頭文件是 include / sound ./ sound . h ，驅動核心數據結構和具體驅動的注冊函數是 include / sound / core . h ，驅動程序 的核心實現是 Sound / core / sound . c 文件。
ALSA 驅動程序使用下面的函數注冊控制和設備：
int snd _ pcm _ new (struct snd _ card * card ， char * id ， int device ， int playback _ count ， int capture _ count ， struct snd _ pcm ** rpcm) ；
int snd ctl _ add(struct snd _ card * card ， struct snd _ kcontrol * kcontro1) ；
ALSA 音頻驅動在內核進行 menuconfig 配置時 ， 配置選項為 「 Device Drivers 」 > 「 Sound c ard support 」 一 > 「 Advanced Linux Sound Architecture 」 。子選項包含了 Generic sound devices( 通用聲音設備 ) 、 ARM 體系結構支持，以及兼容 OSS 的幾個選項。 ALsA 音頻驅動配置對應的文件是sound / core / Kconfig 。
Android 沒有直接使用 ALSA 驅動，可以基於 A-LSA 驅動和 ALSA 庫實現 Android Audio 的硬體抽象層； ALSA 庫調用內核的 ALSA 驅動， Audio 的硬體抽象層調用 ALSA 庫。
4.OSS音頻驅動
OSS（Open Sound System開放聲音系統）是 linux 上最早出現的音效卡驅動。OSS 由一套完整的內核驅動程序模塊組成，可以為絕大多數音效卡提供統一的編程介面。
OSS 是字元設備，主設備號14，主要包括下面幾種設備文件：
1） /dev/sndstat
它是音效卡驅動程序提供的簡單介面，它通常是一個只讀文件，作用也只限於匯報音效卡的當前狀態。（用於檢測音效卡）
2）/dev/dsp
用於數字采樣和數字錄音的設備文件。對於音頻編程很重要。實現模擬信號和數字信號的轉換。
3）/dev/audio
類似於/dev/dsp，使用的是 mu-law 編碼方式。
4）/dev/mixer
用於多個信號組合或者疊加在一起，對於不同的音效卡來說，其混音器的作用可能各不相同。
5）/dev/sequencer
這個設備用來對音效卡內建的波表合成器進行操作，或者對 MIDI 匯流排上的樂器進行控制。
OSS 驅動所涉及的文件主要包括：
kernel/include/linux/soundcard.h
kernel/include/linux/sound.h 定義 OSS 驅動的次設備號和注冊函數
kernel/sound_core.c OSS核心實現部分
5.V4l2視頻驅動
V4L2是V4L的升級版本，為linux下視頻設備程序提供了一套介面規范。包括一套數據結構和底層V4L2驅動介面。V4L2提供了很多訪問介面，你可以根據具體需要選擇操作方法。需要注意的是，很少有驅動完全實現了所有的介面功能。所以在使用時需要參考驅動源碼，或仔細閱讀驅動提供者的使用說明。
V4L2的主設備號是81，次設備號：0~255，這些次設備號里也有好幾種設備（視頻設備、Radio設備、Teletext、VBI）。
V4L2的設備節點： /dev/videoX, /dev/vbiX and /dev/radioX
Android 設備驅動（下）
MTD 驅動
Flash 驅動通常使用 MTD （memory technology device )，內存技術設備。
MTD 的字元設備：
/dev/mtdX
主設備號 90.
MTD 的塊設備：
/dev/block/mtdblockX
主設備號 13.
MTD 驅動源碼
drivers/mtd/mtdcore.c：MTD核心，定義MTD原始設備
drivers/mtd/mtdchar.c：MTD字元設備
drivers/mtd/mtdblock.c：MTD塊設備
MTD 驅動程序是 Linux 下專門為嵌入式環境開發的新一類驅動程序。Linux 下的 MTD 驅動程序介面被劃分為用戶模塊和硬體模塊：
用戶模塊 提供從用戶空間直接使用的介面：原始字元訪問、原始塊訪問、FTL （Flash Transition Layer）和JFS（Journaled File System）。
硬體模塊 提供內存設備的物理訪問，但不直接使用它們，二十通過上述的用戶模塊來訪問。這些模塊提供了快閃記憶體上讀、寫和擦除等操作的實現。
藍牙驅動
在 Linux 中，藍牙設備驅動是網路設備，使用網路介面。
Android 的藍牙協議棧使用BlueZ實現來對GAP, SDP以及RFCOMM等應用規范的支持,並獲得了SIG認證。由於Bluez使用GPL授權, 所以Android 框架通過D-BUS IPC來與bluez的用戶空間代碼交互以避免使用未經授權的代碼。
藍牙協議部分頭文件：
include/net/bluetooth/hci_core.h
include/net/bluetooth/bluetooth.h
藍牙協議源代碼文件：
net/bluetooth/*
藍牙驅動程序部分的文件：
drivers/bluetooth/*
藍牙的驅動程序一般都通過標準的HCI控制實現。但根據硬體介面和初始化流程的不同，又存在一些差別。這類初始化動作一般是一些晶振頻率，波特率等基礎設置。比如CSR的晶元一般通過BCSP協議完成最初的初始化配置，再激活標准HCI控制流程。對Linux來說，一旦bluez可以使用HCI與晶元建立起通信(一般是hciattach + hciconfig)，便可以利用其上的標准協議(SCO, L2CAP等)，與藍牙通信，使其正常工作了。
WLAN 設備驅動（Wi-Fi）（比較復雜我面會專門寫個wifi分析）
在linux中，Wlan設備屬於網路設備，採用網路介面。
Wlan在用戶空間採用標準的socket介面進行控制。
WiFi協議部分頭文件：
include/net/wireless.h
WiFi協議部分源文件：
net/wireless/*
WiFi驅動程序部分：
drivers/net/wireless/*
㈤ Android怎麼生成設備節點
Android如何生成設備節點 在Android中，由於沒有mdev和udev，所以它沒有辦法動態的生成設備節點，那麼它是如何做的呢？ 我們可以在system/core/init/下的init.c和devices.c中找到答案： init.c中 int main(int argc, char **argv) { ... /* Get the basic filesystem setup we need put * together in the initramdisk on / and then we'll * let the rc file figure out the rest. */ mkdir("/dev", 0755); mkdir("/proc", 0755); mkdir("/sys", 0755); mount("tmpfs", "/dev", "tmpfs", 0, "mode=0755"); mkdir("/dev/pts", 0755); mkdir("/dev/socket", 0755); mount("devpts", "/dev/pts", "devpts", 0, NULL); mount("proc", "/proc", "proc", 0, NULL); mount("sysfs", "/sys", "sysfs", 0, NULL); for(;;) { ... if (ufds[0].revents == POLLIN) handle_device_fd(device_fd); if (ufds[1].revents == POLLIN) handle_property_set_fd(property_set_fd); if (ufds[3].revents == POLLIN) handle_keychord(keychord_fd); } return 0; } 我們再來看看handle_device_fd()，該函數定義在devices.c中 void handle_device_fd(int fd) { ... handle_device_event(&uevent); handle_firmware_event(&uevent); } } 而handle_device_event定義如下： static void handle_device_event(struct uevent *uevent) { ... if(!strcmp(uevent->action, "add")) { make_device(devpath, block, uevent->major, uevent->minor); return; } ... } make_device定義如下： static void make_device(const char *path, int block, int major, int minor) { ... mode = get_device_perm(path, &uid, &gid) (block S_IFBLK : S_IFCHR); dev = (major $amp; ... setegid(gid); mknod(path, mode, dev); chown(path, uid, -1); setegid(AID_ROOT); } 我們看看get_device_perm如下實現： static mode_t get_device_perm(const char *path, unsigned *uid, unsigned *gid) { mode_t perm; if (get_device_perm_inner(qemu_perms, path, uid, gid, &perm) == 0) { return perm; } else if (get_device_perm_inner(devperms, path, uid, gid, &perm) == 0) { return perm; } else { struct listnode *node; struct perm_node *perm_node; struct perms_ *dp; /* Check partners list. */ list_for_each(node, &devperms_partners) { perm_node = node_to_item(node, struct perm_node, plist); dp = &perm_node->dp; if (dp->prefix) { if (strncmp(path, dp->name, strlen(dp->name))) continue; } else { if (strcmp(path, dp->name)) continue; } /* Found perm in partner list. */ *uid = dp->uid; *gid = dp->gid; return dp->perm; } /* Default if nothing found. */ *uid = 0; *gid = 0; return 0600; } } 我們最後可以看到在devperms中定義了要生成的設備節點： static struct perms_ devperms[] = { { "/dev/null", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/zero", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/full", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/ptmx", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/tty", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/random", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/urandom", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/ashmem", 0666, AID_ROOT, AID_ROOT, 0 }, { "/dev/binder", 0666, AID_ROOT, AID_ROOT, 0 }, /* logger should be world writable (for logging) but not readable */ { "/dev/log/", 0662, AID_ROOT, AID_LOG, 1 }, /* the msm hw3d client device node is world writable/readable. */ { "/dev/msm_hw3dc", 0666, AID_ROOT, AID_ROOT, 0 }, /* gpu driver for adreno200 is globally accessible */ { "/dev/kgsl", 0666, AID_ROOT, AID_ROOT, 0 }, /* these should not be world writable */ { "/dev/diag", 0660, AID_RADIO, AID_RADIO, 0 }, { "/dev/diag_arm9", 0660, AID_RADIO, AID_RADIO, 0 }, { "/dev/android_adb", 0660, AID_ADB, AID_ADB, 0 }, { "/dev/android_adb_enable", 0660, AID_ADB, AID_ADB, 0 }, { "/dev/ttyMSM0", 0600, AID_BLUETOOTH, AID_BLUETOOTH, 0 }, { "/dev/ttyHS0", 0600, AID_BLUETOOTH, AID_BLUETOOTH, 0 }, { "/dev/uinput", 0660, AID_SYSTEM, AID_BLUETOOTH, 0 }, { "/dev/alarm", 0664, AID_SYSTEM, AID_RADIO, 0 }, { "/dev/tty0", 0660, AID_ROOT, AID_SYSTEM, 0 }, { "/dev/graphics/", 0660, AID_ROOT, AID_GRAPHICS, 1 }, { "/dev/msm_hw3dm", 0660, AID_SYSTEM, AID_GRAPHICS, 0 }, { "/dev/input/", 0660, AID_ROOT, AID_INPUT, 1 }, { "/dev/eac", 0660, AID_ROOT, AID_AUDIO, 0 }, { "/dev/cam", 0660, AID_ROOT, AID_CAMERA, 0 }, { "/dev/pmem", 0660, AID_SYSTEM, AID_GRAPHICS, 0 }, { "/dev/pmem_adsp", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/pmem_camera", 0660, AID_SYSTEM, AID_CAMERA, 1 }, { "/dev/oncrpc/", 0660, AID_ROOT, AID_SYSTEM, 1 }, { "/dev/adsp/", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/snd/", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/mt9t013", 0660, AID_SYSTEM, AID_SYSTEM, 0 }, { "/dev/msm_camera/", 0660, AID_SYSTEM, AID_SYSTEM, 1 }, { "/dev/akm8976_daemon",0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/akm8976_aot", 0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/akm8973_daemon",0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/akm8973_aot", 0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/bma150", 0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/cm3602", 0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/akm8976_pffd", 0640, AID_COMPASS, AID_SYSTEM, 0 }, { "/dev/lightsensor", 0640, AID_SYSTEM, AID_SYSTEM, 0 }, { "/dev/msm_pcm_out", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/msm_pcm_in", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/msm_pcm_ctl", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/msm_snd", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/msm_mp3", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/audience_a1026", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/tpa2018d1", 0660, AID_SYSTEM, AID_AUDIO, 1 }, { "/dev/msm_audpre", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/msm_audio_ctl", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/htc-acoustic", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/vdec", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/q6venc", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/snd/dsp", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/snd/dsp1", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/snd/mixer", 0660, AID_SYSTEM, AID_AUDIO, 0 }, { "/dev/smd0", 0640, AID_RADIO, AID_RADIO, 0 }, { "/dev/qemu_trace", 0666, AID_SYSTEM, AID_SYSTEM, 0 }, { "/dev/qmi", 0640, AID_RADIO, AID_RADIO, 0 }, { "/dev/qmi0", 0640, AID_RADIO, AID_RADIO, 0 }, { "/dev/qmi1", 0640, AID_RADIO, AID_RADIO, 0 }, { "/dev/qmi2", 0640, AID_RADIO, AID_RADIO, 0 }, /* CDMA radio interface MUX */ { "/dev/ts0710mux", 0640, AID_RADIO, AID_RADIO, 1 }, { "/dev/ppp", 0660, AID_RADIO, AID_VPN, 0 }, { "/dev/tun", 0640, AID_VPN, AID_VPN, 0 }, { NULL, 0, 0, 0, 0 }, };
㈥ 033 Android多進程-共享內存
要使用一塊共享內存
還是先看共享內存的使用方法，我主要介紹兩個函數：
通過 shmget() 函數申請共享內存,它的入參如下
通過 shmat() 函數將我們申請到的共享內存映射到自己的用戶空間，映射成功會返回地址，有了這個地址，我們就可以隨意的讀寫數據了，我們繼續看一下這個函數的入參
共享內存的原理是在內存中單獨開辟的一段內存空間，這段內存空間其實就是一個tempfs（臨時虛擬文件），tempfs是VFS的一種文件系統，掛載在/dev/shm上，前面提到的管道pipefs也是VFS的一種文件系統。
由於共享的內存空間對使用和接收進程來講，完全無感知，就像是在自己的內存上讀寫數據一樣，所以也是 效率最高 的一種IPC方式。
上面提到的IPC的方式都是 在內核空間中開辟內存來存儲數據 ，寫數據時，需要將數據從用戶空間拷貝到內核空間，讀數據時，需要從內核空間拷貝到自己的用戶空間，
共享內存就只需要一次拷貝 ，而且共享內存不是在內核開辟空間，所以可以 傳輸的數據量大 。
但是 共享內存最大的缺點就是沒有並發的控制，我們一般通過信號量配合共享內存使用，進行同步和並發的控制 。
共享內存在Android系統中主要的使用場景是 用來傳輸大數據 ，並且 Android並沒有直接使用Linux原生的共享內存方式，而是設計了Ashmem匿名共享內存 。
之前說到有名管道和匿名管道的區別在於有名管道可以在vfs目錄樹中查看到這個管道的文件，但是匿名管道不行， 所以匿名共享內存同樣也是無法在vfs目錄中查看到 的， Android之所以要設計匿名共享內存 ，我覺得主要是為了安全性的考慮吧。
我們來看看共享內存的一個使用場景，在Android中，如果我們想要將當前的界面顯示出來，需要將當前界面的圖元數據傳遞Surfaceflinger去做圖層混合，圖層混合之後的數據會直接送入幀緩存，送入幀緩存後，顯卡就會直接取出幀緩存里的圖元數據顯示了。
那麼我們如何將應用的Activity的圖元數據傳遞給SurfaceFlinger呢？想要將圖像數據這樣比較大的數據跨進程傳輸，靠binder是不行的，所以這兒便用到匿名共享內存。
從谷歌官方提供的架構圖可以看到，圖元數據是通過BufferQueue傳遞到SurfaceFlinger去的，當我們想要繪制圖像的時候， 需要從BufferQueue中申請一個Buffer，Buffer會調用Gralloc模塊來分配共享內存 當作圖元緩沖區存放我們的圖元數據。
可以看到Android的匿名共享內存是通過 ashmem_create_region() 函數來申請共享內存的，它會在/dev/ashmem下創建一個虛擬文件，Linux原生共享內存是通過shmget()函數，並會在/dev/shm下創建虛擬文件。
匿名共享內存是通過 mmap() 函數將申請到的內存映射到自己的進程空間，而Linux是通過*shmat()函數。
雖然函數不一樣，但是Android的匿名共享內存和Linux的共享內存在本質上是大同小異的。
。
㈦ 存儲性能優化 MMKV源碼解析
好久沒有更新常用的第三方庫了。讓我們來聊聊MMKV這個常用的第三方庫。MMKV這個庫是做什麼的呢？他本質上的定位和sp有點相似，經常用於持久化小數據的鍵值對。其速度可以說是當前所有同類型中速度最快，性能最優的庫。
它的最早的誕生，主要是因為在微信iOS端有一個重大的bug，一個特殊的文本可以導致微信的iOS端閃退，而且還出現了不止一次。為了統計這種閃退的字元出現頻率以及過濾，但是由於出現的次數，發現原來的鍵值對存儲組件NSUserDefaults根本達不到要求，會導致cell的滑動卡頓。
因此iOS端就開始創造一個高新性能的鍵值對存儲組件。於此同時，Android端SharedPreferences也有如下幾個缺點：
因此Android也開始復用iOS的MMKV，而後Android有了多進程的寫入數據的需求，Android組又在這個基礎上進行改進。
這里是官方的性能的比較圖：
能看到mmkv比起我們開發常用的組件要快上數百倍。
那麼本文將會從源碼角度圍繞MMKV的性能為什麼會如此高，以及SharePrefences為什麼可能出現ANR的原因。
請注意下文是以MMKV 1.1.1版本源碼為例子分析。如果遇到什麼問題歡迎來到本文 https://www.jianshu.com/p/c12290a9a3f7 互相討論。
老規矩，先來看看MMKV怎麼使用。mmkv其實和SharePrefences一樣，有增刪查改四種操作。
MMKV作為一個鍵值對存儲組件，也對了存儲對象的序列化方式進行了優化。常用的方式比如有json，Twitter的Serial。而MMKV使用的是Google開源的序列化方案:Protocol Buffers。
Protocol Buffers這個方案比起json來說就高級不少：
使用方式可以閱讀下面這篇文章： https://www.jianshu.com/p/e8712962f0e9
下面進行比較幾個對象序列化之間的要素比較
而MMKV就是看重了Protocol Buffers的時間開銷小，選擇Protocol Buffers進行對象緩存的核心。
使用前請初始化：
當然mmkv除了能夠寫入這些基本類型，只要SharePrefences支持的，它也一定能夠支持。
同上，每一個key讀取的數據類型就是decodexxx對應的類型名字。使用起來十分簡單。
能夠刪除單個key對應的value，也能刪除多個key分別對應的value。containsKey判斷mmkv的磁碟緩存中是否存在對應的key。
mmkv和SharePrefences一樣，還能根據模塊和業務劃分對應的緩存文件：
這里創建了一個id為a的實例在磁碟中，進行數據的緩存。
當需要多進程緩存的時候：
MMKV可以使用Ashmem的匿名內存進行更加快速的大對象傳輸：
進程1：
最重要的一點，mmkv把SharePrefences的緩存遷移到mmkv中，之後的使用就和SharePrefences一致。
這里就是把SharedPreferences的myData數據遷移到mmkv中。當然如果我們需要保持SharePreferences的用法不變需要自己進行自定義一個SharePreferences。
mmkv的用法極其簡單，接下來我們關注他的原理。
首先來看看MMKV的初始化。
能看到實際上initialize分為如下幾個步驟：
能看到其實就是做這個判斷。由於此時設置的是libc++的打包方式。此時BuildConfig.FLAVOR就是StaticCpp，就不會載入c++_shared。當然，如果我們已經使用了c++_shared庫，則沒有必要打包進去，使用defaultPublishConfig "SharedCppRelease"會嘗試的查找動態鏈接庫_shared。這樣就能少2M的大小。
請注意一個前提的知識，jni的初始化，在調用了 System.loadLibrary之後，會通過dlopen把so載入到內存後，調用dlsym，調用jni中的JNI_OnLoad方法。
實際上這裡面做的事情十分簡單：
能從這些native方法中看到了所有MMKV的存儲方法，設置支持共享內存ashemem的存儲，支持直接獲取native malloc申請的內存
接下來就是MMKV正式的初始化方法了。
這個方法實際上調用的是pthread_once方法。它一般是在多線程環境中，根據內核的調度策略，選擇一個線程初始化一次的方法。
其實這裡面的演算法很簡單：
defaultMMKV此時調用的是getDefaultMMKV這個native方法，默認是單進程模式。從這里的設計都能猜到getDefaultMMKV會從native層實例化一個MMKV對象，並且讓實例化好的Java層MMKV對象持有。之後Java層的方法和native層的方法一一映射就能實現一個直接操作native對象的Java對象。
我們再來看看MMKV的mmkvWithID。
感覺上和defaultMMKV有點相似，也是調用native層方法進行初始化，並且讓java層MMKV對象持有native層。那麼我們可否認為這兩個實例化本質上在底層調用同一個方法，只是多了一個id設置呢？
可以看看MMKV.h文件：
這里就能看到上面的推測是正確的，只要是實例化，最後都是調用mmkvWithID進行實例化。默認的mmkv的id就是mmkv.default。Android端則會設置一個默認的page大小,假設4kb為例子。
所有的mmkvID以及對應的MMKV實例都會保存在之前實例化的g_instanceDic散列表中。其中mmkv每一個id對應一個文件的路徑，其中路徑是這么處理的：
如果發現對應路徑下的mmkv在散列表中已經緩存了，則直接返回。否則就會把相對路徑保存下來，傳遞給MMKV進行實例化，並保存在g_instanceDic散列表中。
我們來看看MMKV構造函數中幾個關鍵的欄位是怎麼初始化。
mmkvID就是經過md5後對應緩存文件對應的路徑。
能看到這里是根據當前的mode初始化id，如果不是ashmem匿名共享內存模式進行創建，則會和上面的處理類似。id就是經過md5後對應緩存文件對應的路徑。
注意這里mode設置的是MMKV_ASHMEM，也就是ashmem匿名共享內存模式則是如下創建方法：
實際上就是在驅動目錄下的一個內存文件地址。
接下來，在構造函數中使用了共享的文件鎖進行保護後，調用loadFromFile進一步的初始化MMKV內部的數據。
我們大致的了解MMKV中每一個欄位的負責的職責，但是具體如何進行工作下文都會解析。
在這裡面我們遇到了看起來十分核心的類MemoryFile，它的名字有點像 Ashmem匿名共享內存 一文中描述過Java層的映射的匿名內存文件。
我們先來看看MemoryFile的初始化。
MemeoryFile分為兩個模式進行初始化：
這里的處理很簡單：
能看到此時將會調用mmap系統調用，通過設置標志位可讀寫，MAP_SHARED的模式進行打開。這樣就file就在在內核中映射了一段4kb內存，以後訪問文件可以不經過內核，直接訪問file映射的這一段內存。
關於mmap系統調用的源碼解析可以看這一篇 Binder驅動的初始化 映射原理 。
能看到在這個過程中實際上還是通過ftruncate進行擴容，接著調用zeroFillFile，先通過lseek把指針移動當前容量的最後，並把剩餘的部分都填充空數據'\0'。最後映射指向的地址是有效的，會先解開後重新進行映射。
為什麼要做最後這個步驟呢？如果閱讀過我解析的mmap的源碼一文，實際上就能明白，file使用MAP_SHARED的模式本質上是給file結構體綁定一段vma映射好的內存。ftruncate只是給file結構體進行了擴容，但是還沒有對對應綁定虛擬內存進行擴容，因此需要解開一次映射後，重新mmap一次。
MMKV在如果使用Ashmem模式打開：
接下來loadFromFile 這個方法可以說是MMKV的核心方法，所有的讀寫，還是擴容都需要這個方法，從映射的文件內存，緩存到MMKV的內存中。
進入到這個方法後進行如下的處理：
在這里，遇到了一個比較有歧義的欄位m_version ，從名字看起來有點像MMKV的版本號。其實它指代的是MMKV當前的狀態，由一個枚舉對象代表：
注意m_vector是一個長度16的char數組。其實很簡單，就是把文件保存的m_vector獲取16位拷貝到m_metaInfo的m_vector中。因為aes的加密必須以16的倍數才能正常運作。
初始化分為這6點，我們從最後三點開始聊聊MMKV的初始化的核心邏輯。我們還需要開始關注MMKV中內存存儲的結構。
能看到首先從m_file獲取映射的指針地址，往後讀取4位數據。這4位數據就是actualSize 真實數據。但是如果是m_metaInfo的m_version 大於等於3，則獲取m_metaInfo中保存的actualSize。
其校驗的手段，是通過比較m_metaInfo保存的crcDigest和從m_file中讀取的crcDigest進行比較，如果一致說明數據無誤，則返回true，設置loadFromFile為true。
其實這裡面只處理m_metaInfo的m_version的狀態大於等於3的狀態。我們回憶一下，在readActualSize方法中，把讀取當前存儲的數據長度，分為兩個邏輯進行讀取。如果大於等於3，則從m_metaInfo中獲取。
crc校驗失敗，說明我們寫入的時候發生異常。需要強制進行recover恢復數據。
首先要清除crc校驗校驗了什麼東西：
MMKV做了如下處理，只處理狀態等級在MMKVVersionActualSize情況。這個情況，在m_metaInfo記錄上一次MMKV中的信息。因此可以通過m_metaInfo進行校驗已經存儲的數據長度，進而更新真實的已經記錄數據的長度。
最後讀取上一次MMKV還沒有更新的備份數據長度和crc校驗欄位，通過writeActualSize記錄在映射的內存中。
如果最後彌補的校驗還是crc校驗錯誤，最後會回調onMMKVCRCCheckFail這個方法。這個方法會反射Java層實現的異常處理策略
如果是OnErrorRecover，則設置loadFromFile和needFullWriteback都為true，盡可能的恢復數據。當然如果OnErrorDiscard，則會丟棄掉所有的數據。
㈧ 如何在Android上實現FrameBuffer和Overlay的blend
1.SurfaceFlinger是一個服務，主要是負責合成各窗口的Surface，然後通過OpenGLES顯示到FrameBuffer上。
2.DisplayHardware是對顯示設備的抽象，包括FrameBuffer和Overlay。載入FrameBuffer和Overlay插件，羨罩並初始化OpenGLES:
view plain
mNativeWindow = new FramebufferNativeWindow();
framebuffer_device_t const * fbDev = mNativeWindow->getDevice();
if (hw_get_mole(OVERLAY_HARDWARE_MODULE_ID, &mole) == 0) {
overlay_control_open(mole, &mOverlayEngine);
}
surface = eglCreateWindowSurface(display, config, mNativeWindow.get(), NULL);
eglMakeCurrent(display, surface, surface, context);
3.FramebufferNativeWindow 是framebuffer 的抽象，它負責載入libgralloc，並握大打開framebuffer設備。FramebufferNativeWindow並不直接使用 framebuffer，而是自己創建了兩個Buffer：
queueBuffer負責顯示一個Buffer到屏幕上，它調用fb->post去顯示。
dequeueBuffer獲取一個空閑的Buffer，用來在後台繪制。
這兩個函數由eglSwapBuffers調過來，調到
view plain
egl_window_surface_v2_t::swapBuffers：
nativeWindow->queueBuffer(nativeWindow, buffer);
nativeWindow->dequeueBuffer(nativeWindow, &buffer);
4.msm7k/liboverlay是Overlay的實現，與其它平台不同的是，高通平台上的Overlay並不是提供一個framebuffer設備，而通過fb0的ioctl來實現的，ioctl分為兩類操作：
OverlayControlChannel用於設置參數，比如設置Overlay的位置，寬度和高度：
view plain
bool OverlayControlChannel::setPosition(int x, int y, uint32_t w, uint32_t h) {
ov.dst_rect.x = x;
ov.dst_rect.y = y;
ov.dst_rect.w = w;
ov.dst_rect.h = h;
ioctl(mFD, MSMFB_OVERLAY_SET, &ov);
}
OverlayDataChannel用於顯示Overlay，其中最重要的函數就是queueBuffer:
view plain
bool OverlayDataChannel::queueBuffer(uint32_t offset) {
mOvData.data.offset = offset;
ioctl(mFD, MSMFB_OVERLAY_PLAY, odPtr))
}
5.msm7k/libgralloc 是顯示緩存的抽象，包括framebuffer和普通Surface的Buffer。framebuffer只是/dev/graphic/fb0的包 裝，Surface的Buffer則是對/dev/pmem、ashmem和GPU內存(msm_hw3dm)的包裝，它的目標主要是方便硬體加速，因為 DMA傳輸使用物理地址，兄皮鬧要求內存在物理地址上連續。
6.msm7k/libbit這是2D加速庫，主要負責Surface的拉伸、旋轉和合成等操作。它有兩種實現方式：
bit.cpp: 基於fb0的ioctl(MSMFB_BLIT)的實現。
bit_c2d.cpp: 基於kgsl的實現，只是對libC2D2.so的包裝，libC2D2.so應該是不開源的。
7.pmem
misc/pmem.c: 對物理內存的管理，演算法和用戶空間的介面。
board-msm7x27.c定義了物理內存的預設大小：
view plain
#define MSM_PMEM_MDP_SIZE 0x1B76000
#define MSM_PMEM_ADSP_SIZE 0xB71000
#define MSM_PMEM_AUDIO_SIZE 0x5B000
#define MSM_FB_SIZE 0x177000
#define MSM_GPU_PHYS_SIZE SZ_2M
#define PMEM_KERNEL_EBI1_SIZE 0x1C00
msm_msm7x2x_allocate_memory_regions分配幾大塊內存用於給pmem做二次分配。
8.KGSL
Kernel Graphics System Layer (KGSL)，3D圖形加速驅動程序，源代碼drivers/gpu/msm目錄下，它是對GPU的包裝，給OpenGLES 2.0提供抽象的介面。
9.msm_hw3dm
這個我在內核中沒有找到相關代碼。
10.msm_fb
msm_fb.c: framebuffer, overlay和blit的用戶介面。
mdp_dma.c: 對具體顯示設備的包裝，提供兩種framebuffer更新的方式：
mdp_refresh_screen： 定時更新。
mdp_dma_pan_update: 通過pan display主動更新。
mdp_dma_lcdc.c：針對LCD實現的顯示設備，mdp_lcdc_update用更新framebuffer。
㈨ 如何檢查 Android 應用的內存使用情況
解析日誌信息
最簡單的調查應用內存使用情況的地方就是Dalvik日誌信息。可以在logcat（輸出信息可以在Device Monitor或者IDE中查看到，例如Eclipse和Android Studio）中找到這些日誌信息。每次有垃圾回收發生，logcat會列印出帶有下面信息的日誌消息：
Java
1
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
GC原因
觸發垃圾回收執行的原因和垃圾回收的類型。原因主要包括：
GC_CONCURRENT
並發垃圾回收，當堆開始填滿時觸發來釋放內存。
GC_FOR_MALLOC
堆已經滿了時應用再去嘗試分配內存觸發的垃圾回收，這時系統必須暫停應用運行來回收內存。
GC_HPROF_DUMP_HEAP
創建HPROF文件來分析應用時觸發的垃圾回收。
GC_EXPLICIT
顯式垃圾回收，例如當調用 gc()（應該避免手動調用而是要讓垃圾回收器在需要時主動調用）時會觸發。
GC_EXTERNAL_ALLOC
這種只會在API 10和更低的版本（新版本內存都只在Dalvik堆中分配）中會有。回收外部分配的內存（例如存儲在本地內存或NIO位元組緩沖區的像素數據）。
釋放數量
執行垃圾回收後內存釋放的數量。
堆狀態
空閑的百分比和（活動對象的數量）/（總的堆大小）。
外部內存狀態
API 10和更低版本中的外部分配的內存（分配的內存大小）/（回收發生時的限制值）。
暫停時間
越大的堆的暫停時間就越長。並發回收暫停時間分為兩部分：一部分在回收開始時，另一部分在回收將近結束時。
例如：
Java
1
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/K, paused 2ms+2ms
隨著這些日誌消息的增多，注意堆狀態（上面例子中的3571K/9991K）的變化。如果值一直增大並且不會減小下來，那麼就可能有內存泄露了。
查看堆的更新
為了得到應用內存的使用類型和時間，可以在Device Monitor中實時查看應用堆的更新：
1.打開Device Monitor。
從<sdk>/tools/路徑下載入monitor工具。
2.在Debug Monitor窗口，從左邊的進程列表中選擇要查看的應用進程。
3.點擊進程列表上面的Update Heap。
4.在右側面板中選擇Heap標簽頁。
Heap視圖顯示了堆內存使用的基本狀況，每次垃圾回收後會更新。要看更新後的狀態，點擊Gause GC按鈕。
圖1.Device Monitor工具顯示[1] Update Heap和 [2] Cause GC按鈕。右邊的Heap標簽頁顯示堆的情況。
跟蹤內存分配
當要減少內存問題時，應該使用Allocation Tracker來更好的了解內存消耗大戶在哪分配。Allocation Tracker不僅在查看內存的具體使用上很有用，也可以分析應用中的關鍵代碼路徑，例如滑動。
例如，在應用中滑動列表時跟蹤內存分配，可以看到內存分配的動作，包括在哪些線程上分配和哪裡進行的分配。這對優化代碼路徑來減輕工作量和改善UI流暢性都極其有用。
使用Allocation Tracker：
1.打開Device Monitor 。
從<sdk>/tools/路徑下載入monitor工具。
2.在DDMS窗口，從左側面板選擇應用進程。
3.在右側面板中選擇Allocation Tracker標簽頁。
4.點擊Start Tracking。
5.執行應用到需要分析的代碼路徑處。
6.點擊Get Allocations來更新分配列表。
列表顯示了所有的當前分配和512大小限制的環形緩沖區的情況。點擊行可以查看分配的堆棧跟蹤信息。堆棧不只顯示了分配的對象類型，還顯示了屬於哪個線程哪個類哪個文件和哪一行。
圖2. Device Monitor工具顯示了在Allocation Tracker中當前應用的內存分配和堆棧跟蹤的情況。
注意：總會有一些分配是來自與 DdmVmInternal 和 allocation tracker本身。
盡管移除掉所有嚴重影響性能的代碼是不必要的（也是不可能的），但是allocation tracker還是可以幫助定位代碼中的嚴重問題。例如，應用可能在每個draw操作上創建新的Paint對象。把對象改成全局變數就是一個很簡單的改善性能的修改。
查看總體內存分配
為了進一步的分析，查看應用內存中不同內存類型的分配情況，可以使用下面的 adb 命令：
Java
1
adb shell mpsys meminfo <package_name>
應用當前的內存分配輸出列表，單位是千位元組。
當查看這些信息時，應當熟悉下面的分配類型：
私有(Clean and Dirty) 內存
進程獨占的內存。也就是應用進程銷毀時系統可以直接回收的內存容量。通常來說，「private dirty」內存是其最重要的部分，因為只被自己的進程使用。它只在內存中存儲，因此不能做分頁存儲到外存（Android不支持swap）。所有分配的Dalvik堆和本地堆都是「private dirty」內存；Dalvik堆和本地堆中和Zygote進程共享的部分是共享dirty內存。
實際使用內存 (PSS)
這是另一種應用內存使用的計算方式，把跨進程的共享頁也計算在內。任何獨占的內存頁直接計算它的PSS值，而和其它進程共享的頁則按照共享的比例計算PSS值。例如，在兩個進程間共享的頁，計算進每個進程PPS的值是它的一半大小。
PSS計算方式的一個好處是：把所有進程的PSS值加起來就可以確定所有進程總共佔用的內存。這意味著用PSS來計算進程的實際內存使用、進程間對比內存使用和總共剩餘內存大小是很好的方式。
例如，下面是平板設備中Gmail進程的輸出信息。它顯示了很多信息，但是具體要講解的是下面列出的一些關鍵信息。
注意：實際看到的信息可能和這里的稍有不同，輸出的詳細信息可能會根據平台版本的不同而不同。
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336
Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1
SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62
通常來說，只需關心Pss Total列和Private Dirty列就可以了。在一些情況下，Private Clean列和Heap Alloc列也會提供很有用的信息。下面是一些應該查看的內存分配類型(行中列出的類型)：
Dalvik Heap
應用中Dalvik分配使用的內存。Pss Total包含所有的Zygote分配（如上面PSS定義所描述的，共享跨進程的加權）。Private Dirty是應用堆獨占的內存大小，包含了獨自分配的部分和應用進程從Zygote復制分裂時被修改的Zygote分配的內存頁。
注意：新平台版本有Dalvik Other這一項。Dalvik Heap中的Pss Total和Private Dirty不包括Dalvik的開銷，例如即時編譯（JIT）和垃圾回收（GC），然而老版本都包含在Dalvik的開銷裡面。
Heap Alloc是應用中Dalvik堆和本地堆已經分配使用的大小。它的值比Pss Total和Private Dirty大，因為進程是從Zygote中復制分裂出來的，包含了進程共享的分配部分。
.so mmap和.dex mmap
mmap映射的.so(本地) 和.dex(Dalvik)代碼使用的內存。Pss Total 包含了跨應用共享的平台代碼；Private Clean是應用獨享的代碼。通常來說，實際映射的內存大小要大一點——這里顯示的內存大小是執行了當前操作後應用使用的內存大小。然而，.so mmap 的private dirty比較大，這是由於在載入到最終地址時已經為本地代碼分配好了內存空間。
Unknown
無法歸類到其它項的內存頁。目前，這主要包含大部分的本地分配，就是那些在工具收集數據時由於地址空間布局隨機化(Address Space Layout Randomization ，ASLR)不能被計算在內的部分。和Dalvik堆一樣， Unknown中的Pss Total把和Zygote共享的部分計算在內，Unknown中的Private Dirty只計算應用獨自使用的內存。
TOTAL
進程總使用的實際使用內存(PSS)，是上面所有PSS項的總和。它表明了進程總的內存使用量，可以直接用來和其它進程或總的可以內存進行比較。
Private Dirty和Private Clean是進程獨自佔用的總內存，不會和其它進程共享。當進程銷毀時，它們（特別是Private Dirty）佔用的內存會重新釋放回系統。Dirty內存是已經被修改的內存頁，因此必須常駐內存（因為沒有swap）；Clean內存是已經映射持久文件使用的內存頁（例如正在被執行的代碼），因此一段時間不使用的話就可以置換出去。
ViewRootImpl
進程中活動的根視圖的數量。每個根視圖與一個窗口關聯，因此可以幫助確定涉及對話框和窗口的內存泄露。
AppContexts和Activities
當前駐留在進程中的Context和Activity對象的數量。可以很快的確認常見的由於靜態引用而不能被垃圾回收的泄露的 Activity對象。這些對象通常有很多其它相關聯的分配，因此這是追查大的內存泄露的很好辦法。
注意：View 和 Drawable 對象也持有所在Activity的引用，因此，持有View 或 Drawable 對象也可能會導致應用Activity泄露。
獲取堆轉儲
堆轉儲是應用堆中所有對象的快照，以二進制文件HPROF的形式存儲。應用堆轉儲提供了應用堆的整體狀態，因此在查看堆更新的同時，可以跟蹤可能已經確認的問題。
檢索堆轉儲：
1.打開Device Monitor。
從<sdk>/tools/路徑下載入monitor工具。
2.在DDMS窗口，從左側面板選擇應用進程。
3.點擊Dump HPROF file，顯示見圖3。
4.在彈出的窗口中，命名HPROF文件，選擇存放位置，然後點擊Save。
圖3.Device Monitor工具顯示了[1] Dump HPROF file按鈕。
如果需要能更精確定位問題的堆轉儲，可以在應用代碼中調用mpHprofData()來生成堆轉儲。
堆轉儲的格式基本相同，但與Java HPROF文件不完全相同。Android堆轉儲的主要不同是由於很多的內存分配是在Zygote進程中。但是由於Zygote的內存分配是所有應用進程共享的，這些對分析應用堆沒什麼關系。
為了分析堆轉儲，你需要像jhat或Eclipse內存分析工具(MAT)一樣的標准工具。當然，第一步需要做的是把HPROF文件從Android的文件格式轉換成J2SE HRPOF的文件格式。可以使用<sdk>/platform-tools/路徑下的hprof-conv工具來轉換。hprof-conv的使用很簡單，只要帶上兩個參數就可以：原始的HPROF文件和轉換後的HPROF文件的存放位置。例如：
Java
1
hprof-conv heap-original.hprof heap-converted.hprof
注意：如果使用的是集成在Eclipse中的DDMS，那麼就不需要再執行HPROF轉換操作——默認已經轉換過了。
現在就可以在MAT中載入轉換過的HPROF文件了，或者是在可以解析J2SE HPROF格式的其它堆分析工具中載入。
分析應用堆時，應該查找由下導致的內存泄露：
對Activity、Context、View、Drawable的長期引用，以及其它可能持有Activity或Context容器引用的對象
非靜態內部類（例如持有Activity實例的Runnable）
不必要的長期持有對象的緩存
使用Eclipse內存分析工具
Eclipse內存分析工具（MAT）是一個可以分析堆轉儲的工具。它是一個功能相當強大的工具，功能遠遠超過這篇文檔的介紹，這里只是一些入門的介紹。
在MAT中打開類型轉換過的HPROF文件，在總覽界面會看到一張餅狀圖，它展示了佔用堆的最大對象。在圖表下面是幾個功能的鏈接：
Histogram view顯示所有類的列表和每個類有多少實例。
正常來說類的實例的數量應該是確定的，可以用這個視圖找到額外的類的實例。例如，一個常見的源碼泄露就是Activity類有額外的實例，而正確的是在同一時間應該只有一個實例。要找到特定類的實例，在列表頂部的<Regex>域中輸入類名查找。
當一個類有太多的實例時，右擊選擇List objects>with incoming references。在顯示的列表中，通過右擊選擇Path To GC Roots> exclude weak references來確定保留的實例。
Dominator tree是按照保留堆大小來顯示的對象列表。
應該注意的是那些保留的部分堆大小粗略等於通過GC logs、heap updates或allocation tracker觀察到的泄露大小的對象。
當看到可疑項時，右擊選擇Path To GC Roots>exclude weak references。打開新的標簽頁，標簽頁中列出了可疑泄露的對象的引用。
注意：在靠近餅狀圖中大塊堆的頂部，大部分應用會顯示Resources的實例，但這通常只是因為在應用使用了很多res/路徑下的資源。
圖4.MAT顯示了Histogram view和搜索」MainActivity」的結果。
想要獲得更多關於MAT的信息，請觀看2011年Google I/O大會的演講–《Android 應用內存管理》（Memory management for Android apps），在大約21:10 的時候有關於MAT的實戰演講。也可以參考文檔《Eclipse 內存分析文檔》（Eclipse Memory Analyzer documentation）。
對比堆轉儲
為了查看內存分配的變化，比較不同時間點應用的堆狀態是很有用的方法。對比兩個堆轉儲可以使用MAT：
1.按照上面描述得到兩個HPROF文件，具體查看獲取堆轉儲章節。
2.在MAT中打開第一個HPROF文件（File>Open Heap Dump）。
3.在Navigation History視圖（如果不可見，選擇Window>Navigation History），右擊Histogram，選擇Add to Comp are Basket。
4.打開第二個HRPOF文件，重復步驟2和3。
5.切換到Compare Basket視圖，點擊Compare the Results（在視圖右上角的紅色「！」圖標）。
觸發內存泄露
使用上述描述工具的同時，還應該對應用代碼做壓力測試來嘗試復現內存泄露。一個檢查應用潛在內存泄露的方法，就是在檢查堆之前先運行一會。泄露會慢慢達到分配堆的大小的上限值。當然，泄露越小，就要運行應用越長的時間來復現。
也可以使用下面的方法來觸發內存泄露：
1.在不同Activity狀態時，重復做橫豎屏切換操作。旋轉屏幕可能導致應用泄露 Activity、Context 或 View對象，因為系統會重新創建 Activity，如果應用在其它地方持有這些對象的引用，那麼系統就不能回收它們。
2.在不同Activity狀態時，做切換應用操作（切換到主屏幕，然後回到應用中）。
提示：也可以使用monkey測試來執行上述步驟。想要獲得更多運行 monkey 測試的信息，請查閱 monkeyrunner 文檔。
㈩ Android 5.0 SEAndroid下怎麼獲得對一個內核節點的訪問許可權
第一步：找到需要訪問該內核節點的進程（process），筆者自己這個節點由system_server進程來訪問
第二步：打開文件AndroidL/android/external/sepolicy/file_contexts.be
仿照這個逗脊文件里的寫法，為這個定義一個自己想要的名字：
/dev/tegra.* u:object_r:video_device:s0
/dev/tf_driver u:object_r:tee_device:s0
/dev/tty u:object_r:owntty_device:s0
/dev/tty[0-9]* u:object_r:tty_device:s0
/dev/ttyS[0-9]* u:object_r:serial_device:s0
/dev/wf_bt u:object_r: wf_bt_device:s0
wf_bt_device是自定義，其他左右兩邊談指滾的內容都和上面的範例一致。
第三步：打開文件AndroidL/android/external/sepolicy/device.te
仿照這個文件里的寫法，將剛剛第二步寫的wf_bt_device聲明為dev_type：
# Device types
type device, dev_type, fs_type;
type alarm_device, dev_type, mlstrustedobject;
type adb_device, dev_type;
type ashmem_device, dev_type, mlstrustedobject;
type audio_device, dev_type;
type binder_device, dev_type, mlstrustedobject;
type block_device, dev_type;
type camera_device, dev_type;
type wf_bt_device, dev_type;
第四步：
AndroidL/android/external/sepolicy/目錄含餘下很多.te文件都是以進程名來結尾的，比如有針對surfaceflinger進程的surfaceflinger，有針對vold進程的vold.te，
剛剛從第一步得到，這個節點是由system_server進程來訪問，所以，找到system_server.te打開，加入允許這個進程對/dev/wf_bt的讀寫許可權，
# Read/Write to /proc/net/xt_qtaguid/ctrl and and /dev/xt_qtaguid.
allow system_server qtaguid_proc:file rw_file_perms;
allow system_server qtaguid_device:chr_file rw_file_perms;
# chr_file表示字元設備文件，如果是普通文件用file，目錄請用dir
# rw_file_perms代表讀寫許可權
allow system_server wf_bt_device:chr_file rw_file_perms;
這句話的意思是：允許system_server進程擁有對wf_bt_device的這個字元設備的讀寫許可權。
改了這些之後，就可以make installclean;make -j16編譯image來驗證許可權是否獲取成功。
fd =open("/dev/wf_bt",O_RDONLY | O_NOCTTY);