簡介針對 Android 平臺上將 OpenGLES3 紋理 ID 渲染到 ImageReader Surface 的需求這份資源以完整可運(yùn)行的 Android 工程形式提供了從紋理加載、EGLDisplay 虛擬屏幕綁定、eglSwapBuffers 緩沖交換到 ImageReader 回調(diào)讀取數(shù)據(jù)并生成 Bitmap 的端到端參考實(shí)現(xiàn)。源碼按功能拆分結(jié)構(gòu)清晰適合需要對接相機(jī)/視頻幀數(shù)據(jù)或做離屏渲染的 Android 中高級開發(fā)者參考。包含 89 個(gè)文件壓縮包僅 879KB。工程采用 Android Gradle 標(biāo)準(zhǔn)結(jié)構(gòu)java 文件承載渲染線程與回調(diào)核心邏輯xml 完成界面布局及清單配置gradle 與 properties 管理依賴和構(gòu)建參數(shù)webp 等用于界面輔助展示bin、lock 等則屬于工程編譯緩存。代碼中對 EGL 環(huán)境搭建、紋理加載、Surface 數(shù)據(jù)通路和 onImageAvailable 取幀等關(guān)鍵節(jié)點(diǎn)均有直接體現(xiàn)便于對照項(xiàng)目進(jìn)行流程梳理、移植或性能調(diào)優(yōu)。目前已有 731 人學(xué)習(xí)/下載適合正在鉆研 Android 圖形管線、希望打通 OpenGLES 與 Surface 之間數(shù)據(jù)鏈路的開發(fā)者。1. 為什么要把 GL_TEXTURE_2D 紋理 ID 渲染到 ImageReader 的 Surface 上在 Android 圖形鏈路里紋理 ID 往往是離屏渲染鏈尾部的產(chǎn)物FBO 完成特效合成、第三方 SDK 輸出一幀經(jīng)過 GL_TEXTURE_2D 的紋理下一步要么送編碼器要么給系統(tǒng)拍下來。但紋理 ID 只是 GPU 里的一個(gè)“名字”MediaCodec、ImageReader 不認(rèn)識它它們認(rèn)識的是 Surface——或者說得更準(zhǔn)確一點(diǎn)認(rèn)識一塊 BufferQueue 的生產(chǎn)端。把 GL_TEXTURE_2D 紋理 ID 畫到 ImageReader 提供的 Surface 上本質(zhì)是在 GPU 里把一張紋理完整搬一次家完成一次低成本的顏色緩沖交換而不是把圖像數(shù)據(jù)讀回 CPU 再寫出去。這個(gè)需求常見于視頻編輯、老照片修復(fù)、平臺美顏抽幀和低延遲串流。它比 glReadPixels 高效得多比使用 SurfaceTexture 多一層可讀性也比直接向 MediaCodec 編碼器 Surface 輸出更能兼容后續(xù)的 CPU 讀幀邏輯。適合兩類人一類是想把 OpenGL ES 3.0 離屏渲染結(jié)果交給系統(tǒng)編碼、錄屏、拍照的工程師另一類是手頭有一個(gè)來自第三方庫的 GL_TEXTURE_2D 紋理 ID不知道如何不碰像素就轉(zhuǎn)型成 Android 可消費(fèi)幀的人。這篇文章按我的慣用方案把 EGL 環(huán)境、ImageReader Surface 初始化、渲染代碼、同步柵欄和編碼器接入全部拆開。2. 用 EGL 把 ImageReader 的 Surface 接進(jìn) OpenGL ES 3.0先解決“畫到哪”幾乎所有 Android 開發(fā)者看到 ImageReader 的第一反應(yīng)都是調(diào)onImageAvailable后拿Image對象逐一讀 Plane。這個(gè)思路只覆蓋了消費(fèi)端忽略了 ImageReader 另一個(gè)更重要的身份它的getSurface()返回值是一個(gè)標(biāo)準(zhǔn) Surface而 Surface 背后是 BufferQueue 的生產(chǎn)端。換句話說GPU 可以把它當(dāng)作一塊可繪制的緩沖區(qū)域只要 EGL 愿意認(rèn)領(lǐng)這塊 Surface。2.1 ImageReader 的 Surface 不是 View渲染路徑完全不同TextureView、SurfaceView 的 Surface 與 ImageReader 的 Surface 在底層都關(guān)聯(lián) BufferQueue但在 API 表現(xiàn)上差異很大。SurfaceView 上可以用 OpenGL 繪制TextureView 本身是 View 層級里的一個(gè)圖層而 ImageReader 的 Surface 只能作為 ImageReader 的消費(fèi)緩沖入口。它沒有窗口句柄也不能被 attach 到窗口系統(tǒng)唯一的接入方式就是通過 EGL 的eglCreateWindowSurface。很多人在這一步選錯(cuò) API把 ImageReader 的 Surface 當(dāng) SurfaceTexture 傳進(jìn)setPreviewTexture或者嘗試Canvas.lockCanvas后手動編解碼都繞了遠(yuǎn)路。常規(guī)做法是創(chuàng)建 ImageReader取出其 Surface然后在 EGL 層創(chuàng)建 EGLSurface之后所有 GL 繪制命令都會落到這塊 Surface 上eglSwapBuffers之后 ImageReader 就能異步收到一張全新 Image。下面是四種常見 Surface 消費(fèi)者的對比對象可被 GL 繪制能否 CPU 讀像素典型用途SurfaceView 的 Surface可以需要額外處理游戲、視頻播放TextureView 的 SurfaceTexture可以需要額外處理相機(jī)預(yù)覽、UI 合成MediaCodec 的 input Surface可以不可以直接讀硬編碼輸入ImageReader 的 Surface可以通過 EGL 接入可以且是設(shè)計(jì)目標(biāo)拍幀、讀紋理、YUV 轉(zhuǎn)換2.2 EGL Surface 與 ImageReader 的像素格式必須匹配EGL 是 OpenGL ES 和窗口系統(tǒng)之間的橋梁。把 ImageReader 的 Surface 接進(jìn)來核心是eglGetDisplay、eglInitialize、eglChooseConfig、eglCreateWindowSurface這條鏈路。其中最容易出問題的是 EGLConfig 的選擇ImageReader 的緩沖格式由構(gòu)造時(shí)的 pixelFormat 決定而 EGLWindowSurface 創(chuàng)建時(shí)不能直接指定格式它必須從 EGLConfig 中推導(dǎo)。如果 EGLConfig 的 RGBA 位數(shù)與 ImageReader 不一致輕則色彩偏移重則eglCreateWindowSurface直接返回EGL_BAD_MATCH。以下是我在實(shí)際項(xiàng)目里穩(wěn)定使用的 EGL 初始化片段EGLDisplay display EGL14.eglGetDisplay(EGL14.EGL_DEFAULT_DISPLAY); int[] version new int[2]; EGL14.eglInitialize(display, version, 0, version, 1); int[] configAttrs { EGL14.EGL_RENDERABLE_TYPE, EGL14.EGL_OPENGL_ES2_BIT | 0x0040, // 0x0040 對應(yīng) EGL_OPENGL_ES3_BIT EGL14.EGL_RED_SIZE, 8, EGL14.EGL_GREEN_SIZE, 8, EGL14.EGL_BLUE_SIZE, 8, EGL14.EGL_ALPHA_SIZE, 8, EGL14.EGL_NONE }; EGLConfig[] configs new EGLConfig[1]; int[] numConfigs new int[1]; EGL14.eglChooseConfig(display, configAttrs, 0, configs, 0, 1, numConfigs, 0); int[] surfaceAttrs { EGL14.EGL_NONE }; EGLSurface eglSurface EGL14.eglCreateWindowSurface(display, configs[0], imageReaderSurface, surfaceAttrs, 0);這段代碼里第二行的0x0040很關(guān)鍵。Android 的 EGL 頭文件對EGL_OPENGL_ES3_BIT_KHR的定義是 0x0040而EGL14.EGL_OPENGL_ES2_BIT的值是 0x0004兩者并不相同。如果只寫入 ES2 bit某些機(jī)型上依然能創(chuàng)建成功但后續(xù)eglCreateContext請求的 OpenGL ES 3.0 context 與 EGLConfig 的 renderable type 不匹配會得到EGL_BAD_MATCH或EGL_BAD_CONFIG。2.3 共享上下文紋理 ID 在新 EGLContext 里“仍然有效”EGLSurface 創(chuàng)建完成后下一步是創(chuàng)建 EGLContext。如果你已經(jīng)有另一個(gè)線程在渲染紋理比如相機(jī)模塊或第三方濾鏡庫在某個(gè) GL 線程上生成了紋理 ID那么新的渲染線程必須創(chuàng)建共享上下文。EGLContext 默認(rèn)擁有獨(dú)立的資源命名空間紋理 ID 只是一個(gè)小整數(shù)在不同 context 里如果不同步它在 GL 側(cè)會被當(dāng)作“不存在的對象”即使調(diào)用glBindTexture也不會報(bào)錯(cuò)繪制結(jié)果只會是黑色。創(chuàng)建共享上下文的方法是先拿到當(dāng)前線程的活躍 contextEGL14.eglGetCurrentContext()然后把它傳給eglCreateContext的第二個(gè)參數(shù)。這樣兩個(gè) context 共享紋理、FBO 等對象紋理 ID 才能跨線程使用。但如果原紋理所在線程根本沒有 EGLContext而是通過其他方式生成的那問題就不一樣了——那種情況通常要用擴(kuò)展接口導(dǎo)出內(nèi)存句柄這里不展開。3. 渲染 GL_TEXTURE_2D 到 ImageReader Surface 的完整實(shí)現(xiàn)有了 EGL Surface 和共享上下文渲染核心就只剩三件事創(chuàng)建 Shader 程序、綁定紋理、提交繪制。這一章給出可以直接抄進(jìn)工程的 Java 實(shí)現(xiàn)用的是 OpenGL ES 3.0 API沒有引入任何第三方依賴Android Studio 里新建工程即可運(yùn)行。3.1 初始化 EGL 環(huán)境與創(chuàng)建 EGLSurface 的代碼把上一章的邏輯收攏成一個(gè)初始化方法注意imageReader必須提前創(chuàng)建并且寬高要與紋理一致public void init(ImageReader imageReader, EGLContext sharedContext, int textureId) { mImageReader imageReader; mTextureId textureId; mWidth imageReader.getWidth(); mHeight imageReader.getHeight(); mDisplay EGL14.eglGetDisplay(EGL14.EGL_DEFAULT_DISPLAY); int[] version new int[2]; EGL14.eglInitialize(mDisplay, version, 0, version, 1); int[] configAttrs { EGL14.EGL_RENDERABLE_TYPE, EGL14.EGL_OPENGL_ES2_BIT | 0x0040, EGL14.EGL_RED_SIZE, 8, EGL14.EGL_GREEN_SIZE, 8, EGL14.EGL_BLUE_SIZE, 8, EGL14.EGL_ALPHA_SIZE, 8, EGL14.EGL_NONE }; EGLConfig[] configs new EGLConfig[1]; int[] numConfigs new int[1]; EGL14.eglChooseConfig(mDisplay, configAttrs, 0, configs, 0, 1, numConfigs, 0); mSurface EGL14.eglCreateWindowSurface(mDisplay, configs[0], imageReader.getSurface(), new int[]{EGL14.EGL_NONE}, 0); int[] contextAttrs { EGL14.EGL_CONTEXT_CLIENT_VERSION, 3, EGL14.EGL_NONE }; mContext EGL14.eglCreateContext(mDisplay, configs[0], sharedContext, contextAttrs, 0); EGL14.eglMakeCurrent(mDisplay, mSurface, mSurface, mContext); setupShaders(); }參數(shù)說明sharedContext是紋理來源線程的 EGLContext如果傳入的 textureId 就在當(dāng)前線程創(chuàng)建這里可以直接傳EGL14.EGL_NO_CONTEXT。EGL_CONTEXT_CLIENT_VERSION, 3決定創(chuàng)建的是 OpenGL ES 3.0 context注意 EGLConfig 里必須帶上 ES3 bit否則這里報(bào)錯(cuò)。eglMakeCurrent的作用是把 EGLSurface 綁定到當(dāng)前線程的渲染目標(biāo)之后所有 GLES3 指令都作用于這塊 ImageReader Surface。3.2 Shader 與繪制命令如何用三角形覆蓋紋理ImageReader 的 Surface 是一塊矩形緩沖渲染時(shí)最常見的方式是畫兩個(gè)三角形拼成一個(gè)全屏四邊形。頂點(diǎn)著色器負(fù)責(zé)接收頂點(diǎn)坐標(biāo)和紋理坐標(biāo)片段著色器負(fù)責(zé)從 GL_TEXTURE_2D 上采樣顏色。頂點(diǎn)著色器#version 300 es layout(location 0) in vec4 aPosition; layout(location 1) in vec2 aTexCoord; out vec2 vTexCoord; void main() { gl_Position aPosition; vTexCoord aTexCoord; }片段著色器#version 300 es precision mediump float; uniform sampler2D uTexture; in vec2 vTexCoord; out vec4 fragColor; void main() { fragColor texture(uTexture, vTexCoord); }這個(gè)著色器沒有做任何顏色變換和矩陣運(yùn)算保留紋理原始顏色。sampler2D默認(rèn)綁定紋理單元 0所以繪制前不需要顯式glActiveTexture只要把紋理 ID bind 到GL_TEXTURE_2D上即可。如果將來要接入 OES 外部紋理需要將采樣器類型換成samplerExternalOES同時(shí)把紋理目標(biāo)改成GL_TEXTURE_EXTERNAL_OES與本文標(biāo)題鎖定的 GL_TEXTURE_2D 場景不是同一套配置。3.3 draw 幀的調(diào)用時(shí)機(jī)與紋理參數(shù)頂點(diǎn)數(shù)據(jù)和繪制代碼private void drawFrame() { EGL14.eglMakeCurrent(mDisplay, mSurface, mSurface, mContext); GLES30.glViewport(0, 0, mWidth, mHeight); GLES30.glUseProgram(mProgram); GLES30.glBindBuffer(GLES30.GL_ARRAY_BUFFER, mVbo); GLES30.glEnableVertexAttribArray(0); GLES30.glVertexAttribPointer(0, 3, GLES30.GL_FLOAT, false, 5 * 4, 0); GLES30.glEnableVertexAttribArray(1); GLES30.glVertexAttribPointer(1, 2, GLES30.GL_FLOAT, false, 5 * 4, 3 * 4); // 關(guān)鍵綁定紋理 ID 到 GL_TEXTURE_2D 目標(biāo) GLES30.glBindTexture(GLES30.GL_TEXTURE_2D, mTextureId); GLES30.glDrawArrays(GLES30.GL_TRIANGLE_STRIP, 0, 4); EGL14.eglSwapBuffers(mDisplay, mSurface); }glVertexAttribPointer(1, 2, ..., 5 * 4, 3 * 4)表示頂點(diǎn)數(shù)據(jù)每 5 個(gè) float 為一組前 3 個(gè)是位置后 2 個(gè)是紋理坐標(biāo)stride 為 20 字節(jié)。繪制的 4 個(gè)頂點(diǎn)可以用(-1,-1,0,0,0)到(1,1, ..., 1,1)的三角形帶覆蓋全屏。紋理綁定后建議檢查紋理對象的過濾參數(shù)。外部庫生成的紋理 ID 不一定設(shè)置了GL_TEXTURE_MIN_FILTER如果默認(rèn)值是GL_NEAREST_MIPMAP_LINEAR而紋理沒有生成 mipmap畫面會出現(xiàn)模糊接縫或黑邊?？稍赿rawFrame里每次綁定時(shí)執(zhí)行一次glTexParameteriGLES30.glTexParameteri(GLES30.GL_TEXTURE_2D, GLES30.GL_TEXTURE_MIN_FILTER, GLES30.GL_LINEAR); GLES30.glTexParameteri(GLES30.GL_TEXTURE_2D, GLES30.GL_TEXTURE_MAG_FILTER, GLES30.GL_LINEAR); GLES30.glTexParameteri(GLES30.GL_TEXTURE_2D, GLES30.GL_TEXTURE_WRAP_S, GLES30.GL_CLAMP_TO_EDGE); GLES30.glTexParameteri(GLES30.GL_TEXTURE_2D, GLES30.GL_TEXTURE_WRAP_T, GLES30.GL_CLAMP_TO_EDGE);GL_CLAMP_TO_EDGE可以避免紋理邊緣采樣到透明或黑色區(qū)域。如果紋理 ID 來源是最新一幀相機(jī) YUV 轉(zhuǎn)成的 GL_TEXTURE_2D換幀時(shí) GPU 和 CPU 之間可能還有未完成寫入需要在 draw 之前插入glFinish()或使用同步柵欄否則第一幀可能出現(xiàn)紋素錯(cuò)亂。4. 共享上下文、同步與格式最常出問題的 3 個(gè)位置EGL 初始化完成后渲染邏輯本身很短真正消耗時(shí)間的是排錯(cuò)。這一章只討論最常導(dǎo)致黑屏、花屏、綠屏的三個(gè)因素上下文共享失效、GPU 繪制與 ImageReader 消費(fèi)之間的時(shí)序、像素格式不匹配。4.1 紋理 ID 不是“全局身份證”必須用共享上下文許多人拿到外部傳入的 textureId 后既不詢問它的 EGLContext也不做共享直接在新線程里glBindTexture后繪制得到的結(jié)果是黑屏但不報(bào)錯(cuò)。原因是 GL 紋理 ID 在 context 的資源表里只是一個(gè)索引新 context 里沒有這張表的注冊信息。共享上下文的創(chuàng)建方法在 2.3 節(jié)已經(jīng)說明這里補(bǔ)充一個(gè)常見誤用只共享 EGLDisplay卻不共享 EGLContext這種代碼在開發(fā)機(jī)上偶爾能跑因?yàn)槟承?qū)動廠商把資源表做成了全局的但壓測和真機(jī)更換設(shè)備后立刻崩潰。推薦的做法是在紋理生產(chǎn)方初始化時(shí)記錄一個(gè)全局變量sSharedContext EGL14.eglGetCurrentContext();然后在渲染線程 init 時(shí)把它作為創(chuàng)建參數(shù)傳進(jìn)去。如果紋理生產(chǎn)方?jīng)]有 EGLContext直接傳EGL_NO_CONTEXT。注意共享 context 只共享對象不共享 GL 狀態(tài)機(jī)所以紋理參數(shù)、Shader、VBO 都要在新 context 里重新設(shè)置。4.2 EGL 渲染先行ImageReader 異步消費(fèi)同步在哪做ImageReader 的 Image 是異步到達(dá)的onImageAvailable觸發(fā)時(shí)并不代表 GPU 繪制已經(jīng)完成。eglSwapBuffers只表示緩沖被送交 BufferQueue不保證 GPU 已結(jié)束渲染。在部分設(shè)備上ImageReader 拿到幀時(shí)紋理內(nèi)容還處于可寫狀態(tài)后面消費(fèi)線程讀取時(shí)會出現(xiàn)半幀或內(nèi)容撕裂。如果追求穩(wěn)妥最直接的做法是在eglSwapBuffers后插入 GPU 等待EGL14.eglSwapBuffers(mDisplay, mSurface); // 等待 GPU 完成所有繪制指令確保 ImageReader 能拿到已完成的幀 GLES30.glFinish();glFinish會讓 CPU 阻塞直到 buffer 可復(fù)用。對于 30fps 的抽幀需求影響不大但如果要跑 60fps建議換成 fenceEGLSyncKHR fence EGLExt.eglCreateSyncKHR(mDisplay, EGLExt.EGL_SYNC_NATIVE_FENCE_ANDROID, new int[]{ EGLExt.EGL_SYNC_NATIVE_FENCE_ANDROID, 0, EGL14.EGL_NONE }, 0); // 從 fence 里取出 native fence fd傳給消費(fèi)端等待完成后 close這是 Android 推薦的低延遲方案把 fence fd 一并傳給消費(fèi)者而不是讓 CPU 在 GPU 完成后才繼續(xù)跑。如果當(dāng)前只做總結(jié)輸出glFinish簡單不易錯(cuò)。4.3 像素格式與 Size 對齊ImageReader 不是隨便創(chuàng)建的ImageReader 的構(gòu)造參數(shù)pixelFormat必須與 EGLConfig 的 RGBA 位數(shù)一致否則畫面顏色會偏移或者完全失真。RGB_565、RGBA_8888、YUV_420_888 在 BufferQueue 里是不同格式EGL 無法對一個(gè) YUV 格式的 Surface 直接執(zhí)行 RGBA 的渲染操作。標(biāo)題鎖定的場景是 OpenGL ES 3.0 輸出所以 ImageReader 通常這樣創(chuàng)建mImageReader ImageReader.newInstance(width, height, PixelFormat.RGBA_8888, 2);注意最后那個(gè)maxImages參數(shù)。如果設(shè)成 1渲染頻率高時(shí)消費(fèi)者來不及 closeImageReader 會停止向 BufferQueue 請求新緩沖eglSwapBuffers會卡死設(shè)成 4 又會成倍占用內(nèi)存。2 是絕大多數(shù)抽幀和編碼場景下的默認(rèn)值。寬度和高度也需要對齊。給 ImageReader 傳奇數(shù)尺寸部分設(shè)備在eglCreateWindowSurface階段就失敗部分在ImageReader.getPlanes()階段因?yàn)?stride 和 width 不一致返回錯(cuò)誤的 Buffer 布局。常規(guī)做法是先對尺寸做對齊再創(chuàng)建int alignedWidth (width 15) / 16 * 16; int alignedHeight (height 15) / 16 * 16;紋理渲染到對齊后的 Surface 上如果 UVC 相機(jī)原始尺寸是 640x480對齊后依然是這兩個(gè)數(shù)字因?yàn)?16 的倍數(shù)對齊不會改變這兩個(gè)值。5. 接入 MediaCodec 編碼器與 30fps 幀率控制一個(gè)可收尾的技巧渲染到 ImageReader 的最終目的大多離不開編碼。一個(gè)更高效的做法是讓 OpenGL ES 3.0 直接繪制到 MediaCodec 編碼器的輸入 Surface省掉 ImageReader 這個(gè)中間層。但有時(shí)業(yè)務(wù)需要同時(shí)保留 CPU 讀幀能力那就必須雙 Surface 并行。5.1 如果你要編碼別讓 ImageReader 成為中間跳板常見錯(cuò)誤寫法是先渲染到 ImageReader再在onImageAvailable里把Image的 buffer 拷貝出來通過MediaCodec.queueInputBuffer喂給編碼器。這不叫 GPU 渲染等于把 GPU 畫的幀又回到了 CPU再交給編碼器性能損耗巨大。如果不需要 CPU 讀幀直接創(chuàng)建編碼器輸入 SurfacemEncoder MediaCodec.createEncoderByType(video/avc); MediaFormat format MediaFormat.createVideoFormat(video/avc, alignedWidth, alignedHeight); format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface); format.setInteger(MediaFormat.KEY_BIT_RATE, 4_000_000); format.setInteger(MediaFormat.KEY_FRAME_RATE, 30); format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 1); mEncoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); Surface encoderSurface mEncoder.createInputSurface(); mEncoder.start();然后把encoderSurface傳給第 3 章的init方法ImageReader 那條路徑留作旁路抽幀。5.2 兩個(gè) EGLSurface 交替渲染同時(shí)保留讀像素能力為了同時(shí)滿足編碼和讀幀可以創(chuàng)建兩個(gè) EGLSurface一個(gè)綁定 ImageReader一個(gè)綁定編碼器輸入 Surface。每次drawFrame時(shí)按當(dāng)前消費(fèi)者選擇目標(biāo)EGL14.eglMakeCurrent(mDisplay, chooseSurface(), chooseSurface(), mContext); GLES30.glFinish(); EGL14.eglSwapBuffers(mDisplay, chooseSurface());chooseSurface()根據(jù)當(dāng)前是否處于檢測階段返回對應(yīng) EGLSurface。這樣編碼鏈路的每一幀都是 GPU 直接寫入不經(jīng)過 CPUImageReader 路徑只在真正需要抽幀的瞬間才切換過去。幀率控制可以用Choreographer在 VSYNC 信號上回調(diào)或者用循環(huán)控制long startTime System.nanoTime(); long frameInterval 33_000_000L; // 30fps單位納秒 while (running) { drawFrame(); long elapsed System.nanoTime() - startTime; if (elapsed frameInterval) { SystemClock.sleep((frameInterval - elapsed) / 1_000_000L); } startTime System.nanoTime(); }SystemClock.sleep比Thread.sleep更精確它不受 Java 層時(shí)間調(diào)整影響適合在 GL 線程里做節(jié)奏控制。5.3 用 adb 驗(yàn)證 ImageReader 是否真的在刷新接入完成后如果無法確定 ImageReader 是否收到幀可以用 adb 查看 SurfaceFlinger 的圖層狀態(tài)。先列出所有 Surface 名稱找到 ImageReader 對應(yīng)的項(xiàng)adb shell dumpsys SurfaceFlinger --list對比渲染前后同一 Surface 的z-order或visible region變化可以確認(rèn)是否提交了緩沖。但要注意一點(diǎn)ImageReader 表面在eglSwapBuffers后不會永遠(yuǎn)可見如果消費(fèi)者沒有及時(shí) close 圖像Surface 圖層可能被 SurfaceFlinger 判定為無內(nèi)容而在--list中消失。遇到這種情況優(yōu)先檢查onImageAvailable是否執(zhí)行以及Image.close()是否及時(shí)調(diào)用。本文還有配套的精品資源點(diǎn)擊獲取