15.1 ION/DMA-BUF框架內(nèi)存分配的基石先講ION。這是Android系統(tǒng)里統(tǒng)一的內(nèi)存分配器專門給多媒體、顯示、相機(jī)這些模塊用的。為什么需要ION因?yàn)轱@示驅(qū)動(dòng)需要的內(nèi)存不是普通的內(nèi)存。它需要連續(xù)物理內(nèi)存或者至少是IOMMU映射好的內(nèi)存還要支持跨進(jìn)程共享。你想想看應(yīng)用層畫了一幀畫面要傳給SurfaceFlinger合成再送到顯示硬件——這中間要跨多少道進(jìn)程ION的核心概念就是「Heap」。每個(gè)Heap代表一種內(nèi)存類型Heap類型用途特點(diǎn)ION_HEAP_TYPE_SYSTEM普通系統(tǒng)內(nèi)存非連續(xù)速度一般ION_HEAP_TYPE_SYSTEM_CONTIG連續(xù)物理內(nèi)存用于顯示控制器直接訪問ION_HEAP_TYPE_CARVEOUT預(yù)留內(nèi)存固定大小不參與頁(yè)回收ION_HEAP_TYPE_CHUNK分塊內(nèi)存MTK平臺(tái)常用兼顧連續(xù)性和靈活性我在MTK8678上調(diào)試時(shí)遇到過(guò)一個(gè)問題用SYSTEM_HEAP分配顯示緩沖區(qū)結(jié)果畫面偶爾出現(xiàn)條紋。查了半天發(fā)現(xiàn)是內(nèi)存不連續(xù)導(dǎo)致DMA傳輸出錯(cuò)。后來(lái)?yè)Q成SYSTEM_CONTIG_HEAP問題就解決了。關(guān)鍵點(diǎn)顯示緩沖區(qū)必須使用物理連續(xù)內(nèi)存或者通過(guò)IOMMU映射成連續(xù)的虛擬地址空間。DMA-BUF是ION的底層機(jī)制。它本質(zhì)上是一個(gè)文件描述符代表一塊可以跨設(shè)備、跨進(jìn)程共享的內(nèi)存。ION分配的內(nèi)存最終都會(huì)導(dǎo)出為一個(gè)DMA-BUF fd。// ION分配內(nèi)存示例 struct ion_allocation_data alloc_data { .len buffer_size, .heap_id_mask 1 ION_HEAP_TYPE_SYSTEM_CONTIG, .flags ION_FLAG_CACHED, }; int ret ioctl(ion_fd, ION_IOC_ALLOC, alloc_data); // 獲取DMA-BUF fd int dma_buf_fd alloc_data.fd;嗯這里要注意ION的API在較新內(nèi)核中已經(jīng)被DMA-BUF Heaps替代了。但MTK平臺(tái)為了兼容性內(nèi)部還是保留了ION的接口封裝。你看到代碼里還有ION相關(guān)的調(diào)用別奇怪。15.2 GraphicBuffer分配從應(yīng)用到驅(qū)動(dòng)的橋梁GraphicBuffer是Android上層對(duì)ION/DMA-BUF的封裝。應(yīng)用層畫圖時(shí)不會(huì)直接調(diào)ION接口而是通過(guò)GraphicBufferAllocator來(lái)申請(qǐng)。它的分配流程是這樣的應(yīng)用調(diào)用ANativeWindow::dequeueBuffer()SurfaceFlinger通過(guò)BufferQueue向GraphicBufferAllocator請(qǐng)求bufferGraphicBufferAllocator調(diào)用ION分配內(nèi)存ION返回DMA-BUF fd封裝成GraphicBuffer對(duì)象GraphicBuffer通過(guò)Binder跨進(jìn)程傳遞給應(yīng)用我個(gè)人習(xí)慣在調(diào)試時(shí)先確認(rèn)GraphicBuffer的格式和尺寸是否正確。MTK8678支持多種像素格式比如RGBA_8888、RGBX_8888、NV12等。如果格式不匹配顯示硬件會(huì)直接罷工。調(diào)試技巧在dumpsys SurfaceFlinger的輸出中可以看到每個(gè)Layer的buffer信息。重點(diǎn)關(guān)注buffer的width、height、format和usage flags。GraphicBuffer還有一個(gè)重要屬性叫usage flags。它告訴ION這塊內(nèi)存要用來(lái)做什么GRALLOC_USAGE_HW_RENDER給GPU渲染用GRALLOC_USAGE_HW_COMPOSER給顯示合成器用GRALLOC_USAGE_HW_VIDEO_ENCODER給視頻編碼器用GRALLOC_USAGE_SW_READ_OFTENCPU頻繁讀取這些flags會(huì)影響內(nèi)存的cache策略和物理位置。比如HW_COMPOSER通常要求uncached內(nèi)存因?yàn)轱@示控制器不經(jīng)過(guò)CPU cache。15.3 Fence同步機(jī)制別讓畫面撕裂多屏顯示最頭疼的問題是什么同步。你想想看GPU在渲染第N幀顯示控制器在讀取第N-1幀如果兩者同時(shí)操作同一塊buffer畫面就會(huì)撕裂。Fence就是用來(lái)解決這個(gè)問題的。它本質(zhì)上是一個(gè)內(nèi)核態(tài)的同步原語(yǔ)用文件描述符表示。Fence有兩種狀態(tài)signaled操作已完成可以安全使用bufferunsignaled操作還在進(jìn)行中別碰buffer典型的同步流程是這樣的GPU開始渲染buffer A創(chuàng)建一個(gè)release fenceGPU渲染完成后signal這個(gè)fence顯示控制器等待這個(gè)fence signaled后才開始讀取buffer A顯示控制器讀取完成后創(chuàng)建另一個(gè)release fenceGPU等待這個(gè)fence才能把新數(shù)據(jù)寫入buffer A我曾經(jīng)在MTK8678上遇到一個(gè)詭異的問題雙屏顯示時(shí)副屏偶爾卡住不動(dòng)。查了三天發(fā)現(xiàn)是Fence超時(shí)導(dǎo)致的。主屏的release fence一直沒signal副屏的acquire fence等不到就卡死了。避坑指南我曾經(jīng)因?yàn)镕ence超時(shí)時(shí)間設(shè)置太短導(dǎo)致正常操作也被誤判為超時(shí)。建議把超時(shí)時(shí)間設(shè)為5秒以上調(diào)試階段甚至可以設(shè)到10秒。在代碼層面Fence的操作主要通過(guò)sync_file接口// 創(chuàng)建fence int fence_fd sync_file_create(gpu_render_fence); // 等待fence struct sync_fence_info_data *info; int ret ioctl(fence_fd, SYNC_IOC_FENCE_INFO, info); // 合并多個(gè)fence int merged_fd sync_file_merge(merged_fence, fence1_fd, fence2_fd);15.4 BufferQueue生產(chǎn)者-消費(fèi)者模型BufferQueue是Android顯示系統(tǒng)的核心數(shù)據(jù)結(jié)構(gòu)。它實(shí)現(xiàn)了生產(chǎn)者-消費(fèi)者模型讓應(yīng)用生產(chǎn)者和SurfaceFlinger消費(fèi)者能高效地交換buffer。BufferQueue的核心成員成員作用mSlots[]存儲(chǔ)所有buffer的數(shù)組默認(rèn)64個(gè)slotmQueue已填充好的buffer隊(duì)列等待消費(fèi)者處理mFreeSlots空閑slot列表mActiveBuffers當(dāng)前正在被生產(chǎn)或消費(fèi)的buffer它的工作流程說(shuō)白了就是三個(gè)操作dequeueBuffer生產(chǎn)者申請(qǐng)一個(gè)空閑bufferqueueBuffer生產(chǎn)者把填充好的buffer放入隊(duì)列acquireBuffer消費(fèi)者從隊(duì)列取出bufferreleaseBuffer消費(fèi)者用完buffer后歸還多屏場(chǎng)景下每個(gè)顯示設(shè)備都有自己的BufferQueue。MTK8678支持三個(gè)屏幕同時(shí)顯示那就需要三個(gè)獨(dú)立的BufferQueue實(shí)例。這里有個(gè)坑BufferQueue的深度即mQueue中最多能放幾個(gè)buffer會(huì)影響延遲。深度太小生產(chǎn)者容易阻塞深度太大畫面延遲會(huì)增加。我一般建議設(shè)成2或3兼顧流暢度和延遲。核心要點(diǎn)BufferQueue Fence ION這三者配合構(gòu)成了Android顯示系統(tǒng)的完整數(shù)據(jù)通路。ION負(fù)責(zé)「在哪里放數(shù)據(jù)」Fence負(fù)責(zé)「什么時(shí)候可以動(dòng)數(shù)據(jù)」BufferQueue負(fù)責(zé)「數(shù)據(jù)怎么流轉(zhuǎn)」。15.5 實(shí)戰(zhàn)經(jīng)驗(yàn)多屏顯示的內(nèi)存優(yōu)化最后分享一個(gè)我在MTK8678項(xiàng)目中的優(yōu)化經(jīng)驗(yàn)。當(dāng)時(shí)客戶要求三屏同時(shí)顯示1080p視頻每個(gè)屏幕60fps。算一下1920×1080×4字節(jié)×3屏×60fps ≈ 1.5GB/s的帶寬。這還沒算GPU和CPU的訪問。內(nèi)存帶寬很快就成了瓶頸。我做了幾件事使用AFBC壓縮ARM的幀緩沖壓縮技術(shù)可以減少30%-50%的帶寬調(diào)整ION heap分配策略把顯示buffer放在專用的carveout內(nèi)存里避免和系統(tǒng)內(nèi)存爭(zhēng)搶優(yōu)化Fence等待邏輯減少不必要的同步等待讓流水線更緊湊BufferQueue深度調(diào)優(yōu)從默認(rèn)的1改成2讓GPU和顯示控制器能并行工作優(yōu)化后帶寬占用降到了800MB/s左右三屏播放流暢無(wú)卡頓。嗯這一章的內(nèi)容就到這里。緩沖區(qū)管理是顯示驅(qū)動(dòng)的核心也是問題最多的地方。建議你在實(shí)際調(diào)試時(shí)先從ION分配開始排查再看Fence同步最后檢查BufferQueue的狀態(tài)。按這個(gè)順序來(lái)能省不少時(shí)間。